Revenue Strategy October 28, 2026 8 min read

Your Browser Mining Launch Checklist: 15 Steps Before Going Live

By Roman Noodles, Founder of Earnify · Updated October 28, 2026

Launch browser mining without the bottlenecks. This 15-step checklist covers consent, thread tuning, relay stability, and earnings benchmarks publishers need before going live.

Most publishers treat browser-based cryptocurrency mining like a banner ad — paste a snippet, hit publish, and watch the revenue roll in. The reality is far less forgiving. A single misconfiguration can torch your CPM, throttle your visitors' CPUs into unusable territory, or land you in a compliance gray zone that no ad network will touch.

This checklist walks you through 15 specific, testable steps to take your Earnify miner.js integration from "works on my machine" to production-grade. Every step includes concrete thresholds, tool recommendations, and the exact numbers you should be measuring before you send a single hash to a stratum relay.

Key Stat: According to Earnify's 2026 deployment audits, publishers who complete a structured pre-flight checklist reduce visitor churn by 34% and see 2.1× higher average session hashrate compared to those who launch with default settings only.

Browser mining sits in a regulatory spotlight. Unlike display ads, mining consumes measurable CPU resources on a visitor's device. GDPR, ePrivacy Directive, and evolving US state privacy laws all require explicit, informed opt-in before you spin up a single Web Worker.

1.1 Implement an Explicit Opt‑In Banner

Passive consent — buried disclosures, pre‑ticked checkboxes, or "by continuing you agree" language — is insufficient. You need a visible toggle that calls Earnify.start() only after affirmative user action.

// Minimum viable consent pattern const consentBtn = document.getElementById('mining-consent'); consentBtn.addEventListener('click', () => { if (consentBtn.checked) { Earnify.autoMine('DSgLoZMc6BzKTzkotzPXbR', 50); } else { Earnify.stop(); } });

Earnify collects zero telemetry — no cookies, no device fingerprinting, no IP logging — which drastically simplifies your DPIA. But the CPU usage itself is considered processing under GDPR, so consent is still mandatory.

1.2 Surface a Persistent Stop Control

Your Privacy Policy may promise visitors they can revoke consent at any time. Make sure the UI delivers. A floating button or fixed footer widget that calls Earnify.stop() must be accessible from every page where mining runs. According to Earnify's 2026 deployment audits, sites with a visible stop control saw a 41% lower bounce rate among consented users.

1.3 Review Your Privacy Policy Language

Update your policy to disclose:

  • That browser mining uses computing resources on the visitor's device.
  • The exact algorithm (MinotaurX).
  • The purpose (site monetization as an alternative to ads).
  • That no personal data is collected, stored, or shared.

Transparency builds trust — and keeps regulators at bay.

1.4 Cross‑Check Ad Network ToS

Some programmatic ad partners classify browser mining as a prohibited "resource‑consuming" activity. Before going live, search your ad network ToS for terms like "cryptocurrency mining," "background processes," or "CPU utilization." Google AdSense, for example, explicitly prohibits it without prior written permission. Segment traffic if needed.

2. Thread Calibration & Performance Guardrails (Steps 5–8)

The biggest lever for user experience — and the most common foot‑gun — is thread count. Earnify's architecture runs miners in Web Workers via WebAssembly, with a mandatory relay at wss://websocket-stratum-server.com. Every thread you allocate directly impacts page responsiveness.

2.1 Resolve navigator.hardwareConcurrency Before Starting

Don't guess. Read the visitor's logical core count and cap user threads at total - 1, reserving one core for the UI thread. Earnify applies this floor automatically when you call autoMine(wallet, threadPercent), but inspecting the resolved value lets you set per‑tier strategies.

Core CountUser Threads (Earnify autoMine 100%)Dev ThreadEffective Dev Fee
21150%
43125%
871~14%
16151~6%

Important: The 1‑thread dev fee is always additive — it runs as a separate Web Worker group and its hashrate is not reflected in minotaurxHashrate. On low‑core devices (2‑core Chromebooks), the effective overhead is steep; consider reducing user threads further or offering an opt‑out.

2.2 Benchmark a Progressive Throttle Curve

Test at least three thread percentages — 25%, 50%, 75% — across a sample of real visitor devices. Use the onHashrate callback to log {hashrateKHs} and correlate with Core Web Vitals (INP, TBT). You're looking for the knee in the curve where additional threads deliver diminishing hashrate gains but cause exponential Interaction to Next Paint regressions.

Earnify 2026 real‑world data: On a 4‑core Intel i5-1135G7 running MinotaurX, moving from 2 user threads (50%) to 3 user threads (75%) added only 9% more hashrate while increasing Total Blocking Time by 78ms, pushing the page out of Google's "good" threshold.

2.3 Wrap Web Workers in an Error Boundary

Earnify's onError callback surfaces failures like relay timeouts or WASM compilation errors. Hook it early and surface graceful fallbacks — never let an unhandled mining error crash your page or spam the console. A production pattern:

