Concept
Work blocks and cuts
What a work block contains, how it is anchored, registered and executed by cuts, how difficulty follows the hashrate, and when its reward is paid.
On this page
A work block
A work block is a 312-byte header and a body.
| Header field | Meaning |
|---|---|
| Chain ID | The network the block belongs to |
| Work reference | The finalized cut the block is anchored to |
| Parents root | Commits the parent references in the body |
| Payload root | Commits the transactions in the body |
| Payload length and mass | Size of the body |
| Reward lock | The address that earns the block |
| Nonce, extranonce | What the miner varies; the extranonce also carries the miner tag |
| Body limit | Value |
|---|---|
| Size | 46 KiB |
| Transactions | 10 |
| Signature checks | 10 |
| Payload bytes of all transactions | 1,024 |
| Mass | 96,000 |
| Parents | 16 |
The header has no timestamp. Nothing in consensus depends on a node's clock.
Anchors and the registration window
Every work block names a finalized cut as its anchor. The anchor fixes the block's difficulty target and the TenQ epoch. A miner always builds on the newest cut it knows.
A block can be registered by any of the 96 cuts that follow its anchor, about 4 minutes. Inside that window it does not matter which cut picks it up or how many other blocks were found at the same moment. A block that reaches no cut within the window expires and earns nothing.
One cut registers at most 250 work blocks and executes at most 256. An anchor takes at most 250 blocks in total, however many cuts register them. With a cut every 2.5 seconds, the chain takes bursts of up to 100 work blocks per second, twice the target of 50; Testnet100 takes up to 200 against its target of 100.
From found to final
| Step | What happens |
|---|---|
| Pooled | Nodes checked the block's proof of work and hold it |
| Registered | A cut listed it |
| Executed | A later cut ran its transactions, usually the next one |
A transaction is final when the cut that executed its block is certified. That is why a transaction's status shows a registered cut first and a finalized cut one height later.
Two blocks may carry the same transaction, or two transactions that spend the same output. The fixed order decides: the first one executes, and the later one fails without effect.
Parents
A block lists up to 16 earlier blocks as parents. The header binds the list into the proof of work, so it cannot be changed afterwards. Beyond that, parents carry no weight. A block with unknown or invented parents is treated exactly like any other, and nodes never wait for a parent before accepting a block.
Difficulty
The target aims for 50 work blocks per second on average; bursts of up to 100 fit into the cuts. It comes from finalized state alone:
- The controller counts the blocks registered for each of the last 96 anchors.
- More blocks than expected make the target harder, fewer make it easier, with a half-life of 450 seconds.
- An anchor without any block changes nothing, so a pause in mining does not make blocks easier by itself.
- The cap of 250 blocks per anchor also bounds the controller, so withheld work released later cannot push the target around.
Every cut commits the controller's state and target. A miner gets the target from its anchor, and every node derives the same value before it accepts the block.
Rewards
Each cut schedules a mining subsidy for its anchor. When the anchor's registration window closes, that subsidy is divided equally among the blocks registered for it. If no block registered, the amount carries over to the next anchor that has work.
On top, a block earns the miners' half of the fees of the transactions it carried.
The reward is a normal output to the block's reward address, created by a cut. It needs no maturity period: once paid, it is final like every other output.