The admission pace

ZooBC admits new nodes to its node registry and its seats one at a time, on a timer that runs slowly on purpose. An operator's share of block production is its share of the seats, so the pace at which seats can be won is the pace at which anyone can gain power over the chain. The protocol fixes that pace, and anyone can watch it.

Why slowly

Under Proof of Work, a share of block production can be bought as fast as hardware; under Proof of Stake, as fast as coins. In ZooBC that share has to be admitted, one node per admission cycle, at a rate set by the protocol. A sudden takeover, for example to reverse a payment, is therefore impossible in principle, not just expensive (what Proof of Participation defends against).

The slowness has nothing to do with the chain's speed. A new node can start from a recent snapshot instead of the whole history, nobody interviews operators, and the chain makes one block every 15 seconds however many nodes it has.

The formula

The delay between two admissions is:

delay = clamp(base ÷ counted seats, minimum, maximum)

On mainnet the base is 600 days, the minimum 7 days and the maximum 90 days. Testnet uses the same values. The first newcomer can be admitted 7 days after genesis. The timer reads block timestamps and admits at most one node per cycle, never in the block that queued it. Which node it admits is decided by the queue.

The delay to the next admission is set when a newcomer is admitted, counting the seats before that newcomer.

Which seats count

• Genesis seats count as at most 11 (a genesis value, 11 on every chain).
• Newcomers count in full.
• Suspended seats count in neither group.

The cap keeps a large genesis from opening the registry fast. Without it, a chain launched with 100 genesis seats would compute 600 ÷ 100 = 6 days, raised to the 7-day minimum, and admit a newcomer every week from the start. With the cap the count starts at 11, and the schedule is the same as on an 11-seat chain. Leaving suspended seats out means that only working seats set the pace.

The schedule

If the queue never empties and nobody leaves, newcomers arrive as follows:

That makes 9 newcomers in the first year, 25 by the end of year 2, 54 by year 3 and about 155 by year 5. From 86 counted seats, 600 ÷ 86 is under 7 days, so the minimum takes over: admissions become weekly from about the 77th newcomer, about 3.5 years after genesis. An applicant who won every single admission would hold its 12th seat, enough to outnumber the 11 genesis seats, only around day 437.

While the base term decides, the registry grows by a fixed fraction per unit of time, because each admission adds one seat and the delay is the base divided by the seats. Doubling the registry therefore takes about base × ln 2, about 416 days on mainnet, whatever its size.

Special cases

• A small registry. While fewer nodes are active than min_registry_size (7 on mainnet), the maximum delay is capped at 7 days.
• After a long stall, the timer admits one node and then resumes its normal cadence.
• Devnet, the development chain, uses the same formula with a base of 180 seconds, a minimum of 60 seconds and a maximum of 300 seconds, so its admissions come minutes apart.

Every input is on the chain, so anyone can recompute when the next admission is due.

See also

• The queue
• The node registry and its seats
• Proof of Participation compared with PoW and PoS
• What Proof of Participation defends against
• Node parameters on mainnet