Hashrate, Shares, and Reject Rates: The Metrics That Decide Your Earnings

Understand the three key metrics that determine your browser mining revenue. Learn how hashrate, share acceptance, and reject rates impact your earnings on Earnify and how to optimize them.

If you’re running a website and monetizing with browser-based cryptocurrency mining, you’ve probably glanced at a dashboard full of numbers: hashrate, shares, reject rate. These aren’t just vanity metrics—they directly control how much DOGE (or other CPU-mineable coins) your visitors generate for you. A 10% difference in reject rate can wipe out a month’s revenue, while understanding your true hashrate lets you forecast earnings with precision.

In this guide, we’ll break down each metric, show you how they interact, and give you actionable strategies to optimize them. Along the way, we’ll reference real-world data from Earnify’s browser mining platform, including benchmarks from MinotaurX—the algorithm that powers Earnify’s zero-server architecture.

What Is Hashrate and Why Does It Matter?

Hashrate is the speed at which a miner (in this case, a visitor’s browser) guesses solutions to a cryptographic puzzle. It’s measured in hashes per second (H/s). Each guess is a potential block solution; the more guesses per second, the higher the probability of finding a valid share and earning a reward.

In browser mining, hashrate depends on the visitor’s CPU, the number of threads allocated, and the efficiency of the mining code. Earnify uses WebAssembly (WASM) compiled from optimized C++ mining libraries, achieving roughly 70% of native CPU speed—a significant leap over pure JavaScript miners that often hover below 40%.

How Browser Mining Hashrate Differs from ASIC/GPU Mining

ASICs and GPUs dominate traditional mining because they’re purpose-built for parallel hashing. A single ASIC can deliver terahashes per second. Browser mining, by contrast, runs on general-purpose CPUs inside a sandboxed environment. The key differences:

Browser mining’s strength isn’t raw speed—it’s scale. A site with 10,000 daily visitors, each contributing 1.5 kH/s, aggregates to 15 MH/s without any hardware investment. That’s the power of distributed CPU mining.

Shares: The Proof of Your Work

In pooled mining, a “share” is a proof-of-work unit that demonstrates a miner has done a certain amount of computational work. Shares are submitted to the mining pool, which validates them and assigns a proportional reward when the pool finds a block. Think of shares as lottery tickets: more tickets (shares) increase your chance of winning a piece of the block reward.

Accepted vs. Rejected Shares: The Good, the Bad, and the Stale

Not all shares are created equal. The pool classifies each submission:

• Accepted: A valid share that meets the current difficulty target and arrives before the pool moves to the next block. These earn you rewards.
• Rejected (Stale): A valid share that arrived too late—the pool had already started working on a new block. Stale shares earn nothing.
• Rejected (Invalid): The share doesn’t meet the network’s difficulty rules, often due to corrupted computation or a misconfigured miner. Invalid shares can even get you banned from some pools.

The ratio of accepted to total shares is your acceptance rate. A 98% acceptance rate means 2% of your work is wasted. While that sounds small, over thousands of visitors, that 2% can compound into meaningful lost revenue.

Reject Rates: The Silent Earnings Killer

Reject rate is the percentage of submitted shares that are rejected (stale + invalid). It’s the single most overlooked metric in browser mining, yet it directly erodes your effective hashrate. If your raw hashrate is 1,870 H/s but your reject rate is 5%, your effective hashrate—the speed at which you earn—drops to 1,776 H/s. That’s a 5% pay cut for the same visitor resources.

Common Causes of High Reject Rates in Browser Mining

Browser mining introduces unique latency challenges that hardware miners rarely face:

• Network latency: Visitors on mobile networks or distant geographic regions can have 200–500ms round-trip times to the pool. Every millisecond matters when block times are short.
• Proxy overhead: Many browser mining solutions route traffic through a centralized server, adding an extra hop. Earnify’s zero-server architecture eliminates this by connecting the browser directly to the mining pool via WebSocket Stratum.
• CPU throttling: If the visitor’s device thermal-throttles, the miner may produce shares slower than the pool’s difficulty window, causing some to arrive stale.
• Pool difficulty settings: If the pool’s share difficulty is too high for the visitor’s hashrate, they may submit shares infrequently, increasing the chance of stales.

Visitor Browser (Web Worker + WASM)
        |
        | WebSocket Stratum (direct)
        v
   Mining Pool
        |
        v
   Blockchain (DOGE)

Earnify Zero-Server Path: No intermediate proxy

Earnify’s direct-to-pool design keeps reject rates below 2% for the majority of users. In contrast, proxy-based solutions often see reject rates of 8–12% due to the extra latency and server-side queuing.

How to Optimize These Metrics for Maximum Revenue

Now that you understand the metrics, here’s how to move the needle:

Earnify’s Approach: Zero-Server, Low Latency

Earnify’s architecture is purpose-built to minimize reject rates. By using Web Workers and WASM, mining runs in a separate thread, keeping the UI responsive and preventing throttling. The script automatically detects the optimal number of threads (navigator.hardwareConcurrency - 1) and connects directly to the pool via WebSocket Stratum—no middleman. This reduces round-trip time and eliminates a major source of stale shares.

Additionally, Earnify’s pool selection algorithm routes visitors to the geographically closest pool node, further cutting latency. According to Earnify’s internal data, this reduces average reject rate by 1.5 percentage points compared to a single-pool setup.

For publishers, the takeaway is clear: choose a mining solution that prioritizes low latency. Deployment is as simple as adding a single script tag:

Other optimizations you can control:

• Visitor segmentation: Offer higher thread counts to desktop users and lower counts to mobile visitors to balance hashrate and user experience.
• Session duration: Longer visits yield more shares. Integrate mining into pages where users spend time (articles, tools, dashboards).
• Pool difficulty tuning: Some pools allow you to set a fixed share difficulty. For low-hashrate browsers, a lower difficulty can reduce variance and stale rates.

FAQs

What is a good reject rate for browser mining?
A reject rate below 2% is excellent and indicates minimal latency and correct configuration. Anything above 5% should be investigated—it can reduce your effective earnings by 10–15%. Earnify’s direct-to-pool architecture typically keeps reject rates under 2% for visitors in the same continent as the pool.

How does hashrate affect my earnings?
Earnings scale linearly with hashrate: double the hashrate, double the shares, double the reward (all else equal). However, because browser miners share CPU time with other tasks, a 20% increase in raw hashrate might only yield a 15% increase in accepted shares if it causes thermal throttling and higher reject rates. Balance is key.

Can I improve my visitors’ hashrate?
You can’t upgrade their hardware, but you can optimize the mining configuration. Use the maximum number of threads without causing UI lag, ensure the mining script loads early, and avoid running heavy animations simultaneously. Some publishers see a 5–10% hashrate boost simply by moving the miner to a dedicated Web Worker (which Earnify does by default).

Ready to turn your traffic into DOGE with industry-leading low reject rates? Start mining with Earnify today—deploy in one line of code and watch your dashboard fill with accepted shares.

Frequently Asked Questions