Cairn: a chain whose validation state does not grow

A proof-of-work currency in which the state every node must hold is capped by consensus rule at a fixed size, and everything beyond that cap is carried in sixty four hashes.

Abstract

Every deployed chain grows the state a validator must hold as it is used. Bitcoin's unspent output set is past 170 million entries and roughly 11 GB; Ethereum has pursued statelessness for years and its own documentation places it several years from mainnet. The consequence is uncomfortable and rarely stated plainly: the more a chain succeeds, the fewer people can afford to verify it, and verification drifts toward the parties that can.

Cairn caps that cost by rule. A bounded hot set of 131 072 notes is held in full by every node, measured at 516 bytes each, about 68 MB, and that figure is a ceiling rather than an average. Everything older lives in an append-only Merkle forest which a node carries as sixty four hashes, whatever its size. Spending from it takes an inclusion proof supplied by the spender and checked against roots the node already holds. Nothing is ever destroyed, expired, or charged rent.

The design accepts a proven cost rather than claiming to escape it. Christ and Bonneau show that a succinct global state forces a near-linear rate of local proof updates [1]; Cairn falls on that side deliberately, and confines the burden to notes that have not moved in a long time. Headers commit to accumulated work and to a forest of every earlier header, so that joining the chain need not mean downloading it.

1

The problem is the cost of verifying, not the cost of transacting

A permissionless currency works because many independent parties check it. Nobody is in charge, so the checking is what prevents cheating. The security of the system is therefore a function of how many people can afford to be one of those parties.

That number falls as the chain succeeds. A full node holds the set of unspent outputs and validates every rule against it, and that set grows with adoption. Bitcoin's is past 170 million entries and roughly 11 GB [2]. Ethereum's state has driven a research programme spanning state expiry, weak statelessness and Verkle trees, which its own roadmap places several years out and dependent on two other unfinished efforts [3].

The usual answer is that hardware gets cheaper. Perhaps, but the direction is still wrong: the ratio between what a chain demands and what an ordinary person owns moves against the person. Light clients do not resolve this. They change who is trusted rather than removing the need to trust.

Cairn treats the growth of validation state as the design problem, not as an operational detail to be managed later.

2

Notes, and why they are not balances

Cairn keeps notes rather than accounts. A note is a value locked to a public key, identified by the transaction that created it and its index among that transaction's outputs. It is written once and consumed once. This is the unspent output model, as in Bitcoin.

The choice is not stylistic. An account balance must be read and written, so the account has to be held. A note is created once and destroyed once, which means a node can hold a commitment to it instead of the note itself, and can forget it entirely while remaining certain about what remains. Everything that follows depends on this property.

Ordering over note identifiers is defined, so the note set has exactly one canonical enumeration, which the state commitment depends on. Transfer identifiers exclude signatures and witnesses. That gives malleability resistance, and more importantly it means a stale inclusion proof can be replaced with a fresh one without changing any identifier that anything else has committed to.

Hashing is BLAKE3 with a distinct derived key per domain, so a value hashed as a note leaf can never be read as a header leaf or a Merkle node. Signatures are Ed25519 with two restrictions beyond the standard: small-order keys are rejected at construction, and non-canonical encodings are refused, so two byte strings can never name one key. Every signature commits to the network, the version, the transaction identifier, the input index, and the value and owner of the note being spent. Committing to the spent note is the lesson of transaction formats that could be deceived about their own inputs.

3

Two tiers, and only one of them is held

Validation state is split in two by a consensus rule.

Figure 1. What a node holds, at any age of the chain
Hot set
Held in full by every node Notes that have moved recently, in a sparse Merkle tree, capped at 131 072 entries. When the cap is reached, the oldest are evicted at block boundaries by a rule every node applies identically. 131 072 notes · 516 bytes each measured · 68 MB at capacity
Cold set
Held by nobody An append-only Merkle forest of everything evicted. A node keeps its roots and nothing else. Spending from it requires an inclusion proof, supplied by the spender, verified against those roots. unbounded contents · 64 hashes · 2 kB, constant

