Sigil’s durable state is held in AkashaKV, an LSM-tree key/value store with multi-version concurrency control, write-ahead logging, and content-addressed snapshots. Every block commits a new state version. Light clients verify state through the per-block BLAKE3 state root.

​
Why an LSM tree

LSM trees give write throughput sufficient for the per-block fanout of transaction types (currency, DEX, NFT, names, mail, mandates, compute, labor, vigils, nova) without sacrificing read latency for indexed lookups. The compaction model produces stable on-disk artifacts well-suited to snapshot publication.

​
State partitions

State is split into typed partitions. Each partition has its own key prefix, value codec, and indexes:
PartitionPrefixPurpose
Accountsacct/Native balances, nonces, bond ledgers.
Stakingstake/Delegation shares, undelegation queue.
Validatorsval/Active set, candidate set, slashing records.
DEXdex/AMM pools, LP positions, non-native balances.
NFTnft/Collections, token records, royalty configs.
Namessns/SNS records, resolver records, delegations.
Mailmail/Mailboxes, key directory, delivery commitments.
Mandatesmand/Issued mandates and delegation trees.
Computecmp/Provider registry, jobs, receipts, challenges.
Storage marketstorage/Provider records, pin contracts, receipts.
Laborlab/Jobs, bids, contracts, escrow, disputes.
Governancegov/Proposals, votes, timelocks.
Treasurytrsy/Reserve accounts and disbursement ledger.
Cruciblecruc/Training run state, weight commitments.
Novanova/Parcels, world records, presence commitments.
Vigilsvig/Subscriptions, ingestor registry, deliveries.
The full partition layout lives in node/sigil-core/src/state_partitions.rs.

​
MVCC

AkashaKV gives every commit a monotonically increasing version. Reads at version v see the consistent snapshot at that height. Block executors read at the parent height and write to the new height. Concurrent readers (RPC, explorer, light client) never block writers.

​
Write-ahead log

Every state mutation appends to the WAL before reaching the LSM memtable. On crash recovery the node replays the WAL up to the last finalised block. The WAL is fsync-tight; a transaction is durable when fsync returns.

​
State root

Each block header contains a BLAKE3 state root computed over the typed partitions in a canonical order. Validators reject a block whose computed state root does not match the proposer’s. Light clients verify state proofs against the root without trusting the RPC. Implementation: node/sigil-core/src/state_root.rs.

​
Snapshots

Snapshots are published every 1,000 blocks at: 
https://snapshots.sigil.ml/<network>/<height>.akasha.snap
A snapshot is the content-addressed tarball of all LSM levels at the snapshot height plus the latest WAL segment. A new validator can sync state-only from a snapshot in minutes (typically 4–8 minutes for a 50 GiB state), then catch up the block tail from libp2p peers. See the snapshot/restore runbook for the operator procedure.

​
Storage migration

Migrating an existing chain to new on-disk layout (AkashaKV pin upgrade, partition rebalance, sharding) is an upgrade-safe operation. The migration must not change:
  • Chain IDs.
  • Address derivation.
  • Account balances, staking amounts, or validator identities.
  • Transaction semantics.
  • Canonical serialisation.
  • State roots.
The migration runbook is at AkashaKV and Weave storage migration. The pinned AkashaKV revision is in AkashaKV pin.