> ## Documentation Index
> Fetch the complete documentation index at: https://docs.intention.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# State layer

> A state model, storage engine, and proof scheme built for a trading chain: versioned per block, sharded for hot markets, and provable at any version.

The state layer stores what the chain committed, in a form built for trading: a small set of hot accounts and markets touched every block, and a full history that auditors and agents need to replay. Every block is a version, every change is tied to the transaction that caused it, and any value can be proven at any version.

## State model

Chain state is the single authority. The [kernel](https://docs.intention.xyz/protocol/architecture/stack/kernel.md) keeps a working copy laid out for matching and clearing, but that copy is always derived from chain state, never the other way round.

Engine statemarkets · accounts · positions · books · clearinghouselives across blocks · a reconstructionBlock working setmarks · touched accounts · fills · staged outputlives for one block · a journalChain stateversioned key-value, Merkle-authenticatedthe authorityThe failure this preventsAn engine whose in-memory view has drifted from what was committed keeps serving answers, and every one of them is wrong in a way that only shows up at settlement.engine state must be derivable from the committed record, never the other way round

* **Every block is a version.** Values are stored against the block that wrote them, so reads, proofs, and replay can target any past block, not only the latest one.
* **Every change has an author.** Each transaction carries its own writes and events. Effects that belong to no single user, such as funding payments and liquidation takeovers, go to a separate system channel. Nothing in the record is unexplained.
* **Configuration is versioned on-chain.** Fees, leverage tiers, and other parameters live in named, versioned keys. Read them from the chain; a value pinned in client code will drift from what the network applies.

## Storage

Committed state is split across three stores, each tuned for one access pattern.

Committed blockLedger storetransactions · outputs · events · write sets · accumulators · block metadataReplay and auditState KV storecurrent and historical values, sharded sixteen ways, hot state in its own tierQueries and executionState Merkle storea versioned sparse Merkle tree, plus the indexes tracking superseded nodesVerification — proofsA read that only needs a value does not pay for tree traversal, and a proof is not reconstructed from a store optimized for point lookups.

| Store | Holds | Tuned for |
| - | - | - |
| **Ledger store** | Transactions, outputs, events, block metadata | Replay and audit |
| **State KV store** | Current and past values by key and version | Fast reads during execution |
| **State Merkle store** | Tree nodes and their stale-version index | Proofs |

Three choices make it fit a trading workload:

* **Sharded writes.** The state KV store is sharded across sixteen RocksDB instances, so one block's writes do not contend on a single database. Frequently used state has its own tier.
* **No undo on failed blocks.** Results of a block that has not committed yet sit in an in-memory overlay. If the block commits, the overlay is written; if not, it is dropped. Storage never holds data that has to be rolled back.
* **Cheap pruning.** When a value is superseded, the old entry is marked stale in an index at the same moment. Pruning is a scan of that index, with no search for garbage.

## Proofs

Two structures, both committed by consensus in every block, make the state checkable.

Versioned sparse Merkle treeAccumulatorsYour key and its valuesibling hashsibling hashState root, committed by consensusYour transaction, or an eventTransaction accumulator · event accumulatoreach commits to everything included so far, in orderLedger root, committed by consensusThe tree proves what a value was; the accumulators prove what happened and in what order. Together they make "this transaction is in the chain at this position" provable without holding the chain.

* **A versioned sparse Merkle tree** proves what a value was at a given block. Versions share unchanged nodes, so updating one account adds one path, not a new tree.
* **Two accumulators**, one for transactions and one for events, prove what happened and in what order.

Backups, restores, and newly synced nodes are all verified against these roots, so no one has to trust the peer or the snapshot they came from.

## State sync

A new node either replays history, which keeps every version, or downloads the current state, which is fast but has no history to query. Both are verified against the committed roots. A node that serves an [indexer](https://docs.intention.xyz/protocol/architecture/stack/services.md#indexer) or an audit process needs the full history. See [Run a node](https://docs.intention.xyz/developers/run-a-node.md).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.