The cap is consensus, not configuration. Two nodes disagreeing on it would evict different notes at the same height, produce different state commitments, and follow different chains while each believed it was on the same one.

3.1The hot set

A sparse Merkle tree, persistent through structural sharing so that a reorganisation restores the previous root without a rebuild. Eviction is by age, oldest first, in batches at block boundaries. The measured cost is 516 bytes per note, which is the note, its identifier, and its share of the tree. Rather more than half of that is the tree, which makes a leaner tree the clearest remaining optimisation; it changes no rule.

3.2The cold set

An append-only forest of perfect binary trees, held as one root per possible height. This is the structure introduced by Utreexo [4], and Cairn does not claim it.

The property the whole design turns on is that adding a leaf requires only the roots. A node holding none of the set can still extend the accumulator correctly, which is not true of a plain Merkle tree. On insertion the new leaf rides on the right of every merge, so the trees it swallows are its own siblings in order, and the inclusion proof falls out of the addition itself at no extra cost.

Removal is batched. Every proof in a block is verified against the pre-block root before anything is applied, then applied in order with the remaining proofs refreshed, so two cold spends in the same block cannot invalidate each other.

3.3Where Cairn differs from prior accumulator work

Utreexo is a node-level optimisation. Any operator may adopt it independently, the protocol is unchanged, and the underlying set remains unbounded. Accumulator schemes over RSA groups, such as MiniChain [5] and CompactChain [6], achieve constant-size commitments but require a group of unknown order, meaning either a trusted setup or class groups, and likewise leave the set unbounded.

Mina takes the opposite route to the same goal, compressing the entire chain to about 22 kB with recursive zero-knowledge proofs [12]. It works, and it is the most complete answer to this problem in production. The price is proof of stake, with the initial distribution that implies, and a cryptographic stack almost nobody can audit. Cairn pays a different price for a weaker guarantee: the state is bounded rather than eliminated, and everything used to do it is old and widely understood.

Cairn's contribution is not the accumulator. It is the pairing of a consensus-enforced cap on the held tier with an accumulator for the remainder, so that what a validator must hold is bounded by rule rather than by the operator's choice of implementation.

4

Spending what nobody holds

A spender of a fallen note supplies an inclusion proof. The node verifies it against roots it already has and never needs the set. Two windows make this workable rather than merely correct.

4.1The proof window

A proof may be up to PROOF_WINDOW = 32 blocks stale. Without this, a transfer written while a block was being found would be invalid by the time it arrived, through no fault of its author. Verification walks backwards through recent roots and stops at the first block that emptied the position. An earlier version of this check compared roots before checking whether the position had been spent, which permitted a double spend; the ordering is load-bearing.

4.2The grace window

A note that has just fallen remains spendable with no proof at all for GRACE_BLOCKS = 64 blocks, bounded also at GRACE_NOTES = 8 192 entries. Every node still holds both the note and its proof during that window, so nothing is asked of the spender. Without it the boundary between tiers would be a cliff that a payer falls off for no reason of their own.

Utreexo has a comparable observation, that outputs created and spent within one block need not enter the accumulator at all [4], and roughly 40% of outputs live fewer than twenty blocks. There it is an optimisation each node may choose. Here it is a rule the whole network applies, which turns a likelihood into a guarantee for whoever is paying.

4.3Archivists

A wallet keeps its own proofs current from what every block already carries, and asks nobody. A wallet that has been offline long enough, or that has lost its records, needs someone who kept the cold set. Archivists are optional nodes that do. Nobody pays them, and the network does not depend on them: joining a chain takes the headers, which every node keeps at 182 bytes each, and a wallet that kept its own proofs asks no one. What an archivist offers is recovery for a wallet that lost theirs.

They were in the design from the first day, for an intuition. Section 8 explains why they turn out to be structural rather than convenient.

5

Consensus

5.1Proof of work, and why not stake

The reason is the beginning rather than the steady state. Proof of stake requires an initial distribution before it can function, which means somebody decides who holds influence on day one. Proof of work requires nobody to decide anything: the network opens and the first block goes to whoever mines it. For a currency whose claim is that no party is privileged, the opening is exactly where that claim is tested.

