ΛΛnemosyne  /  Documentation  /  Ouronet Accounts

Ouronet Accounts

Anatomy of an Ouronet Account — the Public Key, Payment Key, and Guard, plus the Smart-account-only Governor and Sovereign slots. The architecture behind the Ѻ. and Σ. address prefixes.

Two flavours, one architecture

An Ouronet Account is built on the Dalos Elliptic Curve and lives above the StoaChain native account layer. Every Ouronet Account has a 160-glyph Dalos public key that does not change for the account's lifetime — that's the immutable identifier you see as Ѻ.xxx or Σ.xxx.

Around that immutable public key, an account composes a small set of rotatable slots. Each slot points at on-chain entities (keys, accounts, guards) that the account uses to authorize behaviour. Slots can be rotated independently as your security posture changes.

Ѻ. — Standard Account

The simpler flavour. Has Public Key, Payment Key, and Guard. Designed for everyday usage — single-account, single-flow operations.

Σ. — Smart Account

Standard + two extra slots: Governor (for non-key-based authorization patterns) and Sovereign (a Standard Account that has sovereignty over this Smart Account). Designed for governance, multi-party authorization, and protocol-level integrations.

The slots

Public Key immutable

The Dalos 160-glyph public key derived from the account's seed at creation. Defines the account's identity. Never changes — this is what Ѻ.xxx / Σ.xxx visually encodes.

Stored on chain immutably. If the codex's local copy and the chain disagree, the chain wins. Mnemosyne's UI shows a "codex matches chain" check next to the public-key panel to surface drift.

Payment Key rotatable — STOA

The StoaChain-native account that pays gas for any operation involving this Ouronet Account. At creation this is a k: account — a simple keyset-backed account. It can be rotated to any StoaChain account type:

  • • k: — single-key keyset (the default at creation)
  • • w: — multi-key keyset (multi-sig: 2-of-2, 3-of-5, any-of-N, all-of-N)
  • • c: — capability-guarded (autonomous accounts whose payment is authorized by Pact module logic, not a private key)
  • • u: — user-guarded (custom Pact predicate functions)
  • • r: — keyset-reference (points to a named on-chain keyset)
  • • Any named StoaChain account

Rotating the Payment Key changes who pays and what authorizes the payment, without changing the Ouronet Account's identity. Common rotation: keyset → capability-guard, to make the account fully autonomous under a Pact module.

Guard rotatable

At creation: a single-key keyset (one Stoa key, keys-all predicate), making the account behave as a normal single-signature wallet. The Guard slot is technically any Pact guard — Pact recognises four guard types, and the slot accepts all of them:

  • • keyset — defined inline at transaction-upload time (e.g. { keys: [...], pred: keys-any })
  • • keyset-ref — a reference to a keyset already defined on chain in some namespace (e.g. ouronet-ns.dh_sc_dalos-keyset); the keys can be updated separately from the account
  • • user-guard — any Pact function returning bool can be wrapped as a guard; whatever logic the function enforces becomes the authorization rule
  • • capability-guard — a Pact capability can itself be wrapped as a guard; when that capability is composed in a transaction, the guard is satisfied

That said, the Guard slot is mentally designed for the first two — keysets and keyset-refs. It's the "who has the keys" slot. For the more programmable guard types (user-guards and capability-guards), Smart accounts give you a separate slot — the Governor — to keep the authorization structure easy to read at a glance.

Governor Smart only rotatable

Smart-account-only. Another guard slot, mentally designated for the programmable guard types — user-guards and capability-guards. Where you put authorization logic that says "this account is authorized when these on-chain conditions hold" rather than "this account is authorized when these specific keys sign."

Common patterns:

  • • user-guard composing multiple capability-guards (any-of, all-of)
  • • capability-guard tied to a specific Pact-module capability (e.g. REMOTE-GOV)
  • • Module-defined autonomous logic

Technically Pact would accept the same content in the Guard slot — nothing about the chain stops you from putting a complex user-guard there. The Guard / Governor separation is a human-readability choice (see the design-rationale sidebar below).

