Protocol-level identity on a sovereign Cosmos SDK chain: the network publishes trust roots, not identities. KYC happens once with an accepted issuer; everything after is the holder proving claims in zero knowledge against those roots.
trust roots
The core guarantees
ZK
Zero-knowledge presentations
Selective-disclosure proofs for predicates like grade ≥ A3, age threshold, credential active, issuer accepted and credential unexpired — without revealing raw attributes.
√
Root-based status
The chain stores compact issuer status commitments, not per-holder state. A signed status root is published every 30 seconds, with immediate emergency roots.
10s
10-second presentations
A presentation is valid for ten seconds and bound to a unique challenge, exact audience/origin, requested policy, current status root and finalized chain height.
⊘
Holder self-revocation
A holder can revoke their own credential without the issuer, in a way that reveals neither their identity nor a normal credential identifier.
A
Private assurance grades
Assurance is one of A1–A4, mapped onto eIDAS, ISO/IEC 29115 and the EU AML regimes; only a commitment is public. A verifier receives a threshold proof such as “grade ≥ A3” without learning the exact grade — and, on a second axis, a freshness band (F1–F4) instead of a date.
O(1)
Bounded state growth
Live state scales with issuers, verifiers, validators and active commitments — never with the number of holders or presentations.
Lifecycle
From KYC to a perishable proof
zk presentation
claim
"grade ≥ A3"
never the attributes
challenge
unique nonce
no replay
audience
exact origin
no relaying
status_root
current issuer root
revocation-fresh
height
finalized block
chain-anchored
lifetime
10 seconds
perishable
what a presentation binds · nothing else leaves the wallet
01
Issuance
An accepted issuer performs KYC once and issues an anonymous credential bound to keys the holder controls.
02
Status commitment
The issuer publishes a signed status root every 30 seconds; revocation is a private witness against that root, not a per-holder record on-chain.
03
Presentation
On a verifier’s challenge, the holder assembles a 10-second zero-knowledge presentation, fully bound to verifier, origin, policy, root and chain height.
04
Verification
A KYC-approved verifier checks the proof against the latest finalized issuer and verifier state — online, over chain reads it verifies cryptographically rather than trusts — and stores only a minimal decision record.
05
Revocation & recovery
Issuers can revoke (including immediate emergency roots); holders can self-revoke; lost keys are recovered only by fresh KYC and a new, unlinkable credential.
This loop is reusable KYC in practice — one verification, many proofs. For the plain-language walkthrough, read Reusable KYC explained on the blog.
Assurance
Two axes: how well we know who, and how recently
A grade measures the strength of the identification and follows the published frameworks — eIDAS, ISO/IEC 29115, ETSI TS 119 461, NIST — never its age. Age is reported separately, as a band rather than a date, so no observer can correlate records by timestamp. A relying party states what it needs on both axes; the holder proves both in zero knowledge.
Grade
What it certifies
eIDAS
ISO/IEC 29115
ETSI · NIST
Default validity
A1
Identity document validated against authoritative sources; for a company, the legal entity validated at the registry.
low
LoA 2
— · IAL1
12 months
A2
A1 plus possession proven with biometric liveness; for a company, a verified representative entitled to act.
substantial
LoA 3
Baseline · IAL2
12 months
A3
A2 plus sanctions, PEP and adverse-media screening; for a company, beneficial owners identified and screened.
substantial + EDD
LoA 3⁺
Baseline + screening · IAL2 + EDD
6 months
A4
A3 plus qualified proofing: a high-assurance eID, the EU Digital Identity Wallet, or a qualified provider.
high
LoA 4
Extended · IAL3
3 months
F4
Under 30 days
The most recent band. Freshness is a claim a holder proves as a threshold — “fresher than F3” — never as the date of the verification.
F3
Under 90 days
Strength and freshness are independent: an A4 credential can sit at F1 and an A1 credential at F4. The relying party states the floor it needs on each axis.
F2
Under 180 days
No standard tiers identity proofing by age — eIDAS, ETSI and NIST leave validity to policy — so MintID reports age beside the grade instead of folding it in.
F1
Under a year
The floor for the agent claim “human-backed”: at least A2 and at least F1. Beyond the grade’s default validity the credential is suspended until re-verified.
Grades never decay and nothing is revoked by the calendar alone: an overdue re-verification suspends the credential, visibly, until a new verification completes. The standards mapping and the reasoning are in How we grade identity — and how we keep it fresh.
Engineering
A language boundary that is a security boundary
Built on Cosmos SDK + CometBFT with Protocol Buffers for every message and state. No network, clock, randomness, HSM, RPC or FFI ever runs in a block-execution path.
Go
The chain
Consensus-visible logic: the node daemon, Cosmos SDK modules, deterministic transaction handlers, registries, token economics, CLI and node APIs.
Rust
The proof core
Anonymous-credential and zero-knowledge proof core: circuits, revocation witnesses, the self-revocation prover, and known-answer test vectors.
Python
Simulation & testing
Simulations, load and fault harnesses, integration-test orchestration, automation and analytics — never consensus-path or production-crypto code.
Wondering how these choices stack up against other identity chains? See MintID vs Concordium for an honest side-by-side.
Wallet roadmap · post-MVP
Who checked my identity, when, why
Your wallet keeps its own encrypted log of every presentation and every disclosure — reconcilable against the on-chain disclosure receipts, so you can prove to yourself the record is complete. There is no server-side log anywhere to ask, subpoena or leak: the only complete history of your identity’s use is the one you hold.
Go deeper into the specification
Required specifications, the consensus and validator program, monetary policy, and the module map all live in the protocol spec.