5.2Difficulty and timestamps

Difficulty retargets every block over a linearly weighted moving average of the previous 90, with solve times clamped at six times the target and a maximum factor of four per retarget. A large miner arriving or leaving changes the rate without stranding the chain.

Timestamps are validated against the median of the previous 11 blocks rather than against the parent. A miner writes its own timestamp but holds one vote in a median, which removes the single-block manipulation that a later-than-parent rule permits. A block may not be dated more than two hours ahead of the receiving node's clock, nor before the moment the network opened.

5.3Fork choice

By cumulative work, not length. Ties keep the branch already followed, so churning the tip costs work rather than nothing. A switch is applied atomically: each applied block records its own inverse, and a bad block discovered partway through a switch returns the node exactly where it was.

Undo records are kept for the most recent MAX_REORG_DEPTH = 1 024 blocks and a deeper switch is refused. This is a local safety policy rather than a consensus rule: two nodes with different limits build the same chain and differ only after a reorganisation deeper than either would accept, which on a live network means an attack or a partition lasting most of a day.

6

Emission

Nothing is allocated. There is no sale, no founder allocation and no reserve; on the day a network opens the supply is zero and every unit since has been paid for the work of finding a block. The first blocks of both existing networks pay nobody at all.

The reward begins at 50 CAIRN and halves every 1 051 200 blocks, about two years at a one minute block time, until halving would take it below a floor of 0.01 CAIRN, which is then paid indefinitely. Roughly 105 million CAIRN exist by the time the floor takes over. The smallest unit is the pebble, at 108 to one CAIRN.

The perpetual tail is deliberate. Whether transaction fees alone can fund security in the long run is an open question, and a chain whose central promise is verifiability in thirty years cannot rest its security budget on an open question. The price is a known, small and permanently decreasing rate of dilution.

7

Joining a chain without downloading it

A bounded steady-state cost is not the whole promise if arrival is unbounded, and this is where the design was weakest.

7.1The measured cost of arrival

On this implementation, at one block per minute with blocks carrying 64 transfers, thirty years of chain is 48 GB to download and 5.3 hours to revalidate on one core, to arrive at a validation state weighing 68 MB. The wall is bandwidth, not computation.

7.2What headers commit to

Every header carries two fields beyond its own block, for 48 bytes:

Accumulated work. The work behind this block and every block before it, checked against the parent's, so a block cannot claim work it did not do.

A commitment to every earlier header. The root of an append-only forest holding one leaf per header, carried by a node as sixty four hashes exactly like the cold set, at a cost of one append per block.

These were added before any network carried value, because they could not be added afterwards: changing the shape of a header invalidates every block already mined. The test network took the next number when they landed, which cost nothing at the time and would have cost everything later.

7.3Sampled verification

With those commitments, a newcomer holding only the tip can be handed a logarithmic sample of old headers, verify that each sits where it claims in the tip's commitment, and conclude what work stands behind the tip without reading the headers in between. This is FlyClient [7], whose security rests on the same assumption as the chain itself, that no adversary controls a majority of the work.

The earlier superblock approach, NIPoPoW [11], achieves a similar compression by showing only unusually heavy blocks, but is vulnerable to bribing the miners who find them into withholding them. FlyClient's sampling has no equivalent target and is the construction to follow.

Cairn takes the published construction with its proven distribution rather than devising its own. It is implemented: a newcomer draws 512 headers against accumulated work rather than height, with a Fiat-Shamir seed taken from the tip, and each opened header is checked against the tip's own commitment. Joining a thirty year chain costs 12 MB against 2 067 GB of reading.

The count follows from the assumption the chain already makes. A forger cannot mine what it did not mine, so a chain heavier than the honest one, presented by a party holding a share s of the world's work, has at least 1 − s/(1−s) of itself invented: work no block of it spans. At a third of the world's work that is half the chain. Each draw lands in invented work with that probability, so 512 draws miss with probability at most 2-128 for every share up to 45.7%. Beyond that the count would have to grow without bound, and at half the work there is nothing left to invent — which is the point at which proof of work stops protecting anything.

