ZooBC wiki
ZooBC basics

The genesis block

You are looking at an old version of this page: revision #31 by zoobc.how, 2026-10-26 20:39 UTC. See the current version

Every ZooBC chain begins with a genesis block, block 0. It is not a message and it carries no transactions: it stands for the chain's whole starting state, from the funded accounts to every consensus parameter. All of it is committed in one hash, and that hash is the chain's identity. Change a single balance and you have a different chain.

Built from a configuration

A chain is created off-line from a configuration file. There is no genesis transaction: the configuration is the state. It sets:

  • the funded accounts and their balances, including the apps treasury that funds the apps pool;
  • the genesis tokens and their balances: every chain has the same 14 genesis coins, such as ZUSD and ZBTC (tokens and markets);
  • vesting schedules;
  • the registered nodes, or genesis seats: 11 on each chain, held by the ZooBC Foundation, each with a 10 ZBC operating balance on the node's own account;
  • the consensus parameters, from the block interval to the starting prices, and the activation height of every rule;
  • the keys with a role, such as the release authority (releases and updates), and the custody addresses of the bridge coins (bridge and wrapped coins).

The genesis builder adds up every credit and refuses to write a genesis whose total would pass the supply ceiling of 33,333,333.33333333 ZBC. What it does not hand out becomes the coinbase pool, released over 15 years (supply and emission). No coinbase is paid at heights 0 and 1.

The genesis block holds accounts and balances, genesis seats, genesis coins, vesting schedules, parameters and rule heights; all go into the configuration hash, from which the genesis hash, the chain's identity, is derived.
The genesis block holds accounts and balances, genesis seats, genesis coins, vesting schedules, parameters and rule heights; all go into the configuration hash, from which the genesis hash, the chain's identity, is derived.

One hash for the whole start

The builder folds everything that matters into one configuration hash. The genesis hash is then derived from the block's version, height, timestamp, a zero previous hash and that configuration hash. The genesis block itself carries an all-zero seed, producer key, signature and previous hash, and its hash is the value derived from the configuration, not a hash of its own bytes. Two values are read but not committed: total_supply and node_operating_balance.

Changing any committed value gives a new genesis hash, and so a different chain.

The chain's identity

The genesis hash is a chain's only identity: there is no network-id byte.

  • Nodes compare genesis hashes when they connect, and refuse a peer whose hash differs.
  • Every transaction signature covers it. The signer signs SHA3-256("ZBC-TX" ‖ genesis hash ‖ the unsigned transaction bytes), so a transaction signed for one chain is invalid on every other (chain-bound signatures).
  • A node reports it as genesis_hash at /api/v1/node/info, so a wallet can tell which chain it is talking to.
  • A test network that is relaunched gets a new hash.

This is why devnet, testnet and mainnet share no balances and no signatures (devnet, testnet and mainnet).

A node never builds a genesis itself: block 0 must already be in its database when it starts (running a node).

No master key

The genesis holds no key that can rewrite the chain later. Rules and parameters change only through new releases, which carry the heights at which rules apply, and through the bounded price votes of the registry's seats (price votes). No key changes a rule, a parameter or a balance by signing a message, and a node binary that disagrees with the rule heights recorded for its chain refuses to run. From version 0.5.8 all 121 consensus rules are in force from height 0.

See also