Where data lives

A Yano node keeps three separate stores. Two are authoritative and one is derived. Knowing which is which tells you what to back up, what you can delete, and what a proof covers.

You’ll learn: what each store holds, which data the state root commits to, and the rules for read indexes.
Before you start: State and proofs.

Where a node keeps its dataConcept

chainstate/: The node's own Cardano data: blocks, ledger state, and the stable L1 view members use to check each block's Cardano reference and observations. Set by yano.storage.path (default ./chainstate). App ledger data never goes below it.
appchain-chainstate/: Every hosted app ledger, one RocksDB database per chain under <path>/<chain-id>/, set by yano.app-chain.storage.path (default appchain-chainstate). Authoritative: back it up, and never delete it to fix an error.
Authenticated state: Every key the state machine writes, plus reserved records such as the height-1 identity markers and the finalized block-message record ([height, messagesRoot, messageCount], on by default). This is what the state root commits to, what members re-execute and compare, and what proofs cover.
Blocks + certificates: Every finalized block with its finality certificate and tip metadata. Written with the state changes in one atomic batch per block, so a crash mid-block leaves the previous height intact.
Framework records: Message, topic, and sender indexes, per-sender sequence floors, vote locks, and membership epochs. They are part of the authoritative ledger store and persist across restarts, but they sit outside the state commitment, so they are not provable by themselves.
appchain-indexers/: Node-local read models, such as the eUTxO lifecycle index. They never take part in consensus, state roots, finality, or proof verification, never advance beyond the authoritative ledger's tip, and rebuild from retained finalized blocks after you delete them. Never restore them as authoritative state.

Each node keeps three sibling stores. Cardano state and app ledger state are authoritative; read indexes are derived from finalized blocks, can be deleted and rebuilt, and must never be restored as authoritative.

Cardano L1 store
app ledger store (authoritative)
read indexes (rebuildable)

Three sibling stores

Store	Holds	Authoritative?	Set by
`chainstate/`	The node’s Cardano data	Yes, for Cardano	`yano.storage.path`
`appchain-chainstate/`	Every hosted app ledger, one database per chain under `<path>/<chain-id>/`	Yes, for the app ledger	`yano.app-chain.storage.path`
`appchain-indexers/`	Local read indexes derived from finalized blocks	No: rebuildable	The indexer’s own setting

The launchers place all three side by side in each node’s directory, for example node0/chainstate, node0/appchain-chainstate, and node0/appchain-indexers. App ledger data never goes below chainstate/, and derived indexes never go into either authoritative store.

Inside an app ledger’s store

One ledger’s database holds two kinds of data, written together in one atomic batch per block, so a crash mid-block leaves the previous height intact.

Under the state root. Every key the state machine writes, plus records the framework authenticates: the height-1 identity markers and, on new ledgers by default, a record of each block’s messages ([height, messagesRoot, messageCount]). ordered-log also writes a record for every finalized message. These are what members re-execute and compare, what the state root commits to, and what proofs cover.

Outside the state root. Blocks with their finality certificates, tip metadata, the message, topic, and sender indexes, per-sender sequence floors, vote locks, and membership epochs. They are authoritative and persist across restarts, and blocks are checked through their certificates and hash links, but an index entry is not provable on its own. To prove something, prove a record that is under the root.

Read indexes

Read indexes, such as the eUTxO lifecycle index, make queries convenient. They follow three rules:

Never an authority. Nothing in consensus, state roots, finality, or proof verification reads them.
Never ahead. An index never advances beyond the authoritative ledger’s tip. The eUTxO indexer reports itself failed with “index checkpoint is ahead of authoritative app-chain tip” if it finds that it has.
Rebuildable. Delete the index and restart the node, and it rebuilds from the retained finalized blocks. If old blocks were pruned, it does not invent the missing rows.

Never restore appchain-indexers/ as if it were authoritative state, and never restore it into either authoritative store. The Verifiable Explorer’s index follows the same rules from outside the node: it is a separate database that any node can rebuild.

Stopping, cleaning, and backing up

./yano.sh appchain cluster stop stops the nodes and keeps all three stores; clean stops them and deletes the whole cluster directory.
./showcase.sh stop --instance <name> keeps the instance; ./showcase.sh reset --yes --instance <name> deletes it and cannot be undone.
Back up the authoritative stores, never the read indexes in their place. For an app ledger, a snapshot gives you a signed, verifiable copy.

Retained data carries the ledger’s identity. Do not regenerate the genesis id or mix stores from different ledgers.

Next: Restart, catch-up and snapshots.