Bitcoin Block Templates: Who Builds Your Work?

A miner can have valid shares, a stable connection, and a healthy hashrate while having almost no say over the Bitcoin block template it is trying to solve. That distinction matters. Hashrate searches for a valid block header. The template determines what that successful header would confirm and where the block reward goes.

For solo and lottery miners, Bitcoin block templates are not an abstract pool-side detail. They are the proposed block your hardware is spending electricity to find. If a block is solved, its coinbase transaction, transaction list, fees, and previous-block reference become facts recorded by the network.

What a Bitcoin block template contains

A block template is a candidate block before proof of work is complete. It contains the information needed to construct the block header and the block body that the header commits to.

At a practical level, the template specifies the previous block hash, the current difficulty target, the timestamp range, the version field, and a set of transactions. It also includes the coinbase transaction. The coinbase is not just another payment. It creates the block subsidy and collects the transaction fees from every transaction included in that block.

The transaction list is compressed into a Merkle root. Change one transaction, remove one transaction, or alter the coinbase output, and the Merkle root changes. That produces a different header. Your miner is then working on a different candidate block.

This is why “the pool sends work” is incomplete language. A pool or template provider does not merely hand out hashes to try. It chooses, or relays someone else’s choice of, the economic contents of a possible Bitcoin block.

The coinbase transaction is the ownership test

For a solo miner, the first question is simple: if this work finds a valid block, which Bitcoin address receives the subsidy and fees?

The answer is visible in the coinbase transaction. A direct-payout design constructs that transaction with the miner’s payout address as the reward destination. No internal balance needs to be credited first. No operator wallet needs to receive the block and send a later payout. The settlement transaction is the block itself.

That does not improve the odds of finding a block. Nobody changes your luck. It changes what can be checked if luck arrives.

A miner should also understand that the coinbase has technical constraints. It contains a block-height commitment and can include an extranonce field used to create unique work. Those fields affect the coinbase transaction ID and therefore the Merkle root. They do not give a miner unlimited authority to rewrite the rest of the template.

Who normally builds the template?

In conventional pooled mining, the pool generally runs a Bitcoin node, selects transactions from its mempool, creates a candidate block, and distributes jobs to connected miners. The miner receives enough information to search assigned portions of the header space. It proves contributed work through shares, which are much easier to find than a network-valid block.

That model is operationally useful. A small miner does not need to run a full node, maintain a mempool, or assemble new candidates every time the chain tip changes. But it places template construction on the pool side.

The trade-off is authority. The template builder decides which valid transactions are included, which are excluded, what fee package is selected, and how the coinbase is built. A miner may be able to verify parts of a received job, but under ordinary Stratum V1 operation, it usually does not author the full transaction set.

This does not mean every pool is behaving badly. It means the protocol role is real. Trust should be assigned to named mechanisms, not softened by assumptions about the operator.

Transaction selection is not cosmetic

Bitcoin’s limited block space means transaction selection is policy. Most template builders prioritize transactions and packages that pay competitive feerates under their own mempool policy. They may also filter transactions based on local configuration, legal risk assessments, relay policy, or implementation behavior.

Some differences are harmless. Two honest nodes can have different mempools at the same moment. A high-fee transaction may not have reached one node yet. Package evaluation can differ. A new tip can invalidate a parent transaction and change the best available set.

Other differences are deliberate. A template builder can omit transactions it has seen and could include. It can choose a payout destination that is not yours. It can construct a block from a node you cannot inspect. Bitcoin will validate the resulting block if it follows consensus rules. Consensus validity is not proof that the template matched your preferences.

Why template control affects Bitcoin beyond your rig

A block template is where mining power meets transaction confirmation. If a small number of entities build templates for a large share of global hashrate, those entities have concentrated influence over what the next blocks attempt to confirm.

