Identity layer
Every account on Sigil is an OAS DID with the formdid:oas:sigil:<kind>:<identifier>. Eleven entity kinds are recognised, of which the lineage-bearing ones are hmr (single human root), mhr (multi-human root under a FROST threshold), and agent (autonomous descendant of a root).
Identity carries lineage. An agent’s DID document includes a signed proof linking it to a parent DID. That parent’s DID document carries its own lineage proof. The chain terminates at an hmr or mhr. Every action by an agent is therefore attributable to an accountable human or group.
Addresses are derived from DIDs, not from raw keypairs:
Consensus layer
Sigil uses MACA, a four-round Byzantine Fault Tolerant consensus protocol. On the happy path a block finalises in a single round. The four rounds are propose, prevote, precommit, and finalise, all completed within the target six-second block time. Block producers are elected per height from the active validator set using a deterministic VRF over the previous block’s randomness beacon. Block validators vote on proposals. A 2f+1 quorum is required to finalise. Equivocation, invalid blocks, and missed rounds are slashable. On top of MACA, Tower provides Casper FFG epoch finality. Every 1,000 blocks the chain locks an epoch under Tower. Once locked, those blocks cannot be reorged without a coordinated attack on more than one-third of stake, at which point Tower’s accountable safety property identifies the offending validators and slashes them by their full bonded stake. The mempool enforces admission rules before transactions reach consensus: signature verification, replay protection (per-DID nonce), balance and bond checks, and fee market acceptance. Local fee markets per transaction class prevent a flood of cheap transactions from crowding out signed-fee transactions.Execution layer
Sigil keeps the consensus kernel native, in Rust, and pushes chain policy into WASM system contracts. The split is deliberate: native code owns the rules that cannot fail (quorum, signatures, replay, state roots, slashing finality), and WASM owns the rules that can be tuned safely (staking parameters, validator registry, governance, treasury policy). The native executor handles 58 transaction variants, organised into categories: identity, staking, currency, DEX, NFT, names, mail, mandates, compute, labor, governance, treasury, Crucible, Nova, and Vigils. Each variant has a typed argument struct, a deterministic semantic check, and an apply function that writes to AkashaKV under a typed state partition. System contracts run inside a sandboxed WASM executor (Wasmtime) with deterministic gas accounting. They are pinned at genesis, addressable by name (sigil.system.staking, sigil.system.governance, etc.), and upgradeable only through the governance system contract under a 90-day timelock.
Organisation zones extend the same model. A zone is a WASI execution environment scoped to an organisation DID. Zones can deploy private contracts, hold their own balances, and route messages between zones via CZAC channels. The zone executor is gas-metered, syscall-bounded, and storage-isolated.
Settlement layer
State lives in AkashaKV, an LSM-tree key/value store with MVCC, write-ahead logging, and snapshot/restore. Every block commits a new state version. The block header includes a BLAKE3 state root computed over the typed partitions, which lets light clients verify state without trusting the RPC. State partitions are typed:| Partition | Contents |
|---|---|
accounts/ | Native balances, nonces, and bond ledgers. |
validators/ | Active set, candidate set, slashing records. |
staking/ | Delegation shares, undelegation queue. |
dex/ | AMM pools, LP positions, non-native asset balances. |
nft/ | Collections, token records, royalty configs. |
names/ | SNS records and resolver state. |
mail/ | Mailbox capability records, key directory, delivery commitments. |
mandates/ | Issued mandates and their delegation graphs. |
compute/ | Provider registry, job state, receipts. |
labor/ | Jobs, bids, contracts, escrow, disputes. |
governance/ | Proposals, votes, timelocks. |
treasury/ | Reserve accounts and disbursement ledger. |
crucible/ | Training run state and weight commitments. |
nova/ | Parcels, world records, presence commitments. |
vigils/ | Subscriptions, ingestor registry, delivery records. |
https://snapshots.sigil.ml. A new validator can sync state-only from a snapshot in minutes, then catch up the block tail from peers.
Off-chain payloads referenced by Sigil state — encrypted mail bodies, Weft artifacts, Nova world data — live on Weave, the P2P substrate. Sigil commits the hashes; Weave carries the bytes.
How the layers compose
A typical transaction flow:- Sign. A wallet builds a transaction, signs it with the DID’s Ed25519 key, and submits it through
sigil_sendTransaction. - Admit. The mempool verifies signature, nonce, balance, and admission policy.
- Order. The current block producer drafts a block containing the transaction. The active validator set votes through MACA’s four rounds.
- Execute. Each validator runs the same native executor. If the transaction touches a policy-gated surface (staking, governance, treasury), the relevant system contract is invoked. Organisation-zone transactions run in the zone WASI executor.
- Commit. The state root is computed and embedded in the block header. AkashaKV commits the new version.
- Finalise. The block is final at the end of round one. The epoch locks under Tower 1,000 blocks later.
What this architecture is not
- It is not an EVM fork. Sigil does not run Solidity contracts.
- It is not a DAG. Block order is total, not partial.
- It is not an L0. There are no Sigil subnets, hub-and-spoke zones, or shared-security children. See no L0 for v1 for the rationale.
- It is not a marketing chain. Every primitive in the Primitives tab is executable in
sigil-node.