Blocks and time
You are looking at an old version of this page: revision #14 by zoobc.how, 2026-10-26 20:39 UTC. See the current version
ZooBC adds a block to its chain about every 15 seconds, on every network. The protocol measures time in blocks: when a rule says "a day", it means 5,760 blocks. Knowing that conversion makes most numbers on this wiki easy to read.
A block every 15 seconds
The 15-second interval is a parameter of each chain's genesis (min_block_interval), the same on devnet, testnet and mainnet. After each block, a draw names the nodes that may make the next one, in order (draw). The node drawn first has the first round, aimed at 15 seconds after the previous block. If it is late or offline, the node drawn for the next round may make the block 15 seconds later, and so on, so a missing producer delays one block rather than stopping the chain (rounds, timing and windows).
A block that arrives less than 13 seconds after its parent is refused as "produced too fast", so no producer can speed the chain up.
Empty blocks still count
Blocks keep coming whether or not anyone sends transactions. A block without transactions still does work:
- it carries receipts and the network topology, the signed proofs that nodes relayed data to each other, which feed the participation score;
- from version 0.5.8 it carries the new coins scheduled for its time, the coinbase, exactly as a full block does.
The release of new ZBC follows the clock, not the block count: a block's coinbase is what the 15-year schedule releases between the previous block's timestamp and its own (supply and emission). A slow stretch of blocks does not mint less over a day, and a burst of fast blocks does not mint more.
Durations counted in blocks
Because the interval is fixed, the protocol writes durations as block counts. These are the common conversions, with some of the durations that appear across this wiki (mainnet values):
| Blocks | Time | Where it appears |
|---|---|---|
| 120 | 30 minutes | delay before a node-key rotation takes effect (keys of a node) |
| 240 | 1 hour | one storage-proof epoch (decentralised storage pool) |
| 720 | 3 hours | the rollback limit (finality and rollback) |
| 2,880 | 12 hours | the unit of the score clock while there are fewer than 2,880 nodes (missed turns, suspension and expulsion) |
| 5,760 | 1 day | a queued node's attendance window (queue) |
| 11,520 | 2 days | default wait before a self-updating node installs a release (releases and updates) |
| 40,320 | 1 week | the exit cool-down of a node's stake (leaving the registry) |
| 172,800 | 30 days | one snapshot cycle, which is also the period of account rent and of price votes (account rent and pruning, price votes) |
A few limits are counted in seconds instead, because they compare timestamps. A transaction, for example, may be included up to an hour after its own timestamp by default (expiry and timestamps).
The spine: one block a day
Beside the main chain, every node keeps the spine, a slow companion chain of checkpoints that carries no transactions (spine chain). It makes one block a day on testnet and mainnet (every 86,400 seconds) and one an hour on devnet. Each spine block is co-signed by the registered nodes and names a main-chain block 760 blocks (3 hours 10 minutes) deep, which gives the main chain a floor that no reorganisation may cross (finality and rollback).
Devnet timings
Devnet, the development network, keeps the 15-second block but shortens many of the durations above, such as the rollback limit (60 blocks) and the snapshot cycle (240 blocks), so that their effects show up within minutes or hours. Testnet and mainnet use the same values. The full comparison is in devnet, testnet and mainnet.