Measurement checks the derivation the other way, by forging chains and watching them fail, and it also shows why the distribution must be taken and not improvised: under a uniform draw, a forger who keeps the real chain and fakes only the last twenty blocks goes unnoticed 88% of the time, which is precisely why FlyClient samples the recent end of the chain more densely.

Serving that sample takes the headers and the forest they make, which a node keeps on disk at 182 bytes a header: 129 MB a year, against 50 GB a year for Bitcoin and 200 for Ethereum. Every node keeps them, so joining a chain does not depend on anyone volunteering to carry its history. Blocks a node has already applied are dropped once it has written down the ledger they add up to, which is what stops a node's disk from growing with the chain.

One practical note in Cairn's favour. A production study of FlyClient reports that proof size is dominated by header size, at 1 344 bytes per header on the chain it was deployed to, and that restructuring headers would reduce proofs by 71% at the cost of a consensus change it can no longer make [8]. A Cairn header is 182 bytes.

8

The limit that applies, and where Cairn falls

Christ and Bonneau prove an information-theoretic result about any system of this shape [1]: there is no useful trade-off point. A system must either hold a global state linear in the number of accounts, or require a near-linear rate of local proof updates as coins are spent. They add, and this bears directly on the design here, that so long as the succinct state is too small to capture the full state, enlarging it helps little.

Cairn falls on the proof-update side of that dilemma, deliberately, and had accepted the cost before knowing it was proven inevitable.

A wallet refreshes its own proofs from what every block already carries. The hot set does not repeal the result; what it changes is who is affected. Notes that have moved recently, which are the ones ordinarily spent, are held in full by every node and require no proof at all. The obligation falls only on value that has not moved in a long time.

The authors name proof-serving nodes, third parties holding the full state and producing current witnesses for others, as the natural relaxation, and call for work on how such parties would be compensated. Those are Cairn's archivists. They were included for an intuition and turn out to be structural.

Cairn does not answer the compensation question; it narrows what rests on it. Two services were bundled under the name: showing a newcomer which chain carries the most work, which the network cannot do without, and rebuilding the proof of a note whose owner lost theirs, which it can. The first was separated out and made small enough that every node performs it — 182 bytes a header, 129 MB a year — so nothing in the protocol now depends on a party being paid. What is left is recovery for a wallet that kept no records, and a wallet that keeps its own needs no one.

9

What this borrows, stated plainly

Overclaiming is the fastest way to lose the only readers whose opinion matters.

The append-only forest carried by its roots is Utreexo's [4]. Spender-supplied inclusion proofs are the common model of Utreexo, MiniChain and CompactChain. The header commitment and work-weighted sampling are FlyClient's [7]. The archivists are the proof-serving nodes of Christ and Bonneau [1], arrived at independently. None of the cryptography is novel, and it is not meant to be: BLAKE3 and Ed25519, both with domain separation and canonical encoding enforced, and no trusted setup anywhere.

What a survey of the field did not find an equivalent of: a hot set capped by consensus rule; the two tiers paired, holding a bounded set in full while carrying the remainder in constant space; a grace window as a network rule rather than a per-node cache; and bounding state without destroying anything. Ergo charges storage rent and lets a miner take a box left idle for four years [9]; a December 2025 proposal to the bitcoin-dev list would render outputs below a moving floor permanently unspendable [10]. Both bound the state by removing value from its owner, which the first guarantee here forbids.

A search is not proof of absence, and this section should be read as a claim about what was found rather than about what exists.

10

Parameters and measurements

Every figure below is measured on the implementation rather than estimated, on one core of an ordinary machine.

