Everything the Codex is allowed to store. Six entity types, each with its own structure, semantics, and storage rules. The Codex is the single instrument for managing all of these — your unified cryptographic vault.
| # | Entity | What it holds |
|---|---|---|
| 1 | Ouronet Accounts | Standard Ѻ. + Smart Σ. accounts on Dalos curve |
| 2 | Seed Words | Koala / Chainweaver / Eckowallet HD mnemonic seeds |
| 3 | Pure Key Pairs | Standalone Stoa keypairs not derived from any seed |
| 4 | StoaChain Accounts | k: / c: / u: / w: / r: / named accounts |
| 5 | Address Book | Saved Ouronet + StoaChain accounts for reference / observation |
| 6 | Codex Consumer Settings | Per-app preferences (OuronetUI, AncientHoldings, …) |
The codex stores any number of Ouronet Accounts —
both Standard (Ѻ.) and Smart (Σ.). Each account
is built on the Dalos
Elliptic Curve and exposes the slot model described in the dedicated
Ouronet Accounts
documentation.
Single-flow account. Has Public Key (immutable), Payment Key (rotatable), and Guard (rotatable, designed for keysets). Daily-use account; the CodexPrime is always a Standard account.
Example address:
Standard + two extra slots: Governor (for non-key-based authorization patterns) and Sovereign (a Standard Account that has sovereignty over this Smart Account). Built for governance, autonomous logic, and DAO-style accounts.
Example address:
→ Deep dive: Ouronet Accounts documentation covers all five slots (Public Key, Payment Key, Guard, Governor, Sovereign) with a worked example.
The codex stores any number of hierarchical-deterministic (HD) seed phrases. Each seed produces a tree of keys; the codex tracks which derivation positions you've used. You can add keys consecutively (positions 0, 1, 2, …) or jump to any specific position as needed.
Three seed-word flavours are supported in v0.1, each using a different derivation convention from the Kadena ecosystem:
BIP-39 English wordlist, 256-bit entropy (24 words).
Originated with eckoWALLET's Koala mode. Signing pipeline:
seed → BIP-39 → seed bytes → ED25519 keypair via NaCl.
Example phrase (illustrative):
abandon ability about above absent absorb abstract absurd abuse access accident account
accuse achieve acid acoustic acquire across act action actor actress actual
BIP-39 English wordlist, 128-bit entropy (12 words).
Native to Kadena's official Chainweaver wallet. Signing pipeline:
seed → BIP-39 → Chainweaver-style derivation via WASM.
Example phrase (illustrative):
train ensure ankle fine magic hamster blade bag what bracket dizzy wheel
BIP-39 English wordlist, 128-bit entropy (12 words),
with eckoWALLET-specific derivation path. Signing pipeline:
seed → BIP-39 → Eckowallet-style derivation via WASM.
Same wordlist as Chainweaver, but a different BIP-32 derivation path produces different keys from the same words. The codex stamps the flavour at seed-creation so the right derivation is used at signing.
All three flavours store the mnemonic encrypted at the codex password. Decryption happens client-side on each sign; the mnemonic never leaves your device in plaintext.
Each seed has an accounts array — every key you've derived from that seed, with its derivation path and current chain guard. Add positions as you need them; the seed grows alongside you.
Direct ED25519 public + private keys, not derived from any seed. The keypair IS the entity. Stored encrypted-at-rest under the codex password.
Used for:
Pure keypairs cannot be regenerated from a mnemonic — losing them loses the key. When the codex package flags a Pure Keypair as part of the Duo Pure Prime (the two keys backing CodexPrime), it becomes undeletable to prevent accidental loss.
The codex stores any number of StoaChain accounts you own, plus any number you've added for observation only. StoaChain inherits Kadena's principal-account nomenclature — five reserved prefixes plus arbitrary named accounts:
k:
k: +
a single public key. The account's guard is a single-key
keys-all keyset containing exactly that pubkey.
The default account type — what every fresh address starts as.
c:
c: +
hash of a capability guard. Used for autonomous accounts
controlled by Pact module logic (a capability inside a contract),
not by a private key. Common pattern: a token contract owns its own
treasury via a c: account.
u:
u: + hash
of a user-guard. The guard is a custom Pact function returning bool
— anything programmable, including composition over capabilities,
time-locks, multi-party logic, etc.
w:
w:<keysetHash>:<predicate> — a keyset
containing multiple keys, with a predicate selecting
how many of them must sign (keys-all,
keys-any, keys-2, etc.). The format
covers every multi-sig arrangement: 2-of-2, 3-of-5,
any-of-N, all-of-N. Contrast with k:, which is the
shorthand for the single-key case.
r:
r:<namespace.keysetName>. The account's guard is
a reference to a named keyset defined on chain in a
specific namespace — the actual keys live in the referenced
keyset and can be updated separately from the account itself.
Useful when many accounts should share a single rotatable keyset.
(none)
mihai-treasury.
The codex distinguishes between accounts you own (matching guards in your seeds / pure-keys) and accounts you've added for observation (read-only viewing of any StoaChain account, regardless of prefix or ownership).
Stores any number of Ouronet Accounts and StoaChain accounts you want to remember — friends, business contacts, common destinations, exchanges, DAOs, treasury addresses.
Each entry has:
Ѻ., Σ., k:, or other identifier)Address book entries are local convenience — they don't change anything on chain. Pure metadata for your own reference.
Each recognised Codex Consumer (OuronetUI, AncientHoldings, the upcoming Demiourgos Streaming Platform, any future app) gets its own settings slot inside the codex. Examples:
The property that matters: one codex, many apps, consistent preferences everywhere. Switch from OuronetUI on your desktop to OuronetUI on your phone — same settings, no re-configuration.
Each app reads/writes only its own settings slot — apps never collide with each other's preferences. The codex package enforces this via scoped keys.
The codex architecture is intentionally extensible. v0.1 covers the six entity types above; future versions are planned to add:
The codex's wire format (the v1.2 blob format defined in
@stoachain/ouronet-core/codex) is frozen, but additive
fields can land at minor bumps without breaking backwards
compatibility. The same Codex Identity will continue working as
more entity types come online.