Block Template Construction

Block template construction is the process of assembling a candidate block for miners to work on: choosing which transactions to include, building the coinbase, computing the Merkle root, and packaging the header fields. In a sovereign setup a node produces this template itself — historically through the getblocktemplate RPC — rather than trusting a third party to decide what a block contains. Who builds the template is one of the quietest but most consequential questions in Bitcoin decentralization.

It is easy to think of mining as a single act, but building a block is really two very different jobs fused together. One is the raw, brute-force search for a valid hash that consumes all the electricity and the specialized hardware everyone pictures. The other is the quiet editorial decision of what the block should contain in the first place — which transactions, in which order, paying which fees. That second job takes almost no computing power at all, yet it is where a block's entire economic and political character is decided. Keeping those two jobs in the same hands is what full sovereignty over mining actually means, and letting them drift apart — hashing here, template-building there — is how centralization quietly creeps into a system that looks decentralized on the surface.

Transaction selection

The builder orders mempool transactions by fee rate — fee per unit of block weight — and packs them in descending order until the weight limit is reached, which myopically maximizes fee revenue. Dependency handling complicates this cleanly greedy picture: a low-fee parent may need to be bundled with a high-fee child (child-pays-for-parent), so a good builder evaluates ancestor and descendant fee rates together rather than judging each transaction in isolation. The result is an ordered set that squeezes the most reward out of the roughly four million weight units a block can hold, while respecting every dependency so the block stays valid.

Coinbase and Merkle root

The first transaction is always the coinbase, which claims the block subsidy plus the total fees and carries arbitrary data, including the extranonce. All transaction IDs, coinbase first, are paired and double-SHA-256 hashed up the Merkle tree to a single root that goes in the header. Because the coinbase holds the extranonce, changing it regenerates the Merkle root and hands the miner a fresh batch of headers to grind — which is exactly how a chip that exhausts its four-billion-value nonce range gets more work without waiting for an entirely new block. The template, in other words, is not one puzzle but a whole space of them.

Why it matters for decentralization

Whoever builds the template decides which transactions get mined, and therefore which get censored. When pools build templates centrally, that selection power concentrates in a handful of operators, no matter how many independent machines point hashrate at them — the machines contribute energy, but the pool alone chooses the block's contents. This is the subtle centralization that raw hashrate distribution charts miss entirely, and it is why the question of template authorship has moved to the center of decentralization debates.

Pushing template-building to the edge

Newer designs move the block-content decision back toward the machine. Stratum V2's Job Declaration protocol lets an individual miner declare its own locally built template to the pool, which then handles only accounting and payout. OCEAN's DATUM protocol takes a similar path, having miners construct templates on their own local full node while the pool coordinates shares. Both turn a pool participant into something closer to a solo miner for the purpose that matters most — choosing what goes in the block — while keeping the smooth payouts of pooled mining. This process feeds the work formats described in our Stratum Mining Protocol (v1) and nonce space entries.