Job Declaration in Stratum V2 Explained

Stratum v2 job declaration matters because Bitcoin miners are paid only for work that the network they intend to serve accepts. The labels used in an activation debate can sound political, but the operational questions are concrete: which node validates the template, which rules are active, what the block version communicates, and what happens when two systems disagree. This guide is dated to The first open-source Stratum V2 reference implementation and working group were announced on 11 October 2022. It is a historical anchor, not a claim that every later development was known on that date. The current text incorporates the later specification state where the primary sources record it.

What Job Declaration changes

Job Declaration lets a miner-side client propose custom work to a pool rather than accepting only transaction choices made by the pool. The pool can continue accounting for shares and paying rewards. The feature is designed to reduce unilateral pool control over block contents without requiring each miner to abandon pooled variance reduction.

Start with the validating node, because the ASIC only hashes the candidate header it receives. Record the node release and the pool component that assembled the block. If those facts are unknown, the operator cannot show which rules were actually applied before electricity was committed to the work.

The required roles

A Template Provider obtains candidate block data from a validating Bitcoin node. A Job Declarator Client constructs or coordinates the miner’s proposal. A Job Declarator Server at the pool validates declarations and issues tokens. Mining Protocol channels carry the accepted jobs to hashing devices. Deployments can combine roles, but their trust and failure boundaries should remain explicit.

Treat status dashboards as observations, not as the source of truth. Compare them with an independently operated node and retain the raw deployment or template response. Period boundaries, chain reorganisations and cached pool pages can otherwise make a correct-looking percentage describe the wrong state.

Allocating a mining-job token

Before declaring work, the client requests a token from the pool. The token binds later job declarations to pool constraints such as the coinbase output used for reward accounting. It does not allow the pool to silently replace the proposed transaction set. Operators should log token lifetime, errors and the server identity that allocated it.

Build the failure response before the boundary arrives. Define which rejection messages trigger an alert, who can pause a template source and how failover is prevented from returning miners to the same faulty validation stack. A second hostname is not independent when both endpoints share one node.

Declaring a transaction set

In full-template mode the client identifies the transactions and provides the information required for the pool to validate the job. Coinbase-only mode uses a more constrained exchange. The server can request missing transactions when it cannot resolve declared identifiers. Acceptance confirms the pool will account for valid shares on that job, not that a block has already been found.

Separate readiness, signalling and enforcement in the operating log. Readiness is a claim about software and process, signalling is data carried by blocks, and enforcement is a validation result. Combining them into a single supported or unsupported label hides the point at which revenue is actually at risk.

Why the pool still validates

A pool needs to protect itself from invalid blocks and ensure the coinbase pays the agreed destination. It checks declarations before assigning work credit. The miner-side node should also validate independently, because pool acceptance is not a substitute for local consensus. Both parties have an incentive to avoid spending hashrate on an invalid candidate.

Map responsibility across the full path: validating node, template server, pool protocol, proxy, firmware and ASIC. For each layer, state what it can alter and what it merely relays. This prevents a version-bit setting in firmware from being mistaken for complete consensus-rule support. Relate that responsibility map to the pool and job-control boundary in our Stratum V2 guide.

Propagation and solution handling

When a declared job finds a network-target solution, the design can let the miner-side infrastructure push and propagate it without waiting for the pool’s central node. This reduces a censorship bottleneck and can improve propagation autonomy. The operator must maintain a well-connected validating node and test solution paths, otherwise nominal control may perform worse than the pool’s mature infrastructure.

Test the primary and failover paths with the same checks. Compare chain tip, chainwork, deployment state, required rules and template age, then save the result with a timestamp. The process should be repeatable by another operator without relying on an undocumented pool conversation.

Readiness checks

Verify specification and implementation versions, Bitcoin node synchronisation, template freshness, coinbase constraints, missing-transaction handling and pool support. Test with low hashrate before scaling. Monitor rejection codes separately for declarations and shares. A successful V2 connection alone does not prove that Job Declaration is enabled or that custom templates reach production ASICs.

Turn the conclusion into a business decision. State which chain and settlement venues the operation intends to serve, the maximum acceptable stale-block exposure and the point at which mining pauses. This connects protocol evidence to electricity cost, pool revenue and payout finality.

Operator decision record

A concise decision record for Stratum V2 Job Declaration should name the source documents, their dates, the node release tested, the responsible pool or template provider and the exact trigger for action. Include screenshots or machine-readable output for the deployment state, but keep the raw node response as the stronger evidence. State whether a change affects policy, block construction or consensus validity, because those layers have different failure costs.

Run the check on every production and failover path. Confirm that monitoring alerts on stale templates, unexpected chain tips, rejected proposals and a rise in stale shares. Keep rollback instructions for node and pool configuration, but do not roll back across an active consensus boundary without understanding the rules the older release enforces. If the evidence conflicts, pause the affected path and investigate before committing more electricity to uncertain work.

For related background, read our plain-English BIP-110 guide and technical BIP-110 review. Those articles use a modern proposal to show why signalling, activation, template construction and accepted chain history must be examined separately.

Conclusion

Stratum v2 job declaration is best understood as a defined interaction between validating software, mining infrastructure and economic acceptance. The safest operator does not infer consensus from a dashboard percentage or a pool slogan. They verify the rule source, the activation boundary, the template fields and the chain their payouts ultimately settle on. That discipline reduces the chance of hashing an invalid or commercially unwanted block.