Blog · reusable kyc

Reusable KYC explained

Verify once with an approved issuer, then prove age, assurance grade (A1–A4) or credential status anywhere with a ten-second zero-knowledge presentation. The documents stay with the issuer, and no personal data goes on-chain.

Updated 2026-10-04: revocation bounds, governance and wording.

Reusable KYC means a person is verified once, by an organisation qualified to do it — and then proves facts from that verification anywhere, as many times as needed, without repeating the process or re-sharing documents. Done right, it removes the most expensive, most leaky step in digital onboarding. Done wrong, it just moves copies of your passport around faster. The difference is what, exactly, gets reused.

One-shot KYC re-runs the same check at every relying party

Today, KYC is repeated per relying party. Every exchange, bank, marketplace and fintech runs its own onboarding: the same person uploads the same documents, passes the same liveness check, and waits through the same review — again. Three costs compound:

  • Verification cost. Each relying party pays for a full check that someone else already performed, and users abandon funnels while they wait.
  • PII sprawl. Every repetition creates another database holding identity documents — another breach target, another retention obligation, another copy the user cannot recall.
  • Stale assurance. A check done at signup says little a year later. One-shot KYC has no live revocation: the relying party rarely learns when the verification stops being true.

Reusable KYC reuses the verification and leaves the data where it is

The naive version of “reusable KYC” is forwarding the file: one provider verifies you, then transmits your identity record to each new relying party. That reuses the data — and multiplies every problem above, because now your file travels.

The strong version reuses the verification, not the data. The KYC evidence is examined once and then stays put, with the issuer. What the user carries away is a cryptographic credential — a signed attestation they control with their own keys. When a relying party needs assurance, the user does not send attributes; they send a proof of a claim: over 18, verified at a given assurance level, credential still active. Reuse without disclosure. That distinction is what makes reusable KYC compatible with data minimisation instead of at war with it.

Five moves: issue, commit, present, verify, revoke

verify once, prove many times · nothing to breach downstream

The lifecycle has five moves:

  1. Issue. An accepted issuer verifies the person and issues an anonymous credential. The signature is blinded; the holder binds it with a secret only they hold.
  2. Commit. The issuer publishes a compact status commitment — a status root — on-chain, on a heartbeat of roughly 30 seconds. No per-user record, no credential list: one root per issuer.
  3. Present. The holder answers a verifier’s challenge with a zero-knowledge presentation proving exactly the requested predicates — and that the credential is unrevoked against the current root. It expires in ten seconds and binds to that verifier’s exact origin, so it cannot be replayed or relayed.
  4. Verify. The verifier checks the proof against on-chain trust roots — issuer accepted, root fresh, chain height finalised. It stores a yes/no outcome, not identity data.
  5. Revoke. The issuer can revoke by updating its root, and at the reference values a revoked credential is refused in under a minute; the holder can self-revoke without the issuer’s cooperation, refused in under two minutes. Revocation runs on the clock of the status roots, not of a support ticket.

What each party gains

Holders stop re-uploading their life. They keep the keys, choose per verifier what to prove, and can walk away — self-revocation needs nobody’s permission. Because presentations are unlinkable, using the same credential everywhere does not build a cross-site profile of them.

Verifiers get assurance that is both cheaper and fresher: no document pipeline to run, no PII vault to defend, and a revocation check that is minutes old at most, rather than months. The proof arrives pre-bound to their origin and policy, which collapses whole classes of replay and phishing fraud.

Issuers turn a cost centre into a product: one verification can serve every relying party, metered by issuance rather than repeated labour. In MintID’s model they remain accountable for quality — admitted on chain by governance proposal (by the compliance council once it is seated), bonded on-chain, and auditable through committed evidence rather than raw data.

Who is liable, how stale, will regulators accept it

“If the verifier never sees documents, who is liable?” The issuer vouches. In MintID’s design issuers are organisations admitted on chain by governance proposal (by the compliance council once it is seated), with a slashable on-chain bond, allowed assurance tiers and a public authorization state. The relying party’s reliance is on a named, bonded, supervised issuer — much as it relies today on a passport authority it never audits itself.

“Is a proof from last year still worth anything?” That is what status roots are for. A grade, though, measures the strength of the verification, not its age: MintID’s credentials carry one of four private assurance grades, and how recently the evidence was checked is published separately by the issuer, as a freshness band rather than a date, and is not proven. Each grade has a default validity — twelve months for A1 and A2, six for A3, three for A4 — after which renewal issues a new credential, publicly unlinkable to the old one, rather than quietly extending stale evidence.

“Will regulators accept it?” Reliance frameworks for cryptographic KYC are still forming. What a protocol can do is make the compliant path structurally easy — auditable issuer approval, committed evidence trails, fail-closed freshness — and avoid the one thing regulators consistently punish: uncontrolled copies of personal data. MintID runs on the single-node production chain, in production since 20 September 2026 and operated by the CONECTIA group, and its audits are scheduled milestones whose findings are published.

The chain carries trust roots and never a person

MintID is an identity protocol in production on a single-node chain, designed to scale to a public proof-of-stake network, and built for exactly this pattern — and for what it deliberately refuses to store. The chain carries issuer and verifier records, status roots, governance and audit commitments. It never stores KYC documents, biometrics, names, addresses, dates of birth, credential serial numbers, raw credential payloads or presentation logs. Live state scales with issuers, verifiers and validators — not with the number of people or proofs — so a billion holders add no more chain state than a thousand.

For relying parties the entry points are the verifier programme; for KYC organisations, the issuer programme; and for the mechanics — the ten-second presentation, the status-root heartbeat, the language boundary that keeps consensus deterministic — the technology page walks the full loop.

And reusable KYC is the foundation of something bigger: once a human is verified once, that verification can back every AI agent they deploy. Reusable KYC extended to the agent economy is what the market calls Know Your Agent (KYA).

Reusable KYC — quick answers

Is reusable KYC the same as sharing my KYC file?
No — it is the opposite. In reusable KYC the evidence stays with the issuer that verified you. What travels is a cryptographic proof of a specific claim (“over 18”, “grade ≥ A3”, “credential active”), generated fresh for each verifier. Nobody downstream receives documents, attributes or copies of your file.
What does the verifier actually receive?
A zero-knowledge presentation that is valid for ten seconds and bound to a unique challenge, the verifier’s exact origin, the requested policy, the issuer’s current status root and a finalised chain height. It answers the policy question — yes or no — and carries no reusable identifier.
What if a credential is revoked or expires?
Every presentation must prove non-revocation against a recent status root of the issuer, republished on a 30-second heartbeat; a proof against a superseded root stays acceptable inside that root’s validity window. At the reference values, a revoked credential is refused in under a minute, and a self-revoked one in under two minutes. If the root is stale or the issuer is suspended, verification fails closed. Holders can revoke their own credential without the issuer’s cooperation, and a credential expires with the verification behind it.
What happens if I lose my keys?
Recovery is a fresh KYC re-verification with an accepted issuer, which produces a brand-new credential that is publicly unlinkable to the old one. There is no social recovery and no custodian — nobody can restore or seize the credential on your behalf.

Verify once. Prove anything.

Whether you issue verifications or rely on them, the protocol defines a role for you — with the evidence kept where it belongs.