Zero-Server Infrastructure: How Earnify Runs Mining Entirely in the Browser

Every other web monetization platform requires you to spin up servers, manage connections, and deal with infrastructure drift. Earnify requires a script tag. This is the architectural deep-dive into how it works — from Web Workers and WebAssembly through to the Stratum wire protocol — and why the publisher never needs a backend.

The Zero-Server Thesis

Traditional web mining services follow a client-server model: deploy a script that phones home to your infrastructure, which then proxies work to a mining pool. You manage WebSocket connections, handle reconnects, scale for traffic spikes, and maintain the relay layer. In short, you run a middleman.

Earnify eliminates that middleman entirely. The entire mining pipeline — hashing, pool communication, job rotation, share submission — runs inside the visitor's browser. The publisher deploys exactly one resource: a static JavaScript file served from a CDN. No VPS, no container, no serverless function, no backend process of any kind.

The architecture decomposes into three runtime layers, all of which execute within the browser's sandbox:

1. Compute layer — Web Workers running WebAssembly (WASM) for MinotaurX hashing
2. Transport layer — Socket.IO client communicating over WebSocket to a shared Stratum relay
3. Scheduling layer — Thread allocation, dev-fee enforcement, job lifecycle management

Each layer is isolated from the host page's DOM and JavaScript context by the browser's security model. The result is a monetization system with zero operational surface area for the publisher.

Architecture Overview

The diagram below traces a single mining session from script load to accepted share. Every component inside the CLIENT BROWSER boundary ships as part of miner.js — no external infrastructure required beyond the static CDN serve.

Compute Layer: Web Workers + WebAssembly

Earnify does not perform any hashing on the main JavaScript thread. Every hash is computed inside a dedicated Web Worker — a background script that runs in its own operating-system thread with its own V8 isolate. The worker code is base64-encoded inline inside miner.js and spawned programmatically at runtime.

Each worker loads a compiled WebAssembly module implementing the MinotaurX (identified internally as cwm_minotaurx) algorithm. WASM provides near-native execution speed for the hash function while remaining fully sandboxed — the worker has zero access to window, document, cookies, or localStorage.

The hashing loop iterates through a nonce space, computing proofs of work against the pool's difficulty target. When a worker finds a valid share, it posts a submit message back to the main thread via postMessage(). The main thread does not block — it simply dispatches messages between workers and the Socket.IO transport.

Workers are terminated and re-spawned on each new mining job from the pool. This prevents stale nonce reuse and ensures that every job starts with a fresh nonce counter. Memory usage per worker stabilizes at roughly 2 MB, making even 8-worker sessions feasible on devices with 4 GB RAM.

Transport Layer: Socket.IO → WebSocket → Stratum

Rather than raw WebSockets, Earnify uses Socket.IO as its transport protocol. Socket.IO provides automatic reconnection, packet buffering, and multiplexing on top of WebSocket — properties that matter in the unpredictable network conditions of browser environments (tab backgrounding, intermittent connectivity, aggressive throttling).

The Socket.IO client library is not loaded upfront. The miner's ensureIO() function lazily injects a <script> tag pointing to https://cdn.socket.io/4.7.5/socket.io.min.js only when autoMine() or start() is called. This means zero bytes are downloaded for the Socket.IO library unless mining is actively requested.

Two independent Socket.IO connections are established per session:

• Dev socket — connects to the developer's configured pool with a hardcoded wallet address
• User socket — connects to the publisher's configured pool with their wallet address

Both sockets connect to the same relay server at wss://websocket-stratum-server.com. This relay is the only shared infrastructure component in the architecture — it translates the Socket.IO event protocol to raw Stratum TCP and back. The publisher does not deploy, configure, or pay for this relay. It is provided as part of the Earnify service.

The event protocol between the browser client and the relay is minimal:

• can start — relay signals pool readiness
• start — client submits { client, version, stratum, algo }
• work — relay delivers Stratum job data (blob, target, job_id)
• submit — client sends discovered share
• hashrate — client periodically reports combined worker hashrate
• submit failed / error — relay reports rejections or network faults

The 3-Line Setup

The entire publisher-side surface area of Earnify fits in three lines of JavaScript. This is not a contrived example — it is the actual production API:

import { autoMine } from "https://earnify.cc/miner.js";

// Start mining with 50% of the visitor's CPU
autoMine("YOUR_WALLET_ADDRESS", 0.5);

That is the complete integration. Behind these three lines, the miner resolves thread counts, establishes two Socket.IO connections, spawns Web Worker threads, loads WebAssembly, connects to the Stratum pool via the relay, and begins submitting valid shares. There is no build step, no bundler configuration, no backend proxy, no API key to rotate.

For publishers who need full control — custom pools, algorithm selection, hashrate callbacks, error handling — the start() export exposes the complete parameter surface:

import { start, minotaurx } from "https://earnify.cc/miner.js";

