Self-certifying identities on Cardano, bridged to the Veridian / KERI ecosystem.
ACDC) · caches who's admitted (admission cage) · checks signed permission slips (envelope)KEL/TEL)Every business case needs the same identity registry, verifier, and authorization machinery. The business pick only selects a last-mile adapter.
Every milestone ships a vertical demo — an end-to-end slice, not useful but usable and demoable, recorded as a terminal cast. If it cannot be demoed E2E, the milestone is not done.
Each identity is a quantity-one checkpoint UTxO whose owner rotates keys with no identity oracle (KERI pre-rotation and dual-threshold rule). When witnesses are configured, the checkpoint advances only with their threshold receipts over the KEL anchor—never on controller signatures alone. It holds raw weighted signing keys and the explicit next-key commitment (CheckpointDatumV1, E-native Blake3; independent AIDs only).
The wire contract is frozen and byte-tested across Haskell and Aiken (merged). A plain single-key identity is just the 1-of-1 case.
Re-check the design docs against the agreed no-gatekeeper model (canonical permissionless model) before writing code — vetting gates implementation.
KEL replay).TEL revocation registry, MPF-backed).ACDC chain verifier), up to four links deep and configurable (hop bound 4). An officer credential (OOR) chains through an extra authorization signed by the legal entity (LE-signed OOR-AUTH) — four credentials, not three; every credential in the chain must be un-revoked (all-TELs cascade) and recent (minutes-grade freshness floor).ACDC proof builder). Decode the wire format (CESR) and build the transaction witness (redeemer).trie_key → {credential_saids, role_level, admitted_at, not_after}AID) powers that are explicit, on-chain, and auditable.Re-check the entire credential chain at every gated action (full ACDC verification).
Verify once, record admission, then gate later actions on a cheap lookup (admission cache).
Every case's actors keep keys in KERI wallets, not CIP-30 wallets; producing order/transition-bound detached signatures programmatically is on the critical path of every design.
E-prefix) identities and SAIDs are consumed as-is. In-script blake3 covers the rare genesis/rotation paths; authorizations verify raw keys.M3 can start as soon as the envelope spec is drafted — it does not wait for all of M2.
publish handler).vLEI-verified signers).Demand-driven, after the pilots prove the core.
CIP-113 substandard and/or register-as-cage.)CESR built into the chain the fraud proof isn't trustless (a malicious watcher could fake a divergence proof), so a challenge period or watcher-threshold scheme must be chosen first.Nothing in M1–M3 depends on the business pick. The chain verifier (verify_acdc_chain), the admission cage, and the signature envelope are shared libraries; the last-mile adapter is the first code that uses them with an opinion.
The pilots need credentialed counterparties, and getting a real legal entity credentialed (QVI issuance) has weeks-to-months of lead time. For M4 to start when M3 ends, the pilot pick and the counterparty conversation happen during M2.
The scoped-override verbs are motivated differently per case — freeze/seize vs signer re-designation vs admission expiry. The mechanism is common, but the spec is written with all four verb families in view so the knob does not hard-code one app's semantics.
The core is use-case-invariant — build it once.
Every milestone is closed by an E2E demo — the demo is the acceptance test.
The app choice is deferred to the last responsible moment — and its runway starts early.
The staking-withdrawal-validator registry and the oracle-controlled registry were retired by the canonical permissionless model; their surviving concerns live on in the key-state and scoped-override designs.