Data and storage
You are looking at an old version of this page: revision #1062 by zoobc.how, 2026-10-27 00:42 UTC. See the current version
ZooBC keeps data as well as payments. A profile, an invoice, a token's icon, a small web page or a large archive can each find a place on the chain or beside it. Every node must store what the chain keeps, so space is paid for: nothing is kept for free and forever, and the rent goes to the nodes that do the keeping.
Four ways to keep data
| What | How big | Where the bytes are | Article |
|---|---|---|---|
| A dataset row | property up to 256 bytes, value up to 4,096 bytes | in the chain's state, on every node | Datasets |
| A DFS file | up to about 64 KiB | inside its own transaction, kept by the nodes beside the chain | Files on the chain (DFS) |
| A stored file | up to 100,000 pieces of 1 MiB | on five registered nodes per piece; only the manifest is on the chain | The decentralised storage pool |
| A transaction kept by a deposit | one transaction | in its block, on every node | Paying to keep data (longevity) |
Nothing is kept for free
Each kind of data pays rent once per period: 172,800 blocks, about 30 days, on mainnet. The prices below are starting values, which the seats can vote down as far as one atomic unit (price votes).
- Dataset rent. Dataset rows and DFS files pay 0.05 ZBC per MiB of their bytes, to the longevity pool.
- File rent. A stored file pays 0.05 ZBC per started MiB, to the storage pool, which pays the nodes that prove they hold the pieces.
- Longevity rent. A record that keeps a transaction pays for its bytes after two free periods, to the longevity pool.
- Account rent. Every account that holds ZBC pays 0.01 ZBC, to the longevity pool (account rent and pruning). From version 0.5.8 no vote can raise it above 10 ZBC per period.
When the money runs out, the data goes: dataset rows are deactivated, a stored file is pruned, a kept transaction becomes prunable, and an account that cannot pay is pruned, its dust moving to the longevity pool. Rent is what clears abandoned and junk accounts, lost keys included, out of the state that every node must keep, and no ZBC is lost on the way.
ZBC is never burned (ZBC is never burned). The longevity pool pays the nodes a slice in every block through the coinbase lottery (pools). None of the rent goes to the ZooBC Foundation, and nobody earns it as interest for holding coins.
History and the past
Below a horizon tied to the snapshots, nodes delete old blocks and transactions, so a running node holds 30 to 60 days of blocks on mainnet (pruning of history). Current state, such as balances and records, is not pruned this way.
The decentralised storage, not every node, keeps every snapshot from block 0, so that anyone can rebuild the state at any past snapshot (archive and reading the past).
Articles in this category
- Datasets: small records, with owners, deposits and rent
- Files on the chain (DFS): small files inside a transaction
- The decentralised storage pool: large files, their holders and storage proofs
- Paying to keep data (longevity): keeping a transaction past pruning
- Pruning of history: what nodes delete and what they keep
- The archive and reading the past: snapshots and reading the past
See also
Articles in this topic
- Datasets
Small on-chain records: a property and its value that one account writes under another, grouped in objects with an owner, a deposit address and rent. - Files on the chain (DFS)
DFS files are small files, up to about 64 KiB, whose content travels inside a transaction and whose record is a dataset row under the "dfs:" prefix. - Paying to keep data (longevity)
How a longevity deposit keeps a transaction and its block on every node past pruning, what it costs, who may fund it and how the record ends. - Pruning of history
Which old blocks and transactions a ZooBC node deletes, which it always keeps, and why a running node holds 30 to 60 days of blocks on mainnet. - The archive and reading the past
How ZooBC's decentralised storage keeps every snapshot since block 0, so that anyone can rebuild and check the state at any past snapshot. - The decentralised storage pool
How large files are cut into 1 MiB pieces, held by five registered nodes chosen by a shared draw, proved every hour and paid for by rent.