Economics and governance

ZooBC's economy runs in one direction: what the chain charges for its use goes to the nodes that run it. New ZBC comes from a fixed schedule, fees and rents are collected by the protocol, and all of it is shared out by lottery among the registered nodes, weighted by how well they do their work. No ZBC is ever burned, and nobody, the ZooBC Foundation included, takes a cut. Governance is narrow on purpose: the seats can move a few prices inside fixed bounds, and they hold a check on software releases.

Where new ZBC comes from

• Supply and emission: the ceiling of 33,333,333.33333333 ZBC, and the 15-year curve that releases the coinbase pool, fastest at genesis.
• The coinbase lottery: how each block's new coins, fees and longevity slice are drawn among the nodes in proportion to their participation score.

What using the chain costs

• Fees: the minimum fee that every node computes, the refund of any overpay, and the fee-free duties of nodes.
• Account rent and pruning: the small rent that every funded account pays, and the pruning of accounts that cannot pay it.
• The pools: the longevity pool, which collects rents and penalties and pays a slice in every block, and the storage pool, which pays for stored files.
• ZBC is never burned: why penalties and dust go to the longevity pool instead of being destroyed.

Other charges are explained with their features: dataset and file rent (datasets, decentralised storage pool), keeping transactions (paying to keep data (longevity)), token upkeep (token upkeep (persistence)), and a market's rent and taker fee (markets and orders).

Who decides

• Price votes: the prices that the registry's seats can vote, once per 30-day cycle, to the average of their votes, each vote limited to +20 % or half.
• The ZooBC Foundation: the role keys, and what no key can do.

The seats also hold a check on software releases. The release authority, one key named in the genesis, registers each version with the hash of its files and may revoke it; from version 0.5.8 a version string registers only once, so a fix gets a new version, and a revoked version never returns. When two thirds of the registered seats attest a veto for a version, with suspended seats left out of the count, it is revoked at once, exactly as if the authority had done it: self-updating nodes skip it and the installer refuses it. A vote to replace the authority counts only once its oldest vote is a week old, so the current holder sees it coming; at two thirds, the role passes to the address voted for. Self-updating nodes wait 2 days by default before installing a release, which leaves time for a veto. Operators cast these votes themselves; nothing votes automatically (releases and updates).

See also

• Supply and emission
• The coinbase lottery
• Price votes
• Releases and updates
• The ZooBC Foundation