Hot set capacity131 072 notes
Bytes per hot note, measured516
Hot set at capacity68 MB
Cold set carried by a node64 hashes, 2 kB
Proof window32 blocks
Grace window64 blocks, 8 192 notes
Difficulty window90 blocks, LWMA
Median time past11 blocks
Maximum retargetfactor 4
Maximum reorganisation depth1 024 blocks
Initial reward50 CAIRN
Halving interval1 051 200 blocks
Tail reward0.01 CAIRN, perpetual
Header size182 bytes
Empty block196 bytes
Block with 64 transfers3 211 bytes
Validation, empty block0.009 ms
Validation, 64 transfers1.21 ms
Thirty years of chain at one block per minute, blocks carrying 64 transfers
Quantity Size Bounded?
All blocks, to download 48 GB No, grows with history
All headers, to read 2 GB No, grows with history
Revalidating from genesis 5.3 h No, grows with history
Validation state a node holds 68 MB Yes, by consensus rule
Blocks a node may hold to undo 233 MB Yes, by the block size and window
Headers a node keeps on disk 3.9 GB No, 129 MB a year
Cold set a node carries 2 kB Yes, whatever its contents
Header history a node carries 2 kB Yes, whatever the height

The first three rows are what arriving used to cost, and section 7 is how it stopped costing that: a newcomer is handed 12 MB rather than reading any of it. The rows below are the cost of participating, and only one of them grows.

11

Limitations

Nothing here has been audited. No external review has taken place. The only network in existence is a test network whose currency is worthless by design and which will be reset.

The sample count rests on the majority assumption and nothing weaker. A newcomer opens 512 headers, which holds against any forger up to 45.7% of the world's work at 2-128. Past that no count would do: a forger at half the work has nothing left to invent and can simply mine the chain. The margin between 45.7% and 50% is the price of a bounded proof, and doubling the count moves it only to 47.8%.

A node that joined cannot take in a newcomer. Showing which chain carries the most work takes the headers from the first block, and a node handed a ledger has them only from where it was handed on. It can become one by reading the chain; nothing else is lost.

The theorem's cost is real. A wallet offline long enough, or one that lost its records, must ask an archivist. Nobody is paid for that service and the network runs without it, which bounds the problem rather than solving it: a wallet in that position depends on someone having chosen to keep the cold set.

Smaller. An archivist rebuilds a proof in time proportional to the depth of the set rather than its size. Over half of what a hot note costs is the tree that commits to it, which is where the room left is.

The implementation is roughly 28 600 lines of Rust with 378 tests, no unsafe code, no asynchronous runtime, and five dependencies. Arithmetic side effects, slice indexing, and panicking helpers are denied at the workspace level. It is small enough to be read, which is the point: a chain asking people to verify for themselves should be verifiable in more than one sense.

12

References

  1. M. Christ and J. Bonneau. Limits on revocable proof systems, with applications to stateless blockchains. Financial Cryptography and Data Security, 2023. eprint.iacr.org/2022/1478
  2. Bitcoin Optech. Utreexo topic page, UTXO set size figures. bitcoinops.org/en/topics/utreexo
  3. Ethereum Foundation. Statelessness, state expiry and history expiry. ethereum.org/roadmap/statelessness
  4. T. Dryja. Utreexo: a dynamic hash-based accumulator optimized for the Bitcoin UTXO set. MIT Digital Currency Initiative, 2019. eprint.iacr.org/2019/611
  5. MiniChain: a lightweight protocol to combat the UTXO growth in public blockchain. Journal of Parallel and Distributed Computing, 2020.
  6. CompactChain: an efficient stateless chain for UTXO-model blockchain. Frontiers of Computer Science, 2023. arxiv.org/abs/2211.06735
  7. B. Bünz, L. Kiffer, L. Luu and M. Zamani. FlyClient: super-light clients for cryptocurrencies. IEEE Symposium on Security and Privacy, 2020. eprint.iacr.org/2019/226
  8. Catching the Fly: practical challenges in making blockchain FlyClient real. 2026. arxiv.org/abs/2604.26736
  9. Ergo Platform. Storage rent. docs.ergoplatform.com/dev/protocol/storage-rent
  10. Reducing RAM requirements with dynamic dust. bitcoin-dev mailing list, December 2025. groups.google.com/g/bitcoindev
  11. A. Kiayias, A. Miller and D. Zindros. Non-interactive proofs of proof-of-work. 2017. eprint.iacr.org/2017/963
  12. O(1) Labs. Mina: a 22 kB blockchain, technical reference. minaprotocol.com