I am rebuilding ZooBC from the ground up.

Proof of Participation (PoP)

What it is

ZooBC introduces Proof of Participation, a consensus approach designed to reward nodes not just for creating blocks, but for doing the day-to-day work that keeps a peer-to-peer blockchain alive: staying online and propagating blocks and transactions quickly across the network.

Why it exists

Many blockchains reward only block producers and have no trustless way to measure which nodes actually relay messages, which can incentivize "efficient" actors to avoid gossiping while still collecting rewards.

How ZooBC measures participation

When nodes exchange blockchain data, the receiving node can return a digitally signed receipt acknowledging it received that data. Nodes later prove participation by including receipts (in Merkle-root form) in blocks, making participation auditable at consensus level and turning network propagation into something that can be measured and rewarded.

Node Registry + participation score

ZooBC uses a protocol-governed Node Registry: only registered nodes can create blocks and receive coinbase, and the protocol controls how nodes join/leave (not a centralized admin). Each registered node has a participation score that rises/falls based on behavior; falling to zero leads to automatic ejection from the registry, pushing operators to remain consistently online and well-connected.

Coinbase

Zero premine

ZooBC states that it has no pre-mined tokens: at genesis the supply starts at zero, and new tokens are created as blocks are produced.

How new tokens are distributed

At each block, newly created tokens are distributed to nodes in the Node Registry using a pseudo-random selection process tied to the block seed, and a node's chance of being selected is proportional to its participation score. As honest nodes converge toward strong participation, rewards tend toward a more even distribution across the set of reliably participating operators.

Why this matters

The design goal is to align issuance with maintaining a healthy decentralized network, rather than rewarding only the ability to create blocks while leaving propagation work to unpaid enthusiasts.

Fees Model

The problem: volatile tokens, unstable fees

In public blockchains, if fees are fixed in the native token, real-world cost swings with token price—making fees too cheap to stop spam at low prices, or too expensive for normal use at high prices.

ZooBC's approach: fee scaling governance

ZooBC introduces a network parameter called the fee scale, a multiplier applied to each transaction type's minimum fee calculation, and it is periodically adjustable. To update it, registered node operators vote in monthly cycles using a commit–reveal process (commit phase then reveal phase) so votes can be recorded and counted without being trivially guessable during the commitment stage.

How the final value is chosen

Revealed votes are ordered and the median is selected (not an average), which reduces the impact of outliers; then the change is bounded so it can at most double or halve vs. the previous period to limit sudden swings.

ZooBC P2P Network

A known set of consensus participants (without central admission)

ZooBC separates "anyone can run a node" from "who is allowed to create blocks": block creation and coinbase distribution are restricted to a protocol-managed subset called the Node Registry. Crucially, admission/ejection is controlled by on-chain rules (queueing, trial participation, score-based removal), not by a single authority deciding membership.

Why registry-based participation helps security

By requiring registered nodes to regularly prove participation using signed messages/receipts, ZooBC aims to increase the number of independent keys and operators involved in producing the canonical history, making censorship/collusion harder than in small federations.

Topology incentives

ZooBC's PoP goals include incentivizing nodes to organize into an efficient network topology, reducing propagation hops and improving data spread.

Decentralised Data Storage

The problem: everyone storing everything forever

If every node must store all historical blocks and large data forever, blockchains become expensive to run and hard to join—hurting decentralization over time.

ZooBC's model: torrent-like chunk distribution

ZooBC describes a decentralized file distribution strategy where old snapshots and block backup files are split into chunks and responsibility for storing those chunks is assigned deterministically across Node Registry members. Nodes can delete chunks they are not responsible for, freeing disk space, while still keeping redundancy across the network so data remains retrievable and verifiable by hash.

Redundancy that improves with network growth

The protocol targets multiple redundant copies of each chunk, with the number of copies computed as a function of registry size (designed so per-node burden decreases as the network grows).

Snapshots and Blocks Backup

Constant-time(ish) sync: the goal

ZooBC aims to reduce "download the whole chain since genesis" into a shortcut: new nodes should be able to join quickly even if the chain is decades old.

Spine blocks: cryptographic checkpoints

ZooBC introduces special daily blocks called spine blocks that checkpoint chain state and (periodically) include the hashes of database snapshots, allowing nodes to trust and fetch a recent state efficiently. Spine blocks require signature accumulation from many registry keys, and nodes select the spine-block chain with the highest cumulative difficulty score, similar in spirit to choosing the best chain by work/difficulty.

Snapshots + backups: fast join, full recoverability

Nodes periodically build a snapshot of their database state; new nodes can download the latest snapshot identified by spine blocks, then only download recent blocks since that snapshot. To preserve the ability to reconstruct historical states or inspect old transactions, ZooBC also defines block backups for archived ranges that can be retrieved from the network when needed.

Assets, Signatures, and Transactions

Built beyond pure payments

ZooBC uses an account model and supports specialized account types, including asset-style accounts intended to represent non-fungible "titles" (e.g., warehouse receipts, land ownership) and other real-world representations.

Multiple signature/address formats

Instead of forcing a single signature scheme, ZooBC allows users to choose from supported address types, each with its own signature format; the paper even describes the idea of using a Bitcoin-style address format on ZooBC so the corresponding key can sign spends on ZooBC (without implying cross-chain transfer by default).

Transaction types with practical business logic

ZooBC ships with explicit transaction types rather than on-chain general-purpose smart contracts, arguing that immutable VM-based code can be a liability for serious business logic that needs upgrades and governance. It also includes mechanisms such as escrowed transactions (approval-based transfers with timeouts) and liquid transactions (continuous streaming payments over time).

Wallets, Plugins, Integrations, and SDK

Collateral technologies are part of the plan

ZooBC describes a broader toolset beyond the core chain—wallet software and supporting tooling meant to make key workflows (like node registration and proof collection) usable without specialized knowledge.

Node operations designed for real users

The paper explicitly mentions wallet/UI support to help operators collect a node "proof of ownership" message and assemble node registration transactions, smoothing the experience of becoming a registry participant.

Ecosystem readiness

ZooBC's long-term roadmap positions the base chain as a foundation for broader integrations and application layers, with an emphasis on practical deployment patterns rather than forcing all logic into a narrow on-chain VM.

Tools and Testing Framework

A research + engineering initiative

ZooBC frames itself not only as a blockchain implementation but as an ongoing research initiative, iterating releases and parameters through testing and experience operating the network.

Why tooling matters

Key subsystems (receipt filters, batch sizing, pruning, snapshot timing, and other constants) are described as tunable and to be refined through alpha/beta testing—making test frameworks and operational tooling essential to reach safe defaults.

Open-source development

The book indicates the project's code and supporting work are open-sourced under permissive licenses, and that community contributions can be incentivized via bounties/rewards.

Block Explorer and Service Server

Not every node must be identical

ZooBC allows for specialized roles such as archival nodes, which keep the full historical data for users/services that need complete indexing (e.g., block explorers and analytics).

Archival nodes as resilience backstops

Even with distributed chunk storage, ZooBC acknowledges the possibility of rare availability failures (many custodians offline at once) and positions archival nodes as a way to mitigate catastrophic data loss risks while keeping verification possible by hash.

Service-oriented infrastructure

The design anticipates infrastructure components (explorers, statistics, notification services) that can leverage spine blocks and snapshots to locate and verify the needed historical or state data efficiently.