State Chain

The state chain is a deterministic replicated state machine for DAO governance and network configuration. It is separate from the block lattice -- while the lattice is an account-per-chain DAG, the state chain is a single linear chain of blocks containing key-value operations signed by a quorum of DAO members.

Purpose

The block lattice handles asset transfers and compute leasing. The state chain handles everything else:

• DAO keyset management -- which public keys can sign governance decisions, and how many are needed (quorum threshold).
• Timekeeper configuration -- which nodes are trusted to attest timestamps for lease operations.
• Authorized minters -- which accounts may mint XUSD (sys.minter).
• Tokenomics parameters -- the governance-tunable R-curve and payout-cap parameter set (sys.tokenomics) and the protocol phase (sys.phase).
• Oracle configuration and epoch data -- the trusted oracle keyset (sys.oracle) and the per-epoch emission values the oracle publishes under the key prefix that keyset is authorised to write.
• Governance decisions -- any key-value data the DAO needs to publish to the network.

Architecture

┌───────────────────────────────────────────────┐
│                  State Chain                   │
├───────┬───────┬───────┬───────┬───────┬───────┤
│ Block │ Block │ Block │ Block │ Block │ Block │
│   0   │   1   │   2   │   3   │   4   │   5   │
│genesis│       │       │       │       │  tip  │
└───────┴───────┴───────┴───────┴───────┴───────┘
    │       │       │       │       │       │
    ▼       ▼       ▼       ▼       ▼       ▼
┌───────────────────────────────────────────────┐
│              In-Memory KV Store               │
│  sys.dao_keyset  → {keys:[...], threshold:2}  │
│  sys.timekeepers → {keys:[...], threshold:2}  │
│  sys.minter      → {keys:[...]}               │
│  sys.oracle      → {keys:[...], threshold:1,  │
│                     allowed_prefix:"epoch."}  │
│  sys.phase       → 1                          │
│  sys.tokenomics  → {r_init:2000, ...}         │
│  epoch.<n>       → {r_effective:..., ...}     │
│  config.param_x  → "value"                    │
└───────────────────────────────────────────────┘

Each block contains one or more operations (set or delete) that modify the KV store. When a block is applied, its ops update the in-memory state. The KV store is rebuilt on startup by replaying all blocks from genesis — and the replay re-verifies every stored block (index contiguity, hash, prev_hash linkage, signatures) rather than trusting the local store.

Key properties

• Linear. One chain, one tip. No forks under normal operation (forks trigger a callback for alerting).
• Multisig. Every block must be signed by at least Threshold distinct keys from the current DAOKeyset. The one exception is an oracle-scoped block: when sys.oracle is configured and every op in the block targets the oracle's allowed_prefix, the block is validated against the oracle keyset instead. Mixed blocks are rejected, and DAO blocks may not write into the oracle prefix.
• Self-referential. The DAO keyset is itself stored in the KV store under sys.dao_keyset. The keyset can be updated by the keyset -- governance evolves itself.
• Deterministic. Every node replays the same blocks and arrives at the same KV state. No non-deterministic inputs.
• Separate storage. State chain blocks are stored independently from lattice blocks in the backing store.

Comparison with the block lattice

Property

Block Lattice

State Chain

Structure

DAG (account-per-chain)

Linear chain

Signers

Individual account holders

DAO quorum (multisig), or the oracle keyset for oracle-scoped blocks

Content

Asset transfers, leases

Key-value operations

Consensus

Delegation + voting

Threshold signatures

Forks

Conflict detection + resolution

Fork detection + alert

Related pages

• Governance -- DAO keyset, multisig validation, chain mechanics
• Operations -- set/delete operations and the KV store
• Sync -- state chain synchronisation between peers