Job Declarator

The Job Declarator is the moving part of Stratum V2 that actually carries a miner's transaction choices to the pool and gets them approved. It exists as two halves: the Job Declarator Client (JDC), which runs on the miner's side, and the Job Declarator Server (JDS), which runs on the pool's side. Together they implement the negotiation that resolves mining's oldest tension — how a miner can build its own blocks, choosing its own transactions, while still smoothing income through a shared pool. Under legacy Stratum V1 and default V2 operation, the pool constructs the block template and the miner just grinds on it; the Job Declarator is the machinery that hands template authority back to the operator.

The Client (JDC)

The JDC sits between the local Template Provider — typically a patched full node generating candidate block templates from the operator's own mempool and policy — and the pool. Its duties span the whole job lifecycle: it pulls fresh templates from the node, declares the chosen transaction set to the pool and obtains approval against a mining job token, distributes the resulting work to downstream hashing devices, manages share submission upstream, and, when a miner in its charge finds a valid block, broadcasts it to the Bitcoin network directly rather than waiting on anyone. Because the JDC runs on infrastructure the operator controls, the operator — not the pool — decides which transactions are mined, which is the entire point.

The Server (JDS)

The JDS lives at the pool. It issues the job tokens, receives and acknowledges declarations, and keeps an internal mempool so it can independently sanity-check the declared transaction set; when the declaration references transactions the JDS has not seen, it asks the client to provide them. It also publishes valid block submissions to the network from the pool side, adding propagation redundancy. Crucially, the protocol is designed with a failure mode in mind: if a pool's JDS rejects shares that are demonstrably valid — say, to punish a miner for including transactions the pool dislikes — the honest countermeasure is built into the incentive structure. The miner's JDC can fail over to another pool, taking its hashrate and its declared templates with it. Censorship becomes a customer-service problem for the pool rather than a silent structural feature of the network.

Why This Matters for Decentralization

Pooled mining concentrated template construction into a handful of pool operators, making them the practical chokepoint for transaction censorship — a regulator leaning on three companies could, in principle, shape what gets confirmed. Job declaration redistributes that power to every participating pool member who chooses to run the infrastructure. Even partial adoption changes the threat model: censoring a transaction no longer means pressuring a few template builders, but overriding thousands of independent operators each running their own node and policy. This is decentralization done at the layer where it was quietly lost.

Running It Yourself

The working stack is a full node with a Template Provider, a JDC, and a pool whose JDS accepts declarations — with a translation proxy bridging older V1-only hardware into the V2 world. Native Stratum V2 support in miner firmware remains selective: BraiinsOS+ carries it on industrial Antminers, and the open-source AxeOS/ESP-Miner firmware brought native V2 to the Bitaxe in 2026. The Job Declarator is the enforcement layer of the broader Job Declaration Protocol, and it depends on that local Template Provider for the templates it negotiates over — one more case where sovereignty costs exactly one node, run by you.

Adoption is still early, and that is precisely the argument for participating: every operator who declares their own jobs makes the censorship-resistant path more normal, better tested, and harder to ignore — the network-level equivalent of running your own node instead of trusting someone else's.