Block template

From pending transactions to mining work

The daemon chooses eligible transactions from its pool and constructs the miner transaction. The candidate must fit the current consensus constraints, including block weight and reward rules. The reward address directs the miner transaction, not the ordinary payments in the block.

The get_block_template RPC returns serialized block data, a hashing blob, the target height and difficulty, and RandomX seed information. Mining software uses these together rather than treating the block hash as the proof-of-work hash.

References: Daemon RPC reference · Monero source: cryptonote_core/blockchain.cpp

Refreshing a job

A new accepted block changes the parent on which the miner should build. Transaction-pool changes can also make a newer template preferable. An old job can become stale while a miner is still processing it.

A template provider influences transaction selection and the payment destination supplied to workers. Running the relevant node and mining software locally gives an operator more control over these choices, but the completed work must still meet the same network rules.

References: Daemon RPC reference · Monero source: cryptonote_core/blockchain.cpp

Example

A mining application asks its own daemon for a block template using a reward address. When a new chain tip arrives, the application requests fresh work instead of continuing indefinitely on the old parent.

References: Daemon RPC reference · Monero source: cryptonote_core/blockchain.cpp

Limits and cautions

A template is not a mined or confirmed block. The resulting block still needs valid proof of work and full node validation. A restricted public RPC endpoint may refuse template requests.

References: Daemon RPC reference · Monero source: cryptonote_core/blockchain.cpp