Sovereign Smart only rotatable

Smart-account-only. Points to a Standard Ouronet Account (Ѻ.xxx) that has sovereignty over this Smart Account.

Satisfying the Sovereign account's ownership rules = satisfying the Smart Account's sovereignty. In practice: if you can sign on behalf of the Sovereign, you can authorize sovereign operations on the Smart Account too.

Why exist: it gives a clean "override path" for Smart accounts. The day-to-day authorization runs through Guard + Governor; deep / structural changes (rotations, mode changes, module upgrades) route through the Sovereign as a human-controllable escape hatch.

Why three slots instead of one — the design rationale

Technically, a single guard slot would have been enough. Pact lets you compose arbitrarily complex guards — you could put a single user-guard in the Guard slot that internally composes a keyset, capability checks, sovereign overrides, and any other logic you need. One slot, infinite expressiveness.

The Guard / Governor / Sovereign separation exists because the system was designed for humans, not for machines. A machine doesn't care whether your authorization rules live in one compound guard or three discrete slots — it just runs the predicates. A human reading an account's structure needs to see, at a glance, what authorizes what. The three slots answer three distinct questions:

  • Guard — “Who has the keys?” A keyset or keyset-ref. The "wallet" semantic — direct private-key-based control.
  • Governor — “What programmable conditions authorize this?” A user-guard or capability-guard. The "logic" semantic — autonomous, contract-driven, governance-pattern authorization.
  • Sovereign — “Whose human override sits above this?” A Standard Ouronet Account. The "escape hatch" semantic — when something at the Guard or Governor layer needs structural change.

You're free to ignore the mental separation entirely. Pact treats all guard types as just "a guard" — you can put a capability-guard in the Guard slot, a single-key keyset in the Governor slot, anything you want. The slots are conventions to help you build accounts whose ownership structure is readable, not constraints the chain enforces.

The trade-off accepted: more slots = slightly more setup complexity at account creation, in exchange for an ownership structure a human can understand without unwrapping a deeply-nested compound guard.

Worked example — a real Smart Account from a codex

This is an actual Ouronet Account viewed through OuronetUI's account panel. It demonstrates the full flexibility of the slot model:

DALOS · Smart Account · Active

Ouronet Account (immutable Public Key)

Payment Key (rotated from default k: to autonomous c:)

Payment-Key Guard: capability-guard → ouronet-ns.DALOS.DALOS|NATIVE-AUTOMATIC. The Payment Key is itself a c: autonomous account whose gas is authorized by a Pact capability, not by a private key.

Guard (a keys-any keyset combining two backup keys)

Either key alone can satisfy the Guard. The two keys come from independent seeds, so losing one seed doesn't lock you out.

Sovereign (a Standard Ouronet Account)

Whoever can authorize as this Standard Account can also exercise sovereignty over the Smart Account.

Governor (user-guard composing multiple capability-guards)

The Governor accepts authorization from any of five different Pact-module capabilities. Each represents a distinct governance pathway — token-launchers, oracles, swap-pair governance, time-locked release, distributor governance. The account is effectively "governable from any of these modules" without needing keys.

Three slots out of three rotated to non-default forms — Payment Key to a capability-guarded c: account, Guard to a 2-of-2 multi-source keyset, Governor to a user-guard composing five module capabilities, plus a Sovereign for the override path. The Public Key is the only thing that stayed constant from creation.

Why this matters for Codex Consumers

The slot model makes Ouronet Accounts much more flexible than typical single-key blockchain accounts. A Codex Consumer (OuronetUI, AncientHoldings, the upcoming Demiourgos Streaming Platform) can build features like:

None of these require changing the account's Public Key. Anyone resolving Σ.xxx always finds the same identity — what's behind it can change as the user's needs evolve.

Related

The Dalos Elliptic Curve →
The curve every Ouronet Account's Public Key lives on.
StoicTags →
Human-readable names for Ouronet Accounts — §bytales → Ѻ.xxx.

Reference implementation: github.com/StoaChain/DALOS_Crypto