MintID runs its own Cosmos SDK chain and keeps people off it: the chain holds trust records and status roots, never identities. Today that is the single-node production chain, in production since 20 September 2026 and operated by the CONECTIA group. A person completes KYC once with an accepted issuer; from then on, the holder proves claims in zero knowledge against those public records.
trust roots
The chain holds trust records and status roots, never identities: who the accepted issuers and verifiers are, their keys and bonds, and a signed root per issuer at least every 30 seconds. A revocation, the issuer’s or the holder’s own, enters the next root and is refused by every verifier within the maximum root age; the person or the operator switches an agent off without asking the issuer and without telling the network which credential died.
pip install mintid-proof-coreThe proof core as Python bindings: a prebuilt wheel for Linux x86-64, elsewhere pip builds it with a Rust toolchain. To watch the kill switch against a running deployment, run the revocation trace from a clone of the main project: uv run python test-harness/trace/revocation_trace.py --target testnet.
Proves
Does not prove
Every claim of status on this page points at something public you can open or reproduce.
Proofs of predicates such as grade ≥ A3, over 18, credential active and issuer accepted — without revealing names, dates, documents or which credential was used.
The chain stores one compact, signed status root per issuer, published at least every 30 seconds — never a record per holder. An issuer can also publish an emergency root at once.
A presentation lives for ten seconds, can be used once, and is bound to one verifier, its exact origin, the requested policy and the chain state the verifier checked.
A holder can revoke their own credential without the issuer, revealing neither who they are nor which credential it was, and every verifier refuses it in under two minutes. It is the one proof the chain checks itself, so it has its own dedicated audit: a scheduled milestone whose findings are published.
Every credential carries a private assurance grade, A1 to A4, anchored on eIDAS and squared with ISO/IEC 29115. A verifier learns only that the grade meets its threshold — never the grade itself. Beside it, the issuer publishes a freshness band instead of a date; the band is read on the classical seller rail and is not a presentation predicate.
Live state grows with issuers, verifiers and validators — never with the number of people, credentials or presentations. A billion credentials cost the chain what a thousand do.
zk presentation
claim
"grade ≥ A3"
never the attributes
challenge
single-use
no replay
verifier
exact origin
no relaying
policy
what was asked
nothing more
chain state
finalised
status re-checked
lifetime
10 seconds
perishable
what a presentation binds · nothing else leaves the holder software
An accepted issuer performs KYC once, keeps the evidence encrypted in its own vault, and issues an anonymous credential bound to a secret only the holder knows.
At least every 30 seconds the issuer publishes a signed status root. Once a root covering the new credential is final on-chain, the credential is usable, and no transaction ever records that it was issued.
When a verifier asks, the holder software checks the verifier against its own trust list and answers with one zero-knowledge proof for everything requested — valid for ten seconds, bound to that request.
A KYC-approved verifier re-checks the issuer and its own registration against finalised chain state — read through cryptographic proofs, not a trusted server — accepts or rejects, and keeps only a minimal decision record.
An issuer revocation enters the next root and is refused everywhere in under a minute at the reference values, where the maximum root age is 45 seconds (180 seconds on the single-node production chain), or at once through the emergency key; a holder’s own revocation is refused everywhere in under two minutes; lost holder keys are recovered only by fresh KYC and a new, unlinkable credential.
This loop is what reusable KYC means in practice: a person verifies once and proves claims many times. For the plain-language walkthrough, read Reusable KYC explained on the blog.
A grade measures how strong the identification was, and follows published frameworks — eIDAS first, squared with ISO/IEC 29115, with ETSI and NIST as reference points. How recently the evidence was checked is a separate freshness band, never a date. A presentation proves the grade threshold; the band is published by the issuer and read on the classical seller rail, so a relying party can require grade ≥ A2 and freshness ≥ F1 there without either answer becoming a correlator. Strength and freshness are independent: an A4 credential can sit at F1 and an A1 credential at F4. Every framework reviewed tiers identity proofing by strength, and none attaches a validity period to a level, so MintID reports recency beside the grade instead of folding it in.
| 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 |
The most recent band. Like every band, the issuer publishes it beside the grade instead of a date, and it is read on the classical seller rail; it is not a presentation predicate.
Verified within the last 90 days.
Verified within the last 180 days.
The widest band. ZadQ, the first product built on MintID, reads “human-backed” as at least A2, with a published freshness band of F1: a policy evaluated on the issuer’s session and attestation state on the classical seller rail; the band is not a presentation predicate.
Grades never decay, and expiry is not revocation: a credential expires exactly when the verification behind it does, with no grace period, and the way back is a new verification. The standards mapping and the reasoning are in How we grade identity — and how we keep it fresh.
MintID reuses Cosmos SDK and CometBFT instead of writing its own consensus, networking or staking. Block execution is deterministic and self-contained: no network call, wall clock, randomness, hardware signer or outside service ever runs while a block is produced.
Everything consensus-visible: the chain, its registries and bonds, status roots, governance, and the token economics designed for a possible public network.
The anonymous-credential and zero-knowledge cryptography — credentials, proofs and self-revocation — with shared test vectors. Anything that enters a consensus path gets its own dedicated audit: a scheduled milestone whose findings are published.
Simulation, test harnesses and automation — with no role in producing a block, applying a transaction or holding a key.
Every JSON object MintID hashes or signs is canonicalised with RFC 8785 (JCS) and hashed with SHA-256; digests are cited as typed references that say what they point at and how they were computed; anything logged in a Merkle tree is hashed as raw bytes. The rule is published as the improvement proposal bIP-0003 and follows the IETF SCITT draft on binding payloads; nothing changes for existing integrations.
Why the bytes are now specified, and what it prepares: Declaring how we hash.
Wondering how these choices compare with other identity chains? MintID vs Concordium sets them side by side, including where Concordium is the better choice.
The protocol page goes further: the specifications, the guarantees they enforce, what the chain stores and where the build stands. The whitepaper has the whole argument.