Stratum V1 vs Stratum V2: Protocol Evolution

Stratum is the language between your hall and the pool. It changes neither SHA-256 nor the network target. What it changes is who builds the work, how the job travels, and what is encrypted. So the choice between v1 and v2 turns on control and channel security, not on hashrate.

What both versions must do

In both cases, pool and miner must agree on a job, meaning the tip of the chain, the share target, and the pieces of the header. The pool must then receive shares, the proofs that a machine found a hash under pool difficulty. And both must drop the job as soon as a new block makes the template stale.

The difference between versions comes down to three questions: who picks the transactions, who can tamper with traffic on the wire, and who carries the implementation complexity.

Stratum v1: the pool builds, the miner finishes

The v1 scheme, now the de facto standard, works like this:

• the pool sends a textual JSON job holding prevhash, nBits, nTime, coinbase parts, and Merkle branches;
• the miner inserts its extraNonce, computes the Merkle root, sweeps the nonce, and returns a share;
• the channel is, in common use, cleartext over TCP.

Those three points have direct consequences. An observer on the path reads jobs and shares as readable text. A middlebox can delay or rewrite messages, which is a structural limit of the model rather than a theoretical risk.

Above all, the miner does not choose the transaction list: it hashes the pool's template. That is what makes v1 simple to implement in firmware, and it is also what concentrates block construction at the pools. Fee policy and the choice of which transactions get included live with them, not with you.

Jobs are also relatively chatty, since a template change can mean resending branches. The slower or lossier the channel, the more you hash against a chain state that has already moved on.

Stratum v2: structured jobs, authenticated channel

Stratum v2 is an open specification organized in several layers. It aims at four things:

• binary message encoding, less ambiguous and less verbose than a JSON line;
• an encrypted, authenticated channel, where miner and pool recognize each other and a third party on the wire does not read the job in clear;
• a clean split between connection, mining channel, and work negotiation;
• the option, depending on the mode enabled, for the miner or an operator proxy to build the template, and therefore to choose its transactions, while the pool keeps coordinating shares.

Not every v2 deployment offers all four. Some stay close to v1 with a better transport, keeping the same roles and improving the channel. Others genuinely expose miner-side construction. Who builds the block therefore depends on the mode actually connected, not on a "v2" label on a commercial page: ask the pool operator explicitly.

Encryption does not make your shares more valid. It reduces passive eavesdropping and some tampering with the job in transit. It corrects neither a wrong worker password, nor a lying DNS, nor firmware hashing a bad midstate.

Four checks before switching

1. Does the firmware speak the pool's dialect? A v2 endpoint with a v1 client, or the reverse, does not mine slightly worse: it does not negotiate at all, and the machines stay silent.
2. Who emits the template? If you want your own transactions included, or those your node selects, v1 will never allow it. You need a mode where the miner builds, and a node that keeps up with the chain.
3. Is the channel genuinely protected? On v1, treat the path as readable and size your network accordingly. On v2, protection depends on the certificates and endpoints in use, to be validated with the pool.
4. What is the arrival latency of a new job? It is the only parameter that weighs directly on your revenue. A cleaner protocol changes nothing if the template lands after the next block is already public.

Three common mistakes

• Believing v2 pays more. The payout scheme, PPS, FPPS, or PPLNS, is a pool contract and has nothing to do with the protocol version.
• Confusing channel encryption with chain privacy. Published blocks stay public, whatever transport was used to build them.
• Switching a whole fleet at once. Test on a few machines, confirm that shares are counted and workers appear correctly, then roll out.