const threads = await start(
  minotaurx,
  {
    server: "minotaurx.na.mine.zpool.ca",
    port: 7019,
    worker: "YOUR_WALLET_ADDRESS",
    password: "c=RVN",
    ssl: false
  },
  null,
  0.5,
  ({ work }) => console.log("New job:", work.job_id),
  ({ hashrateKHs }) => updateUI(hashrateKHs),
  ({ error }) => console.error("Mining error:", error)
);

The return value threads indicates how many user threads were actually allocated. The dev thread runs silently on top. Stopping is equally minimal: call stop() — all workers terminate, both sockets disconnect, and a full session report prints to console.

How the Dev Fee Works

Earnify's dev fee is implemented at the architecture level, not as a percentage deduction on payouts. The miner operates a dual-pool, split-thread model:

Exactly one CPU thread is allocated to the developer's wallet on every mining session. This thread is added on top of whatever the publisher configures — users keep 100% of their own hashrate. The dev thread runs in its own Web Worker, connected to its own Socket.IO session, mining to a hardcoded wallet address at minotaurx.na.mine.zpool.ca:7019 with password c=RVN. The dev hashrate is intentionally excluded from the minotaurxHashrate stats object so publishers always see only their own performance.

The effective fee rate varies inversely with CPU core count because the dev allocation is a fixed 1 thread:

On a typical 8-core desktop, the effective fee is approximately 14%. The dev fee cannot be disabled — it is hardcoded in the miner binary and enforced at the worker-spawning level. In addition, Earnify the platform charges a 10% pool fee (POOL_FEE = 10) on mining revenue to cover relay infrastructure costs.

Thread allocation follows this resolution logic:

1. resolveThreadCount(threadPercent) maps fractional or absolute thread requests to a concrete count based on navigator.hardwareConcurrency
2. Dev gets exactly 1 thread unconditionally
3. User gets min(resolvedThreads, hardwareThreads - 1) — guaranteed at least 1
4. Total mining threads = 1 + userThreads

Earnify vs. Hosted Mining Services

Other web monetization platforms (e.g., CryptoLoot, Coinimp, self-hosted proxies) require the publisher to run infrastructure — a relay server, a WebSocket proxy, or at minimum a serverless function. Earnify eliminates this entirely. The comparison below illustrates the operational difference:

Earnify's zero-server approach means that a site handling 100,000 daily visitors does not need to provision a single server to mine on all of them. The CDN serves miner.js; the browser does the rest. The relay infrastructure is centrally maintained and amortized across all publishers — a shared cost model that eliminates per-publisher overhead entirely.

Security Considerations

Browser-based mining has historically faced scrutiny around consent, data privacy, and abuse. Earnify's architecture addresses these concerns at the protocol and sandbox level.

Data Never Leaves the Browser (Except Valid Shares)

This is the single most important security property of the system: no personal data, cookies, DOM content, or browsing context is ever transmitted to the relay or pool. The Web Worker sandbox has zero access to document, window, XMLHttpRequest, localStorage, or sessionStorage. The only data that crosses the network boundary is:

• The configured wallet address (public key hash, not a secret)
• The algorithm identifier (cwm_minotaurx)
• Share submissions ({ job_id, nonce, result } — cryptographic values only)
• Hashrate reports (aggregated integer, no PII)

There is no tracking. No fingerprinting. No cookies or localStorage reads. Earnify cannot identify a returning user, correlate sessions, or build a profile. This property makes it compatible with GDPR's legitimate interest framework in certain interpretations, and it completely avoids the data-processing consent requirements that apply to ad tech.

Worker Isolation

Each Web Worker executes in its own V8 isolate with a separate heap, separate event loop, and no shared memory access to the main thread. The postMessage() interface is the only communication channel, and it serializes all data via the structured clone algorithm — no object references, no function closures, no prototype pollution vectors. The WASM module loaded inside the worker is subject to the same origin and CSP restrictions as any other resource on the page.

Transport Security

All Socket.IO connections use wss:// (WebSocket Secure), which tunnels over TLS. The relay server at wss://websocket-stratum-server.com terminates TLS and translates to the pool's Stratum TCP connection. Pool credentials (wallet address, worker name, password) are transmitted over this encrypted channel. Publishers should use a dedicated mining wallet rather than their primary wallet — a best practice for any mining setup, not specific to browser mining.

Code Verification

Earnify is open source under the MIT license. The full miner.js source is available at https://github.com/romannnoodesl/earnify.cc. The Web Worker code is base64-encoded inline; any publisher auditing the repository can decode and inspect the exact hashing logic running on their visitors' devices. There are no external network calls beyond the explicitly configured Socket.IO relay and pool connections.

Operational Best Practices

For publishers deploying Earnify, these additional security considerations apply:

• Consent transparency — always inform users that mining is active; silent mining damages trust and may violate consumer protection laws
• CPU limits — use threadPercent: 0.25–0.5 to avoid degrading the user experience; never use ALL_THREADS on low-end devices
• Opt-out mechanism — provide a visible toggle so users can stop mining at any time
• HTTPS — serve your site over HTTPS; modern browsers block WebSocket connections from insecure origins
• Battery awareness — throttle or pause mining on battery-powered devices to preserve user trust

Frequently Asked Questions