
premise
Root distributes value in fixed epochs. During each epoch, entitlement accumulates for every wallet according to a rule established before the epoch begins, and that rule remains unchanged until the epoch closes. Once complete, every wallet's final entitlement becomes an individual leaf within a Merkle tree. Each leaf is hashed, paired with another, hashed again, and the process repeats until a single hash remains. That final hash becomes the published root, allowing an entire epoch to be represented on chain by one value regardless of how many wallets participated. A wallet claiming its entitlement does not require the full tree. It submits its allocation together with the sibling hashes forming the path back to the published root, approximately log₂(n) proofs for a tree containing n leaves. The claim instruction reconstructs the path, recomputes the root, and compares the result against the value already stored on chain. A matching proof authorizes payment immediately, while an invalid proof authorizes nothing. A bitmap records every successful claim so the same entitlement cannot be redeemed twice during the same epoch. After the claim window closes, any account may finalize the epoch by calculating the remaining balance as the original distribution minus everything successfully claimed, carrying that remainder directly into the following epoch before its own root is constructed. Unclaimed value never leaves the protocol and is never returned to an administrator. It simply becomes part of the next distribution, while the account performing the rollover receives a small fixed reward. The published root is a deterministic consequence of the leaves that produced it rather than an assertion made by a privileged signer. Once written on chain, it cannot be modified and the closed epoch cannot be reopened. The program itself contains no upgrade authority, which was removed permanently after deployment. The only assumption underlying the system is that every wallet's entitlement can be derived from publicly observable on-chain state, such as balances at a specific slot, instead of values chosen by whoever constructs the tree. The verification process itself requires no trust, since a proof either reconstructs the published root or it does not. The only place trust could enter the system is during entitlement generation, which is why the governing rule must remain deterministic, publicly reproducible, and independently verifiable.
the rings
each ring in the diagram below represents one sealed season, arranged the way growth rings appear in an actual cross section of wood. the center holds the earliest seasons. each ring outward is more recent. the outermost ring is whichever season is currently open.
past seasons shown with placeholder data until the first mark is published.
closed rings are rendered fully defined, each with a labeled line pointing to its season number, its published seal, its total pool, and the portion of that pool claimed versus folded forward. the outermost ring is rendered incomplete, because its totals are still moving and its seal has not yet been computed. once that season closes, its ring hardens into the same fixed state as every ring before it, and a new open ring begins forming beyond it.
a real tree's rings can describe growth only after the fact, to whoever happens to be measuring them. root's rings can be checked by anyone at any time, because the seal for each one was published publicly the moment it closed, and nothing recorded in it can be revised.
regrowth
when a season closes, the value nobody claimed from it is not lost, and it is not held aside waiting to be reclaimed by an operator, because no such operator exists. it is added to the next season's total before that season's seal is sealed, at which point it becomes indistinguishable from everything else accumulating during that new window. this is the entire mechanism by which presence is rewarded. absence is not penalized directly. it simply does not hold a place in the next distribution unless someone claims it before the fold occurs.
no operator
no wallet is capable of publishing a seal that does not match the underlying season data, because the seal is computed deterministically from that data rather than asserted by a signer. no key exists that can revise a season once its seal is recorded. there is no pause instruction, no override, and no privileged account with authority over the sequence of seasons. the program responsible for closing and sealing each season has no upgrade authority. it was removed permanently once deployment completed. if every person who built root stepped away permanently, the next season would still close on schedule, still fold its unclaimed remainder forward, and still seal its record in exactly the same way as every season before it.
terminal states
two edges of this system are worth describing plainly rather than leaving implied. if every entitlement is claimed in every season, nothing ever folds forward, and each season begins the next entirely from zero. that is a complete and valid outcome. it simply means nothing accumulated beyond what each season generated on its own.
the opposite edge holds as well. if nothing is ever claimed, the unclaimed total compounds forward without limit, season after season, indefinitely. nothing in the design caps how large that total can grow, and nothing redirects it elsewhere. it remains in the pool, sealed and provable at every stage, until someone eventually checks. whoever does inherits whatever accumulated in the interim, not as a reward assigned by the system, but because the system was never designed to retain anything for itself. it only holds what has not yet been claimed and passes it forward to whoever claims it next.