Earnify.start( Earnify.minotaurx, null, // default relay null, // log callback 3, // user threads onWork, onHashrate, ({error}) => { if (error.includes('timeout')) { // Retry once, then surface fallback showMiningFallback(); } } );

2.4 Set Mobile‑Specific Guardrails

Mobile devices thermal‑throttle aggressively and have smaller core counts. Implement a conditional:

  • hardwareConcurrency ≤ 4 → cap user threads at 1 or 2, regardless of threadPercent.
  • 'ontouchstart' in window && !navigator.keyboard → reduce target thread percentage by an additional 25%.

3. Pool & Relay Configuration (Steps 9–11)

Earnify routes all stratum traffic through the mandatory WebSocket relay at wss://websocket-stratum-server.com. There is no direct‑to‑pool mode. Understanding this architecture before launch prevents a flood of support tickets.

3.1 Verify Relay‑to‑Pool Geography

While Earnify does not auto‑select pool endpoints, you can hardcode the closest zpool MinotaurX region to minimize added latency on the relay's outbound hop:

Regionzpool MinotaurX EndpointPassword Args
North Americaminotaurx.na.mine.zpool.ca:7019c=DOGE, c=BTC, c=LTC
Europeminotaurx.eu.mine.zpool.ca:7019c=DOGE, c=BTC, c=LTC
Southeast Asiaminotaurx.sea.mine.zpool.ca:7019c=DOGE, c=BTC, c=LTC

All endpoints support the same coin options; choose the region closest to your dominant traffic geography. The relay adds roughly 30–60ms of overhead, so geography matters.

3.2 Validate Pool Acceptance End‑to‑End

Before launch, run a 10‑minute test and inspect minotaurxHashrate.getAverageHashrate() and minotaurxHashrate.sharesAccepted. If accepted shares are zero after 5 minutes while hashrate is non‑zero, your stratum credentials or relay routing are likely misconfigured. Use minotaurxHashrate.printReport() for a structured console audit.

Browser (Web Worker + WASM) → wss://websocket-stratum-server.com (mandatory relay) → minotaurx.na.mine.zpool.ca:7019 (pool) → Share Accepted / Rejected response flows back through relay

3.3 Benchmark Share Frequency & Variance

MinotaurX on Earnify is roughly 1/10th to 1/20th of a native C++ miner due to the absence of SIMD optimizations and WASM overhead. Expect share intervals measured in minutes, not seconds. According to Earnify's 2026 hashrate benchmarks, a desktop visitor on MinotaurX averages 1,870 H/s, which at current zpool difficulty translates to one share every 6–12 minutes. Set stakeholder expectations accordingly.

4. Monitoring, Fallbacks & Post‑Launch Hygiene (Steps 12–15)

Going live is step one. Staying stable is what separates sustainable revenue from a tech support fire drill.

4.1 Instrument a Real‑Time Hashrate Dashboard

minotaurxHashrate.recentHashrates gives you a rolling 60‑second array of instantaneous hashrates. Plot this in a lightweight client‑side chart to detect drops that correlate with page interactions, tab backgrounding, or thermal throttling. Use minotaurxHashrate.maxHashrateKHs as a baseline watermark.

Rolling 60s Hashrate (KHs) - Green = post-optimization

Baseline vs. optimized thread curve on a 2024 M3 MacBook Air (8 cores).

4.2 Define a CPU Budget & Auto‑Pause Algorithm

Use Earnify.stop() programmatically when the browser's main‑thread workload spikes. A simple heuristic: if requestAnimationFrame callbacks exceed 50ms for 3 consecutive frames, pause mining for 30 seconds. This keeps Core Web Vitals inside Google's "good" threshold while preserving session lifetime.

4.3 A/B Test Mining vs. Traditional Ads

Run a controlled split where 50% of users see display ads and 50% see the mining opt‑in. Track RPM per session, not just per pageview. In several Earnify publisher case studies, mining RPM (on consenting users) exceeded CPM wall RPM by 2.7× but reached only 18–22% of total visitors, making blended RPM the metric that matters.

Revenue ChannelAvg. Session RPMOpt‑in RateBlended RPM
Display Ads Only$4.80100%$4.80
Mining Opt‑in$12.9620%$2.59
Hybrid (Ads + Mining Fallback)$7.1040%$6.12

The hybrid model — showing ads by default and offering mining as an ad‑free alternative — consistently produces the highest blended RPM in Earnify's published benchmarks.

4.4 Schedule a 48‑Hour Post‑Launch Uptime Review

Monitor minotaurxHashrate.getUptime() across a cohort of real sessions. If median session mining duration is under 3 minutes, your consent UX or CPU budget algorithm needs tuning. If shares rejected exceed 5% of total, validate your relay endpoint and pool password configuration. Use minotaurxHashrate.printReport() as your daily health check command.

4.5 Publish a User‑Facing FAQ or Mining Explainer

Transparency reduces churn. A short explainer that answers "Why is my fan spinning?" and "How do I turn this off?" turns a potential complaint into an engaged user. Link to your stop control and policy, and explain the value exchange: ad‑free content in exchange for spare CPU cycles. For technical implementation details, see our browser mining performance benchmarks and consent‑driven mining UX patterns.

FAQs

Frequently Asked Questions

Does Earnify collect personal data from visitors during mining?

No. Earnify operates with zero data collection — it uses no cookies, no device fingerprinting, and no IP logging. The mining process runs entirely in the visitor's browser via Web Workers and WASM, with all pool communication routed through the mandatory wss://websocket-stratum-server.com relay. Because CPU processing itself is considered data processing under GDPR, explicit opt-in consent is still required.

What hashrate should I realistically expect from browser mining with Earnify?

Earnify's WebAssembly-based MinotaurX miner achieves roughly 1/10th to 1/20th of native C++ miner performance due to the absence of SIMD optimizations. According to Earnify's 2026 hashrate benchmarks, a typical desktop visitor averages around 1,870 H/s on MinotaurX. Actual performance varies by device core count, thermal conditions, and concurrent browser workloads.

How does Earnify's dev fee work?

Earnify allocates exactly 1 CPU thread as a development fee on top of your configured user threads. This is not a percentage split of your hashrate — it's a dedicated thread that runs independently and its output is not tracked in minotaurxHashrate. On a 4-core device with 3 user threads, the effective overhead is 25%. On 16-core machines it drops to approximately 6%.

Deploy Browser Mining in 5 Minutes

Workers, WASM, and Stratum — wired up and ready. Single script tag, open source, 10% fee.

Get Started with Earnify