That influence has limits. A template builder cannot make an invalid transaction valid. Other nodes will reject an invalid block. It cannot force miners to find a block. It cannot change the 21 million supply limit. But it can decide what its connected hashrate is asked to work on.

For an independent miner, this is a question of agency and visibility. Are you working on a candidate assembled from a node and policy you selected? Are you receiving a job built by someone else? Can you identify the reward output before a block is found? Can you tell whether a job changed because a new block arrived, because transactions changed, or because the operator changed something else?

The answers depend on the mining protocol and the pool architecture.

Stratum V1 jobs and the limits of inspection

Stratum V1 made pooled mining practical at scale. A server sends jobs, difficulty settings, and notifications to miners. The miner submits shares. The protocol is widely supported, including by most home ASICs and ESP32-class miners.

Its age shows in its trust boundaries. In a typical V1 flow, the server provides the parts that commit to the transaction set. The miner can vary nonce-related fields and an assigned extranonce space. It is not normally handed a complete, independently reconstructable transaction list for every job.

You can still verify meaningful things. Confirm the endpoint you connected to. Confirm the configured payout address where the pool exposes it. Monitor accepted shares and stale shares. If a block is found, inspect the on-chain coinbase output and block contents.

But post-block inspection is not the same as pre-block authority. Once a block exists, the outcome is permanent. The useful question is what your setup lets you verify before your hashrate is committed.

Stratum V2 separates roles more clearly

Stratum V2 was designed with stronger transport security and clearer mining roles. Its encrypted transport uses Noise, and authority-key pinning gives a miner a way to identify the server it intended to reach rather than trusting an unauthenticated endpoint on the network path.

It also defines roles such as a template provider and a pool. That separation matters because creating a template and accounting for mining work are different jobs. A pool can coordinate connections and shares while a template provider supplies candidate block contents.

Job Declaration is the part of Stratum V2 that can allow miners to propose transaction sets for approval. It is not a magic switch that makes every connected miner a full template author. The pool must support the relevant mode and policy. The miner needs access to transaction data and, in a meaningful self-directed setup, usually a node and mempool it controls. There are bandwidth, hardware, and operational costs.

For a Bitaxe running native V2 firmware or an ASIC with compatible firmware, native V2 avoids putting a separate translator between the miner and pool. For the many miners that still speak V1, a pool can support the existing protocol without pretending V1 provides the same control surface.

What to verify before you point hashrate

Start with the payout path. If your goal is direct ownership, determine whether a solved block pays your address in its coinbase transaction or whether the pool takes custody first. Those are different settlement models, even when both use the word “payout.”

Then identify the template source. Ask whether the pool operates its own full node, relies on an upstream node, or uses another template service. There is no need for theater here. A clear answer is better than a vague claim of decentralization.

Check the connection security your miner can actually use. Encrypted Stratum V2 with a pinned authority key protects a different part of the system than a familiar hostname alone. If your rig only supports V1, understand that constraint instead of assuming a settings page creates protections the protocol does not have.

Finally, retain evidence. Save your miner configuration. Record job IDs and timestamps when your software exposes them. Watch your stale rate, especially when network conditions change. If a block is found, inspect it on-chain: the coinbase output, the fees, the transaction set, and the block’s relationship to the chain tip.

NexusPool applies this principle to solo mining by building jobs from its own full Bitcoin node and paying a solved BTC block directly to the miner’s configured address. That is a claim with a concrete artifact. The resulting coinbase transaction is public, permanent, and independently checkable.

The honest limit

No block template removes mining variance. A home miner can operate correctly for years without finding a block. A much smaller miner can find one tomorrow. Expected outcomes describe a long-run probability. They do not create a schedule.

Template transparency is not a yield product. It is a way to know what your work is trying to solve, who constructed that work, and where the money goes if the improbable event happens.

That is the standard worth keeping. Your miner is not a vote for a dashboard balance. It is a machine searching for a valid commitment to a specific block.

Trust nothing. Verify the block template.