# MintID — full site content (https://mintid.net) > One markdown document with the content of every page. Per-page mirrors live at `/index.md`; the curated index is [llms.txt](https://mintid.net/llms.txt). --- > An identity protocol for reusable, privacy-preserving KYC-backed credentials for people and AI agents, in production on a single-node chain and designed to scale to a public proof-of-stake network. # KYC-backed identity and accountability for the agentic era Zero-knowledge identity layer for agents MintID is an open, permissionless identity layer: accepted KYC issuers verify a person once; the person’s agents prove, in zero knowledge, that an accountable human stands behind them, within a scope the human fixed. Nothing about the person is stored on the chain or handed to the relying party. [How it works](/en/technology)[Identity for AI agents](/en/agent-kyc) the credential your keys Use cases ## What a person, an agent or a seller can do with it, and where each one stands Eight outcomes, in the order they exist: what runs in production comes first, the recovery of funds comes last. Every outcome carries its status, and none is claimed beyond it. [VERIFY ONCE ### A person verifies once and proves many times. A KYC issuer verifies the person and gives them a credential they hold themselves. From then on they answer a service’s question (“over 18”, “verified at grade A2 or better”) with a ten-second proof the service can check; the service learns the answer, never the person. No new verification per service, no tracking across services. In production on the single-node production chain. How a proof works](/en/technology)[AGENTS ### Every agent carries a verified person behind it, and a scope that person fixed. The person mints one credential per agent. The agent proves, to any relying party, that an accountable human backs it and that the action is inside its scope, without saying who the human is. One verification covers a whole fleet; an operator’s agents cannot be linked to each other. In production; the bounded agent (an agent minted with a preset scope) in production. Human-backed agent identity](/en/agent-kyc)[KILL SWITCH ### The kill switch. The person, or the operator, switches a credential or an agent off without asking the issuer and without telling the network which credential died. Every service refuses it in under two minutes (reference values); the issuer can act in under a minute, or at once in an emergency. In production since 24 September 2026; its independent audit is a scheduled milestone. How revocation works](/en/technology)[BUYING AGENT ### A buying agent a seller can let in. The agent attaches a ten-second proof to its paid request: human-backed, within scope, not revoked. The seller decides on the proof instead of blocking everything that is not a browser. In production on the single-node production chain, end to end (related-party pilot). What a verifier checks](/en/verifiers)[SELLER ### A seller that charges per request proves it is an accountable business. ZadQ, the first product built on MintID and a disclosed related party, lets a seller on the x402 payment rail show every buyer that an accountable organisation stands behind the endpoint. In production for ZadQ on the classical seller rail (issuer-signed attestations); the zero-knowledge seller rail follows on engineering readiness. Read about ZadQ](/en/x402-pilot)[CONSENT ### Identification, not surveillance. When a seller legitimately needs to know its customer, it asks for one graduated item of information and may offer to pay for it; the person’s consent policy decides, and refusal, timeout or error disclose nothing. A payment is never the lawful basis, and knowing once confers no right to recognise again. Built, switched off and fail-closed on both sides; activation waits for counsel. Consent is the firewall](/en/agent-kyc)[MANDATE ### A nominated, legally obligated counterparty learns what the law needs, and nothing else. A person can mandate in advance that a named obligated party receives a bounded set of attributes, capped and expiring; everyone else receives the proof, not the person. Specified; under construction on the disclosure rail; activation depends on a counsel item. The disclosure rails](/en/agent-kyc)[RECOURSE ### Money before identity. When an agent misorders or defrauds, the wronged party does not need the operator’s name; it needs to be made whole. A substantiated claim settles against capital the operator locked in advance; a contested one is decided by a bonded, independent arbiter; identity reaches a court only after the money question is closed. Specified and scheduled as the next layer (2027 window); audits not started; no funds are locked today. When money moves before identity](/en/agent-kyc) [Read the concept paper (PDF, 17 pages)](/docs/Agent-Identity-Concept-and-Market-Paper.pdf) Start here ## MintID in 60 seconds Proving one fact about yourself should not mean handing over your identity. You verify once; after that, each proof answers one question and reveals nothing else. 01 ### You verify yourself once An accepted issuer checks your identity once. Until that check expires, no service needs to see your documents. 02 ### You get a credential only you control It lives in your own holder software, under your keys. No one else holds a copy. 03 ### You prove a fact and keep the rest Asked “are you over 18?”, your credential answers “yes” — without your name, your birthday or your document. 04 ### Your AI agents inherit the trust Each AI agent you deploy can prove that a real, accountable person stands behind it — without revealing who. ## What the chain records, and what it never holds The chain records which issuers and verifiers are trusted and whether they are in good standing; it keeps no credentials. ZK ### Prove the claim, not the identity Zero-knowledge proofs answer the question asked and reveal nothing else. KEY ### Your keys stay yours Credentials and their secrets stay with the holder. No issuer, verifier or operator ever holds your keys. ⊘ ### Nothing personal on the chain No names, documents, biometrics, credentials or proofs on the ledger. Nothing to leak. ◈ ### Rules that answer to no other chain MintID is designed to run its own validators and governance, so the rules that protect identity answer to no other chain. Today that chain is the single-node production chain, with one validator and no token. √ ### Status no older than the last root Each issuer publishes a signed status root at least every 30 seconds, and verifiers refuse any root older than the maximum root age, so a credential its issuer revokes is refused everywhere in under a minute at the reference values. 10s ### Proofs that expire after ten seconds Each proof answers one request and expires ten seconds later. It cannot be replayed, and it cannot be relayed to another service. The design principles are on the [about page](/en/about). How it works ## Who vouches, who holds, who checks Verification happens once, off-chain. After that, the holder answers services directly, and the chain lets anyone check who is trusted. lifecycle issuerverifies once credential · stays off-chain holderkeeps the keys proof · valid 10 s verifierchecks the proof status updates trust records MintID chainnothing personal — ever nothing personal ever touches the chain 01 ### An accepted issuer verifies you once The issuer checks your identity, keeps the evidence encrypted in its own vault, and issues a credential bound to a secret only you hold. 02 ### You keep the credential It stays in your holder software, under your keys. Nothing public links it to you, and you can revoke it yourself without asking the issuer. 03 ### You answer a question with a proof Your holder software builds a zero-knowledge proof for that service, valid for ten seconds. 04 ### The service checks the proof against the chain It keeps only its decision; your data never reaches it. Human-backed agent identity ## Verified human backing for AI agents Verify once, then give each AI agent its own credential. The agent proves that a real, accountable person stands behind it and acts within the powers granted. The consented commercial disclosure rail is built, switched off and fail-closed, and its activation waits for counsel. Through it, a seller that legitimately needs to know who is behind an agent asks for one graduated item of information and may offer to pay for it; the person’s consent policy decides, and refusal, timeout or error disclose nothing. The funded-recourse layer, the only other route to identity and only under due process, is specified and scheduled. [Explore identity for AI agents](/en/agent-kyc) AccountablePrivateCapped per personRevocable ## Who does what in MintID [ ### Issuers KYC organisations, accepted as issuers, that verify people once and vouch for them. Only they could ever link a credential to a person, and only under due process. See how the role works](/en/issuers)[ ### Verifiers Services that need an answer — “over 18?”, “a real person behind this agent?” — and get it without storing personal data. See how the role works](/en/verifiers)[ ### Validators Operators who would secure MintID’s public network if that route is chosen, running consensus over status roots and registries without ever seeing a name or a document. See how the role works](/en/validators) ## Where the project stands Since 20 September 2026 MintID has been in production on the single-node production chain, operated by the CONECTIA group; there is no token, no token price, and nothing is for sale. Accepted issuers verify people and issue the credentials; the chain publishes their status, their bonds and the registries; MintID itself issues nothing and certifies nothing. On the single-node production chain the first accepted issuer is operated by the CONECTIA group, a related party, on the same terms as any other. ZadQ, the first product built on MintID, an x402 seller-verification service operated by the CONECTIA group, a disclosed related party, runs on that chain as a pilot; nothing measured there counts as independent adoption. The code is open source under Apache-2.0; the whitepaper sets out the design, and the roadmap shows what is built and what comes next. New here? Start with the [frequently asked questions](/en/faq), read how [the technology works](/en/technology), or see [ZadQ, the first pilot](/en/x402-pilot). [See the roadmap](/en/roadmap)[Ask the team](/en/contact) --- Source: https://mintid.net/en · MintID — KYC-backed identity and accountability for the agentic era --- > Holders prove claims in zero knowledge against status roots published at least every 30 seconds; each proof lasts ten seconds, grades run A1 to A4, and holders can revoke their own credentials. Technology # How MintID works 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 off-chain · holderon-chain · no PIIstatus root ## Six guarantees the protocol enforces ZK ### Zero-knowledge presentations Proofs of predicates such as grade ≥ A3, over 18, credential active and issuer accepted — without revealing names, dates, documents or which credential was used. √ ### Root-based status 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. 10s ### 10-second presentations 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. ⊘ ### Holder self-revocation 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. A ### Private assurance grades 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. O(1) ### Bounded state growth 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. Lifecycle ## From KYC to a perishable proof 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 01 ### Issuance 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. 02 ### Status commitment 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. 03 ### Presentation 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. 04 ### Verification 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. 05 ### Revocation & recovery 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](/en/blog/reusable-kyc-explained) on the blog. Assurance ## Two axes: how strongly a person was identified, and how recently 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 F4 ### Under 30 days 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. F3 ### Under 90 days Verified within the last 90 days. F2 ### Under 180 days Verified within the last 180 days. F1 ### Under a year 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](/en/blog/grades-follow-eidas). Engineering ## A language boundary that is a security boundary 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. Go ### The chain Everything consensus-visible: the chain, its registries and bonds, status roots, governance, and the token economics designed for a possible public network. Rust ### The proof core 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. Python ### Simulation & testing Simulation, test harnesses and automation — with no role in producing a block, applying a transaction or holding a key. JCS ### Canonicalisation, declared 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](/en/blog/declaring-how-we-hash). Wondering how these choices compare with other identity chains? [MintID vs Concordium](/en/blog/mintid-vs-concordium) sets them side by side, including where Concordium is the better choice. ## Go deeper into the specification 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. [Read the protocol](/en/protocol)[See identity for AI agents](/en/agent-kyc) --- Source: https://mintid.net/en/technology · How MintID works: ten-second zero-knowledge proofs — MintID --- > Check that an AI agent is backed by an accountable, KYC-verified human without learning who: the person verifies once, each agent carries its own credential, and it proves its backing in zero knowledge on request. Agent KYC # Zero-knowledge identity layer for agents: verifiable human-backed agent identity AI agents now book, buy, negotiate and sign on people’s behalf, so every counterparty has to ask who stands behind them. The market calls that check know your agent. MintID answers it with verifiable human-backed agent identity: a person verifies once, deploys the agents they need, and each agent proves in zero knowledge that a real, accountable, KYC-verified human backs it, without revealing who. [Talk to us](/en/contact)[Issue agent credentials](/en/issuers) human-backed agentproof · 10 shuman-backednever who The problem ## Six ways agent identity is broken Every identity system of the last twenty years assumed a human at the keyboard. Agents act autonomously, in fleets, across organisational boundaries, at machine speed — and today’s stack bolts them onto service accounts, API keys and OAuth tokens. Six failures follow. FAKE ### Impersonation A stolen or injected agent credential acts with the principal’s full authority — and nothing proves a liable party stands behind it. ANON ### Anonymous clients Agents register with no paper trail. Non-human identities sprawl with no accountable identity to point to. CHAIN ### Delegation breaks at the boundary Delegation chains don’t survive crossing organisations. The relying party cannot verify who ultimately authorised the agent in front of it. FRICTION ### Consent fatigue Humans are asked to approve so often that approval stops meaning anything. STALE ### Revocation is unsolved There is no fast, scalable way to kill a compromised agent’s standing across the whole ecosystem. PIVOT ### Accountability or privacy, pick one Today the only way to make an agent accountable is to attach its human’s real identity — and the only way to stay private is to be unaccountable. MintID is built around the sixth failure: accountability and privacy at the same time. The sections below show which of the other five the same credential answers today, and which arrive in later waves. Definition ## What the market calls know your agent (KYA), and what MintID builds Know your agent (KYA) is the market’s expression for verifying that an autonomous AI agent is operated by a known, accountable party: the agent-era counterpart to Know Your Customer (KYC). It answers two questions counterparties can no longer skip: who is behind this AI agent, and who is liable if it acts in bad faith? What MintID builds is verifiable human-backed agent identity, provable on demand, private and revocable. one human · many agents human principalKYC once · grade A1–A4 · liable issuer mints agent credentials · private agent 1 agent 2 agent n verifierseach agent proves "human-backed, within scope S" — never who sibling agents mutually unlinkable the agent credential model · accountability without identity 01 ### A human verifies once A person or business completes KYC a single time with an accepted issuer. That verification — not the raw documents — becomes the accountable foundation every one of their agents can stand on. 02 ### Each agent gets its own credential From that one verification, the issuer mints a separate, privacy-preserving credential for each AI agent the person operates, with its permissions and limits signed in. No new paperwork per agent — and a per-person cap stops one verification from backing an army. 03 ### Each agent proves it is human-backed On request, an agent presents a proof, valid for ten seconds, that a real, liable, KYC-verified human stands behind it — and that it is acting within its allowed scope — without exposing who that human is. ## When the agent carries the proof of its human Classic KYC identifies the customer to the business. MintID turns that around: one human verification backs many AI agents, and each agent proves its own backing. KYC ### Know Your Customer A person identifies themselves to the business. Being accountable means handing over a real identity — and, usually, a full trail of everything they do afterwards. AGENT ### Human-backed agent identity A person does KYC once with an accepted issuer, which then mints a credential for each of their AI agents. Every agent can prove it is run by a verified, liable human without revealing which human, and no two of that person’s agents can be linked to each other. ## Verifiable AI agents, accountable and private at once Counterparties get assurance they can check; operators keep their identity to themselves. The chain carries no extra weight, however many agents you run. ✓ ### Provably human-backed Every agent can prove a real, KYC-verified, liable human stands behind it, at the assurance level you require — the core guarantee of human-backed agent identity. ⊗ ### Private by design The proof reveals that the agent is backed and in good standing — never the identity of the human behind it, and never a trail of everywhere the agent has been. S ### Scoped permissions What an agent is allowed to do is fixed into its credential when it is issued, so it cannot quietly grant itself more power and counterparties see exactly the authority it carries. The scope axes are specified; bounded agents are minted today with a preset scope, and the verifier-side delegation checks arrive in the next waves. € ### Funded recourse Specified and scheduled for the financial-recourse stage: an agent will be able to prove that at least a given amount of self-custodied stablecoin stands behind it, without revealing the amount, the owner or the address. ⊘ ### Fast revocation Revoke a misbehaving agent yourself and every service refuses it in under two minutes. When the issuer revokes it, every verifier refuses it in under a minute at the reference values, or at once through the issuer’s emergency key. Switching off every agent a person operates, under issuer policy, takes a few minutes. The kill switch has been in production since 24 September 2026. ∞ ### Scales to any fleet Run one agent or a million: the design adds no per-agent footprint to the chain, so verification stays fast and free however large the deployment grows. Staged on purpose. The agent credential profile and issuer-side minting run on the single-node production chain, and bounded agents are minted today from a bundle catalogue the operator supplies; the person or the operator switches a credential or an agent off without asking the issuer, in production since 24 September 2026; the verifier-side delegation checks come in the next waves. The consented commercial disclosure rail, contact-attribute identification included, is built and ships switched off and fail-closed; its activation waits for counsel. Disclosure to a nominated, legally obligated counterparty is specified and under construction on the disclosure rail; its activation depends on a counsel item. Funded recourse and the dispute rail are specified and scheduled as the next layer (2027 window); audits not started; no funds are locked today. Each audit in the programme is a scheduled milestone whose findings are published. Where human-backed agent identity matters ## Designed for agents that buy, sign and negotiate Wherever AI agents transact, delegate or act under rules, the counterparty needs to know an accountable human stands behind them. $ ### Agentic commerce & payments When an AI agent checks out, books or pays, the merchant can confirm that an accountable person stands behind it — and, once recourse is live, that funds stand behind it too — without a login for every buyer. ⇄ ### Agent-to-agent (A2A) Before two AI agents transact or delegate over A2A or MCP, each can verify the other is backed by an accountable party — turning open agent networks into ones you can safely deal with. ⊞ ### Enterprise agent fleets Give every agent your organisation deploys a verifiable identity with scoped permissions, so partners and regulators can trust them and you can withdraw any one of them quickly. § ### Regulated & high-trust workflows In finance, healthcare and the public sector, prove an agent is operated by a verified, liable party at the required assurance level, without building a store of personal data your compliance team then has to guard. Accountability without surveillance ## When something goes wrong, money moves before identity Once the financial-recourse stage is live, an AI agent can carry pre-funded recourse, so most disputes settle with money and nobody is unmasked. The capital is the principal’s own USDC or EURC, locked in a contract the principal controls on the chain where the stablecoin lives (Base in the current deployment variant). MintID runs no general smart-contract VM: it keeps the reservation state and checks a proof of the lock. Specified, scheduled; not built. The layer is scheduled for the 2027 window; its audits have not started and no funds are locked today. Identity comes last, reached only through due process and never bought with a payment. L0 ### First: the money settles it Routine disputes are paid out from the funds standing behind the agent, quickly and with no identity revealed. For most cases, this is the whole story. L1 ### Next: a minimal fraud signal If fraud is found, a minimal, banded signal is shared: that a real, KYC-verified person stood behind the agent, at what grade, in which jurisdiction, and how many disputes against them were upheld before. Never a name, a document or personal data. L2 ### Last resort: full identity, under due process Only if both parties reject the arbiter’s determination and the arbiter certifies that a court is warranted is the human behind the agent identified — the arbiter decides, the issuer releases, and the council, once seated, reviews after the fact. Never on payment alone. The ladder is built so that nobody profits from stalling or from a counterparty’s forfeiture: silence has a cost, and forfeited stakes serve the party that was wronged, never anyone else’s balance sheet. Design decision ## Consent is the firewall Why a relying party wants identity determines whether consent can even be asked — and that splits disclosure into two rails that never touch. ↗ ### The consented commercial disclosure rail A relying party that wants a relationship (an account, a subscription, compliance for its own books) can make an offer: a priced disclosure bid, paid to the principal, resolved by the principal’s own policy or a live prompt to the human. Refusal is free, safe and the default. The lawful basis is the person’s explicit consent, never the payment. Built, switched off and fail-closed on both sides; activation waits for counsel. ⚖ ### The dispute rail When something went wrong, you cannot ask the subject — a defrauder would always refuse. In the design specified and scheduled for the financial-recourse stage, disputes run on escrow, bonds and due process: paid first with no identity, escalated to a minimal fraud signal, unmasked in full only when an arbiter certifies a court case is warranted. The subject cannot veto it, and no one can buy it. The two rails are separated by construction. A refusal on the commercial rail can never escalate into a dispute, and an unmasking can never be dressed up as a consented offer. Each disclosure leaves a committed receipt on-chain, never its content. Even a paid reveal identifies one agent at one moment. It gives no right to recognise, re-contact or track the principal afterwards; a counterparty that wants to know again later pays again. Pairwise pseudonyms live only as long as the credential and change on renewal, which is how the privacy guarantee works. **Identification, not surveillance.** The credential, sharpened ## What an agent credential can prove Four properties of the agent credential — each one provable in zero knowledge, none of them a tracking handle. 5× ### Scope you can prove, part by part An agent’s delegated scope is structured: what it may do, with whom, in which categories and places, when, and up to what value. It is signed at mint, so the agent cannot widen it, and each part is provable on its own — a merchant can learn “authorised for this category, under this limit” and nothing more. The axes are specified; bounded agents are minted today with a preset scope, and the verifier-side delegation checks arrive in the next waves. KC ### Key custody, attested The issuer attests how the agent’s keys are held, and the agent can prove it meets a custody requirement without exposing a correlatable identifier. A managed runtime is a signal to weigh, never a root of trust. OC ### Operator context, without linkability An optional attested attribute describes who operates the agent, separately from which agent it is. Two agents of the same principal stay unlinkable, always. <1m ### Revocation through fresh status Issuer-side revocation enters the next status root (≤ 30 s) and is refused by every verifier within the maximum root age — under a minute at the reference values — or at once through the emergency key. The chain enforces status freshness as a consensus rule, and no verifier accepts a status root older than the maximum root age: 45 seconds at the reference values, 180 seconds on the single-node production chain. An optional push channel can announce revocations sooner, but it carries no security weight: the status root is the truth. No human reachable? ## When an agent runs for months and no human answers Agents run for months with no human reachable. In the design of the consented commercial disclosure rail, the principal can pre-delegate a bounded consent authority, with a ceiling cut along identifiability: a pairwise pseudonym is fully delegable; a single contact attribute only to a named allowlist, with caps and an expiry; full KYC never — that always takes a live human, or the answer is no. A price can be a condition for consent, but never a substitute for it. Where it stands ## What ships today, and what the next wave adds The agent credential profile and issuer-side minting run today on the single-node production chain, in production since 20 September 2026 and operated by the CONECTIA group. Each agent credential is derived from a presentation of its principal’s credential, under a per-person cap, an issuance rate limit and a renewable lease, and the buyer-side transport for payment flows runs there too. Bounded agents are minted today from a bundle catalogue the operator supplies. The person or the operator can switch a credential or an agent off without asking the issuer, in production since 24 September 2026. The consented commercial disclosure rail, contact-attribute identification included, is built and ships switched off and fail-closed; its activation waits for counsel. Disclosure to a nominated, legally obligated counterparty is specified and under construction on the disclosure rail; its activation depends on a counsel item. The next waves bring the verifier-side delegation checks, which make the counterparty proven rather than declared, and the self-service verifier tier. Money before identity, the financial layer, is specified and scheduled as the next layer (2027 window); audits not started; no funds are locked today. Each audit in the programme is a scheduled milestone whose findings are published. The CONECTIA group operates the chain, the first accepted issuer and verifier, and ZadQ, the first product built on MintID; it is a disclosed related party of MintID, and nothing measured there is independent adoption. ## Works with the agent stack you already use MintID’s agent credentials compose with the emerging agent-identity and agentic-payment rails, so human-backed identity can sit inside agent-to-agent (A2A) and Model Context Protocol (MCP) workflows. By April 2026 the major payment networks had shipped or announced know-your-agent features that restore accountability by revealing the principal’s identity to the seller. MintID leaves that mass, lower-assurance segment to them and builds for a narrower one: backing that is private, regulated-grade and, from the financial-recourse stage, funded. OpenID4VCIOpenID4VPx402Web Bot AuthA2AMCPAP2 For agent payments, MintID integrates as a transport profile and leaves the payment protocol unchanged. An x402 seller’s payment-required response can state an identity requirement; the buying agent answers a short-lived challenge from the payment facilitator, which acts as the registered verifier, and presents alongside its payment. The profile defines three levels: payment only; Web Bot Auth, for identified software; and Web Bot Auth plus MintID, for identified software with an accountable human behind it. ZadQ, the first product built on MintID, an x402 seller-verification service operated by the CONECTIA group, a disclosed related party, applies the idea to sellers on the classical seller rail; the zero-knowledge seller rail follows. [Read about ZadQ](/en/x402-pilot) ## Human-backed agent identity — the essentials What does the market call know your agent (KYA)? Know your agent (KYA) is the market’s expression for verifying that an autonomous AI agent is operated by a known, accountable party: the agent-era counterpart to Know Your Customer (KYC). What MintID builds is verifiable human-backed agent identity: an agent proves that a real, KYC-verified, liable human stands behind it, without revealing who. How does human-backed agent identity differ from KYC? KYC identifies a customer to a business. The market practice of knowing your agent asks the same question about an agent: who is accountable for it? In MintID’s implementation, one human is verified once and backs many AI agents, and each agent proves its backing on demand, accountable to counterparties while the operator’s identity stays private. How does an AI agent prove it is human-backed? The person behind the agent completes KYC once with an accepted issuer, which then mints a credential for each agent. On request, the agent presents a zero-knowledge proof, valid for ten seconds, that a verified, liable human stands behind it, at the required assurance level and within its allowed scope, without exposing the human’s identity. Does MintID expose who is behind the agent? No. The proof shows the agent is human-backed and in good standing, not who the human is. Identity leaves the system only with the person’s consent, or as a last resort under due process, and a payment alone is never a reason to disclose it. Does MintID’s agent identity work with A2A and MCP? It is designed to. MintID’s agent credentials compose with existing agent-identity and agentic-payment rails (agent-to-agent (A2A) and Model Context Protocol (MCP) workflows, OpenID4VCI and OpenID4VP, x402 and Web Bot Auth, and agent-payment mandates such as AP2), so agents keep the stack they already use. More questions — on assurance grades, key recovery or what the chain stores? Read the [full FAQ](/en/faq). New to the concept? Start with the guide to [what the market calls know your agent](/en/blog/what-is-know-your-agent) ## Give your AI agents an identity people can trust Each of your agents can carry its own credential, backed by one verification of you and private by design; the design draws on the OpenID Foundation’s work on identity for agentic AI. See how the protocol defines it, or talk to us about building on it. [Get in touch](/en/contact)[How the protocol defines it](/en/protocol) --- Source: https://mintid.net/en/agent-kyc · Agent KYC — verifiable human-backed agent identity — MintID --- > How a native token would secure a public MintID network, if MintID ever scales that way: a hard cap of 108,000,000, a declining emission, protocol cuts, staking and issuer bonds. No token is issued, MintID does not need one today, and nothing is for sale. Token design # If MintID goes public, a token capped at 108,000,000 would pay for its security If MintID one day scales to a public, permissionless network, that network’s design includes a native token with a maximum supply fixed at exactly 108,000,000. No such token exists today, and MintID does not need one: it runs on the single-node production chain, which is permissioned and where nothing can be bought. In that design, the token makes the network expensive to attack and cheap to trust: validators bond it to secure consensus, issuers lock it as collateral for good behaviour, and the flows that grow with adoption carry a protocol cut whose allocation is a governed parameter under review. Its job is to pay for security, and no amount of it ever buys access to anyone’s identity. the flows 108 mhard capstakebondfees [Read the whitepaper](/en/whitepaper)[See the roadmap](/en/roadmap) Status ## The token exists on paper, and this page says why No MintID token is issued, offered or admitted to trading. Today MintID runs on the single-node production chain, in production since 20 September 2026 and operated by the CONECTIA group — a permissioned chain where security is key custody, not stake, and whose unit of account has no value and is never carried over to a public network. That chain serves the current issuers, verifiers and pilots without any token. Everything on this page describes one way MintID could scale later — a public, permissionless network that pays for its own security — if that route is chosen at the Gate-1 go/no-go, and only through the full EU MiCA Title II process. No token todaySingle-node production · nothing for saleScaling route · decided at Gate 1 In one minute ## How the money would work 01 ### The supply is capped The maximum supply is 108,000,000 tokens, counted against everything ever minted. New tokens come only from the validator reward pool, on a public, strictly declining curve that must exhaust the pool exactly. The prior is 3% of the cap in year one — 3.24 million tokens — declining by a factor of 0.95 each year: about 40% of the pool in ten years, and 79% within thirty. 02 ### Validators earn the new tokens Each epoch’s new tokens would go to the validators who did the work, weighted by stake and by how reliably they signed. A validator that misses blocks would earn less, and one that cheats would lose its stake. Nobody is paid for judging identities: validators never see one. 03 ### Protocol flows pay Issuers pay admission, renewal and registry-lease fees. Agent credentials pay a mint fee and a recurring lease, and consented disclosures pay a protocol cut too. Each cut, and how it is allocated, is a governed parameter whose final form is under review. The cap is frozen. Everything else is a ratified band, inside which only governance can move a value, or a prior — an argued working point that the independent pre-genesis simulation validates or argues against. No price appears anywhere on this site. Genesis allocation ## Where the supply would go, in three compartments The genesis allocation is ratified as bands — development and team 15%, public-sale tranche 20–25%, reward pool at least 60% — with priors of 15, 25 and 60%. The simulation fixes the final points inside the bands, and if it recommends a lower sale point, the difference returns to the reward pool. 15% ### Development & team 16.2 million tokens at the prior, for developer compensation, operations, and ecosystem and tester grants, in labelled sub-accounts. Four-year continuous vesting with a one-year cliff and a twelve-month lock-up after genesis — and while those apply, the accounts may not delegate or vote, and they do not count toward the launch-security gate. 25% ### Public-sale tranche 27 million tokens at the prior: the tranche that would finance a launch if the public route is chosen, offered only through the full EU MiCA Title II process, at a single fixed price and with a raise floor of $4.0 M net. Nothing is for sale today. 60% ### Reward pool 64.8 million tokens at the prior, reserved for one thing only: paying the validators who secure the chain, on a strictly declining emission. When the pool runs out, the security budget is the fee market, backed by a committed succession ladder — and minting beyond the cap is excluded by construction. One genesis event, and no discretionary mint after it. A Genesis Allocation Statement will list every genesis address with its label, percentage, vesting and custody, and its hash will be committed in the genesis file so that anyone can reconcile block 1 against it. Treasury and grants accounts sit behind a multisig with an independent co-signer and a timelock. These bands, and the mechanism behind every flow on this page, were examined by an economic-viability review in July 2026, performed by Conectia PRO — a related-party service provider, not an arm’s-length third party, as the report’s cover discloses. The report is published in full. The independent economic review, the only arm’s-length opinion, is still ahead. [Read the findings](/en/blog/we-audited-ourselves) Economics ## Every flow would pay into the same structure Everything a public network would earn fits in five flows. Only two carry protocol cuts, and a firewall keeps service revenue away from consensus rewards. Apart from the fixed cap, every number is a band or a prior until the simulation fixes it. LEASE ### Agent mint + lease Each agent credential pays a mint fee and a recurring lease on a governed schedule. The protocol takes a cut — a governed parameter under review. It is the one protocol revenue line that grows with the agent population; presentations stay free. ISSUER ### Issuer economics KYC organisations pay admission, renewal and an active-registry lease — governed parameters — and post a slashable bond without which they cannot operate. Slashes fund remediation for the parties harmed. BID ### Disclosure brokerage When a relying party pays to identify an agent and the principal consents, the bid goes to the principal, the issuer may earn a brokerage fee, and the protocol takes a cut — a percentage plus a fixed floor per disclosure — collected on aggregate settlement. A refusal costs nothing and pays nothing. The consented commercial disclosure rail is built and ships switched off and fail-closed; its activation waits for counsel. ARBITER ### Dispute & arbiter market Claim bonds, slashable dispute bonds, and arbiter fees paid by the losing party. This is off-chain service revenue for arbiters, and it must never influence consensus rewards. The dispute rail is specified and scheduled for the financial-recourse stage. SVC ### Premium verification services Basic verification is free by design: off-chain, against public state, with no per-check fee. What can be paid for is the premium layer around it — mirrors, archives, managed services — and those fees never touch consensus. No usage tax exists or is planned. At a glance ## Ratified values, bands and priors The figures the Protocol Whitepaper v1.0 publishes, and the status of each one. Value Status Figure Maximum supply Frozen 108,000,000 tokens, exact Genesis allocation — development / public sale / reward pool Bands 15 / 20–25 / ≥ 60% Priors 15 / 25 / 60% Emission curve Rule: exhausts the reward pool exactly; strictly declining Prior 3% of the cap in year one, ×0.95 per year Protocol cut on agent mint and lease Governed parameter Under review Allocation of each protocol cut Governed parameters Final form under review Genesis active set · voting-power cap · unbonding Priors 60 (toward 100 by governance) · 5% · 21 days Launch-gate thresholds Priors ≥ 20% of supply externally bonded · ≥ 25 independent operators · Nakamoto coefficient ≥ 7 Raise floor (public-offer route only) Ratified invariant $4.0 M net of statutory withdrawals Offer price, if an offer is ever made Ratified mechanism One fixed price, no tiers — the figure appears only in the MiCA white paper Vesting · lock-up Policy Four years with a one-year cliff · 12 months; no delegation or vote while they apply Status freshness · presentation lifetime Governed · constant 30 s heartbeat, 45 s maximum age (reference value; 180 s on the single-node production chain), fail closed · 10 s, single use Frozen means fixed for good. A band binds; a prior is an argued working point, validated or argued against by the independent simulation before genesis. Why it compounds ## One KYC, every agent One human verification carries across every agent that human deploys. Machine identities already outnumber human ones by roughly 50 to 1 (Omdia, December 2024). In a per-check world, every agent of every person pays for verification again at every counterparty. Here, one KYC backs many agent credentials, each paying only its mint and lease — and every presentation is free for everyone. Every market figure on this site carries a primary source — see [where the numbers come from](/en/sources). ## What the token would do On a public network, the token would be the economic-security asset: each use below puts value at stake against misbehaviour. STAKE ### Staking & delegation Validators would bond tokens to run consensus, and delegators could back them and share in their rewards. The more value staked, the more an attack costs. BOND ### Issuer bonds On a public network, every KYC organisation allowed to issue credentials would lock a native-token bond, and the chain would not activate an issuer without one. Proven fraud or negligence is slashed through an evidence-backed council process, and a slash that exhausts the bond suspends the issuer at once. The bond is sized against a published deterrence target, above the gain from the cheapest slashable violation. Each slash funds a remediation share for the parties harmed; the allocation of the rest is a governed parameter under review, and the body that adjudicates can never profit from it. FEES ### Fees & leases Transaction fees, registry leases and status-publication fees would keep a public network running; they are governed parameters. The system does not depend on end users transacting constantly to sustain itself. VOTE ### Governance weight On a public network, software governance would run through the token: protocol upgrades and versioned parameters are decided by token-weighted on-chain voting, alongside an operational compliance council, once it is seated, whose reserve actions always require an independent custodian’s co-signature. Deliberate boundaries ## Where the design draws its limits Each boundary below is written into the specifications, and each one closes a way the token could be misused. ∅ ### Not a key to identities No payment — token, bid or bond — is ever the lawful basis for revealing who someone is. Commercial disclosure requires the person’s consent; dispute disclosure requires due process. Money alone never unlocks identity. € ### Not the dispute escrow The recourse behind AI agents does not depend on the native token. The capital is the principal’s own USDC or EURC, locked in a contract the principal controls on the chain where the stablecoin lives (Base in the current deployment variant). MintID runs no general smart-contract VM: it keeps the reservation state and checks a proof of the lock. Specified, scheduled; not built. No funds are locked today. No fiat custodian, no third-party deposit, and no anonymity-enhanced coin in any collateral set. ₿ ### Not backed by the reserve A small, separate BTC reserve would exist only for proven issuer-fraud remediation and critical security incidents. It is not token backing, not a bridge, not escrow collateral and not a price-support fund — moving it takes the council plus an independent custodian, an on-chain commitment, a reason code, a timelock and a public report. ✕ ### Not a claim on anyone’s revenue No dividends, no distributions, no backing, no price support. The protocol cut on agent flows and its allocation are governed parameters under review, and whatever share of protocol cuts the Foundation receives is earmarked and never paid out to token holders. ⊘ ### Not a privacy coin The native token never supports shielded or anonymity-enhanced transfers — a protocol invariant of the same rank as the hard cap. MintID’s privacy protects identities, not payments: the token’s value flows stay transparent and auditable end to end. Consent or due process ## A bid is not a bond BID ### Disclosure bid A payment for consent. It goes to the principal if they accept; nothing happens if they refuse; it is never slashed. On the commercial rail the basis for any disclosure is the principal’s consent. BOND ### Dispute bond Slashable stake: it deters frivolous claims and is adjudicated. On the dispute rail the basis is due process, never money. The two never mix — and no payment of either kind is ever a lawful basis for revealing someone’s identity. Incentives ## Who earns what In the public-network design, consensus rewards and service revenue are firewalled from each other: securing blocks would be paid in new tokens, while identity services are paid in ordinary fees that can never influence consensus. ### Validators & delegators Earn the declining epoch emission, split by stake and signing performance, plus transaction fees. Validators charge a declared commission on delegated rewards. ### Issuers Pay admission, renewal and registry leases, and earn off-chain by charging for KYC and credential issuance. The locked bond is what they stand to lose. ### Verifiers & arbiters Earn direct service fees off-chain — managed verification services, status mirrors and archives, and arbitration fees paid by the losing side of a dispute. Never consensus rewards. ### The Foundation Dormant until the public-offer route is chosen. On that route it would receive a share of protocol cuts, earmarked first for the validator operator floor program and then for its own operations, under a public annual report. It has no other revenue role. ## Only the cap is frozen; every other value is a band or an argued prior The hard cap and the declining emission are normative requirements; the maximum supply is exactly 108,000,000 tokens and immutable. The allocation is ratified as bands with published priors — 15% development, 25% public sale, 60% reward pool — and the independent simulation validates each prior or argues against it before genesis. Many token models quote a maximum supply their own emission can never reach; MintID closes that gap by rule, so the cap is the real denominator of every figure published. One thing stays visible on this page on purpose: nothing is for sale. No sale, no pre-sale, no whitelist, no price, no date. There is exactly one route by which an offer could ever exist — the full EU MiCA Title II process: a crypto-asset white paper, notification to the AFM (the Dutch authority, competent through the Foundation’s seat), a public offer at a single fixed price, and only then admission to trading. Every other offer term will appear only in that white paper. Until then, anything that looks like a MintID sale is not us. Every market figure on this site carries a primary source — [see where the numbers come from](/en/sources). [Read the whitepaper](/en/whitepaper)[Get in touch](/en/contact) --- Source: https://mintid.net/en/tokenomics · Token design for a possible public network: hard cap, staking, bonds — MintID --- > The MintID roadmap as set out in Protocol Whitepaper v1.0: the single-node production chain today, five gated stages to commercial operation, seven build phases toward mainnet, and a financing route decided at the Gate-1 go/no-go. Roadmap # Where we are, and what comes next The path is published before it is walked. The design has been reviewed for economic viability by [Conectia PRO](https://conectia.pro), a related-party service provider, and both that review and the whitepaper are published in full. Every change since traces back to a recorded decision; the specifications are available on request. Today MintID runs on the single-node production chain, in production since 20 September 2026 and operated by the CONECTIA group. The MintID Foundation, a Netherlands Stichting, is being incorporated by the founder and stays dormant until the public-offer route is chosen. The independent simulation and the audit programme come next, as scheduled milestones with published findings; an offer under the full MiCA process follows only if the public route is chosen, and the network starts after that. [Talk to the team](/en/contact)[Read the whitepaper](/en/whitepaper) The path to commercial operation ## Each stage opens only when its gate is met If a minimum is not reached, the plan re-stages rather than launching early. Stages and target windows follow Protocol Whitepaper v1.0 (4 October 2026). 00 We are here · Now → 2027 ### Single-node production The seven build phases below sit inside this stage. The single-node production chain, in production since 20 September 2026 and operated by the CONECTIA group, carries the first issuer, the first verifier and the ZadQ pilot while the distributed network is built; the public testnet with its KYC sandbox runs beside it, and the proof core is in production. The code is open source under Apache-2.0. The MintID Foundation is being incorporated by the founder and stays dormant until the public-offer route is chosen, and the financing route is decided at the Gate-1 go/no-go. The CONECTIA group funds the work as its own R&D and is never reimbursed. **Gate:** the Gate-1 go/no-go on the financing route; on the public route, the simulation delivered, legal workstreams complete, trademark filed, and the Foundation’s board and statutory safeguards in place. 01 Upcoming · 2027 ### Public offer, on the public route only If the Gate-1 go/no-go chooses the public route, the full EU MiCA Title II path follows, in order: the crypto-asset white paper, notification to the AFM, the public offer, then admission to trading. **Gate:** white paper cleared by counsel and notified, board and safeguards in effect before signature, bank and custodian onboarded, and the $4.0 M net raise floor met — otherwise the plan re-stages. 02 Upcoming · Target H2 2027 → 2028 ### Identity-only mainnet Genesis, with a set of 60 validators. Credentials for people and their agents, zero-knowledge presentations, status roots, free verification, the verifier registry and the compliance council go live, and ZadQ, today on the classical seller rail, moves onto the network. No escrow and no disputes yet. **Gate:** the economic-security thresholds met in measurable units, genesis values frozen and the Genesis Allocation Statement published, with the audit programme reported as scheduled quality milestones whose findings are published — with genesis itself triggered by a published traction criterion sustained for two quarters. 03 Upcoming · 2028–2029 ### Financial recourse and disputes Self-custodied stablecoin escrow, the dispute rail and its arbiter market. The consented commercial disclosure rail is already built and ships switched off and fail-closed; its activation waits for counsel. **Gate:** a published demand criterion and unmasking governance reviewed by counsel, with the audits of the escrow contracts and the dispute cryptography as scheduled milestones whose findings are published. 04 Upcoming · 2030–2031 ### Maturity Multiple issuers, a growing agent population, the active set grown toward 100 by governance, and the post-emission transition planned on a committed ladder. **Gate:** continuous — transparency reporting, annual audits published with their findings, and monitored gate metrics. Stage 0 · the build ## The build, phase by phase Underneath the stages sit seven build phases. Each one ends in something that can be tested. 00 Done ### Specifications frozen The core, agent-identity and disclosure specifications and the full requirement set were written and frozen before code was built against them — then revised and frozen again after the economic-viability review. 01 Done ### Chain foundation Stand up the sovereign Layer-1 itself: consensus and the base chain. The first thing that runs is a real blockchain, and it runs without any token. 02 Done ### Issuers, council, bonds & status The machinery of trust: the accepted-issuer registry, the compliance council’s on-chain machinery (the council itself is not yet seated), slashable issuer bonds and the 30-second status heartbeat — done on the chain, with the status plane and the issuer service running off-chain and issuing credentials in production. 03 Done ### Verifier registry and verification core The exact-origin verifier registry and the verification core: chain reads proven rather than trusted, single-use challenges and the full acceptance pipeline, behind a versioned service contract. Done. 04 Done ### Anonymous credentials The cryptographic heart: the anonymous-credential scheme and issuance, so that holders can prove claims in zero knowledge. Done: credential issuance, selective-disclosure presentations and the non-revocation path run in production, with the construction and the proof system frozen. 05 Done ### Holder self-revocation The proof that lets anyone withdraw their own credential — after a lost phone, for instance — without revealing who they are or which credential it was. In production on the single-node production chain since 24 September 2026; its audit a scheduled milestone whose findings are published. 06 Upcoming ### Public adversarial testnet & audits Invite independent operators, issuers and verifiers to attack the public adversarial testnet, run the independent audits and publish their findings, and open mainnet when the launch gate is met. The gate is measurable and price-independent — priors of at least 20% of supply bonded by external parties, at least 25 independent operators and a Nakamoto coefficient of at least 7 — and insider accounts count toward none of it. Two deployments exist today: the single-node production chain on which the ZadQ pilot runs, and the public testnet with its KYC sandbox. Neither is yet the distributed MintID network. Bounded agents are minted today from a bundle catalogue the operator supplies. The consented commercial disclosure rail, contact-attribute identification included, is built and ships switched off and fail-closed; its activation waits for counsel. Stage 1 · financing ## How a launch would be financed, if the public route is chosen If the Gate-1 go/no-go chooses the public route, the launch would be financed through the project’s own public tranche, under the EU MiCA Title II regime and in its prescribed order: the independent economic simulation sets the numbers, counsel drafts the crypto-asset white paper, the AFM — the Dutch regulator, competent through the Foundation’s seat — is notified, the public offer opens, and admission to trading follows. Any such offer would have a single fixed price and a raise floor of $4.0 M net: below it, the project re-stages instead of launching under-funded. Proceeds would finance the launch under a published budget — audits, validator bootstrap, counsel, the Foundation, custody and runway — and every other offer term would appear only in the MiCA white paper. Genesis path ## The work that stands between today and any genesis ### Independent economic simulation An external study that fixes the emission and allocation points inside the ratified bands, the launch-gate thresholds, bond sizing, the post-emission security budget and the traction criterion — with adverse, base and growth scenarios, and a model a third party can re-run. ### Counsel workstreams The legal path for a possible offer and for the disclosure rails — including drafting the single crypto-asset white paper that MiCA Title II requires. ### MiCA Title II execution On the public route, notification to the AFM, the Dutch regulator, comes first, then the public offer, and admission to trading only after both. The European regime runs in full and in that order. Pilot ## The first product built on MintID ZadQ, the first product built on MintID, is an x402 seller-verification service operated by the CONECTIA group, a disclosed related party. It runs today as a pilot on the single-node production chain, on the classical seller rail, and nothing it records counts as independent adoption. [Read about ZadQ](/en/x402-pilot) ## What an early issuer, verifier or validator can do today MintID needs three kinds of collaborators, and each can start a conversation today, well before mainnet. ### Issuers KYC organisations that verify people and vouch for them. You keep the customer relationship and the only private link to a person; the chain never sees your files. Early issuers help shape admission, the KYC policy behind the A1–A4 grades, and bonding. [Start the conversation](/en/contact) ### Verifiers Businesses that need to check a fact about a person or an AI agent — age, accreditation, a real human behind a bot — without holding their data. Early verifiers define the policies the rail must serve. [Start the conversation](/en/contact) ### Validators Operators who would run nodes and secure consensus on a public network, if that route is chosen. The role involves no identity work and no KYC files. Early validators join the public adversarial testnet first, when it opens, and help battle-test the network. [Start the conversation](/en/contact) ## Where the build is announced The whitepaper explains the destination; the specifications, available on request, define every step. If you want to issue, verify, validate — or just understand — we would like to hear from you. [Get in touch](/en/contact)[Read the protocol](/en/protocol) --- Source: https://mintid.net/en/roadmap · Roadmap — a staged, gated path to mainnet — MintID --- > Accepted KYC organisations issue reusable credentials, publish a signed status root at least every 30 seconds, and keep the only link between a credential and a person. For issuers # Vouch once; the link to the person stays in your custody Issuers are the organisations that check who someone is, once, and vouch for them from then on. You run the KYC, issue the credential and publish a live status root, and you are the only party that can ever link a credential back to a person, and only under due process. An issuer is admitted on chain by governance proposal (by the compliance council once it is seated) and posts a slashable bond; the first accepted issuer runs on the single-node production chain, in production since 20 September 2026 and operated by the CONECTIA group. the seal \[ accepted \]bond · slashable ## What an accepted issuer is responsible for Each issuer is recorded on-chain as an institution: an identifier, an organisation-level name, its keys, its permitted grades, its authority state, its current status root and its bond. The chain holds you to those commitments. ✓ ### Accepted-issuer model Only KYC organisations admitted on chain by governance proposal (by the compliance council once it is seated) can issue credentials that verifiers accept. An issuer’s authority moves through a closed set of states — pending, active, enhanced monitoring, suspended, revoked — and the chain rejects any other transition. A ### Private assurance grades You issue at grades A1 to A4 according to the strength of the verification, within the grades your admission allows. The grades are anchored on eIDAS low, substantial and high and squared with ISO/IEC 29115, with enhanced due diligence as the step between substantial and high. Recency is a separate freshness band that you publish beside the grade; it is read on the classical seller rail and is not a presentation predicate. Validity defaults to 12 months for A1 and A2, 6 for A3 and 3 for A4, and a credential expires exactly when the verification behind it does, with no grace period; the way back is a new verification. 30s ### 30-second status roots You publish a signed status root at least every 30 seconds. Verifiers check credentials against your latest finalised root, so a revocation enters your next root and is refused everywhere within the maximum root age, without revealing who a credential belongs to — and if your roots stop, your credentials fail closed within that same bound: 45 seconds at the reference values, 180 seconds on the single-node production chain. RVK ### Emergency revocation A separately scoped emergency key lets you publish an emergency root at once, with strict ordering and rate limits. It is final after normal chain finality, reveals nothing about anyone, and its use is reviewed through governance (by the compliance council once it is seated). BOND ### Issuer bonds & council An issuer locks a slashable bond before it can become active. In the protocol design, the compliance council, once seated, can suspend, sanction or slash an issuer through an evidence-backed decision with a public reason code; a slash that exhausts the bond suspends the issuer at once. Routine key rotation stays in your hands; the council steps in only to force a rotation when an operator key is lost or compromised. VAULT ### Private case vault You hold the encrypted KYC evidence and, for agents, the private accountability escrow — the only link between an agent credential and a human. That link is released only under due process, and never on-chain. Off-chain ## The services you run, and what the chain sees of them Issuance and status live in your own off-chain services. The chain only ever sees signed roots, registry transactions and bond operations — never personal data, documents or the credentials themselves. VCI ### Issuance over OpenID4VCI Credentials reach the holder’s software over OpenID4VCI, the protocol family of the EU Digital Identity Wallet. REG ### Private status registry An encrypted registry records whether each credential you issued is active, suspended or revoked — and the chain never sees a single entry. ROOT ### 30-second status roots The registry is condensed into a signed root at least every 30 seconds. Relayers may batch many issuers’ roots and pay the fees, but only your signature authorises a root. KYC ### Provider-neutral KYC Your identity-verification provider plugs in behind one neutral interface, so changing provider never touches the chain — and the grade remains your decision. KEYS ### Hardware-backed keys Signing keys, the emergency key included, stay in hardware-backed signers, so forging a root, a credential or a revocation would require breaking into the signer itself. FEES ### The economics You pay admission, renewal and registry-lease fees, all governed parameters. You earn from your own KYC services and, for agent credentials, from the mint fee and lease fee. The first accepted issuer is operated by the CONECTIA group, a related party of MintID. The first issuer and the first verifier were admitted through the same path the protocol offers anyone: a governance proposal, today voted by the chain’s single validator and, once the compliance council is seated, by the council; the same slashable bond; the same 30-second roots; all of it on chain. ## Become an accepted issuer Issuer admission runs through the compliance council once it is seated; until then it is a governance proposal voted by the chain’s single validator, and it starts as a conversation with the team. Talk to us about admission, permitted grades and bonding, or read how issuance, status roots and the registry fit into the protocol. [Talk to us](/en/contact)[Read the protocol](/en/protocol) --- Source: https://mintid.net/en/issuers · For issuers — become a KYC credential issuer — MintID --- > Check a fact about a person or an AI agent with a ten-second zero-knowledge proof, pay no per-check protocol fee, and keep only a minimal decision record: never the proof, never the person. For verifiers # A yes-or-no answer in ten seconds, and nothing to store Verifiers are the businesses that need an answer (“over 18?”, “accredited?”, “a real human behind this agent?”) without holding anyone’s data. You ask a holder to prove a fact and get back a cryptographic yes or no, with no identity attached. Presentations are valid for ten seconds, bound to your exact request, and never written to the chain. the answer the data · sealedzk proof10 s · gone ## How verification works in your favour The protocol is designed so that the safest record to keep is almost no record at all. You can show that a person met your policy without ever storing who they are. 10s ### 10-second perishable proofs A presentation is valid for ten seconds and answers exactly one challenge. One answer can cover several predicates at once; after that it expires, and a durable replay guard makes sure it is never accepted twice. ⊞ ### Bound to your request Every presentation is bound to your verifier, your exact origin, the request key you signed with, the single-use challenge, the policy you asked for and the chain state you checked. Nothing about it transfers to another context. ◉ ### Online verification Before accepting, you re-check issuer and verifier state against finalised chain state, read through cryptographic proofs instead of a trusted node. Verification is online by design, so the trust you act on is never older than the maximum root age. ≥ ### Ask for the fact and nothing underneath You request only the facts you need: grade ≥ A3, over 18, credential active, a particular issuer. The holder proves each predicate without revealing the data underneath. ▤ ### Minimal decision record Presentations never enter the chain. You keep only a minimal record of the outcome; the proof and the person stay out of it, so there is nothing sensitive to leak or subpoena. ✓ ### KYC-approved verifier registry To request proofs you complete KYC with an accepted issuer, register a request-signing key and your exact origins, prove control of those domains, and are admitted on chain by governance proposal (by the compliance council once it is seated). Origins are revalidated periodically; wildcards are not allowed. Lifecycle ## A single verification, end to end 01 ### Request a challenge You issue a signed, single-use challenge over OpenID4VP that names your verifier and exact origin, states the predicates you need — for example grade ≥ A3 and credential active — and expires in ten seconds. 02 ### Holder builds a bound presentation The holder software checks you against its own trust list, then answers with one zero-knowledge proof bound to your challenge, origin and policy and to the chain state you recorded. 03 ### Verify against finalised state You re-check the issuer and your own registration against finalised chain state — read through cryptographic proofs rather than a trusted node — confirm every requested predicate is proven, and consume the challenge so it can never be replayed. 04 ### Record a minimal decision You store a minimal decision record — that the policy was satisfied at a point in time — and discard the proof. Nothing enters the chain, and no personal data is retained. Free by design ## Basic verification costs nothing Verification runs off-chain against public state, so the protocol charges no usage tax and no fee per check. That is a protocol rule, written into the design, and it does not expire. 0 ### No fee per check The protocol’s fees sit on agent credentials (the mint fee and lease fee) and on the consented commercial disclosure rail, never on the act of verifying. ∅ ### Nothing to keep The decision record is minimal by construction, so verifying never turns you into a holder of personal data. SVC ### Optional paid services Mirrors, archives and managed verification services may charge their own fees. Those fees never touch consensus rewards. Registered verifiers are accountable too: KYC-approved, bound to exact origins, revalidated periodically, and suspended if they abuse the registry. For registered verifiers ## Your stack, our guarantees The verification logic exists in exactly one implementation. You embed it in your backend, or run the same core as a service next to it; client SDKs are transport-only and carry requests to that service. You bring the infrastructure — your registration, your origins, your keys, durable replay protection and a clock you trust. The core brings the parts you cannot get wrong: the acceptance checks always run in full, presentations expire in ten seconds, every chain read is proven rather than trusted, and only a minimal decision record is kept. None of it is configurable, and no client offers a “lite” mode. Available today: a versioned service contract, a Python SDK, a transport-only TypeScript client and an MCP server for agent tooling; further languages follow demand. The proof core behind them is in production. Admission is not self-service yet, so integration starts as a conversation; the [technical integration docs](/en/sdk) are open. For agent runtimes ## Verification where agents live: MCP Agents run inside runtimes, so that is where agent identity should be checked. The MCP server exposes the operations of the verifier service as Model Context Protocol tools, so an MCP-capable agent framework can ask for a challenge, pass on a presentation and read the decision. Like every client it is transport-only, runs inside your own perimeter and points at your own service. A rejection comes back as an ordinary result with a reason code, so an agent can reason about a refusal instead of retrying blindly. The [MCP server docs](/en/sdk/mcp-server) list the tools and the trust boundary. x402 sellers ## The first product built on MintID ZadQ, the first product built on MintID, is an x402 seller-verification service operated by the CONECTIA group, a disclosed related party. An accepted issuer signs a conventional attestation that an accountable, KYC-verified party stands behind a seller’s payment address, without naming that party, and explorers and buying agents read the signal for free. This runs on the classical seller rail; the zero-knowledge seller rail follows. ZadQ is an ordinary issuer-and-verifier pairing, and it runs as a pilot on the single-node production chain. [Read about ZadQ](/en/x402-pilot) ## Verify without becoming a data liability Registration and KYC approval put you on the verifier registry and let your users approve your exact origins as trusted in their own holder software — no wildcards, so a lookalike domain cannot impersonate you. Once registered, you integrate on your terms: embed the verification core in your backend or run it as a service, with the same checks and the same privacy guarantees either way. Talk to us about onboarding, or read how the protocol fits together. [Ask about registration](/en/contact)[Integrate verification →](/en/sdk)[Read the protocol](/en/protocol) --- Source: https://mintid.net/en/verifiers · For verifiers — verify credentials without storing PII — MintID --- > How validators would secure MintID’s public network if that route is chosen: proof-of-stake consensus on CometBFT that checks cryptographic evidence only, never passports, biometrics or KYC files. For validators # The chain a validator would run carries status roots, never names Validators run the machines that would keep MintID’s public network honest: they run consensus and check deterministic state transitions without ever touching a passport, a biometric or a KYC file, which is issuers’ work. What runs today is the single-node production chain, in production since 20 September 2026 and operated by the CONECTIA group; the validator role below is the design for a public network, if that route is chosen. consensus sees no identitiesfinalised ## What securing MintID would look like Validation here would be cryptographic and deterministic. There would be no identity to inspect and no discretionary judgement to make about a person, only protocol rules to enforce. PoS ### Proof of stake, bounded set In the public design, anyone could run a node, bond tokens and register a validator. The active set would be capped at 60 validators at genesis, growing toward 100 by governance once fee-funded security supports it; no validator’s effective voting power may exceed 5%, and unbonding takes 21 days. All three are priors. ⊨ ### Fast, deterministic finality MintID is designed for delegated proof of stake on CometBFT through the Cosmos SDK, with a block every two to three seconds and a finality objective of about five seconds under normal conditions; a finalised state is final, with no probabilistic waiting. ∅ ### Validators see no personal data A validator would never inspect passports, biometrics, names, addresses or KYC files. KYC is performed entirely by issuers; validators would replicate a deterministic state machine and check cryptographic evidence, nothing else. ◇ ### Paid for consensus, never for judging people In the public design, each epoch’s emission would be shared by capped voting power, weighted by signing performance; delegators would share through the standard path and validators would charge a declared commission. No reward is ever paid for “identity work”. Paid off-chain services you choose to run earn their own fees, firewalled from consensus rewards. ⚖ ### Slashing on objective evidence only In the design, double-signing is slashed with permanent exclusion and sustained downtime with a temporary jail. There is no slashing for alleged censorship at launch, because attribution would be subjective. Professional topologies (sentry nodes, separated and hardware-backed keys, monitoring, reproducible builds) are expected. SLA ### Bootstrap service agreements If the public route is chosen, the initial operators would be recruited under fiat or stablecoin service agreements for their first 12 to 24 months, followed by an operator floor programme, funded by the Foundation once it is active, that pays for verifiable service (uptime, topology, monitoring) and never for stake. ⊓ ### Hard-capped monetary policy In the public design, supply is capped at exactly 108,000,000 tokens. The reward pool, a prior of 60% of the cap, would be paid out only as validator emission, on a strictly declining curve that exhausts the pool exactly: the prior is 3% of the cap in year one, declining by a factor of 0.95 each year. The cap counts everything ever minted; no mint beyond it is ever possible. GATE ### Security-first launch gate If the public route is chosen, genesis would wait for published, price-independent thresholds — priors of at least 20% of supply bonded by external parties, at least 25 independent operators and a Nakamoto coefficient of at least 7 — plus a public adversarial testnet and a funded bug bounty, with the audit programme reported as scheduled milestones whose findings are published. Development and Foundation accounts would count toward none of it. Values marked as priors are working points the team has argued for, inside ranges already agreed; an independent economic simulation, run before any genesis, confirms each one or argues against it. The numbers that shape the role ## Starting values for a public genesis The values the public network would start from. The first three are priors that the simulation confirms or argues against before genesis; the status-root heartbeat is a consensus rule today. 60 → 100 Active validators: at genesis, then by governance 5% Cap on any validator’s voting power 21 days Unbonding period 30 s Issuer status-root heartbeat, enforced by consensus ## Interested in the validator role? Staking, delegation and slashing would follow standard proof-of-stake mechanics. Issuer bonds, and a separate BTC remediation reserve designed to sit under council and independent-custodian control, are outside the validator role. If you operate infrastructure and want to follow the validator design, talk to us, or read the protocol. [Talk to us](/en/contact)[Read the protocol](/en/protocol) --- Source: https://mintid.net/en/validators · For validators — the validator role in MintID’s design — MintID --- > Three specifications define MintID: the identity Layer-1, agent identity and consensual disclosure, shared on request. This page explains why MintID runs its own chain, what it guarantees, what the chain stores and what runs today on the single-node production chain. Specifications # The rules that keep identity off the chain, written down MintID is defined by three normative specifications. Together they describe a sovereign Layer-1, its credential and status protocol, the agent-identity layer built on top of it, and the rules for how identity may ever leave the system. Today MintID is an identity protocol in production on the single-node production chain, operated by the CONECTIA group since 20 September 2026 and designed to scale to a public, permissionless proof-of-stake network; the specifications are shared on request. the stack spec-3 · agentsspec-2 · protocolspec-1 · chain [Request the specifications](/en/contact) Normative documents ## Where two specifications disagree, the lower-numbered one wins The three specifications form a strict hierarchy: SPEC-1 is the foundation, SPEC-2 and SPEC-3 are normative but subordinate, and nothing downstream may weaken a SPEC-1 requirement. SPEC-1 ### Sovereign Privacy-Preserving Identity Blockchain The foundational specification: the sovereign Layer-1, the validator program, the issuer and verifier registries, the credential and status protocol, token economics, governance and operational controls. Frozen; its September 2026 amendment added the agent products. Available on request. SPEC-2 ### Agent KYC and Verifiable Human-Backed Identity The agent-credential layer. It defines human-backed agent identity — minting, backing and scope predicates, and revocation — without weakening the base protocol. SPEC-3 ### Consensual Disclosure and Graduated Remediation The disclosure layer. It fixes how identity may ever flow out of the system: two strictly separated rails, commercial and dispute; the money-before-identity cascade; the difference between a bid and a bond; and on-chain commitments to disclosure receipts. Alongside them sit the Genesis Allocation and Transparency Policy, the MiCA Title II plan for a possible public offer, the scope of the economic simulation, the decision records and the role manuals. Where the whitepaper and the specifications differ, the specifications govern. Design decision ## Why MintID runs its own chain We evaluated launching on an existing network (an Ethereum L2, Solana, BNB Chain) and chose a sovereign Layer-1. The promises MintID makes are promises about an entire chain, and you can only make those if the chain is yours. ### The privacy promise covers the whole ledger MintID guarantees that no personal data, no credential, and no record of any identity check ever touches the chain. On someone else’s chain that promise shrinks to “our contract behaves” — on a ledger where anyone can write anything alongside it. A privacy rail that shares a ledger with everything else isn’t a privacy rail. ### The chain itself rejects a stale status root Issuers publish status roots every 30 seconds, and verifiers reject anything older than the maximum root age: 45 seconds is the reference value, and the single-node production chain runs at 180 seconds. On MintID that bound is enforced by the chain’s own consensus rules end to end — expired, stale and even future-dated roots are rejected at ingestion, so not even a compromised issuer key can pass off an old root as a fresh one. As a contract on a busy general-purpose chain, one congestion spike or outage would silently break that guarantee for every issuer at once. ### Governance and money belong to the chain’s own rules In the design, issuer registries, the compliance council, slashable issuer bonds and the hard-capped token are native capabilities of the chain itself, so no key holder can swap them out the way one swaps an upgradeable smart contract. On a public network, the rules would change only the way the protocol says they can: by token-weighted, on-chain governance. The single-node production chain that runs today has no token, and the CONECTIA group operates it. ### Neutrality you can point to MintID’s core argument against centralized agent-identity schemes is that trust shouldn’t be anchored in one company. Launching on a chain controlled by a single operator or sequencer would undercut that argument in front of the regulated European issuers MintID is built for. The target is a sovereign chain with permissionless validators and many issuers. Today one validator, operated by the CONECTIA group, runs the single-node production chain, and that is why every stage toward the distributed network has a published gate. Running a sovereign chain has real costs, and they are treated as engineering requirements rather than footnotes. Mainnet is gated on published, price-independent economic-security thresholds — priors of at least 20% of supply bonded by external parties, at least 25 independent operators and a Nakamoto coefficient of at least 7 — and the independent simulation must evaluate whether the first years warrant rented security. If the public route is chosen at the Gate-1 go/no-go, the launch would be financed through the public-sale tranche under EU MiCA Title II. Where the design does not need sovereignty, it does not pretend to: agent recourse, specified and scheduled, would rest on the principal’s own USDC or EURC, locked in a contract the principal controls on the chain where the stablecoin lives, and only what needs the chain’s guarantees lives on the chain. Guarantees ## The envelope the whole system is held to Each of these eight is a normative, testable requirement in the specification corpus; together they set the privacy, custody, status and economic envelope. PII ### No PII on-chain No raw KYC data, personal information, credential payloads, serial numbers or presentation logs are ever written to the chain. The ledger holds commitments and roots, never identities or checks. KEYS ### User custody of keys The holder keeps custody of their own keys and proof secrets. No issuer, verifier or operator can present on a user’s behalf or recover their credentials. ROOTS ### Root-based status Validity is checked against a published status root, not per-user state on-chain. The chain commits to a root; holders prove inclusion or exclusion without revealing who they are. REVOKE ### Holder self-revocation A holder can revoke their own credential while revealing neither their identity nor the credential, and every service refuses it in under two minutes. Losing a device never means exposing who you are to revoke it. The proof’s dedicated audit is a scheduled milestone whose findings are published. 10 S ### 10-second perishable proofs A presentation is perishable, valid for ten seconds, and fully bound to its context. A captured proof cannot be replayed, forwarded or reused against a different verifier. CAP ### Hard-capped monetary policy The token designed for a possible public network has a hard cap of 108,000,000 and a declining issuance schedule. The protocol bounds supply, and no operator can raise it. STATE ### Bounded state growth Chain state scales with the number of issuers, verifiers and validators, never with the number of holders: a billion credentials cost the chain what a thousand do. AUDIT ### Security-first release A committed audit programme — two independent chain and protocol audits, a cryptography audit, an infrastructure penetration test and an independent economic review — scheduled as quality milestones and published with their findings, alongside a public adversarial testnet, a bug bounty and an incident-response exercise. On-chain ## What the chain stores MintID reuses the framework’s standard modules — accounts, staking, slashing, distribution, governance, upgrades — and adds a small set of identity-specific capabilities. Every record is small and institutional: no table holds a holder’s name, account, credential, KYC record, presentation or proof history. ISSUER ### Issuer registry and bonds Admission, authority state, signing and emergency keys, permitted grades and the bond — locked, frozen, slashed or released, with remediation held per adjudicated case. ROOTS ### Status roots The latest signed root per issuer, with freshness bounds enforced as consensus rules, and emergency updates under strict ordering and rate limits. VERIFIER ### Verifier registry KYC-approved relying parties: a commitment to their KYC attestation (never the attestation), request-signing keys, exact origins, periodic revalidation and suspension. REVOKE ### Self-revocation The set of spent nullifiers, the one-time values a self-revocation publishes, and the check of their proofs. Its dedicated audit is a scheduled milestone whose findings are published. COUNCIL ### Council and treasury policy Threshold-vote proposals with evidence commitments and policy versions; reserve-movement commitments, timelocks and co-signature state. PARAMS ### Parameters and fees Versioned schemas, verification keys, freshness policy and agent-layer parameters; fee routing and the supply ledger. The engineering boundary is a security boundary: Go owns everything consensus-visible, Rust owns the specialised cryptography, and Python owns simulation and testing, with no role in producing a block or holding a key. Integrations read chain state through proofs checked against a light-client header — never by trusting a single server. Implementation status ## Where the build stands What exists today, stated at the level of capabilities, so that nobody mistakes specification for delivery. IN PRODUCTION ### The chain The application chain with its issuer, bond, verifier, status, council, treasury, parameter and fee capabilities, and deterministic primitives pinned by cross-language test vectors. Since 24 September 2026, holders on the single-node production chain can revoke their own credential through a privacy relay, revealing neither who they are nor which credential it is. The chain gives the issuer a short grace to remove it, and every service refuses it in under two minutes. Self-revocation runs on the public testnet as it does in production, and is switched off at the distributed public network’s genesis, where switching it on is a governance decision. Its independent audit is a scheduled milestone whose findings are published. IN PRODUCTION ### The proof core The credential profile, issuance, selective-disclosure presentations and the non-revocation path are built and run in production, pinned by known-answer vectors that three languages check; the construction and the proof system are frozen. BUILT ### Verifier service The full acceptance pipeline, single-use challenges, authenticated chain reads and an audit trail behind a versioned service contract. BUILT ### Issuer services The encrypted status registry, 30-second root publication and relaying, a hardware-signing interface, credential issuance over the standard transport, and the provider-neutral KYC interface with a real identity-verification provider behind it. AVAILABLE ### SDKs A Python SDK, a transport-only TypeScript client and an MCP server over the verifier service; a holder library with Python, Go and TypeScript bindings; further languages are demand-gated. BUILT ### Agent products Bounded agents are minted today from a bundle catalogue the operator supplies. The consented commercial disclosure rail, contact-attribute identification included, is built and ships switched off and fail-closed; its activation waits for counsel. The funded-recourse layer is specified and scheduled. SINGLE NODE ### Deployments The single-node production chain, in production since 20 September 2026 and operated by the CONECTIA group, carrying the first issuer, the first verifier and ZadQ; plus the public testnet, with its KYC sandbox: the only deployment where a third party may test, on the same software and parameters, where nothing issued carries weight (its status is stated in the developer documentation). The distributed mainnet of Stage 2 has not launched: there is no token, no token price and no public validator set. The seven build phases and the five launch stages are set out on the [roadmap](/en/roadmap). ## Request the specifications The specification corpus is shared on request with prospective issuers, verifiers, validators, auditors and counsel. Tell us who you are and what you are evaluating. [Contact the team](/en/contact) --- Source: https://mintid.net/en/protocol · The protocol: specifications, guarantees and build status — MintID --- > A plain-language tour of the MintID Protocol Whitepaper v1.0: privacy-preserving, KYC-backed identity for people and AI agents, from an identity protocol in production on a single-node chain and designed to scale to a public proof-of-stake network. Invariants, credentials, agents, economics, governance and the launch plan. MintID · Protocol Whitepaper v1.0 · on-site tour # Verified once, proven anywhere, revealed nowhere. Privacy-preserving, KYC-backed identity for people and the AI agents they deploy: accepted issuers vouch for them, holders keep their keys and prove claims in zero knowledge, and not a single identity is written to a public ledger. * Version1.0 · 4 October 2026 * NatureTechnical, non-normative * SpecificationsAvailable on request * OfferNone — nothing is for sale This page is a plain-language tour of the Protocol Whitepaper v1.0 in its 4 October 2026 revision (v1.0, revised in place); v1.0 supersedes the August 2026 draft. It follows the paper chapter by chapter and, like the paper, stays above the level of wire formats and implementation detail; the specifications that define those details are available on request and govern wherever the two differ. Neither this page nor the paper is the MiCA crypto-asset white paper: nothing is for sale, no price exists, and every economic value below is a ratified band or an argued prior unless it is marked frozen. [Download the whitepaper (PDF)](/docs/MintID-Whitepaper.v1.0.pdf)[Executive Edition (PDF)](/docs/MintID-Whitepaper-executive.v1.0.pdf)[Read the protocol](/en/protocol) Contents 1. [01Abstract](#abstract) 2. [02The problem](#problem) 3. [03Principles and invariants](#invariants) 4. [04Roles and trust](#roles) 5. [05The life of a credential](#architecture) 6. [06The chain](#chain) 7. [07Credentials and presentations](#credentials) 8. [08The agent layer](#agents) 9. [09Standards decisions](#standards) 10. [10Security](#security) 11. [11Token economics](#tokenomics) 12. [12Governance and the Foundation](#governance) 13. [13Launch plan](#roadmap) 14. [14Where it stands](#status) 15. [15Open items and risks](#risk) 16. [16Glossary](#glossary) 01 ## Abstract Identity on the internet fails in two opposite directions. Where it works, it works by surveillance: every login, age check and payment leaks a durable identifier to someone who keeps it. Where it protects privacy, it usually gives up accountability: keys with no liable human behind them. Autonomous AI agents make both failures worse at once. MintID is an identity protocol whose only job is to be the public trust layer for a different arrangement. It is in production on the single-node production chain, operated by the CONECTIA group since 20 September 2026, and designed to scale to a public, permissionless proof-of-stake network. Accepted KYC issuers — regulated organisations admitted on chain by governance proposal (by the compliance council once it is seated), each posting a slashable bond, in the native token on a public network — verify a person once and issue an anonymous credential into that person’s own holder software. The holder then proves claims such as “grade ≥ A3”, “over 18” or “credential active” in zero-knowledge presentations that live for ten seconds and never touch the chain. The chain stores only what must be public for trust to be checkable: issuer and verifier registries, 30-second status roots, self-revocation nullifiers, staking, governance and evidence commitments. Nothing identifying is ever written on-chain, and live state grows with institutions, never with people. The same machinery extends to software. A verified person can have agent credentials minted that prove an accountable, KYC-verified principal stands behind the agent — within a scope and, from the financial-recourse stage, with recourse behind it — without revealing who, and without two agents of the same person being linkable. Identity leaves the system only by consent or by due process. 0 identities, credentials or presentations written on-chain 10 s lifetime of a fully bound zero-knowledge presentation 30 s status-root heartbeat per issuer, fail-closed when stale 108M the hard cap of the token designed for a possible public network; frozen, and no token exists today 02 ## The problem Identity today either leaks or cannot be held to account — and autonomous agents make both failures worse. Mainstream identity — federated login, per-service KYC, document-upload age checks — assumes that knowing who someone is is the price of trusting what they claim. The result is structural over-collection, which data-protection law now treats as a liability. The privacy-preserving alternatives solved the leakage but gave up the liable, verified party that regulators and counterparties need: a signature from an unaccountable key is not identity, it is a nickname. Both failures share one root cause: the proof of a claim and the identity of the claimant travel together. MintID separates them cryptographically — the claim is provable, the identity is not — while keeping a governed, bonded, checkable chain of accountability from every proof back to a regulated issuer. Why agents make it urgent Non-human identities already outnumber human ones by roughly 50 to 1 (Omdia, December 2024), and IDC projects more than a billion active agents by 2029. Today’s stack bolts agents onto service accounts and API keys — with no verifiable link to a liable party, an unbounded blast radius, no way to scope what an agent may do and no recourse when it does harm. The know-your-agent rails shipped by payment networks restore accountability by revealing the principal to the seller. MintID’s thesis is that accountability can be provable and funded while identity stays private by default. What a solution has to be * A public trust layer that no one owns: sovereign, permissionless, with deterministic finality. * Nothing identifying on that layer, and state that scales with institutions, not people. * User custody of keys and secrets, self-revocation, and recovery only by fresh KYC. * Accountable, bonded issuers, admitted by a compliance council. * Fresh, root-based status that fails closed when it goes stale. * KYC-approved verifiers, bound to exact web origins. * Perishable, fully bound presentations, checked online against finalised state. * A hard-capped, transparent monetary policy, and a security-first release. 03 ## Principles and invariants Six invariants hold across the whole specification, and each one is a refusal the chain enforces. 1. **The chain never learns who anyone is.** No KYC data, personal data, credential, credential serial, presentation or per-holder issuance event is ever written on-chain. 2. **State scales with institutions, not people.** Live state grows with issuers, verifier origins, validators, status roots and governance records — never with holders, credentials or presentations. 3. **Consensus is deterministic and self-contained.** No network call, wall clock, randomness, hardware signer, remote service or foreign-function bridge runs during block execution. 4. **Backing is provable, identity is not.** A holder or agent proves that an accepted issuer stands behind it at a given assurance, never which person; two agents of one person are unlinkable. 5. **Disclosure is rail-segregated and, on the commercial rail, consensual.** Identity leaves only by consent or by due process, and no payment is ever a lawful basis for disclosing personal data. 6. **The value layer is transparent and hard-capped.** Exactly 108,000,000 tokens, with no shielded or anonymity-enhanced transfers, ever. Privacy lives in the credential layer, not the money layer. Three engineering principles follow from them: reuse mature infrastructure and own only the identity-specific parts; treat the language boundary as a security boundary; and put bands before points, simulation before genesis, and every audit on a published schedule with published findings. 04 ## Roles and trust Every party can be named, bonded or pinned — and none of them needs to learn who the holder is. Role Mandate Hard boundary Holder Controls the credential secrets, proves predicates, self-revokes and asks for re-verification. Cannot delegate signing, publish credential identifiers or reuse a challenge. Accepted issuer Performs KYC, issues and reviews credentials, publishes 30-second status roots and can emergency-revoke its own registry. Never puts KYC data on-chain, alters another issuer’s credentials or sees presentations. KYC-approved verifier Requests minimal claims, checks current chain state and the proof, and enforces single use and expiry. No unapproved claims, no wildcard origins, no replays, no proof activity on-chain. Validator Validates consensus and deterministic protocol rules, and earns emission and fees. Never sees KYC documents or judges whether a real-world identity is genuine. Compliance council Once seated, admits, suspends and revokes issuers and verifiers, adjudicates bonds and co-signs protected treasury actions. Cannot move funds alone, approve a person’s identity or change software. Token governance On a public network, decides protocol upgrades and versioned parameters, on-chain. Does not run the operational compliance gates. Independent custodian Co-signs reserve movements and attests custody and policy compliance. Never acts alone or replaces the council. What sits where ### On-chain * Issuer and verifier registries, and issuer bonds * Signed issuer status roots, at least every 30 seconds * Self-revocation nullifiers * Staking, slashing, fees and emission * Governance records and evidence commitments ### Never on-chain * KYC documents and biometrics * Names, addresses and dates of birth * Credentials, serials and payloads * Presentations and per-holder issuance events * Anything that grows with the number of people Assurance grades Grade Default validity Meaning A1 12 months Basic identity binding and issuer verification. A2 12 months Stronger document and liveness verification. A3 6 months Enhanced due diligence and periodic evidence review. A4 3 months Highest assurance, with stricter issuer controls and audit requirements. A holder proves “grade ≥ the requested grade”. The verifier learns the issuer and the policy result — never the exact grade, the expiry, the credential or any attribute. Grades measure strength, anchored on eIDAS and squared with ISO/IEC 29115; 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. 05 ## The life of a credential One credential, from its issuer’s admission to its retirement, in six steps. 1. 01 ### Admission A KYC organisation applies through a governance proposal, today voted by the chain’s single validator and, once the compliance council is seated, by the council. The issuer registers its signing keys and a separately scoped emergency key, is granted a set of permitted grades and locks a bond. Only then can it become active. 2. 02 ### Issuance A person completes KYC, and the evidence stays encrypted in the issuer’s vault. Over OpenID4VCI the person receives an anonymous credential bound to a secret only they know. At the next 30-second heartbeat a new status root is finalised and the credential becomes usable. No transaction records that it was issued. 3. 03 ### Presentation A registered verifier sends a signed, single-use challenge that expires within ten seconds. The holder software checks the verifier against its own trust pins and answers with one zero-knowledge proof for every requested predicate. The verifier re-checks finalised state, consumes the challenge and keeps a minimal decision record. Nothing is written to the chain. 4. 04 ### Status and revocation Roots come every 30 seconds, with their time bounds enforced as consensus rules, and a verifier fails closed once a root is older than the maximum root age (45 seconds at the reference values; 180 seconds on the single-node production chain). Issuer-side revocation enters the next root (≤ 30 s) and is refused by every verifier within the maximum root age (under a minute at the reference values), or at once through the emergency key; a holder can self-revoke through a privacy relay, revealing neither who they are nor which credential it was, and is refused everywhere in under two minutes. 5. 05 ### Renewal and recovery Renewal is a new credential, from any accepted issuer, publicly unlinkable to the old one. Lost holder keys have exactly one recovery path: fresh KYC and a brand-new credential. No social recovery, no custodial back door. 6. 06 ### Agents A verified person proves in zero knowledge that they hold a sufficient, unrevoked credential; the issuer mints a fresh, unlinkable agent credential carrying a backing assertion and a delegated scope. The chain sees nothing new. 06 ## The chain A purpose-built application chain whose state is registries, commitments and economics — never people. **Why a sovereign chain.** The privacy invariants are chain-wide properties that a shared virtual machine cannot promise for its other tenants; the registries, council, bonds and status policy need native capabilities with their own economics; and an identity trust anchor should not rent its security from a market that prices someone else’s asset. The Cosmos SDK gives exactly this shape over a proven BFT engine, so MintID writes nothing of consensus, networking, staking or light clients. **Consensus.** CometBFT. Today the single-node production chain runs it with one validator; the design for a public network is delegated proof of stake. The genesis candidates are a capped active set of 60 validators, growing toward 100 by governance once fee-funded security supports it; blocks every two to three seconds, with a finality objective of about five seconds; a 5% cap on any validator’s voting power; and a 21-day unbonding period. Rewards follow capped voting power and signing performance — never “identity work” — and slashing applies to objective evidence only. **Status roots.** Each issuer publishes a small signed commitment to its private status registry at least every 30 seconds. Relayers may batch many issuers’ roots and pay the fees, but they gain no authority. Freshness is a consensus rule: the chain rejects roots that are expired, stale, dated in the future or valid for too long, so not even a compromised key can publish a root that reads as fresh forever. A billion credentials cost the chain what a thousand do: one root per issuer. The economic-security launch gate A young proof-of-stake chain is cheapest to attack at genesis, and a takeover here would compromise status roots and registries, not just balances. Genesis therefore waits for published, price-independent thresholds — priors of at least 20% of supply bonded by external parties, at least 25 independent operators and a Nakamoto coefficient of at least 7 — with development and foundation accounts excluded. Bootstrap validators work under service agreements for the first 12 to 24 months, continuing as a foundation-funded operator floor program that pays for service, never for stake. Whether the first years warrant rented security is a mandatory question for the simulation. 07 ## Credentials and presentations One credential, many unlinkable proofs, and a way for the holder to revoke it without being identified. MintID’s credential is an anonymous credential in the Hyperledger AnonCreds lineage: blinded issuer signatures, a holder secret that is never revealed, selective disclosure, predicate proofs, and non-revocation proofs without a correlatable identifier. The exact construction and proof system are frozen. Transport is OpenID4VCI for issuance and OpenID4VP for presentation. A verifier accepts a presentation only when all of the following hold. The check exists in exactly one implementation, and no client library can weaken it: * the verifier and its exact origin are active on-chain, and the request was signed with a key registered for that origin; * the challenge is fresh, has never been used, and was answered within ten seconds; * the presentation is bound to that verifier, origin, request key, challenge, policy and chain state; * every requested predicate is proven; * the issuer is active and its status root current, re-checked immediately before the decision; * the challenge is consumed, so the same proof can never be accepted twice. Verifiers complete KYC themselves, register exact origins — never wildcards — and prove control of their domains. On the holder’s side, the holder software keeps its own list of trusted verifiers; any change of key or origin needs fresh consent, and none of those approvals ever reaches the chain. Holder self-revocation The holder derives a one-time nullifier from a private secret and proves, in zero knowledge, that it belongs to a valid credential — without revealing which. The chain records the nullifier, and later presentations of that credential can no longer prove it unrevoked. It is the only proof verified inside block execution, so it gets its own dedicated audit, a scheduled milestone whose findings are published. Recovery, by contrast, is never social: lost holder keys mean fresh KYC and a new, unlinkable credential. 08 ## The agent layer The same machinery, applied to the software people deploy — with no new consensus module and no new proof type in block execution. What an agent proves “I am operated by a KYC-verified, liable principal at grade ≥ G, within scope S, with at least F of self-custodied recourse behind me” — without revealing who that principal is, and without two agents of the same person being linkable. The recourse clause is specified and scheduled for the financial-recourse stage. **Minting, not registration.** A principal proves in zero knowledge that it holds an unrevoked credential at a sufficient grade; the issuer mints a fresh agent credential with its own secrets, a backing assertion and a delegated scope, and records the only link between agent and human in its private accountability escrow. There is no per-agent chain record and no public agent registry. Sybil resistance has a price: a KYC gate, a per-principal cap on active agents, KYC freshness, and a mint fee with a recurring lease. **Scope and revocation.** Scope says what the agent may do, with whom, in which categories and places, when and up to what value; it is signed at mint, so an agent cannot elevate itself. Bounded agents are minted today from a bundle catalogue the operator supplies. Revocation works per agent, through the issuer within one root or at once, and across a principal’s fleet under issuer policy. A push channel may notify verifiers sooner, but carries no security weight: the root is the truth. **Funded accountability.** An agent would prove that at least a given amount of regulated stablecoin stands behind it. The capital is the principal’s own USDC or EURC, locked in a contract the principal controls on the chain where the stablecoin lives (Base in the current deployment variant). MintID runs no general smart-contract VM: it keeps the reservation state and checks a proof of the lock. Specified, scheduled; not built. The agent cannot move the money, and the lock has exactly three exits: a re-merge by the same agent, a payout to a claimant on a dispute verdict, or a return to the principal. Higher funding bands require the lock contract, whose audit is a scheduled milestone whose findings are published, and arrive after the identity-only launch. Consent on one rail, due process on the other ### The commercial rail A relying party may offer a priced bid for one graduated item — a pairwise pseudonym, a single contact attribute or full KYC. The principal’s consent policy decides, refusal is the default, and the bid is paid to the principal. Full KYC is never delegable. Paying to identify one agent once confers no right to recognise or track the person later: identification, not surveillance. The consented commercial disclosure rail, contact-attribute identification and contact-attribute identification included, is built and ships switched off and fail-closed; its activation waits for counsel. ### The dispute rail The subject cannot veto it, and it settles with money before identity: first the escrow pays the claimant; then a minimal, banded fraud signal is shared; and only if both parties reject a bonded arbiter’s determination and the arbiter certifies that a court is warranted is the person identified. The arbiter decides, the issuer releases, and the council reviews after the fact. The dispute rail is specified and scheduled for the financial-recourse stage; audits have not started, and no funds are locked today. Deliberately out of scope: self-derived minting and multi-hop delegation, any per-agent on-chain record, a shared liability pool, and any mechanism by which a bid buys identity. 09 ## Standards decisions The choices architects and integrators ask about most — each with the alternative it was chosen over. Decision Instead of Why A sovereign Cosmos SDK application chain on CometBFT Contracts on a general-purpose chain; a rollup Chain-wide privacy invariants and native registries with their own economics; nothing of consensus is rewritten. Go, Rust and Python as a security boundary One language everywhere Go owns consensus-visible state, Rust the specialised cryptography, Python simulation and testing — never keys or blocks. Standard, deterministic primitives and proven state reads Novel primitives; a trusted server Widely audited signatures and hash trees in the consensus path; integrators verify finalised state themselves. Anonymous credentials in the AnonCreds lineage SD-JWT VC or ISO mdoc; DIDs Unlinkability across verifiers, predicate proofs and non-revocation without a correlatable identifier. HAIP serves as security guidance only; SD-JWT and mdoc interoperability is not claimed. OpenID4VCI and OpenID4VP as transports Bespoke transports The same protocols as the European Digital Identity Wallet, plus chain-native verifier registration and exact-origin binding. A1–A4 anchored on eIDAS, squared with ISO/IEC 29115, with freshness as a separate band A bespoke vocabulary, or one framework adopted wholesale Regulators and the EUDI Wallet speak eIDAS first; ISO gives the four-level backbone; no framework attaches a validity period to a level. An x402 and Web Bot Auth transport profile A parallel payments rail The facilitator is the registered verifier; a ladder from payment only, to identified software, to identified software with an accountable human. One verification pipeline, thin clients Per-language reimplementation Acceptance logic lives in one place with one conformance suite; the ten-second lifetime cannot be weakened. MiCA Title II as the only offer path; no anonymity-enhanced value layer Pre-sales, SAFTs, shielded transfers An identity network for regulated issuers cannot afford a contestable token; privacy lives in the credential layer. The assurance vocabulary Grade eIDAS ISO/IEC 29115 NIST SP 800-63 AML posture A1 low LoA2 IAL1 Customer due diligence A2 substantial LoA3 IAL2 Due diligence with biometric liveness A3 substantial + EDD LoA3⁺ IAL2 + EDD Screening: sanctions, PEP, adverse media A4 high LoA4 IAL3 Qualified identity proofing The external columns are mappings, not redefinitions. Freshness is a second dimension: F4 under 30 days, F3 under 90, F2 under 180 and F1 under 365, published as a band and never as a date. For ZadQ, “human-backed” means 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. The decision was accepted in August 2026; the issuer-side KYC policy that applies it awaits counsel sign-off, and the first issuer already operates with a real identity-verification provider behind the provider-neutral interface, where the evidence stays with the provider and never enters MintID. 10 ## Security Issuers, verifiers, validators, relayers, the council and a compromised holder device are all assumed potentially malicious — and the chain must stay identity-free and deterministic under every one of them. Threat Primary controls KYC data breach through the chain Nothing identifying on-chain by construction; the issuer’s private vault Issuer fraud Admission by governance proposal (by the compliance council once it is seated); a slashable bond that gates activation; suspension and slashing with a public reason code Issuer key compromise A separately scoped emergency key; self-service and forced rotation; an immediate root update Validator collusion A capped active set; objective slashing; the economic-security launch gate Verifier impersonation A KYC-approved registry; exact origins, no wildcards; holder-side trust pins Presentation replay A single-use challenge; ten-second expiry; full binding; a durable replay guard Credential correlation Anonymous credentials; a fresh proof per session; per-verifier pseudonyms for agents Stale revocation status 30-second roots; consensus-enforced freshness; fail closed at the maximum root age (45 seconds at the reference values; 180 seconds on the single-node production chain) Proof-system bug A formal specification; test vectors; independent audits as scheduled milestones with published findings; a bug bounty Council capture A threshold quorum; independently selected members; one-for-one seat rotation; custodian co-control; no power over software Sybil agent armies A human KYC gate; a per-principal cap; mint fee and lease fee; KYC freshness Coercion into disclosure No bid is ever a lawful basis; full KYC is never delegable; refusal is free and leaves no trace Release discipline Two independent chain and protocol audits, a specialist cryptography audit, an infrastructure penetration test and an independent token and economic review are committed quality milestones, scheduled and published with their findings, alongside a public adversarial testnet with independent validators, issuers and verifiers, a funded bug bounty and an incident-response exercise. Any new cryptography in a consensus path gets its own dedicated audit. If the economic review objects to a value frozen before genesis, genesis does not proceed on that value. 11 ## Token economics The token a public network would use: a hard cap, a declining emission, and no price anywhere. The status of every figure The maximum supply is frozen. Everything else is either a ratified band — binding, with values movable only inside it and only by governance — or a ratified prior: an argued working point that the independent pre-genesis simulation validates or argues against. No price appears here; an offer price, if an offer is ever made, will exist only in the MiCA white paper. On a public network, the native token would be the economic-security asset: validator bonding and delegation, issuer bonds, fees, registry leases and governance. It is not a stablecoin, not backed, not price-supported, not dividend-bearing and not a claim on anyone’s revenue. The allocation of protocol fees and cuts is a set of governed parameters; its final form is under review. Its job would be to pay for network security. Genesis allocation (priors) 15%25%60% * Development and team — 15% (16.2M), band 15% * Public-sale tranche — 25% (27M), band 20–25% * Reward pool — 60% (64.8M), band ≥ 60% The reward pool is paid out only as validator emission, on a curve that must exhaust it exactly. The prior is 3% of the cap in year one (3.24M tokens), declining by a factor of 0.95 per year — about 40% of the pool in ten years and 79% within thirty. The cap is counted against the total ever minted, not the circulating supply, and no mint beyond it is ever possible. Which flows carry a protocol cut, and which never touch consensus Flow What it is Touches the token? A — Agent mint and lease A per-agent mint fee and recurring lease on a governed schedule, with a normative protocol cut Yes — the one protocol revenue line that grows with the agent population B — Issuer registry Admission, renewal and registry lease; the slashable issuer bond Yes — protocol fees; slashes fund remediation for the parties harmed C — Consensual disclosure The disclosure-bid rail, with a protocol cut: a percentage plus a fixed floor Yes — with no per-holder or per-presentation state D — Dispute and arbiter market Claim and dispute bonds; arbiter fees paid by the losing party No — it must never influence consensus rewards E — Premium verification services Mirrors, archives and managed verification services No — basic verification is free by design Protocol cuts on flows A and C Parameter Ratified band Prior Protocol cut on agent mint and lease A governed parameter under review — Allocation of each A/C cut Governed parameters; final form under review — The foundation share is earmarked — first for the operator floor program — and never distributed to token holders. After emission ends, the security budget is the fee market; if the simulation finds it insufficient, a succession ladder applies in order — the cut points, then a protocol-state rent, then shared security — and a post-cap mint is excluded by construction. No usage tax exists or is planned. Genesis and offer discipline One genesis event and no discretionary mint after it, with a published Genesis Allocation Statement whose hash is committed in the genesis file. Development tokens vest over four years with a one-year cliff and a twelve-month lock-up, and development and foundation accounts may not delegate or vote while those apply. An offer, if made, uses a single fixed price and a raise floor of $4.0 M net of statutory withdrawals: below it, the project re-stages instead of under-funding. Every other offer term will appear only in the MiCA white paper. Issuer bonds are sized against a published deterrence target, and a small BTC reserve would exist only for proven issuer-fraud remediation and critical incidents, under council and independent-custodian control — never as token backing. 12 ## Governance and the Foundation On a public network, token holders would govern the software and a threshold council the compliance gates; the Dutch foundation that would anchor both is being incorporated and stays dormant until the public-offer route is chosen. From genesis on a public network, token-weighted, on-chain governance owns the software: upgrades, consensus parameters and every versioned protocol parameter. Once seated, the compliance council — a threshold vote, recommended 5-of-9 — owns the operational gates: admitting, suspending and revoking issuers and verifiers, adjudicating bonds and co-signing protected treasury actions, with an independent custodian’s signature on any reserve movement. Every council action commits a reason code, an evidence commitment and a policy version, and the council never changes software. The MintID Foundation, a Netherlands Stichting, is being incorporated by the founder and stays dormant until the public-offer route is chosen: it holds no treasury, enters no contracts, seats no sponsors and receives no services. The single-node production chain is operated by the CONECTIA group as a disclosed related party. The code is published under an Apache-2.0 licence; the financing route is decided at the Gate-1 go/no-go. On the public-offer route, the Foundation performs the genesis, holds the treasury and lock-up commitments, publishes the Genesis Allocation Statement and, as offeror, makes the Dutch AFM the competent authority under MiCA. The founder incorporates it and is its sole director for the pre-offer phase only: before any white paper is signed, independent members join the board, statutory locks take effect, and the council is constituted as an organ of the Stichting. The Foundation has no protocol revenue role and no debt relationship with the implementing group in either direction; a public transparency report covers issuer and verifier states, council actions, slashes, reserve activity, vesting and related-party flows — never holder data. Related parties, disclosed Role Held by Flows to disclose Founder Marc Molas Founder of MintID; beneficial owner of the CONECTIA group; founder-director of the Stichting at incorporation. Recused from every Foundation decision that concerns the group; the founder-separation commitments apply before any white paper is signed Development company Conectia PRO (Spanish SL, 100 % Conectia OÜ) Development allocation; operating budget from proceeds. Pre-genesis work is the group’s own R&D at its own cost: no advance, no reimbursement, no debt in either direction First accepted issuer and first registered verifier CONECTIA group Mint and lease fees, disclosure brokerage — on the same bond and admission terms as any issuer Reference SDK / premium-services operator CONECTIA group Direct service revenue, firewalled from consensus rewards Anchor-product operator (ZadQ) CONECTIA group x402 seller-verification service revenue (fiat); base verification stays free Operator of the single-node production chain CONECTIA group Operates the chain’s infrastructure; no on-chain money flow beyond nominal fees and the issuer bond; operated under a disclosed related-party arrangement; activity reported as a pilot and excluded from the traction criterion Pre-genesis R&D funder CONECTIA group An internal pre-genesis budget of €400,000 spent by CONECTIA on MintID as its own R&D; disclosed in amount; no services on credit to the Foundation, no reimbursement, no claim on proceeds Foundation (being incorporated; dormant) MintID Foundation (Stichting) Being incorporated by the founder; dormant until the public-offer route is chosen; on that route, treasury custody, grants, sponsorship dues and the foundation share; no protocol revenue role; no debt with the group MintID is conceived and built by the CONECTIA group — Conectia OÜ in Estonia and Conectia PRO, its wholly owned Spanish operating company — and every role the group holds is disclosed as a related-party position. The first issuer and the first verifier were admitted through the same path the protocol offers anyone: a governance proposal, today voted by the chain’s single validator and, once the compliance council is seated, by the council; the same slashable bond; the same 30-second roots; all of it on chain. The independence that is claimed is methodological: every figure sourced, every model re-runnable. The independent economic review remains the only arm’s-length opinion. 13 ## Launch plan Each stage opens only when its published gate is met. If a minimum is not reached, the plan re-stages — it never launches under-funded or under-secured, and every audit is scheduled and published with its findings. 1. stage 0 ### Single-node production · now → Gate 1 The single-node production chain, in production since 20 September 2026 and operated by the CONECTIA group, with the first issuer, the first verifier and the ZadQ pilot on it, while the distributed network is built; the public testnet with its KYC sandbox, frozen specifications, the proof core in production, code open source under Apache-2.0; the Foundation being incorporated and dormant; the financing route decided at the Gate-1 go/no-go; funded by the CONECTIA group as its own R&D, never reimbursed. Gate: the Gate-1 go/no-go on the financing route — on the public route, simulation delivered, counsel workstreams, trademark filed, and the Foundation’s board and statutory locks in place. 2. stage 1 ### Public offer, on the public route only · 2027 If the Gate-1 go/no-go chooses the public route: the MiCA Title II white paper, notification to the AFM, the offer of the sale tranche and admission to trading. Gate: white paper cleared by counsel and notified; board and safeguards in effect before signature; bank and custodian onboarded; the $4.0 M net raise floor met — otherwise re-stage. 3. stage 2 ### Identity-only mainnet · target H2 2027 → 2028 Issuance, zero-knowledge presentations, status roots, free verification, the verifier registry, a live council and a genesis set of 60 validators — no escrow or disputes yet — with ZadQ, today on the classical seller rail, on mainnet. Gate: the economic-security thresholds met, genesis values frozen and the Genesis Allocation Statement published; the audit programme reported as scheduled milestones with published findings. 4. stage 3 ### Financial recourse · 2028 → 2029 Self-custodied stablecoin escrow, the dispute cascade and the arbiter market; the consented commercial disclosure rail is already built and ships switched off and fail-closed, and its activation waits for counsel. Gate: a published organic-demand criterion and counsel-reviewed unmasking governance; the circuit and escrow-contract audits are scheduled milestones with published findings. 5. stage 4 ### Maturity · 2030 → 2031 Multiple issuers, a growing agent population, the active set grown toward 100 by governance, and the post-emission transition planned. Gate: continuous — transparency reporting, annual audits published with their findings, and monitored gate metrics. Condition-triggered genesis Genesis has a target — the second half of 2027, ahead of 24 December 2027, when EU relying parties must start accepting the European Digital Identity Wallet — and a trigger in three parts: a published traction criterion (attested x402 sellers who stay, and active independent registered verifiers, sustained for two quarters, with the promoter group excluded and the single-node pilot never counted); on the public-offer route, a raise above the $4.0 M net floor; and the simulation and counsel work delivered. Until all three hold, the single-node operating mode continues. Product marketing is unrestricted; token marketing is prohibited until a white paper is published. The two-sided cold start is met by a first implementer and an anchor product, both disclosed as related-party positions. The CONECTIA group operates the first issuer and the first verifier on undifferentiated terms. ZadQ, an x402 seller-verification service and the first product built on MintID, lets a seller prove that an accountable, KYC-verified party stands behind its payment address, without revealing who. Its first version runs on the classical seller rail, with conventional issuer-signed attestations; the zero-knowledge seller rail follows. It runs on the single-node production chain, operated by the CONECTIA group — the same MintID software, operated, never forked — changing one thing at a time: first the proof form, then the topology. [Read about the ZadQ pilot](/en/x402-pilot). 14 ## Where it stands What exists in October 2026, stated at the level of capabilities, so that nobody mistakes specification for delivery. Component Status What it means Chain Implemented Issuer, bond, verifier, status, council, treasury, parameter and fee capabilities; deterministic primitives pinned by cross-language test vectors. Holder self-revocation has been in production on the single-node production chain since 24 September 2026; its independent audit is a scheduled milestone whose findings are published. Proof core In production Credential profile, issuance, selective-disclosure presentations and the non-revocation path, built and running in production, pinned by known-answer vectors that three languages check; construction and proof system frozen. Verifier service Implemented The full acceptance pipeline, single-use challenges, authenticated chain reads and an audit trail behind a versioned service contract. Issuer services Implemented Encrypted status registry, 30-second roots, a hardware-signing interface, credential issuance over the standard transport, and provider-neutral KYC with a real identity-verification provider behind it. SDKs Available A Python SDK, a transport-only TypeScript client and an MCP server over the verifier service; a holder library with Python, Go and TypeScript bindings; further languages are demand-gated. Agent products In production / built, switched off Bounded agents are minted today from a bundle catalogue the operator supplies. The consented commercial disclosure rail, contact-attribute identification included, is built and ships switched off and fail-closed; its activation waits for counsel. The funded-recourse layer is specified and scheduled. Test harness Implemented Issuer, holder and verifier simulators, with end-to-end and adversarial tests. Deployments Single-node production The single-node production chain, in production since 20 September 2026 and operated by the CONECTIA group, carrying the first issuer, the first verifier and ZadQ; plus the public testnet, with its KYC sandbox: the only deployment where a third party may test, on the same software and parameters, where nothing issued carries weight (its status is stated in the developer documentation). The distributed mainnet of Stage 2 has not launched: there is no token, no token price and no public validator set. Specifications Frozen Frozen; its September 2026 amendment added the agent products. Available on request. Manuals Published Issuer, Verifier & SDK, Holder and Validator manuals, on the docs page. 15 ## Open items and risks What still has to be fixed, what is deliberately left open, and what could go wrong. Before genesis ### Still to be fixed The allocation and emission points inside their bands; the protocol cuts and their allocation, governed parameters under review; the economic-security thresholds in measurable units; the issuer bond and slashing ranges; council selection and quorum; the validator cap, self-bond and unbonding; the proof system and the exact credential construction; freshness limits after benchmarks; jurisdictions and the KYC policy; and the agent-economy parameters, including the escrow disclosure policy. With counsel ### Deliberately open Custodial or facilitated payment addresses on the seller rail; the KYC-provider arrangements; offer sequencing, subscription currencies and unsold tokens; the characterisation of the arbiter step; the lawful basis for delegated consent; and AI Act conformity of disclosure receipts. Risks, stated plainly * **Competitive timing.** Payment networks already ship transparent know-your-agent rails. MintID’s niche — privacy-preserving, funded, regulated-grade backing — is validated but narrow, and the answer is sequencing. * **Cold start.** Two-sided, and met by the first implementer and ZadQ, both related parties, with success criteria set in advance and measured; nothing they generate counts as independent adoption or toward the traction criterion. * **Cryptographic delivery.** The proof core is built and in production; the self-revocation proof, the highest-risk consensus-path item, has been in production on the single-node production chain since 24 September 2026, runs on the public testnet as it does in production, and is switched off at the distributed public network’s genesis, where switching it on is a governance decision; its audit is a scheduled milestone whose findings are published. * **Regulatory.** MiCA execution, the Foundation’s statutes, GDPR and consent texts, AI Act conformity and unmasking governance are subject to counsel; the design took the strictest reading at each point. * **Economic.** The points inside the bands are not yet fixed; adverse scenarios are shown, not averaged away; and re-staging is the committed answer to a weak offer. * **Related-party concentration.** Development, the first issuer, the reference SDK, ZadQ and the pre-genesis R&D budget sit in one group. Each position is disclosed in the table above, and the group’s issuer runs on the same on-chain terms as any other. * **Delegated trust and fail-closed operation.** A relying party trusts issuers it does not choose, and a silent issuer takes its credentials offline within the maximum root age (45 seconds at the reference values; 180 seconds on the single-node production chain). Both are the price of the guarantee. 16 ## Glossary Accepted issuer A bonded KYC organisation, admitted on chain by governance proposal (by the compliance council once it is seated), whose credentials the protocol accepts. Accountability escrow The issuer’s private record linking an agent to its human, disclosed only by due process — distinct from the financial escrow. Agent credential A credential the issuer derives from a principal’s credential, carrying a backing assertion and a delegated scope. Anchor product ZadQ, the x402 seller-verification service that is the first product built on MintID; a disclosed related-party position. Anonymous credential A credential with a blinded issuer signature, a holder secret, selective disclosure and predicate proofs. Assurance grade The private A1–A4 grade an issuer assigns, proven only as a threshold. Band, prior, point A ratified range; an argued working point inside it; and the final value the simulation fixes. Commercial and dispute rails The two firewalled disclosure paths: one gated by consent, the other by due process. Compliance council The threshold-vote operational body designed for admissions, bonds and treasury co-signing; built on chain, not yet seated. Freshness band The issuer-held band (F1–F4) saying how recently a holder’s evidence was verified; a second dimension next to the grade, published as a band and never as a date; read on the classical seller rail, not a presentation predicate. Nullifier The one-time value a self-revocation publishes, revealing neither the holder nor the credential. Operator floor program Foundation-funded service agreements that pay validators for verifiable service, never for stake. Pairwise pseudonym An agent’s per-verifier identifier: stable for that verifier, unlinkable across verifiers. Presentation A ten-second, fully bound zero-knowledge proof of requested predicates. Never on-chain. Status root An issuer’s signed 30-second commitment to its private status registry. Stichting The Dutch foundation form of the MintID Foundation — being incorporated by the founder and dormant until the public-offer route is chosen. Next ## Read the full document This page follows the Protocol Whitepaper v1.0. Download the full paper (42 pages) or its Executive Edition (12 pages) as PDF; the specification corpus behind them is shared on request. [Download the whitepaper (PDF)](/docs/MintID-Whitepaper.v1.0.pdf)[Executive Edition (PDF)](/docs/MintID-Whitepaper-executive.v1.0.pdf)[Request the specifications](/en/contact) Protocol Whitepaper v1.0, 4 October 2026 · prepared by MintID, developed and operated by the CONECTIA group; the MintID Foundation, a Netherlands Stichting, is being incorporated and stays dormant until the public-offer route is chosen · related parties disclosed above · non-normative; the specifications govern · not a MiCA crypto-asset white paper and not an offer, solicitation or marketing of a crypto-asset · not legal, tax or investment advice. --- Source: https://mintid.net/en/whitepaper · Whitepaper — MintID --- > Public trust infrastructure for identity: accepted issuers vouch for people; the chain stores no documents and logs no checks. Private by construction. Mission # Infrastructure that can prove who vouched, never who was vouched for MintID exists so accepted KYC organisations can vouch for people without anyone building a database of identity documents. The chain publishes the trust signals — accepted issuers, accepted verifiers, status roots, revocations and audit commitments — and nothing else. It must never become a log of who checked whom. the blueprint private by construction48 u29 u · sealed Invariants ## The principles we will not trade away These invariants hold across every design decision, and the protocol is built so that none of them can quietly erode. ∅ ### No raw KYC on-chain The ledger holds accepted-issuer and accepted-verifier records, status-root and revocation commitments, staking, governance actions and immutable audit commitments — never identity documents or the details of a check. KEY ### Users keep custody People hold their own keys and proof secrets. No issuer, verifier or operator can present on their behalf or recover their credentials. O(1) ### Bounded state growth Chain state scales with issuers, verifiers and validators — not with the number of holders. The system stays small however many people rely on it. FAIR ### Privacy and accountability A deliberate balance: holders prove claims without exposing themselves, while immutable audit commitments keep issuers and verifiers accountable. AUDIT ### Security-first Independent application, cryptography, infrastructure and economic audits are committed, scheduled quality milestones, each published with its findings — while the single-node production chain already runs, carrying the first issuer and the first verifier. CHAIN ### Own rules, proven infrastructure The design gives a public network its own validators, consensus rules, governance and token from launch, and reuses mature infrastructure instead of reimplementing networking and consensus. Sovereignty ## The new code is the identity protocol; consensus comes from Cosmos SDK and CometBFT MintID runs its own chain: it is an identity protocol in production on the single-node production chain, designed to scale to a public, permissionless proof-of-stake network. Today that means its own consensus rules and chain state; a public network would add its own validator set, reward schedule, governance and native token. MintID reuses Cosmos SDK and CometBFT rather than rewriting networking and Byzantine-fault-tolerant consensus, so the code it writes is the identity protocol. Token: design onlyValidator set: one validator todayOwn consensus rulesReward schedule: design onlyOwn governanceCosmos SDKCometBFT Governance ## A council, and an independent custodian Two bodies share what is loosely called governance, and they are deliberately not the same. On a public network, token-weighted, on-chain governance would own the software: upgrades and versioned parameters. The compliance council is designed as an operational body — a threshold vote, recommended 5-of-9 — that admits, suspends and revokes issuers and verifiers, adjudicates bonds, forces a key rotation when an operator key is lost, and co-signs protected treasury actions, with an independent custodian’s signature on any reserve movement. It never changes the software, and on a due-process identity reveal it reviews only after the fact. The council is constituted as an organ of the MintID Foundation before any white paper is signed, and until then it is not seated: admissions are governance proposals, today voted by the chain’s single validator. Why trust MintID ## Built like it has something to prove Each card below points to something you can check yourself: a published report, a numbered requirement or a written commitment. ### Audit-first, by rule Two independent chain and protocol audits, a specialist cryptography audit, an infrastructure penetration test and an independent token and economic review are committed quality milestones, scheduled and published with their findings — alongside a public adversarial testnet, a funded bug bounty and an incident-response exercise. The commitment is written into the specifications. ### Reviewed before genesis — published in full In July 2026 the project had its own design reviewed for economic viability: the token model, the economics of each participant, survivability. The review was performed by Conectia PRO, part of the group that builds MintID and therefore a related party, as the report’s cover discloses. It is published in full, together with what changed in response. It is not the independent economic review — that review, and the independent simulation, are still ahead. [Read what the review found](/en/blog/we-audited-ourselves) ### Risks stated plainly The whitepaper names what could go wrong — competitive timing, the two-sided cold start, cryptographic delivery, regulation, economics, related-party concentration and fail-closed operation — and what the design does about each. ### Privacy written as numbered, testable requirements “No personal data on chain”, “no tracking across renewals” and “state never grows with people” are numbered, testable requirements that auditors check. ### Six refusals, written into the specification No identity data on-chain, no shielded transfers, no dividends, no price support, no minting beyond the cap, no social recovery. Every refusal removes an attack surface or a conflict of interest — and each one is written into the specification. ### 108,000,000 is the only frozen number The cap is fixed and published: 108,000,000 tokens. The genesis allocation is ratified as bands — development 15%, public sale 20–25%, reward pool at least 60% — with priors of 15, 25 and 60%, which the independent simulation validates or argues against before genesis. Every genesis address will be published and labelled; development tokens would vest on-chain over four years and stay locked for a year after genesis, and insider accounts could neither delegate nor vote while that applies. ### GDPR and MiCA shaped the design from the first draft GDPR lawful bases are mapped per disclosure rail; the MiCA posture was fixed before any token exists; AI Act conformity is on the counsel list. Built in Europe, for regulated issuers, on purpose. State of the project ## One validator has been producing blocks since 20 September 2026 Today MintID runs on the single-node production chain, in production since 20 September 2026 and operated by the CONECTIA group as a disclosed related party, carrying the first issuer, the first verifier and the ZadQ pilot while the distributed network is built. Accepted issuers verify people and issue the credentials; the chain publishes their status, their bonds and the registries; MintID itself issues nothing and certifies nothing. On the single-node production chain, the first accepted issuer is operated by the CONECTIA group, a related party, on the same terms as any other. The code is open source under Apache-2.0. The MintID Foundation, a Netherlands Stichting, is being incorporated by the founder and stays dormant until the public-offer route is chosen. The public network and any token come later, if traction is demonstrated and that financing route is chosen. In production · single nodeOpen source · Apache-2.0Foundation being incorporated · dormantNo token · nothing for sale Who builds this ## The CONECTIA group runs the first issuer on the same terms as anyone A protocol without a production implementer at launch is a specification. The CONECTIA group chose to be that implementer, under a structure that keeps neutrality intact. BUILD ### First implementer The CONECTIA group, which conceives and builds MintID, operates MintID’s first accepted issuer — behind the same provider-neutral KYC interface every issuer uses — and its first registered verifier: today in production on the single-node production chain, and from block 1 on the distributed network. The group is a related party, and every role it holds is disclosed as such. EQUAL ### No privileges The first issuer and the first verifier were admitted through the same path the protocol offers anyone: a governance proposal, today voted by the chain’s single validator and, once the compliance council is seated, by the council; the same slashable bond; the same 30-second roots; all of it on chain. That is what turns the position into an argument instead of a risk. OPEN ### Open references The first implementer operates the first issuer service and the first verifier service and publishes the holder library under a permissive licence. MintID ships no wallet. The cryptographic core is the same, whoever runs it. ZADQ ### The anchor product ZadQ, an x402 seller-verification service, is the first product built on MintID and the group’s own product line, a disclosed related party. It runs as a pilot on the single-node production chain, on the classical seller rail, not yet on the distributed network, and nothing measured there counts as independent adoption or toward the distributed network’s launch criteria. [Read about ZadQ](/en/x402-pilot) FOUNDATION ### A dormant foundation, separate from the operator The MintID Foundation, a Netherlands Stichting, is being incorporated by the founder and stays dormant until the public-offer route is chosen: it holds no treasury, enters no contracts, seats no sponsors and receives no services. The single-node production chain is operated by the CONECTIA group as a disclosed related party. The code is published under an Apache-2.0 licence. On the public-offer route, the Foundation performs the genesis, holds the treasury and the lock-up commitments, publishes the Genesis Allocation Statement and, as offeror, fixes the notification authority under MiCA: the Dutch AFM. The Foundation has no protocol revenue role and no debt relationship with the implementing group in either direction. FOUNDER ### The founder, disclosed Marc Molas, founder of MintID and beneficial owner of the CONECTIA group, is founder-director of the Stichting at incorporation and recused from every Foundation decision that concerns the group. The founder holds a disclosed economic interest in the development contractor, holds no office in it once the Foundation is active, and takes no part in any Foundation decision concerning it. A neutral, multi-issuer rail is only credible if its first operator holds no special position on it. Every role the group holds, and the flows to disclose for each, are listed in the [related-parties table of the whitepaper](/en/whitepaper#governance). ## See how the protocol enforces this The three specifications turn these invariants into normative, testable requirements. Read the protocol, or get in touch to request the specifications. [Read the protocol](/en/protocol)[Contact the team](/en/contact) --- Source: https://mintid.net/en/about · About MintID — public trust infrastructure for identity --- > Answers about MintID: zero-knowledge presentations, reusable KYC credentials, what the chain stores, key recovery, agent KYC (Know Your Agent), the token, the ZadQ pilot on the classical seller rail, and where the project stands. Questions # Frequently asked questions How MintID keeps identity off the chain while letting holders prove claims in zero knowledge — from issuers and assurance grades to key recovery, agent KYC, the token, ZadQ and where the project stands today. What is MintID? MintID is an identity protocol for privacy-preserving, KYC-backed credentials, for people and for the AI agents they deploy. An accepted issuer verifies a person once; the person then proves what a counterparty needs, in zero knowledge, without revealing who they are. MintID is in production on the single-node production chain, operated by the CONECTIA group since 20 September 2026, and designed to scale to a public, permissionless proof-of-stake network. Does the chain store my identity documents? No. No KYC data, personal data, credential, credential serial, presentation or per-person record is ever written to the chain. It holds only issuer and verifier records, status roots, self-revocation nullifiers, staking, governance and evidence commitments — and it grows with institutions, never with people. Who can issue credentials? Under the protocol, only accepted issuers can issue: KYC organisations admitted on chain by governance proposal, today voted by the chain’s single validator and, once the compliance council is seated, by the council. Each one locks a slashable bond before it can operate, posted in the native token on a public network, and can be suspended or slashed through an evidence-backed decision. Today the single-node production chain carries the first accepted issuer, operated by the CONECTIA group as a disclosed related party on the same terms as any other. What is a zero-knowledge presentation? The holder proves a claim — for example “grade ≥ A3”, “over 18” or “credential active” — against public chain state without revealing the underlying attributes or which credential was used. The verifier learns the policy result and which accepted issuer stands behind it. What are assurance grades A1–A4? A private four-level measure of how strong the identification was, anchored on eIDAS and squared with ISO/IEC 29115: A1 corresponds to eIDAS low (LoA2), A2 to substantial with biometric liveness (LoA3), A3 adds enhanced due diligence — sanctions, PEP and adverse-media screening — and A4 corresponds to eIDAS high (LoA4), such as qualified identity proofing or the EU Digital Identity Wallet. A verifier receives only a threshold proof such as “grade ≥ A3” — never the grade itself. What if I lose my keys? There is exactly one recovery path: fresh KYC re-verification, which issues a brand-new credential with new secrets, publicly unlinkable to the old one. There is no social recovery and no custodial back door. Can I revoke my own credential? Yes. Holder self-revocation works without the issuer and reveals neither your identity nor the credential; every service refuses the revoked credential in under two minutes. It has run on the single-node production chain since 24 September 2026. Because it is the one proof the chain checks itself, it gets its own dedicated audit, a scheduled milestone whose findings are published. How long is a presentation valid? Ten seconds, and only once. It is bound to one verifier, that verifier’s exact origin and request key, a single-use challenge, the requested policy and the chain state the verifier checked — so it cannot be replayed or reused anywhere else. What is agent KYC, and how does it relate to Know Your Agent? Agent KYC is how MintID provides verifiable human-backed agent identity, what the market calls know your agent: a person does KYC once, and the issuer mints privacy-preserving credentials for the agents they deploy, up to a per-person cap. Each agent proves it is backed by a KYC-verified, liable human at a required grade and within a delegated scope, without revealing which human, and without two agents of the same person being linkable. Is there a token, and is it live? No token exists today. Today MintID runs on the single-node production chain, operated by the CONECTIA group: a permissioned chain where security is key custody, not stake, and nothing can be bought; whatever unit of account that chain uses has no value and is never carried over to a public network. If MintID later scales to a public, permissionless network — a route it does not need today — that network’s design includes a native token with a hard cap of exactly 108,000,000 and a declining emission. The genesis allocation is ratified as bands — development 15%, public sale 20–25%, reward pool at least 60% — with priors of 15, 25 and 60%, which the independent economic simulation validates or argues against before any genesis. Whether a public network is launched, and how it is financed, is decided at the Gate-1 go/no-go: a public token offer is one route among several, and if chosen it would follow the full EU MiCA Title II process at a single fixed price. Nothing is for sale, and nothing here is an offer or investment advice. Do units on the production chain or a test network have any value? No. They are free, unlimited and worthless by construction. They exist so the software can be exercised by the parties admitted to the environment; they never convert into any future token, and they may be deleted at any time through resets. Does a grade expire or decay with time? No. Grades measure strength, never age. Recency is a second axis, published by the issuer as a band — F4 under 30 days, F3 under 90, F2 under 180, F1 under a year — rather than a date, so records cannot be correlated by timestamp. The band is read on the classical seller rail; a presentation proves the grade threshold, not the band. Each grade has a default validity (12 months for A1 and A2, 6 for A3, 3 for A4); the credential expires exactly when the verification behind it does, with no grace period and no extension, and the way back is a new verification. Expiry is not revocation. What is ZadQ? ZadQ is an x402 seller-verification service and the first product built on MintID. A seller paid per request proves that an accountable, KYC-verified party stands behind its payment address, without revealing who. It runs as a pilot on the single-node production chain, not yet the distributed network, and its first version runs on the classical seller rail, with conventional issuer-signed attestations; the zero-knowledge seller rail follows. ZadQ is the CONECTIA group’s own product, a disclosed related party, so nothing it records counts as independent adoption. Who is behind MintID? MintID is conceived and built by the CONECTIA group, a related party that also runs the first issuer, the first verifier and ZadQ — on the same terms as anyone else, and disclosed as such. Today MintID runs on the single-node production chain, in production since 20 September 2026 and operated by the CONECTIA group, with the code under an Apache-2.0 licence. The MintID Foundation, a Netherlands Stichting, is being incorporated by the founder and stays dormant until the public-offer route is chosen; on that route, its seat would make the AFM the competent authority under MiCA. What exists today? The chain with its registries, bonds and status roots; the verifier service; the issuer status plane and a first issuer service; the proof core, with credential issuance and selective-disclosure presentations; holder self-revocation, in production since 24 September 2026; a Python SDK, a transport-only TypeScript client, an MCP server and a holder library with Python, Go and TypeScript bindings; the public testnet with its KYC sandbox; and the single-node production chain, in production since 20 September 2026, which runs the ZadQ pilot. Bounded agents are minted today from a bundle catalogue the operator supplies. The consented commercial disclosure rail, contact-attribute identification included, is built and ships switched off and fail-closed; its activation waits for counsel. When does the network launch? In stages, each behind a published gate. The target for an identity-only mainnet is the second half of 2027, ahead of the EU Digital Identity Wallet acceptance date of 24 December 2027, but genesis waits for conditions rather than dates: a published traction criterion, the simulation and counsel work delivered, and, if the public-offer route is chosen, a raise above the $4.0 M net floor. If a minimum is not met, the plan re-stages. --- Source: https://mintid.net/en/faq · FAQ — zero-knowledge identity, credentials & the token — MintID --- > Reach the MintID team: general enquiries, KYC credential issuers, verifiers and prospective validator operators. Specifications available on request. Contact # Get in touch MintID runs today on the single-node production chain. Whether you have a general question, want to issue credentials, build on the verification rail or operate a validator, send us a message and a person will reply. Name Email TopicGeneral enquiryIssuing credentialsBuilding on the verification railOperating a validator Message Send message This opens your email app with the message ready to send. Your email app should now be open with the message ready — just press send. If nothing happened, write to us directly at [info@mintid.net](mailto:info@mintid.net). Prefer plain email? Write to us at [info@mintid.net](mailto:info@mintid.net). ## Who should write, and what happens next Every message goes straight to the team inbox and is read by a person — there is no ticketing system and no autoresponder. Telling us which role fits you helps us send a useful answer the first time. 01 ### KYC organisations You verify identities today and want to issue reusable, privacy-preserving credentials on MintID. We will walk you through admission, status-root publication and the issuer bond — start with [the issuer role](/en/issuers). 02 ### Builders and verifiers You want to check zero-knowledge presentations instead of collecting documents — age checks, compliance gates, agent verification. See what the rail gives you on [the verifier page](/en/verifiers). 03 ### Validator operators You run proof-of-stake infrastructure and want to join the public adversarial testnet when it opens. Requirements and slashing rules are on [the validator page](/en/validators). 04 ### Everyone else Researchers, journalists, potential partners, or anyone who wants the SPEC-1 / SPEC-2 / SPEC-3 specifications — say what you are working on and we will reply with the relevant material. ## Reading the specifications The SPEC-1, SPEC-2 and SPEC-3 specifications are available on request; the whitepaper, the role manuals and the SDK documentation are public on the docs page. MintID runs on the single-node production chain and the protocol continues to evolve. Tell us briefly who you are and what you are evaluating, and we will send the current revision of each specification. [Download the whitepaper](/en/docs)[Read the protocol](/en/protocol) --- Source: https://mintid.net/en/contact · Contact — MintID --- > How the mintid.net website handles data. The protocol itself writes no KYC, personal data or identity logs on-chain — this page covers the website only. Legal # Privacy policy A short, plain-English summary of how this website handles information. Last updated: October 2026 ## Scope This policy covers the mintid.net website only. MintID is a protocol project running on the single-node production chain, in production since 20 September 2026 and operated by the CONECTIA group, and these pages exist to share information about it. It does not govern any third-party site you reach through a link, nor any future application that may be built on the protocol. ## What we collect We aim to collect as little as possible. The site keeps basic server logs and uses Google Analytics 4 to understand traffic in aggregate: approximate location, device and browser type, and which pages were viewed. Analytics is on by default: Google Analytics 4 loads on every page and records page views and the two contact-form events described below. We do not sell personal data, we do not use this information to build advertising profiles, and we never join analytics identifiers to any real-world identity. The contact form works in your browser: it opens your own email app with the message pre-filled, and the message travels directly from you to our inbox. When you submit it, the page sends Google Analytics 4 an event recording that the form was submitted, without your name, email, topic or message; we use your details only to answer you. ## The protocol versus the website The MintID protocol itself is engineered so that no raw KYC material, personal data or identity-check logs are ever written to the chain. Holders keep their own keys and prove claims in zero knowledge against published trust roots. The data handling described here is entirely separate from the protocol and concerns only ordinary web analytics for this informational site. ## Hosting and server logs The site is served as static pages from a content delivery network (Amazon CloudFront, with storage on Amazon S3). Like any web server, the network may keep standard access logs — the requesting IP address, the page requested and the time — which we use only for security and capacity monitoring. The pages run no scripts beyond the analytics snippet described above and, on the contact page, one short inline script that composes your email and sends two form-submission events to Google Analytics 4; those events carry no name, email, topic or message. There are no other trackers, no advertising pixels and no embedded third-party widgets. ## Cookies Apart from Google Analytics 4, the site sets no cookies. Google Analytics 4 sets its analytics cookies when a page loads. You can block or clear cookies at any time in your browser settings, and the site will keep working for reading. ## Your rights You can ask us what information we hold about you, ask us to correct it, or ask us to delete it. Because we collect so little, the answer will usually be an email you once sent us plus aggregate analytics that identify no one — but the request is always yours to make. If you are in the European Union, these requests are backed by the GDPR, including the right to lodge a complaint with your local supervisory authority. ## Contact For any privacy request or question, email [info@mintid.net](mailto:info@mintid.net). ## Changes We may update this policy as the project evolves. The "last updated" date above always reflects the latest version. --- Source: https://mintid.net/en/privacy-policy · Privacy policy — MintID --- > Terms of use for the mintid.net website: informational material about a protocol that runs today on the single-node production chain, a permissioned chain — no public network, no token issued or offered; not an offer, solicitation or financial advice. Legal # Terms of use The terms on which this website and its materials are provided. Last updated: October 2026 ## Informational only This website and all materials on it — including the whitepaper, the role manuals and the software documentation — are provided for information about a protocol that runs today on the single-node production chain and whose public network does not exist. There is no public network, no token, no token price, and nothing is for sale. None of these materials is a crypto-asset white paper under Regulation (EU) 2023/1114 (MiCA), a prospectus, or an offering document of any kind. ## The chain that runs today is permissioned Today MintID runs on the single-node production chain, in production since 20 September 2026 and operated by the CONECTIA group as a disclosed related party, together with invited partners — a permissioned chain; its security rests on key custody, not on stake; and nothing on it can be bought. The public, permissionless network described on this site does not exist yet. It is one route by which MintID could scale beyond its first implementer and its partners — a route MintID does not need today — and the production chain serves the current issuers, verifiers and pilots without any token. This website does not grant access to the production chain: any such access is governed by separate written agreements, not by these terms. The production chain keeps the same state discipline the public network is designed for: no identity document, personal data, credential or presentation is stored on it. If a public network is ever launched, its genesis may import the production chain’s registries — issuers, verifiers, bonds, status roots and governed parameters — but never any unit of account. Whatever unit of account the production chain uses has no value and is not carried over. ## No token, no offer, no advice No MintID token is issued, offered, sold, distributed or admitted to trading, on any market or by any party. Nothing on this site is an offer or solicitation to buy or sell any token, security or financial instrument, nor a promise that any token will ever exist. MintID does not provide crypto-asset services, and nothing here is financial, legal or tax advice. You should seek your own professional advice before making any decision. ## Forward-looking statements Descriptions of the protocol, of the roadmap and of a possible public network, including any description of a native token, its supply, allocation or economics, are forward-looking statements about a possible scaling route that MintID does not need today; they do not describe a product that exists. How a public network would be financed, if one is launched at all, is decided at a future go/no-go; a public token offer is only one of the routes considered, and if it were ever chosen it would follow the full EU MiCA Title II process before anything could be offered. Features may be revised, delayed, or never implemented as described. ## Test networks and units without value Any unit of account on the single-node production chain, on a test network or on any other environment operated for MintID has no value — deliberately. Such units exist only so that the software can be exercised. Such units (a) have no monetary value and are not offered, sold, or exchangeable for value; (b) are made available, if at all, free of charge — on the public testnet from its open faucet, within its rate limits; elsewhere only to parties admitted to the environment for testing or operation; (c) will not convert into, entitle the holder to, or be exchangeable for any token on any future public network; and (d) may be deleted at any time, including through full resets of the environment. Participation in any such environment does not create any entitlement to future tokens or compensation. Any recognition of contributors is made retroactively, at the operator’s sole discretion, and is never promised in advance. ### The public testnet’s terms These four statements are the public testnet’s terms. 1. **Own denomination.** The public testnet runs on its own denomination, `utestmint`. It is not the token of any other MintID chain, present or future. 2. **Free from the faucet.** Anyone can obtain test tokens free of charge from the public faucet, within its rate limits. Test tokens are not for sale and have no value. 3. **No conversion.** Test tokens cannot be transferred or converted to any other chain or asset. No snapshot, points programme or conversion promise attaches to them, and testing creates no claim. 4. **Reset.** The public testnet, every balance on it included, may be reset at any time without notice. ## Open-source software and intellectual property The MintID software is published under the Apache License 2.0. That licence governs the software only: it does not extend to the content of this website, to the MintID name and marks, or to the names, logos and content of third parties referenced here, which belong to their respective owners. Please do not misrepresent any affiliation with, or endorsement by, MintID, the CONECTIA group or third parties referenced here. ## No warranty The site is provided "as is" and "as available", without warranties of any kind, whether express or implied, including accuracy, completeness or fitness for a particular purpose. ## Limitation of liability To the maximum extent permitted by law, neither MintID nor the CONECTIA group, which develops and operates it, is liable for any damages or losses arising from your use of, or inability to use, this site or its materials. ## Contact Questions about these terms? Email [info@mintid.net](mailto:info@mintid.net). --- Source: https://mintid.net/en/terms · Terms of use — MintID --- > Dated engineering notes and explainers from MintID: the single-node production chain, verifiable human-backed agent identity, what the market calls know your agent (KYA), reusable KYC, zero-knowledge credentials, and how MintID compares with other identity chains. Blog # Engineering notes, signed Dated notes from the build: what runs on the single-node production chain, the decisions behind it, and explainers on human-backed agent identity, reusable KYC and zero-knowledge proofs. 2026-09-22 6 min read ## [The single-node production chain is live — and the identity behind it is real now](/en/blog/anchor-chain-live) engineering The single-node production chain has produced blocks in Spain since 20 September 2026, operated by the CONECTIA group and keeping ZadQ’s accounting. The identity checks behind its attestations now run on a certified external provider, and the proof core is in production. [Conectia PRO](https://conectia.pro/en/) and ZadQ are related parties, so none of this is independent adoption. 2026-09-17 6 min read ## [Declaring how we hash: a small standard for the bytes behind a ten-second proof](/en/blog/declaring-how-we-hash) engineering If two implementations hash the binding of a ten-second presentation over different bytes, a valid proof fails or a wrong one passes. MintID now declares its rule — RFC 8785 canonicalization, then SHA-256 — cites every digest as a typed reference, and hashes Merkle-tree entries as raw bytes. Recorded as bIP-0003; existing integrations see the same bytes, and the rule follows an individual IETF submission on SCITT payload binding. 2026-08-22 7 min read ## [How we grade identity — and how we keep it fresh](/en/blog/grades-follow-eidas) design note MintID’s four assurance grades, A1–A4, map onto eIDAS, ISO/IEC 29115, ETSI TS 119 461, NIST IAL and EU anti-money-laundering law. The issuer publishes age separately as a freshness band, F1–F4, and a credential expires with its verification: twelve months for A1 and A2, six for A3, three for A4. 2026-08-02 11 min read ## [The first live network: running, not written](/en/blog/first-live-network) milestone In August 2026 MintID ran its first end-to-end test on an internal testnet — a chain node and the verifier service, rebuilt from a reproducible package: proof-backed reads, live ten-second challenges, a minimal decision record and a complete MCP session. The same month’s re-freeze of the specifications fixed the token design for a possible public network: the 108,000,000 hard cap, ratified allocation bands, a price-independent launch gate. The protocol cuts and their allocation are under review. 2026-08-02 9 min read ## [We audited ourselves before anyone asked](/en/blog/we-audited-ourselves) transparency In July 2026 [Conectia PRO](https://conectia.pro/en/) — the related-party group that conceived MintID and is building it — audited MintID’s economic viability against its own frozen corpus, before any token existed. The verdict, quoted whole: a qualified opinion, with the demand thesis corroborated against independent sources and five critical findings. The specification corpus was re-frozen within days with five written answers; the report is published unedited. 2026-07-26 6 min read ## [Verification is now a tool call](/en/blog/verification-is-a-tool-call) announcement MintID’s verifier now runs as an MCP server: the three frozen verifier-service operations become tools any agent framework can call, with the same closed reason codes, so an agent reads a rejection as a decision it can act on. 2026-07-26 8 min read ## [The graduated-knowledge slot: an identity profile for x402 and Web Bot Auth](/en/blog/x402-web-bot-auth-identity-profile) standards Between an anonymous payment and a doxxed buyer sits a slot: human-backed, in scope, unrevoked, and unrevealed. A zero-knowledge proof is built to fill it. MintID has drafted a standards-track profile that carries that proof over x402 and Web Bot Auth without changing either, with machine-readable schemas and a validation suite. 2026-07-26 7 min read ## [AI writes the evidence. It doesn’t get to decide.](/en/blog/ai-writes-the-evidence) issuance Cheaper AI screening is good news for a credential rail: more organisations can afford to issue. MintID’s issuer plane keeps the decision with the issuer by construction: a screener’s output is accepted only as enumerated checks with provenance, an asserted grade is rejected by name, and no field exists that could carry one. 2026-07-26 7 min read ## [The pay-per-use web is here. It needs Know Your Agent.](/en/blog/x402-pay-per-use-web-needs-identity) agentic identity Cloudflare’s Monetization Gateway makes agents pay per call over x402, and Web Bot Auth signs the big fleets. Neither tells a seller whether an accountable human stands behind the long tail of agents. Why verifiable human-backed agent identity, proven in zero knowledge, is the missing half of the paying web. 2026-07-20 6 min read ## [Implementing clients: where the rubber meets the road](/en/blog/implementing-clients) architecture MintID’s verifier SDKs share one verification core, embedded in Python and never rewritten per language. TypeScript and later languages are thin clients with no cryptography and no policy, calling a verification service you host yourself, so no binding can weaken a check. An implementation audit of the core is a scheduled milestone whose findings are published. 2026-07-20 5 min read ## [The MintID SDKs: one core, thin clients](/en/blog/embedded-not-hosted) announcement The MintID verifier SDKs are built around one verification core, embedded in Python and reached from other languages through transport-only clients, TypeScript first, with further languages as demand appears. Inside every binding, the same non-negotiables: nine acceptance checks, a ten-second presentation lifetime and zero policy knobs. 2026-07-13 9 min read ## [MintID vs ERC-8004: trustless agents still need accountable humans](/en/blog/mintid-vs-erc-8004) comparison ERC-8004 makes agents discoverable and their work verifiable; its identity is a transferable NFT, its reputation open to Sybil inflation, and recourse out of scope. A MintID presentation proves that a liable, verified human backs an agent without naming them. Where the standard stops, and how the two compose. 2026-07-10 7 min read ## [Scope an agent can prove, axis by axis](/en/blog/agent-scope-axis-by-axis) agent credentials Agent authorisation today is a plaintext scope inside a token: all or nothing. A scope structured along five provable axes applies selective disclosure to authorisation itself — the merchant learns the limit, not the mandate. 2026-06-25 7 min read ## [One KYC, every agent: the economics of amortised accountability](/en/blog/amortised-accountability) economics One KYC with an approved issuer backs every agent credential minted for that human’s agents, so accountability is paid for once instead of at every counterparty. How amortisation changes the cost structure of trust, and the five flows a public MintID network would earn from if that route is chosen. 2026-06-11 8 min read ## [Identification, not surveillance](/en/blog/identification-not-surveillance) privacy Identifying an agent once, paid and consented, is categorically different from holding a handle that tracks its human forever. How pay-per-disclosure, pseudonym churn and committed receipts are designed to make identification a bounded event rather than a tracking right. 2026-05-27 9 min read ## [Money before identity: how disputes settle without ever learning who](/en/blog/money-before-identity) disputes MintID’s dispute design starts from a premise: a wronged party wants to be made whole before it wants a name. How the specified dispute rail — self-custodied escrow, bonded arbiters, due process — would settle claims without unmasking anyone, and why that protects both sides. Specified and scheduled for the financial-recourse stage; audits not started; no funds are locked today. 2026-05-14 10 min read ## [The agentic identity problem: no human at the keyboard](/en/blog/agentic-identity-problem) agentic identity Passwords, MFA, KYC and fraud scoring all assume a human at the keyboard. Autonomous AI agents break that assumption, and six concrete failures follow. The sixth — accountability or privacy, pick one — is the one to solve first, because it keeps the other five unfixed. 2026-04-13 8 min read ## [Reusable KYC explained](/en/blog/reusable-kyc-explained) reusable kyc 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. 2026-03-30 8 min read ## [MintID vs Concordium](/en/blog/mintid-vs-concordium) comparison Concordium puts a verified identity behind every account and lets a court order plus 2-of-3 Privacy Guardians reverse its privacy. MintID keeps no person-level record on-chain and leaves the only identity link with the issuer, released under due process. How the two identity-first chains differ, and where Concordium is ahead. 2026-03-01 9 min read ## [What is Know Your Agent (KYA)?](/en/blog/what-is-know-your-agent) kya What Know Your Agent (KYA) means, why AI agents need verified human backing, how KYA differs from KYC, and how zero-knowledge agent credentials work. --- Source: https://mintid.net/en/blog · Blog — identity, agent accountability and reusable KYC explained — MintID --- > Every market figure and third-party fact on this site, with its primary source and how we label it. Vendor projections are flagged, and no protocol fee, token price or offer term is published. Sourcing # Where the numbers come from A protocol that promises verifiability should not publish unverifiable numbers. Every market figure and third-party fact used on this site appears below with its primary source and how we label it. Vendor projections and announcements are labelled as such; estimates are flagged as estimates and never dressed up as measurements; and protocol economics appear only as the frozen cap and the ratified bands and priors published in the Protocol Whitepaper v1.0 — never as prices or offer terms. The register ## Each figure and fact, its source and how we use it Figure Source How we use it Machine (non-human) identities outnumber human identities ~50:1 Omdia, December 2024; reported in IBM Think, The Practitioner’s Guide to Non-Human Identities (Clark & Forward, February 2026) The scale of the accountability gap; the amortisation argument (one KYC backs N agents) More than 1 billion active AI agents expected by 2029 IDC (Rick Villars), December 2025 An analyst projection, labelled as one: the growth curve the identity layer must survive, and why state must never scale with agents 40% of enterprise applications with task-specific agents by end of 2026, up from <5% in 2025 Gartner An analyst projection, labelled as one: why the integration window is now (cited on the blog) “With autonomy comes accountability” — the framing of agentic identity as an unsolved accountability problem OpenID Foundation, Identity Management for Agentic AI (Tobin South et al., October 2025) Primary corroborating source for the problem statement Cloudflare’s Monetization Gateway puts a per-call price on any resource, paid in stablecoins Cloudflare’s own launch announcement, 1 July 2026 A vendor announcement, labelled as one: why sellers on the pay-per-use web now face the identity question (cited on the blog) Anthropic’s finance agents include a KYC screener and ship wired to MCP connectors Anthropic’s own product announcement, as cited on the blog in July 2026 A vendor announcement, labelled as one: the compliance middle is being automated, and the tool is the unit of consumption (cited on the blog) Reasoning is commoditising; durable value sits in evidence quality and operational infrastructure Sardine’s public response to Anthropic’s announcement, as cited on the blog in July 2026 A vendor statement, labelled as one: why the evidence, not the reasoning, is what a credential must carry (cited on the blog) ERC-8004: three registries per EVM chain, its deployment and the integrations announced around it The draft ERC-8004 specification on eips.ethereum.org and its Ethereum Magicians discussion thread; the projects’ own announcements; as of July 2026 A standards draft and vendor announcements, labelled as such: the comparison with MintID (cited on the blog) Web Bot Auth: HTTP message signatures that authenticate agent software, in the IETF process The Web Bot Auth Internet-Draft at the IETF, as of July 2026 A standards draft, labelled as one: software identity as the layer below an accountable principal (cited on the blog) This register is the single point of truth: a market figure or third-party fact that is not in it does not appear on this site. New primary sources are added here before they are used. ## Not on this page, by design No offer figures — no price, no fee schedule, and nothing for sale: the only route by which an offer could ever exist is the full EU MiCA Title II process. What is published is what the whitepaper publishes: the frozen cap of 108,000,000 tokens, and ratified bands with argued priors — among them 15% development, 25% public sale and 60% reward pool — which the independent simulation validates or argues against before genesis. Any other allocation, fee or price figure attributed to MintID elsewhere is not ours. [How the economics work](/en/tokenomics)[Ask about a figure](/en/contact) --- Source: https://mintid.net/en/sources · Where the numbers come from — MintID --- > Every integration runs the same verifying code: embed the Python SDK, deploy it as your own service, or call that service from a transport-only client. index — 17 documents 1. [overviewsdk/00](/en/sdk) * [the same verifying code](#one-core) * [what you cannot turn off](#invariants) * [the decision model](#decision-model) 2. [getting startedsdk/01](/en/sdk/getting-started) 3. [python sdksdk/02](/en/sdk/python) 4. [service modesdk/03](/en/sdk/service-mode) 5. [typescript clientsdk/04](/en/sdk/typescript-client) 6. [mcp serversdk/04a](/en/sdk/mcp-server) 7. [conformancesdk/05](/en/sdk/conformance) 8. [reason codessdk/06](/en/sdk/reason-codes) 9. [substrate readssdk/07](/en/sdk/substrate-reads) 10. [credentials & holderssdk/08](/en/sdk/credentials-and-holders) 11. [payment identitysdk/09](/en/sdk/payment-identity-profile) 12. [becoming a verifiersdk/10](/en/sdk/becoming-a-verifier) 13. [protocol statesdk/11](/en/sdk/protocol-state) 14. [record · assurance vocabularyrecord/01](/en/sdk/kyc-trust-model) 15. [record · packagingrecord/02](/en/sdk/packaging) 16. [record · multi-languagerecord/03](/en/sdk/multi-language-clients) 17. [record · service contractrecord/04](/en/sdk/verifier-service-contract) SDK docs · sdk/00 # Integration overview Every integration runs the same verifying code: embed the Python SDK, deploy it as your own service, or call that service from a transport-only client. Your backend asks a holder to prove a _predicate_, such as "over 18", "KYC grade at least A3" or "credential active", and gets a decision without ever seeing attributes, documents or identifiers. The SDK issues that request and validates the answer for a **verifier agency**: a relying party such as a bank, a marketplace or a platform. The MintID code, meaning the chain, the proof core and the SDKs, is licensed under **Apache-2.0**, and every package manifest declares it. The packages are pre-release: their source is published from the main repository under the Apache License 2.0, at [gitlab.com/mintid/mintid](https://gitlab.com/mintid/mintid), and none is on a public package index yet (see [getting started](/en/sdk/getting-started)). ## The same verifying code, whether you embed it, host it or call it Every deployment runs the **same single verifying core** — the Python SDK, with its proof engine built in at a fixed version. Nothing else ever validates a presentation, and the protocol’s single-core rule makes that binding on every deployment. Mode What you run For whom Embedded Your Python backend imports `mintid-verifier-sdk` and calls `validate_presentation` in-process Python backends; lowest latency, fewest moving parts Service The same SDK wrapped in a thin first-party HTTP service you self-deploy next to your backend Any backend language; operational isolation Client `@mintid-net/verifier-client` (TypeScript, Node) — a transport-only client of **your own** service instance Node/TypeScript backends; further languages as demand appears Transport-only has two consequences: * **Clients carry no cryptography and no policy.** The TypeScript client is a thin HTTP layer; it cannot verify, cache, weaken or skip anything. If your client-side code ever seems to need a verification feature, the feature belongs to the service. * **The service is yours.** Pointing your client at somebody else's verifier service would delegate the _decision_ itself. Service mode adds transport, never authority. ## What the SDK enforces that you cannot turn off These are constants and closed types in the code, with no configuration switch: 1. **The nine acceptance conditions run in full, in order**, on every presentation: active verifier and exact origin on proven chain state; registered request key; unused nonce; inside the deadline; proof bound to the exact challenge (origin, verifier id, request key, nonce, policy, finalised chain height); every requested predicate proven; issuer operational with a current status root; a final proven-state re-check; and irreversible nonce consumption as the accept gate. 2. **Presentations live 10 seconds.** The lifetime is a constant. 3. **Chain reads are proven or they don’t count.** Every answer from a chain node is checked with a cryptographic store proof against your trust anchor — today, a node you run yourself — and a claimed absence that cannot be proven fails closed. There is no “trust this node” mode. 4. **Retention is closed.** The only thing kept is a minimal decision record — the session, the outcome, the reason code, a digest of the bound context and the time. Proof bytes, claim values and personal data structurally do not fit. ## The decision model Validation returns a **decision**, never throws for a rejection. `reason_code` comes from a **closed vocabulary** shared byte-for-byte across the Python SDK, the HTTP contract and every client — see [reason codes](/en/sdk/reason-codes). Transport-level problems (malformed body, service refusing to work from unproven chain state) are errors; domain rejections are data. Where to go next: 1. [Getting started](/en/sdk/getting-started) — verifier obligations first, then installation channels and current status. 2. [Becoming a verifier](/en/sdk/becoming-a-verifier) — what registration puts on chain, and which steps are still done by hand. 3. [Python SDK](/en/sdk/python) — the embedded mode. 4. [Service mode](/en/sdk/service-mode) — the deployable + the OpenAPI contract. 5. [TypeScript client](/en/sdk/typescript-client). 6. [Conformance & versioning](/en/sdk/conformance) — how "every SDK behaves identically" is enforced, and what our version numbers promise. 7. [Protocol state](/en/sdk/protocol-state) — what is stable, draft and absent, before you commit a date to anyone. decisionsdk/00 · verbatim ``` { accepted: true, reason_code: "accepted", verified: { issuer_id, status_root, proven_predicates } } { accepted: false, reason_code: "nonce_replayed", verified: null } ``` [nextgetting started →](/en/sdk/getting-started) --- Source: https://mintid.net/en/sdk · Integration overview · MintID SDK docs --- > What to register before you write code, how the SDK reaches you today, and what already runs in production: the verification pipeline and the proof core. index — 17 documents 1. [overviewsdk/00](/en/sdk) 2. [getting startedsdk/01](/en/sdk/getting-started) * [before any code](#verifier-obligations) * [installation channels](#installation) * [current status](#current-status) * [the 60-second mental model](#mental-model) 3. [python sdksdk/02](/en/sdk/python) 4. [service modesdk/03](/en/sdk/service-mode) 5. [typescript clientsdk/04](/en/sdk/typescript-client) 6. [mcp serversdk/04a](/en/sdk/mcp-server) 7. [conformancesdk/05](/en/sdk/conformance) 8. [reason codessdk/06](/en/sdk/reason-codes) 9. [substrate readssdk/07](/en/sdk/substrate-reads) 10. [credentials & holderssdk/08](/en/sdk/credentials-and-holders) 11. [payment identitysdk/09](/en/sdk/payment-identity-profile) 12. [becoming a verifiersdk/10](/en/sdk/becoming-a-verifier) 13. [protocol statesdk/11](/en/sdk/protocol-state) 14. [record · assurance vocabularyrecord/01](/en/sdk/kyc-trust-model) 15. [record · packagingrecord/02](/en/sdk/packaging) 16. [record · multi-languagerecord/03](/en/sdk/multi-language-clients) 17. [record · service contractrecord/04](/en/sdk/verifier-service-contract) SDK docs · sdk/01 # Getting started What to register before you write code, how the SDK reaches you today, and what already runs in production: the verification pipeline and the proof core. ## Before any code: become a verifier The SDK accepts presentations only for a verifier that is registered and active: it resolves your origin against proven on-chain state on every decision. Complete these four steps before you write integration code; [becoming a verifier](/en/sdk/becoming-a-verifier) explains how admission works today. 1. **Pass the verifier identity check and have your record admitted**: it must be active on chain, and today an operator processes admission. 2. **Register every exact origin you present from**, and renew each registration periodically. Origins are exact — no wildcards — and an origin resolves to one verifier only, so a lookalike domain can never impersonate you. 3. **Register your request-signing keys** — the key that signs your challenges must be registered for your origin. 4. **Plan your infrastructure**: access to chain nodes, whose answers are checked cryptographically so the nodes need no trust; a trust anchor you control, which today means a node you run yourself, since a light client that checks untrusted peers has not shipped; a crash-durable store for single-use challenges (the SDK ships one); a disciplined clock; and a place for the decision records. ## Installation channels **The source.** Everything is public under the Apache License 2.0 at **[https://gitlab.com/mintid/mintid](https://gitlab.com/mintid/mintid)** (the whole implementation, the local stack and these pages), with a read-only mirror per SDK. Issues and merge requests go to the main project; a vulnerability goes privately to the address in its `SECURITY.md`, never to a public issue. **The packages.** None is on a package registry yet: build from the main project (or from the mirror, where there is one). Until a package is published, the lines below are the install path. Package Directory (mirror) Today `mintid-verifier-sdk` (Python ≥ 3.12) `verifier-core/` not yet on PyPI: `pip install ./verifier-core` from a clone of the main project (a Rust toolchain compiles the pinned proof engine into it) `mintid-proof-core` (Python bindings of the proof core and holder library) `identity-proof-core/python/` not yet on PyPI: `pip install ./identity-proof-core/python` (Rust toolchain) `mintid-agent` (Python agent client) `sdk/python/mintid-agent/` ([https://gitlab.com/mintid/sdk-python](https://gitlab.com/mintid/sdk-python)) not yet on PyPI: install `mintid-proof-core` first, then `pip install -e "./sdk/python/mintid-agent[ed25519]"` `@mintid-net/verifier-client` (Node ≥ 20, ESM + types) `sdk/typescript/` ([https://gitlab.com/mintid/sdk-typescript](https://gitlab.com/mintid/sdk-typescript)) not yet on npm: `npm install && npm run build && npm pack` there, then install the tarball `@mintid-net/verifier-mcp` `sdk/mcp/` ([https://gitlab.com/mintid/verifier-mcp](https://gitlab.com/mintid/verifier-mcp)) not yet on npm: build the client first, then `npm install` there Go holder binding `sdk/go/` ([https://gitlab.com/mintid/sdk-go](https://gitlab.com/mintid/sdk-go)) `go get gitlab.com/mintid/sdk-go/holder`; it drives the `mintid-holder` binary (`cargo build -p mintid-holder` in `identity-proof-core/`) **Target channel.** `pip install mintid-verifier-sdk` from a package index, one wheel per platform (Linux/macOS, x86\_64/arm64) with the Rust proof engine compiled in at a pinned version, so no Rust toolchain is needed; `npm install @mintid-net/verifier-client` and `@mintid-net/verifier-mcp`; `pip install mintid-agent`. These pages will say so when a package is published. **Where to test.** On [the public testnet](/en/developers), with its KYC sandbox, and only there; check its status line first. The single-node production chain is not for third parties and is never a place to test. Until the testnet answers, the local stack of the main project runs the same flows on your machine. Every artifact records its release pins — SDK version, proof-engine version, the chain store-layout vectors it was checked against, the specification revision and the conformance-suite version — and a running service reports them through its build-info operation. ## Current status — read before integrating * The **verification pipeline is complete**: the acceptance conditions, proven chain reads, single-use challenges, decision records, the service, its contract and the TypeScript client all exist and are gated by a shared conformance suite. * The **proof core is built and runs on the single-node production chain**, in production since 20 September 2026 and operated by the CONECTIA group: credential issuance, selective-disclosure presentations and the non-revocation path are implemented and pinned by known-answer vectors that three languages check. You can also build and test a full integration against injectable test doubles before you touch a chain. * A given deployment may be running an **older engine than this page describes**. The pin is the fact, not the release note: read `engine_pin` from `GET /v1/build-info` on the instance you are actually talking to. * Assurance grades (A1–A4) are set by accepted issuers, within the grades their admission permits. They are anchored on the eIDAS levels and mapped to ISO/IEC 29115 without redefining either. How recently the evidence was checked is a separate freshness band, published by the issuer next to the grade: a presentation proves the grade threshold, and the band is not a presentation predicate. ## The 60-second mental model sdk flow your backendcreates challenge signed challenge · 10 s holder softwareproof bound to your exact challenge envelope · proof + outputs verifier SDKdecision → your business logic proven reads trust anchor the chainreads proven or they don't count one decision, one minimal decision record, per presentation [previous← overview](/en/sdk)[nextpython sdk →](/en/sdk/python) --- Source: https://mintid.net/en/sdk/getting-started · Getting started · MintID SDK docs --- > The embedded Python SDK: one call returns the decision, five ports take your infrastructure, and the proof engine ships compiled in at a fixed version. index — 17 documents 1. [overviewsdk/00](/en/sdk) 2. [getting startedsdk/01](/en/sdk/getting-started) 3. [python sdksdk/02](/en/sdk/python) * [install channel today](#install) * [the public surface](#public-surface) * [the entrypoint](#entrypoint) * [issuing challenges](#issuing-challenges) * [chain access](#chain-access) * [retention](#retention) 4. [service modesdk/03](/en/sdk/service-mode) 5. [typescript clientsdk/04](/en/sdk/typescript-client) 6. [mcp serversdk/04a](/en/sdk/mcp-server) 7. [conformancesdk/05](/en/sdk/conformance) 8. [reason codessdk/06](/en/sdk/reason-codes) 9. [substrate readssdk/07](/en/sdk/substrate-reads) 10. [credentials & holderssdk/08](/en/sdk/credentials-and-holders) 11. [payment identitysdk/09](/en/sdk/payment-identity-profile) 12. [becoming a verifiersdk/10](/en/sdk/becoming-a-verifier) 13. [protocol statesdk/11](/en/sdk/protocol-state) 14. [record · assurance vocabularyrecord/01](/en/sdk/kyc-trust-model) 15. [record · packagingrecord/02](/en/sdk/packaging) 16. [record · multi-languagerecord/03](/en/sdk/multi-language-clients) 17. [record · service contractrecord/04](/en/sdk/verifier-service-contract) SDK docs · sdk/02 # Python SDK (embedded mode) The embedded Python SDK: one call returns the decision, five ports take your infrastructure, and the proof engine ships compiled in at a fixed version. ## Install channel today **Install channel today.** Not yet on PyPI: build it from a clone of the main project, [https://gitlab.com/mintid/mintid](https://gitlab.com/mintid/mintid) (`verifier-core/`, Apache License 2.0). The pin is the only thing that says which engine you got. `build_info()` reports it at runtime, with the store-layout vectors, spec revision and suite version. The engine is real and in production; an independent audit of its implementation is scheduled and its findings will be published — see [protocol state](/en/sdk/protocol-state). To exercise it against a live chain, use [the public testnet](/en/developers) or the local stack of the same project; the single-node production chain is not a place to test. bashsdk/02 · install channel today ``` git clone https://gitlab.com/mintid/mintid && cd mintid pip install ./verifier-core # a Rust toolchain compiles the pinned engine in ``` ## The public surface **`mintid-verifier-sdk`** is the embedded mode: your Python backend imports it and gets each decision in-process. The proof engine ships compiled inside the package at a version fixed at build time, so a supported installation cannot end up with a substituted or mismatched engine. The public surface is small and frozen: one decision entrypoint, the challenge types that mirror the service contract, the closed reason-code vocabulary and five infrastructure ports. Everything else is internal and may change without notice. A test enforces that surface on every change, and versions follow semver: any change to the surface, or to what the SDK accepts, is a **major** version. ## The entrypoint `validate_presentation` takes the challenge you issued and the holder’s response, and returns a decision. You supply **infrastructure, never policy**: Port What it provides Your freedom Chain reader proven reads from chain nodes you choose, checked against your trust anchor which nodes — never whether reads are proven Replay store durable, exactly-once consumption of challenges; a durable store ships with the SDK the backend, as long as consumption stays atomic and exactly-once Proof engine the engine built into the package none — a proof not bound to the exact challenge is always rejected Decision log the sink for decision records where records go — never what they contain Clock the time you pass in a skewed clock only makes you _more_ rejecting How far behind the latest chain height a challenge may be is a local deployment setting, never a per-request option. ## Issuing challenges A challenge carries exactly what the service contract describes: a session identifier and a single-use value generated on your side, your verifier identity, one of your registered exact origins, your registered request key, an expiry of exactly ten seconds, the finalised chain height you read, and the issuer and claim policies you require. It is serialised canonically and signed with your registered request key. The proof binds to the whole canonical body, so tampering with any part of the challenge breaks the binding (the fifth of the nine acceptance conditions listed on the integration overview). ## Chain access Trust is split into two roles on purpose: * **Any chain node** may answer queries, and is assumed malicious: every answer must carry a store proof. * **The trust anchor** is separate: headers come from a source you control — typically your own node — and never from an arbitrary public endpoint. A light client that checks untrusted peers is planned and has not shipped; until it does, back the anchor with a node you run. Absence is never trusted: if a node claims a record does not exist and cannot prove it, the read fails closed and the decision is `state_unproven`. ## Retention (what you keep, all of it) Exactly one decision record per decision, accept or reject: the session identifier, whether it was accepted, the reason code, a digest of the bound context and the time of the decision. Nothing else fits — presentations, proof bytes and claim values are never persisted — and any extension of that record is a privacy review. [previous← getting started](/en/sdk/getting-started)[nextservice mode →](/en/sdk/service-mode) --- Source: https://mintid.net/en/sdk/python · Python SDK (embedded mode) · MintID SDK docs --- > Run the same SDK as an HTTP service inside your perimeter, so a backend in any language verifies through a frozen, versioned OpenAPI contract. index — 17 documents 1. [overviewsdk/00](/en/sdk) 2. [getting startedsdk/01](/en/sdk/getting-started) 3. [python sdksdk/02](/en/sdk/python) 4. [service modesdk/03](/en/sdk/service-mode) * [the contract](#contract) * [deploying](#deploying) * [trust boundaries](#trust-boundaries) 5. [typescript clientsdk/04](/en/sdk/typescript-client) 6. [mcp serversdk/04a](/en/sdk/mcp-server) 7. [conformancesdk/05](/en/sdk/conformance) 8. [reason codessdk/06](/en/sdk/reason-codes) 9. [substrate readssdk/07](/en/sdk/substrate-reads) 10. [credentials & holderssdk/08](/en/sdk/credentials-and-holders) 11. [payment identitysdk/09](/en/sdk/payment-identity-profile) 12. [becoming a verifiersdk/10](/en/sdk/becoming-a-verifier) 13. [protocol statesdk/11](/en/sdk/protocol-state) 14. [record · assurance vocabularyrecord/01](/en/sdk/kyc-trust-model) 15. [record · packagingrecord/02](/en/sdk/packaging) 16. [record · multi-languagerecord/03](/en/sdk/multi-language-clients) 17. [record · service contractrecord/04](/en/sdk/verifier-service-contract) SDK docs · sdk/03 # Service mode & the OpenAPI contract Run the same SDK as an HTTP service inside your perimeter, so a backend in any language verifies through a frozen, versioned OpenAPI contract. ## The contract Service mode lets a backend in any language use the same nine-condition pipeline: the SDK runs inside a thin first-party HTTP service you deploy next to your backend, and transport-only clients call it, TypeScript today and further languages as demand appears. It is **embedded mode plus transport**, with the same checks, no extra options and no “lite” path. `verifier-service.v1` — a versioned OpenAPI 3.1 document, frozen by a published decision record (see the verifier service contract record). Three operations: Operation Method & path Purpose `createChallenge` `POST /v1/challenges` Issue one signed presentation challenge bound to the deployment's registered identity `validatePresentation` `POST /v1/presentations` Run the nine conditions; returns the decision `getBuildInfo` `GET /v1/build-info` The artifact's release pins (versions — never secrets) Semver at the contract level: decision semantics or reason-vocabulary changes are **major**; additive surface is **minor** (current: 1.1.0, which added the conformance-suite pin to build-info). **Deliberately absent from the wire** — these are invariants, not parameters: any lifetime setting (10 s is a constant), any skip flag for the conditions, and `max_height_lag` (local deployment policy, configured at service start — a compromised web tier must not be able to widen staleness acceptance). ### Decision vs transport error * Anything parseable into the challenge-response schema flows through the pipeline and returns **HTTP 200 with a decision** — accept or reject — plus exactly one decision record server-side. * **HTTP 400** exists only for bodies that cannot be parsed into the schema at all (no session identity exists, so no decision record is possible). * **HTTP 503** means the service refused to issue a challenge because proven chain state was unavailable — fail closed; retry, never work around. ## Deploying Before you deploy: * **Identity is deployment configuration** — origin, verifier identity and request key — bound to your on-chain registrations and never accepted from HTTP callers. * **Challenge signing is your key custody.** The service signs challenges with a request signer you provide, backed by hardware-protected keys. * The bundled runner is a reference server for integration; in production, front it with your own web tier. * The service holds no state of its own: durability lives in the replay store and the decision log you configure. artifact [verifier-service.v1.yaml](/openapi/verifier-service.v1.yaml) format OpenAPI 3.1 · contract 1.1.0 status frozen — published verbatim ## Trust boundaries, restated Your service instance is part of _your_ verifier. Deploy it inside your perimeter and point your transport clients at it, never at anyone else’s: the acceptance decision is your obligation as a registered verifier, and handing the service to someone else hands them that decision. [previous← python sdk](/en/sdk/python)[nexttypescript client →](/en/sdk/typescript-client) --- Source: https://mintid.net/en/sdk/service-mode · Service mode & the OpenAPI contract · MintID SDK docs --- > @mintid-net/verifier-client carries requests from a Node backend to your own verifier service, where every check runs, so the client has nothing to weaken. index — 17 documents 1. [overviewsdk/00](/en/sdk) 2. [getting startedsdk/01](/en/sdk/getting-started) 3. [python sdksdk/02](/en/sdk/python) 4. [service modesdk/03](/en/sdk/service-mode) 5. [typescript clientsdk/04](/en/sdk/typescript-client) * [install channel today](#install) * [quickstart](#quickstart) * [error semantics](#error-semantics) * [types](#types) * [conformance](#conformance) * [framework bridges](#framework-bridges) 6. [mcp serversdk/04a](/en/sdk/mcp-server) 7. [conformancesdk/05](/en/sdk/conformance) 8. [reason codessdk/06](/en/sdk/reason-codes) 9. [substrate readssdk/07](/en/sdk/substrate-reads) 10. [credentials & holderssdk/08](/en/sdk/credentials-and-holders) 11. [payment identitysdk/09](/en/sdk/payment-identity-profile) 12. [becoming a verifiersdk/10](/en/sdk/becoming-a-verifier) 13. [protocol statesdk/11](/en/sdk/protocol-state) 14. [record · assurance vocabularyrecord/01](/en/sdk/kyc-trust-model) 15. [record · packagingrecord/02](/en/sdk/packaging) 16. [record · multi-languagerecord/03](/en/sdk/multi-language-clients) 17. [record · service contractrecord/04](/en/sdk/verifier-service-contract) SDK docs · sdk/04 # TypeScript client @mintid-net/verifier-client carries requests from a Node backend to your own verifier service, where every check runs, so the client has nothing to weaken. ## Install channel today **Install channel today.** Not yet on npm: build it from the main project, [https://gitlab.com/mintid/mintid](https://gitlab.com/mintid/mintid) (`sdk/typescript/`), or from its read-only mirror, [https://gitlab.com/mintid/sdk-typescript](https://gitlab.com/mintid/sdk-typescript), and install the tarball next to the service it talks to. `npm install @mintid-net/verifier-client` becomes the path once the package is published; see [protocol state](/en/sdk/protocol-state). **Where to point it while you integrate.** At your own service on the local stack, or at the sandbox verifier of [the public testnet](/en/developers) (`https://verifier.testnet.mintid.net`; check its status first), whose decisions carry no weight. Never at the services of the single-node production chain: production is not for third parties. bashsdk/04 · install channel today ``` cd sdk/typescript && npm install && npm run build && npm pack npm install /path/to/mintid-verifier-client-.tgz # in your backend ``` ## Quickstart Before this code runs, your agency must be a registered, active verifier with its exact origin and request key on chain (see Getting started). The client is an ES module for **Node backends**, with type definitions and no runtime dependencies; it carries requests to the verifier service **your agency deploys**, and that service holds the cryptography, the chain access, the nonce store and the policy. A change that looks like a verification feature belongs in the service. **Node-only, on purpose.** Challenges are bound to your registered verifier identity and signed with your request keys; the decision gates your business logic. That is server-side material — a browser build will not be provided. typescriptsdk/04 · contract example ``` import { VerifierClient } from "@mintid-net/verifier-client"; // Your own service instance — never a third party's. const client = new VerifierClient("https://verifier.internal.example"); // 1. Issue a challenge (policy only — expiry is always +10 s, server-side). const challenge = await client.createChallenge({ claim_policy: [{ claim: "age", value: 18, operator: ">=" }], }); // → forward challenge.request + challenge.signature_hex to the holder. // 2. Validate the holder's response. const decision = await client.validatePresentation({ request: challenge.request, envelope: holderResponse, // { proof_hex, issuer_id, status_root, claimed_predicates } }); if (decision.accepted) { decision.verified?.proven_predicates; // e.g. ["age"] } else { decision.reason_code; // closed vocabulary, e.g. "nonce_replayed" } ``` ## Error semantics (the part people get wrong) **A rejection is a resolved decision, not an exception.** The client throws only for transport-level events: Transport error When What to do HTTP 400 · `malformed_body` the body cannot be parsed into the contract schema fix the caller; this is a programming error HTTP 503 · `state_unavailable` the service failed closed on unproven chain state retry later; never skip the check anything else network failure, a non-JSON body, an undocumented status treat as an outage Everything else — replayed nonces, expired presentations, unbound proofs, suspended issuers — arrives as `{ accepted: false, reason_code }` with HTTP 200. Branch on the decision data. ## Types Wire types mirror the contract one to one (`PresentationRequestBody`, `PresentationEnvelope`, `PresentationDecision`, `BuildInfo`, …), and the reason-code vocabulary is exported as a constant with its matching `ReasonCode` type. The vocabulary is test-locked against the shared conformance suite: a reason code cannot be added, renamed or dropped anywhere in the system without every language shipping the change together. ## Conformance The client’s test suite replays the entire cross-language vector suite over real HTTP against the reference service and asserts byte-equal decisions. A client release declares the suite version it passed — that declaration is its compatibility contract. ## Framework bridges Framework adapters are deliberately kept out of this package; if they come, they ship as separate optional packages, so the core client stays dependency-free and auditable at a glance. Clients in further languages follow integrator demand. [previous← service mode](/en/sdk/service-mode)[nextmcp server →](/en/sdk/mcp-server) --- Source: https://mintid.net/en/sdk/typescript-client · TypeScript client · MintID SDK docs --- > Two artifacts declaring the same contract major and suite version decide identically; the CI suite, semver rules and release pins below make that true. index — 17 documents 1. [overviewsdk/00](/en/sdk) 2. [getting startedsdk/01](/en/sdk/getting-started) 3. [python sdksdk/02](/en/sdk/python) 4. [service modesdk/03](/en/sdk/service-mode) 5. [typescript clientsdk/04](/en/sdk/typescript-client) 6. [mcp serversdk/04a](/en/sdk/mcp-server) 7. [conformancesdk/05](/en/sdk/conformance) * [the conformance suite](#suite) * [version numbers](#versioning) * [release pins](#release-pins) * [decision equivalence](#equivalence) 8. [reason codessdk/06](/en/sdk/reason-codes) 9. [substrate readssdk/07](/en/sdk/substrate-reads) 10. [credentials & holderssdk/08](/en/sdk/credentials-and-holders) 11. [payment identitysdk/09](/en/sdk/payment-identity-profile) 12. [becoming a verifiersdk/10](/en/sdk/becoming-a-verifier) 13. [protocol statesdk/11](/en/sdk/protocol-state) 14. [record · assurance vocabularyrecord/01](/en/sdk/kyc-trust-model) 15. [record · packagingrecord/02](/en/sdk/packaging) 16. [record · multi-languagerecord/03](/en/sdk/multi-language-clients) 17. [record · service contractrecord/04](/en/sdk/verifier-service-contract) SDK docs · sdk/05 # Conformance & versioning Two artifacts declaring the same contract major and suite version decide identically; the CI suite, semver rules and release pins below make that true. ## The cross-language conformance suite CI enforces "every SDK behaves identically": a release that fails the cross-language suite does not ship. The suite is a committed set of JSON vectors derived deterministically from the reference implementation, each holding a canonical challenge, a holder envelope, a declarative description of the proven on-chain state ("world") and the frozen expected decision. Coverage is total by construction and CI-asserted: * one accepted case (plus policy-nuance positives), * at least one rejection for **each of the nine acceptance conditions**, * every producible reason code in the vocabulary. Every SDK must pass the suite before release: * the **Python SDK** replays every vector through the library _and_ through the service HTTP surface; * the **TypeScript client** replays every vector through real HTTP against the reference service running with test doubles; * the committed vectors are **byte-compared against regeneration** on every CI run — the suite cannot drift from the reference implementation silently. A release declares the suite version it passed (also readable at runtime via `build_info().conformance_suite_version`). ## Version numbers and what they promise Everything follows semver with one shared rule: **decision semantics are major**. Artifact Major means Minor means `mintid-verifier-sdk` (Python) public surface or accepted-behavior change additive surface OpenAPI contract `verifier-service.v1` decision semantics or reason-vocabulary change additive wire surface Conformance suite a change to any case’s expected decision new cases `@mintid-net/verifier-client` tracks the contract major — ## Release pins (what an artifact tells you about itself) Every SDK artifact records, programmatically readable: * **`engine_pin`** — the exact proof engine compiled into the package, and the fact about a build that no release note can override: two deployments that disagree on this string are not interchangeable, and a non-verifying build can never masquerade as a verifying one. Read it from the instance you integrate against, not from a page. * **`state_vectors_version`** and `state_vectors_sha256` — the chain store-layout vectors this build was release-gated against; a mismatch with the target chain blocks the release outright. * Engine pin bumps are reviewed release changes — never automatic, not overridable by dependency resolution, not substitutable through any supported install path. jsonsdk/05 · build-info shape ``` { "sdk_version": "…", "engine_pin": "proof-core …", "state_vectors_version": "…", "state_vectors_sha256": "…", "spec_revision": "…", "conformance_suite_version": "…" } ``` ## What this buys you as an integrator You can treat any two artifacts declaring the same contract major and the same suite version as **decision-equivalent**: same inputs, same accept/reject, same reason code, in any language. CI re-proves that equivalence on every change. [previous← mcp server](/en/sdk/mcp-server)[nextreason codes →](/en/sdk/reason-codes) --- Source: https://mintid.net/en/sdk/conformance · Conformance & versioning · MintID SDK docs --- > Sixteen codes explain every accept and reject, byte-identical in the Python SDK, the HTTP contract and every client, and fixed within a contract major. index — 17 documents 1. [overviewsdk/00](/en/sdk) 2. [getting startedsdk/01](/en/sdk/getting-started) 3. [python sdksdk/02](/en/sdk/python) 4. [service modesdk/03](/en/sdk/service-mode) 5. [typescript clientsdk/04](/en/sdk/typescript-client) 6. [mcp serversdk/04a](/en/sdk/mcp-server) 7. [conformancesdk/05](/en/sdk/conformance) 8. [reason codessdk/06](/en/sdk/reason-codes) * [producible codes](#producible) * [reserved codes](#reserved) 9. [substrate readssdk/07](/en/sdk/substrate-reads) 10. [credentials & holderssdk/08](/en/sdk/credentials-and-holders) 11. [payment identitysdk/09](/en/sdk/payment-identity-profile) 12. [becoming a verifiersdk/10](/en/sdk/becoming-a-verifier) 13. [protocol statesdk/11](/en/sdk/protocol-state) 14. [record · assurance vocabularyrecord/01](/en/sdk/kyc-trust-model) 15. [record · packagingrecord/02](/en/sdk/packaging) 16. [record · multi-languagerecord/03](/en/sdk/multi-language-clients) 17. [record · service contractrecord/04](/en/sdk/verifier-service-contract) SDK docs · sdk/06 # Reason codes Sixteen codes explain every accept and reject, byte-identical in the Python SDK, the HTTP contract and every client, and fixed within a contract major. ## Producible codes Every decision carries exactly one of these codes. Changing the list is a major contract version that reaches every language at once, so within a contract major your `switch` never meets a code it does not know. Code Condition Meaning Typical handling `accepted` — all nine conditions passed; verified is present proceed `request_malformed` precondition the challenge body violates the signed-challenge shape (e.g. empty claim policy) fix challenge construction `verifier_not_active` 1 your verifier registration is not ACTIVE on proven state check your registry state `origin_not_registered` 1 the origin does not resolve to your verifier (no trust-by-name) register/renew the exact origin `revalidation_expired` 1 domain-control proof for the origin lapsed renew the origin registration `request_key_not_active` 2 the challenge's signing key is unregistered or rotated out rotate/register keys properly `nonce_replayed` 3 this challenge's nonce was already consumed issue a fresh challenge; investigate replays `deadline_exceeded` 4 the response arrived at or after the 10-second deadline issue a fresh challenge `proof_invalid` 5 the proof failed verification or is bound to a different challenge context reject; possible tampering `predicate_missing` 6 a requested predicate is not among the proven ones reject; holder cannot satisfy policy `issuer_not_accepted` 7 the credential's issuer is outside your accepted-issuer policy policy decision — yours `issuer_not_active` 7 the issuer is not operational (or below your state minimum) reject; retry later is legitimate `status_root_stale` 7 proof built against a root that is no longer acceptable (superseded and outside its validity window), or a root that has expired (fail closed) holder retries with a fresh proof `height_stale` 8 the challenge's chain height fell outside \[latest − max\_height\_lag, latest\] issue a fresh challenge `state_unproven` 1/8 a chain read could not be cryptographically proven — including claimed absence infrastructure alert; never skip the check `nonce_race_lost` 9 a concurrent presentation consumed the nonce first (atomic accept gate) reject; exactly one winner exists Notes: * **Issuer-state policy nuance (condition 7):** with the default `issuer_state_minimum: "ACTIVE"`, an issuer under enhanced monitoring rejects as `issuer_not_active`; opting into `"ENHANCED_MONITORING"` accepts it. This is the only policy knob in the vocabulary's behavior, and it is _your_ policy, expressed in the challenge. * **`state_unproven` is your pager, not your bug.** It means the SDK refused to decide on unproven state — a node lying, a proof failing, an anchor unreachable. The correct response is operational, never a retry-until-accept loop. ## Reserved codes Present in the contract enum for defence in depth; structurally unreachable through the validation entrypoint — do not wait for them: Code Why it cannot occur `origin_invalid` a non-exact origin already fails the shape precondition and rejects as `request_malformed` `domain_validation_failed` a generic reason; a more specific code is always returned instead [previous← conformance](/en/sdk/conformance)[nextsubstrate reads →](/en/sdk/substrate-reads) --- Source: https://mintid.net/en/sdk/reason-codes · Reason codes · MintID SDK docs --- > Plain-language definitions: Know Your Agent (KYA), agent KYC, zero-knowledge presentations, reusable KYC, holder binding, x402, Web Bot Auth and the roles in the MintID protocol. Glossary # What the words on this site mean, and why each one exists The terms the protocol uses, defined the way it uses them. Each entry is self-contained — what the term means, why it exists and how MintID implements it — and every definition has its own anchor. [§](#know-your-agent)Know Your Agent (KYA) Know Your Agent (KYA) is the market’s name for the practice of verifying that an autonomous AI agent is operated by a known, accountable party — the agent-era counterpart to Know Your Customer (KYC). A know-your-agent check answers one question before an agent is allowed to transact: if this agent causes harm, is there a real, liable human or organisation behind it? MintID’s answer is verifiable human-backed agent identity: zero-knowledge credentials that make the answer provable without revealing who that human is. [§](#agent-kyc)Agent KYC Agent KYC is how MintID delivers verifiable human-backed agent identity, the capability the market calls Know Your Agent: an AI agent carries a credential derived from its operator’s real KYC, issued by an accepted issuer, and proves with a zero-knowledge presentation that an accountable, KYC-verified human backs it, without disclosing the human’s identity. It is defined in MintID’s agent-identity specification and runs on the same rail as human credentials, adding nothing new to the chain. [§](#zero-knowledge-kya)Verifiable human-backed agent identity · zero-knowledge agent identity Verifiable human-backed agent identity — what the market calls privacy-preserving know your agent — is agent verification where the counterparty learns exactly one bit — "this agent is backed by an accountable, KYC-verified principal" — and nothing else: no name, no passport, no persistent handle that tracks the operator across services. It resolves the accountability-versus-privacy binary that plaintext agent registries and transferable agent NFTs cannot: accountability exists, surveillance does not. [§](#zero-knowledge-presentation)Zero-knowledge presentation A zero-knowledge presentation is a cryptographic proof, generated by a credential holder, that convinces a verifier a claim is true (over 18, valid credential, agent backed by a verified human) without revealing the underlying data or creating a linkable identifier. In MintID, presentations are bound to the verifier’s challenge, expire after ten seconds, and are never logged on-chain. [§](#reusable-kyc)Reusable KYC Reusable KYC means completing identity verification once, with an accepted issuer, and then proving facts from it anywhere, any number of times, without repeating the check or re-exposing documents. One verification backs many proofs — and, through agent credentials, many agents. It replaces the per-service KYC cycle, where every counterparty re-collects and re-stores the same passports and selfies. [§](#verifiable-credential)Verifiable credential A verifiable credential is a digitally signed attestation — an issuer vouching that facts about a subject are true — that third parties can check cryptographically without contacting the issuer. In MintID, credentials live with the holder (never on-chain), and what circulates are zero-knowledge presentations derived from them. [§](#anonymous-credential)Anonymous credential An anonymous credential is a verifiable credential designed so that using it does not identify the holder: each presentation is unlinkable to previous ones and to the issuance event. The verifier learns the proven claim and nothing else. MintID uses anonymous credentials in the Hyperledger AnonCreds lineage — blinded issuer signatures, a holder secret, selective disclosure and predicate proofs — with the exact construction frozen. It is the primitive that lets accountability and privacy coexist. [§](#selective-disclosure)Selective disclosure Selective disclosure is revealing only the specific attributes a transaction needs — an age bound, an assurance grade, a spending limit — while keeping every other attribute of the credential hidden. MintID applies it to authorisation too: an agent’s scope is proven axis by axis, so a merchant learns the limit that matters, not the whole mandate. [§](#holder-binding)Holder binding Holder binding is the cryptographic link between a credential and the only key that can use it. The holder keeps that private key; issuers cannot use the credential on the holder’s behalf, and a stolen credential file is useless without the key. In MintID, an agent credential is derived from its principal’s credential at mint, but the only link between the two lives in the issuer’s private accountability escrow — nothing public connects them. [§](#issuer)Issuer An issuer is an accepted KYC organisation that verifies people once, off-chain, and then issues reusable credentials to them. MintID issuers publish signed status roots, lock a slashable bond that is cut for proven fraud or negligence, and never see where holders later present their credentials. The chain records issuer approvals and status roots, never the KYC files. [§](#verifier)Verifier A verifier is any service — an exchange, a marketplace, an API, a merchant checkout — that requests a zero-knowledge presentation before acting. MintID verifiers are themselves KYC-approved and registered on-chain for exact web origins. They check a ten-second proof against current chain state, keep a minimal decision record, and never receive, store or forward personal data. Integration is through the MintID verifier SDKs. [§](#validator)Validator A validator is a node operator that runs consensus (CometBFT) and, on the public proof-of-stake network MintID is designed to scale to, stakes to secure it; today the single-node production chain, in production since 20 September 2026, has one validator, operated by the CONECTIA group. Validators order transactions and check cryptographic evidence — signatures, bonds, status roots. They never process passports, biometrics or KYC files, because none of that ever touches the chain. [§](#status-root)Status root A status root is a small, signed cryptographic commitment that an issuer publishes on-chain at least every 30 seconds, summarising the validity state of every credential it has issued — without listing them. A verifier treats a root older than the maximum root age (45 seconds is the reference value; the single-node production chain uses 180 seconds) as stale and fails closed. A presentation proves membership of the current root in zero knowledge, so revocation works (including holder self-revocation) while the chain learns nothing about individual credentials. [§](#assurance-grade)Assurance grade (A1–A4) · assurance tier, level of assurance An assurance grade is MintID’s four-level measure of how robust an identity verification was, mapped onto the published frameworks rather than invented: A1, a validated identity document (eIDAS low, ISO/IEC 29115 LoA 2, NIST IAL1); A2, plus possession proven by biometric liveness (eIDAS substantial, LoA 3, ETSI TS 119 461 Baseline, IAL2); A3, plus sanctions, PEP and adverse-media screening (enhanced due diligence); A4, plus qualified proofing such as a high-assurance eID or the EU Digital Identity Wallet (eIDAS high, LoA 4, ETSI Extended, IAL3). For companies the same grades cover the registered entity, a verified representative and screened beneficial owners. A grade measures strength, never age: the credential carries it as a private claim, and a verifier receives only a threshold proof such as “grade ≥ A3”. [§](#freshness-band)Freshness band (F1–F4) · recency band A freshness band is the issuer-held band (F1–F4) saying how recently a holder’s evidence was verified: a second dimension next to the grade, published as a band — F4 under 30 days, F3 under 90, F2 under 180, F1 under a year — and never as a date, so that observers cannot correlate records by timestamp. It is read on the classical seller rail, not a presentation predicate: a presentation proves the grade threshold. Bands are independent of grades (a strong grade can be old, a weak one fresh); for ZadQ, the first product built on MintID, “human-backed” means 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. Each grade also has a default validity (twelve months for A1–A2, six for A3, three for A4) inside the EU anti-money-laundering update periods; the credential expires exactly when the verification behind it does, with no grace period — expiry, not revocation. [§](#compliance-council)Compliance council The compliance council is MintID’s designed operational body, built on chain and not yet seated: a threshold vote, recommended at five of nine members, that would admit, suspend and revoke issuers and verifiers, adjudicate issuer bonds and co-sign protected treasury actions. It is constituted as an organ of the MintID Foundation before any white paper is signed; until it is seated, admissions are governance proposals voted by the chain’s single validator. It never changes software or protocol parameters, which belong to token-weighted, on-chain governance on a public network, and on a due-process identity reveal it reviews only after the fact. [§](#money-before-identity)Money-before-identity cascade The money-before-identity cascade is how MintID’s dispute rail would settle harm caused by an agent: first the escrow pays the claimant, with no identity revealed; then, if fraud is found, a minimal banded fraud signal is shared; and only under due process — when an arbiter certifies that a court is warranted — is the human behind the agent identified. No payment ever buys that last step. The capital is the principal’s own USDC or EURC, locked in a contract the principal controls on the chain where the stablecoin lives (Base in the current deployment variant). MintID runs no general smart-contract VM: it keeps the reservation state and checks a proof of the lock. Specified, scheduled; not built. Audits have not started, and no funds are locked today. [§](#anchor-product)Anchor product (ZadQ) The anchor product is ZadQ, an x402 seller-verification service and the first product built on MintID. The CONECTIA group operates it, a disclosed related-party position; it runs as a pilot on the single-node production chain, which is not yet the distributed network, and nothing measured there counts as independent adoption or toward the distributed network’s launch criteria. [§](#x402)x402 x402 is an open payment protocol that puts the dormant HTTP 402 "Payment Required" status to work: a server quotes a price in the 402 response, the client pays (typically in stablecoins, wallet to wallet), and retries with proof of payment. Now maintained under the Linux Foundation, it is a settlement rail of the emerging pay-per-use agentic web, and it prices requests without identifying anyone — the gap that products built on MintID address, first for sellers through ZadQ and then for buying agents. [§](#mcp)Model Context Protocol (MCP) The Model Context Protocol (MCP) is an open protocol by which an AI agent discovers and calls external capabilities as "tools" — a uniform listing-and-invocation surface that agent frameworks speak natively. It is becoming the consumption unit of the agentic web, which is why identity verification has to be reachable as a tool: MintID provides an MCP server that exposes the operations of its verifier-service contract, run inside the verifier’s own perimeter against the verifier’s own service. [§](#web-bot-auth)Web Bot Auth Web Bot Auth is an IETF Internet-Draft (built on HTTP Message Signatures, RFC 9421) by which a bot or agent cryptographically signs its requests so origins can verify which operator is calling. It authenticates the agent’s software identity — which platform or crawler is calling. It does not, by itself, say anything about the accountability of the principal behind an autonomous agent; that is the layer MintID’s human-backed agent credentials add. ## See the vocabulary at work Agent KYC is where these ideas meet in the protocol: how an AI agent proves an accountable human stands behind it, in zero knowledge, without revealing who. [Agent KYC, explained](/en/agent-kyc)[What is Know Your Agent?](/en/blog/what-is-know-your-agent) --- Source: https://mintid.net/en/glossary · Glossary — Know Your Agent (KYA) & zero-knowledge identity terms — MintID --- > Accepted in August 2026: grades A1–A4 are MintID’s own contract, anchored on eIDAS and squared with ISO/IEC 29115; recency is a separate freshness band. index — 17 documents 1. [overviewsdk/00](/en/sdk) 2. [getting startedsdk/01](/en/sdk/getting-started) 3. [python sdksdk/02](/en/sdk/python) 4. [service modesdk/03](/en/sdk/service-mode) 5. [typescript clientsdk/04](/en/sdk/typescript-client) 6. [mcp serversdk/04a](/en/sdk/mcp-server) 7. [conformancesdk/05](/en/sdk/conformance) 8. [reason codessdk/06](/en/sdk/reason-codes) 9. [substrate readssdk/07](/en/sdk/substrate-reads) 10. [credentials & holderssdk/08](/en/sdk/credentials-and-holders) 11. [payment identitysdk/09](/en/sdk/payment-identity-profile) 12. [becoming a verifiersdk/10](/en/sdk/becoming-a-verifier) 13. [protocol statesdk/11](/en/sdk/protocol-state) 14. [record · assurance vocabularyrecord/01](/en/sdk/kyc-trust-model) * [context](#context) * [the two options](#options) * [decision: the hybrid](#decision) * [consequences](#consequences) 15. [record · packagingrecord/02](/en/sdk/packaging) 16. [record · multi-languagerecord/03](/en/sdk/multi-language-clients) 17. [record · service contractrecord/04](/en/sdk/verifier-service-contract) SDK docs · record/01 # Decision record — assurance vocabulary Accepted in August 2026: grades A1–A4 are MintID’s own contract, anchored on eIDAS and squared with ISO/IEC 29115; recency is a separate freshness band. ## Context _Status: **Accepted** (August 2026) · first recorded in July 2026 as an open decision · depends on the specification’s assurance-grade and issuer-conduct rules · Updated 2026-10-04: freshness, validity and provider wording._ Issuers turn authenticated identity checks into one assurance grade, A1 to A4, and the protocol has to state, normatively, _which evidence suffices for which grade_. Two issuers grading the same evidence differently — or one grading A3 on evidence the ecosystem would call basic — would undermine exactly the trust the grades exist to carry. The choice shapes conformance testing, issuer onboarding and how regulators read a MintID grade. It does not touch chain state or consensus, which is why it could stay open while the provider-neutral KYC interface was being built. ## The two options ### Option A — a bespoke MintID vocabulary MintID defines its own evidence requirements: for each grade, the required check types, evidence classes and review cadence, versioned with the protocol. * **Pros:** full control over the semantics; an exact fit for four grades; no dependence on an external body’s revision cycle; conformance tests derived directly from our own text. * **Cons:** the authoring and maintenance burden is ours; every provider and issuer maps onto _our_ vocabulary without ecosystem tooling; regulators and partner institutions must be taught what a MintID grade means; audit defensibility rests on our own documentation alone. ### Option B — adopt an external framework wholesale A1–A4 are defined purely as mappings onto an established framework — candidates included OpenID Connect for Identity Assurance, the eIDAS levels (low, substantial, high) and NIST SP 800-63 (IAL1–3). * **Pros:** regulator and institutional legibility for free; providers already describe their checks in these vocabularies; external audit can lean on established criteria; less text to maintain. * **Cons:** none of these frameworks has four levels, so any mapping onto A1–A4 is partial; revisions happen outside our control; each framework carries a jurisdictional flavour; and some assumptions — such as verifier-side attribute visibility — do not fit a credential presented in zero knowledge. A: bespoke B: external framework Fit to four grades exact partial (three-level frameworks) Regulator and partner legibility must be built largely inherited Provider-mapping effort higher (our vocabulary) lower (their native vocabulary) Revision control ours an external body’s Jurisdiction neutrality yes flavoured by the chosen framework Maintenance burden authoring tracking plus glue A hybrid — MintID’s own four-grade contract, anchored on external levels — was recorded at the time as a variant of A. It is where the decision landed. ## Decision: the hybrid MintID keeps its own four-grade contract — grades are decided by the issuer from enumerated, authenticated checks, within the grades its admission permits — and **anchors the grades on the eIDAS assurance levels, squared with ISO/IEC 29115**. The grade meanings are unchanged; the external columns are mappings, not redefinitions. Grade eIDAS ISO/IEC 29115 NIST SP 800-63 AML posture A1 low LoA2 IAL1 customer due diligence A2 substantial LoA3 IAL2 due diligence with biometric liveness (ETSI TS 119 461 baseline proofing) A3 substantial + enhanced due diligence LoA3⁺ IAL2 + EDD screening: sanctions, PEP, adverse media A4 high LoA4 IAL3 qualified identity proofing (ETSI extended proofing, a notified eID at high, the EU Digital Identity Wallet) **Freshness is a second dimension, not a grade.** The issuer holds a freshness band — F4 under 30 days, F3 under 90, F2 under 180, F1 under 365 — published as a band and never as a date, so that it cannot become a linkable timestamp. **Why.** eIDAS is what Europe’s regulators, the EU Digital Identity Wallet and qualified trust-service proofing use first, and the EU AML Regulation points to it; ISO/IEC 29115 supplies the four-level backbone; and every framework reviewed tiers identity proofing by _strength_, while none attaches a validity period to a level — which is why validity moved out of the grade. The grade measures how strong the proofing was; validity is set per grade (12 months for A1 and A2, 6 for A3, 3 for A4), and a credential expires exactly when the verification behind it does. The first issuer implementation informed the choice, and the provider-neutral KYC interface did not change. ## Consequences The issuer-side KYC policy that applies the grades — requirements per type of operator (person or organisation), evidence reuse within the AML envelope, a credential that expires with the verification behind it, with no grace period, rather than being revoked, and consent withdrawal revoking everything it backed — is implemented behind the provider-neutral interface, with a real identity-verification provider behind it. For verifiers nothing changes on the wire. 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. [previous← protocol state](/en/sdk/protocol-state)[nextrecord · packaging →](/en/sdk/packaging) --- Source: https://mintid.net/en/sdk/kyc-trust-model · Decision record — assurance vocabulary · MintID SDK docs --- > Accepted: the verifier SDK ships as versioned platform packages with the proof engine compiled in, so no normal install brings a swapped or drifted engine. index — 17 documents 1. [overviewsdk/00](/en/sdk) 2. [getting startedsdk/01](/en/sdk/getting-started) 3. [python sdksdk/02](/en/sdk/python) 4. [service modesdk/03](/en/sdk/service-mode) 5. [typescript clientsdk/04](/en/sdk/typescript-client) 6. [mcp serversdk/04a](/en/sdk/mcp-server) 7. [conformancesdk/05](/en/sdk/conformance) 8. [reason codessdk/06](/en/sdk/reason-codes) 9. [substrate readssdk/07](/en/sdk/substrate-reads) 10. [credentials & holderssdk/08](/en/sdk/credentials-and-holders) 11. [payment identitysdk/09](/en/sdk/payment-identity-profile) 12. [becoming a verifiersdk/10](/en/sdk/becoming-a-verifier) 13. [protocol statesdk/11](/en/sdk/protocol-state) 14. [record · assurance vocabularyrecord/01](/en/sdk/kyc-trust-model) 15. [record · packagingrecord/02](/en/sdk/packaging) * [context](#context) * [options considered](#options) * [decision & versioning](#decision) * [consequences](#consequences) 16. [record · multi-languagerecord/03](/en/sdk/multi-language-clients) 17. [record · service contractrecord/04](/en/sdk/verifier-service-contract) SDK docs · record/02 # Decision record — SDK packaging Accepted: the verifier SDK ships as versioned platform packages with the proof engine compiled in, so no normal install brings a swapped or drifted engine. ## Context _Status: **Accepted** (2026-07-21) · recorded 2026-07-19 · depends on the specification’s paid-verification permission and its trust-boundary rules_ The verifier SDK is a Python package whose correctness depends on a specific release of the Rust proof engine and on byte-for-byte agreement with the chain’s state layout, checked by a published vector suite. An integrator must receive all of that as **one verifiable unit**: a mismatched engine or a stale state-layout assumption is a security defect, so the distribution form had to be settled before the first external integrator existed. Three constraints of the specification frame the choice: verification may also be offered as a paid off-chain service, so packaging must make both embedded and service consumption practical; no interface is trusted merely for returning well-formed data, so the cryptographic checks must not be silently substitutable; and proof verification lives in the pinned Rust engine while Python orchestrates — packaging must preserve the pin. ## Options considered ### Option A — versioned Python package with the engine compiled in (accepted) Publish `mintid-verifier-sdk` as platform wheels, with the Rust engine compiled in as a native extension at a version fixed at build time and recorded in package metadata. * **Pros:** one artifact, one version; standard `pip install` experience; the engine pin is decided at release time and not overridable by dependency resolution; platform wheels make the Rust toolchain invisible to integrators. * **Cons:** we own a per-platform build matrix and release engineering before the first integrator; source builds still need the Rust toolchain as a fallback. ### Option B — git dependency at a tag Zero release infrastructure and always buildable from source — but every integrator needs the Rust toolchain, the engine pin lives in build configuration where an integrator can patch it, and repository access is a bad long-term distribution channel with no artifact-level integrity story. Retained only as the interim channel for integrators until the package-index release exists. ### Option C — vendored source drop (rejected) Works in locked-down environments, but has the worst upgrade path, makes pin substitution trivial, and duplicates the build burden onto every integrator. A: wheels B: git tag C: vendored Engine pin enforceable **yes (built-in)** weak no Integrator toolchain burden none Rust + ours Rust + ours Upgrade path semver via pip re-pin tag manual Works for paid-verification service operators yes yes awkward ## Decision & versioning policy **Accepted: Option A**, with B as the interim channel for integrators until the package-index release exists. Versioning under Option A: * Semver on the SDK package: **major** for any change to the public surface or to accepted-behavior semantics; **minor** for additive surface; **patch** otherwise. * Package metadata records the engine release, the state-layout vector version and the specification revision built against. A release is blocked if the state-layout vectors fail against the target chain version. ## Consequences Option A commits us to a wheel-building pipeline and a release checklist — an engine pin bump is a reviewed change, never automatic. In exchange, integrators cannot end up running an unpinned or substituted proof engine through normal installation paths: substituting one becomes a deliberate, visible act outside the supported channel, which is exactly the posture the specification’s trust-boundary rules ask for. [previous← record · assurance vocabulary](/en/sdk/kyc-trust-model)[nextrecord · multi-language →](/en/sdk/multi-language-clients) --- Source: https://mintid.net/en/sdk/packaging · Decision record — SDK packaging · MintID SDK docs --- > Accepted: one verifying core, in Python or as your own service behind a frozen OpenAPI contract; other languages get thin clients, never a rewrite. index — 17 documents 1. [overviewsdk/00](/en/sdk) 2. [getting startedsdk/01](/en/sdk/getting-started) 3. [python sdksdk/02](/en/sdk/python) 4. [service modesdk/03](/en/sdk/service-mode) 5. [typescript clientsdk/04](/en/sdk/typescript-client) 6. [mcp serversdk/04a](/en/sdk/mcp-server) 7. [conformancesdk/05](/en/sdk/conformance) 8. [reason codessdk/06](/en/sdk/reason-codes) 9. [substrate readssdk/07](/en/sdk/substrate-reads) 10. [credentials & holderssdk/08](/en/sdk/credentials-and-holders) 11. [payment identitysdk/09](/en/sdk/payment-identity-profile) 12. [becoming a verifiersdk/10](/en/sdk/becoming-a-verifier) 13. [protocol statesdk/11](/en/sdk/protocol-state) 14. [record · assurance vocabularyrecord/01](/en/sdk/kyc-trust-model) 15. [record · packagingrecord/02](/en/sdk/packaging) 16. [record · multi-languagerecord/03](/en/sdk/multi-language-clients) * [context](#context) * [options considered](#options) * [decision & mechanics](#decision) * [consequences](#consequences) 17. [record · service contractrecord/04](/en/sdk/verifier-service-contract) SDK docs · record/03 # Decision record — one core, thin clients Accepted: one verifying core, in Python or as your own service behind a frozen OpenAPI contract; other languages get thin clients, never a rewrite. ## Context _Status: **Accepted** (2026-07-20) · depends on the specification’s verifier obligations, presentation rules, decision records, paid-verification permission, single-core rule and trust boundaries · Updated 2026-10-04: audit wording._ The Python surface of the verifier SDK is fixed (one entrypoint, five infrastructure ports) and its packaging is decided (see the [packaging record](/en/sdk/packaging): platform packages with the Rust engine compiled in). But many verifier agencies build their backends outside Python, and TypeScript/Node and PHP are common in web-facing agency stacks; nothing yet said what a TypeScript or PHP "MintID SDK" _is_. The dangerous default is that each becomes a port of the validation entrypoint: three implementations of the nine acceptance conditions, three state-proof verifiers, three places for the engine release to drift. The value of the SDK is the verified core; the languages are reach. ## Options considered ### Option A — one verified core; transport-only clients (accepted) Python remains the only embedded SDK. Service mode is promoted from "a thin wrapper someone can deploy" to a first-class product: a **versioned OpenAPI contract**, a first-party deployable the agency runs next to its backend, and per-language clients that issue challenges and delegate every decision to the agency's own instance. ### Option B — native bindings of the Rust core per language True in-process verification everywhere and best latency — but it requires migrating the nine-condition orchestration from Python to Rust first, a large refactor of code that is implemented, tested and in production, and it triples the prebuilt-binary matrix. Nothing today demonstrates demand that justifies it. It re-enters only on demonstrated integrator need, through its own design record. ### Option C — idiomatic reimplementation per language (rejected permanently) The "native SDK" each ecosystem superficially expects — and three audit surfaces that drift independently. Every new implementation of consensus-relevant cryptography becomes an audit item, a scheduled milestone whose findings are published, and this option adds two of them. The trust-boundary rule becomes a promise instead of a property, and a bug fixed in one binding survives in the others. A: thin clients B: native bindings C: reimplementation Crypto implementations **1** 1 (after Rust migration) 3 Audit surface added none foreign-function bridge ×2 full pipeline ×2 In-process latency Python only all all Fourth language later trivial binding + binaries full port ## Decision & mechanics **Accepted (2026-07-20): Option A now; Option B only as a demand-gated future path; Option C rejected permanently.** The mechanics: * **The OpenAPI contract is the product.** Versioned under the SDK’s semver policy — major on any change to decision semantics or the reason-code vocabulary — and frozen before the first client ships (see the [verifier service contract](/en/sdk/verifier-service-contract) record). * **One cross-language conformance-vector suite**, derived from the Python reference and run in CI by every SDK. * **Clients carry no invariants to weaken:** no lifetime parameter, no skip flags, no local nonce store, no presentation persistence. * **Server-side only:** challenge issuance and request keys never reach a browser. * **Verifier obligations first in every quickstart:** on-chain registration, verifier KYC and exact-origin control appear before the first code sample. * **Idiomatic packaging** in each language — for TypeScript, an ES module with type definitions — with framework bridges as separate optional packages, never in the core client. Development order: ① the Python embedded SDK (the reference the vectors derive from); ② the OpenAPI contract, the service-mode deployable and the conformance vectors — the load-bearing new artifact; ③ the TypeScript client. All three exist. Clients in further languages are added only as integrator demand appears, against a surface the TypeScript work has already hardened. ## Consequences We commit to owning an HTTP compatibility surface and a vector suite alongside the packaging pipeline. In exchange, integrators in any language can never end up running verification logic outside the single pipeline through a supported channel: every decision an agency accepts traverses the one pipeline that the scheduled audits will cover, whatever language its backend speaks. [previous← record · packaging](/en/sdk/packaging)[nextrecord · service contract →](/en/sdk/verifier-service-contract) --- Source: https://mintid.net/en/sdk/multi-language-clients · Decision record — one core, thin clients · MintID SDK docs --- > Why the verifier-service contract froze at v1: three operations, a closed reason-code vocabulary and invariants no client, in any language, can change. index — 17 documents 1. [overviewsdk/00](/en/sdk) 2. [getting startedsdk/01](/en/sdk/getting-started) 3. [python sdksdk/02](/en/sdk/python) 4. [service modesdk/03](/en/sdk/service-mode) 5. [typescript clientsdk/04](/en/sdk/typescript-client) 6. [mcp serversdk/04a](/en/sdk/mcp-server) 7. [conformancesdk/05](/en/sdk/conformance) 8. [reason codessdk/06](/en/sdk/reason-codes) 9. [substrate readssdk/07](/en/sdk/substrate-reads) 10. [credentials & holderssdk/08](/en/sdk/credentials-and-holders) 11. [payment identitysdk/09](/en/sdk/payment-identity-profile) 12. [becoming a verifiersdk/10](/en/sdk/becoming-a-verifier) 13. [protocol statesdk/11](/en/sdk/protocol-state) 14. [record · assurance vocabularyrecord/01](/en/sdk/kyc-trust-model) 15. [record · packagingrecord/02](/en/sdk/packaging) 16. [record · multi-languagerecord/03](/en/sdk/multi-language-clients) 17. [record · service contractrecord/04](/en/sdk/verifier-service-contract) * [what the freeze covers](#frozen) * [why freeze now](#why) * [locked invariants](#invariants) * [post-freeze changelog](#changelog) SDK docs · record/04 # Decision record — verifier service contract Why the verifier-service contract froze at v1: three operations, a closed reason-code vocabulary and invariants no client, in any language, can change. ## What the freeze covers _Status: **Accepted** (2026-07-21) — contract v1 frozen at 1.0.0 · depends on the specification’s presentation rules, decision records, paid-verification permission and single-core rule_ The OpenAPI document [`verifier-service.v1.yaml`](https://mintid.net/openapi/verifier-service.v1.yaml) at contract version **1.0.0**: three operations (`getBuildInfo`, `createChallenge`, `validatePresentation`), their schemas, and the closed `ReasonCode` vocabulary — byte-identical to the reason codes the embedded SDK emits. Freezing means: any change to decision semantics or the reason vocabulary is a **major** contract version (the SDK’s semver policy, applied at the contract level); additive, non-semantic surface is **minor**. Transport-only clients, in every language, build against the frozen contract. ## Why freeze now The multi-language strategy makes this contract the load-bearing artifact of the whole approach: it is the boundary that guarantees no client ever carries cryptography or policy. The nine acceptance conditions, the 10-second constant and the retention schema sit _behind_ the contract and are deliberately unexpressible in it: no lifetime parameter, no skip flags, no per-request height-lag override. A contract test enforces route-for-route and code-for-code agreement between the YAML and the running service, so the frozen document is checked against reality on every CI run. ## Invariants the freeze locks in * **One decision path:** `validatePresentation` responses are the embedded SDK’s decision verbatim; HTTP 400 exists only where no session identity can exist — nothing parseable means no retention record. * **Closed reason vocabulary** shared with the conformance vectors; any change is major and flows to every language at once. * **Challenge identity** (verifier id, exact origin, request key) is deployment configuration bound to on-chain registrations — never caller input. * **`build-info` exposes exactly the release pins** — enough for a client to verify what it talks to, never secrets. ## Post-freeze changelog Version Date Change `1.0.0` 2026-07-21 Contract frozen (this record). `1.1.0` 2026-07-21 Additive minor: `BuildInfo` gains required `conformance_suite_version`. No decision-semantics or reason-code change. The freeze is what lets every client — in any language — treat the service surface as a stable fact: the conformance suite, the reason-code page and the service-mode guide in these docs all build on it. [previous← record · multi-language](/en/sdk/multi-language-clients) --- Source: https://mintid.net/en/sdk/verifier-service-contract · Decision record — verifier service contract · MintID SDK docs --- > @mintid-net/verifier-mcp gives an agent runtime three MCP tools over your own verifier service; a rejection comes back as a result the agent can reason about. index — 17 documents 1. [overviewsdk/00](/en/sdk) 2. [getting startedsdk/01](/en/sdk/getting-started) 3. [python sdksdk/02](/en/sdk/python) 4. [service modesdk/03](/en/sdk/service-mode) 5. [typescript clientsdk/04](/en/sdk/typescript-client) 6. [mcp serversdk/04a](/en/sdk/mcp-server) * [overview](#quickstart) * [the three tools](#tools) * [error semantics](#error-semantics) * [trust boundary](#trust-boundary) 7. [conformancesdk/05](/en/sdk/conformance) 8. [reason codessdk/06](/en/sdk/reason-codes) 9. [substrate readssdk/07](/en/sdk/substrate-reads) 10. [credentials & holderssdk/08](/en/sdk/credentials-and-holders) 11. [payment identitysdk/09](/en/sdk/payment-identity-profile) 12. [becoming a verifiersdk/10](/en/sdk/becoming-a-verifier) 13. [protocol statesdk/11](/en/sdk/protocol-state) 14. [record · assurance vocabularyrecord/01](/en/sdk/kyc-trust-model) 15. [record · packagingrecord/02](/en/sdk/packaging) 16. [record · multi-languagerecord/03](/en/sdk/multi-language-clients) 17. [record · service contractrecord/04](/en/sdk/verifier-service-contract) SDK docs · sdk/04a # MCP server @mintid-net/verifier-mcp gives an agent runtime three MCP tools over your own verifier service; a rejection comes back as a result the agent can reason about. ## Overview The tools decide nothing until your agency is a registered, active verifier with its exact origin and request key on chain; Getting started lists those steps. `@mintid-net/verifier-mcp` is a Model Context Protocol (MCP) server you run **inside your own perimeter**, next to the verifier service you already deploy. Registered as a local MCP server in your agent runtime, it exposes the three contract operations as tools that any MCP-capable framework can list and call. Like `@mintid-net/verifier-client`, which is its only dependency and its transport, it is **transport-only**: the cryptography, chain access, replay store and policy all stay in your verifier service, and the package pulls in no external runtime dependency. The single-use value, the session identifier and the ten-second expiry are generated by the verifying core; no tool argument can set them. ## The three tools One tool per operation of the frozen contract — no aggregate helpers, no convenience wrappers that could reorder a flow: Tool Contract operation build information `GET /v1/build-info` create a challenge `POST /v1/challenges` validate a presentation `POST /v1/presentations` The contract is untouched by this package: same request and response shapes, same closed reason-code vocabulary, same decisions as every other client in every other language. ## Error semantics (the part that survives the protocol hop) **A rejection is a successful tool result.** A presentation that fails — replayed nonce, stale status root, missing predicate — comes back as `{ accepted: false, reason_code }`, so the calling agent can reason about _why_ instead of retrying blindly. Only transport failures are tool errors: a body the service cannot parse, proven chain state unavailable (fail-closed — retry later, never skip the check), or the service unreachable. Branch on the decision data. ## Trust boundary This server is part of _your_ verifier deployment. Run it inside your perimeter, pointed exclusively at your own service instance: pointing it at anyone else’s service would hand them the acceptance decision, which is your obligation as a registered verifier. The server **persists nothing and logs nothing**; your service keeps the only decision record. The public testnet runs the server over Streamable HTTP in front of its sandbox verifier: `https://mcp.testnet.mintid.net/mcp`. **Whose decision it is.** Challenges from this endpoint are bound to the testnet’s sandbox verifier, so its decisions belong to the testnet and carry no weight: the credentials it checks come from a KYC sandbox whose outcome the caller chooses. That makes it the right tool for exploring the flow and wiring an agent end to end, with credentials you obtain from the testnet’s sandbox ([the public testnet](/en/developers)). It is not a way to outsource your own verification. If a decision gates your business, run the server yourself, in front of the service **you** deploy. Pointing it at anyone else’s service would delegate the decision itself, and the protocol does not allow that. The single-node production chain is not for third parties and is never a place to test. [previous← typescript client](/en/sdk/typescript-client)[nextconformance →](/en/sdk/conformance) --- Source: https://mintid.net/en/sdk/mcp-server · MCP server · MintID SDK docs --- > Two public reads, substrate status and attestation standing, answer from proven chain state with no presentation and without taking the issuer’s word. index — 17 documents 1. [overviewsdk/00](/en/sdk) 2. [getting startedsdk/01](/en/sdk/getting-started) 3. [python sdksdk/02](/en/sdk/python) 4. [service modesdk/03](/en/sdk/service-mode) 5. [typescript clientsdk/04](/en/sdk/typescript-client) 6. [mcp serversdk/04a](/en/sdk/mcp-server) 7. [conformancesdk/05](/en/sdk/conformance) 8. [reason codessdk/06](/en/sdk/reason-codes) 9. [substrate readssdk/07](/en/sdk/substrate-reads) * [two reads](#two-reads) * [substrate status](#substrate-status) * [attestation standing](#attestation-standing) * [without the issuer’s word](#standing-without-trust) * [freshness arithmetic](#freshness) * [re-initialised deployments](#reinitialised) * [limits of these reads](#limits) 10. [credentials & holderssdk/08](/en/sdk/credentials-and-holders) 11. [payment identitysdk/09](/en/sdk/payment-identity-profile) 12. [becoming a verifiersdk/10](/en/sdk/becoming-a-verifier) 13. [protocol statesdk/11](/en/sdk/protocol-state) 14. [record · assurance vocabularyrecord/01](/en/sdk/kyc-trust-model) 15. [record · packagingrecord/02](/en/sdk/packaging) 16. [record · multi-languagerecord/03](/en/sdk/multi-language-clients) 17. [record · service contractrecord/04](/en/sdk/verifier-service-contract) SDK docs · sdk/07 # Substrate reads Two public reads, substrate status and attestation standing, answer from proven chain state with no presentation and without taking the issuer’s word. ## Two reads that need no presentation Two reads tell you whether the substrate is healthy and what standing one issuer-signed record has, from proven chain state, with no presentation, no proof engine and no verifier registration: `GET /v1/status` and `GET /v1/attestations/{ref}/standing?issuer_id=<64 hex>`. They are **additive to the frozen `verifier-service.v1` contract and versioned separately at v0**, so the three v1 operations keep their semantics and their version. Both are public and cacheable for a few seconds; a route a deployment is not configured for answers `404`. > **Related-party disclosure:** the single-node production chain, in production since 20 September 2026, and its first issuer and verifier are operated by the CONECTIA group; the CONECTIA group and ZadQ, the first product built on them (on the classical seller rail), are related parties of MintID, and nothing measured there is independent adoption. ## Substrate status One aggregate of what the verifier already holds: the node’s head, the proven registry and root state of every issuer it watches, and the chain’s published root policy — **metadata only**, no holder, attestation, witness or presentation. `substrate` Means Commits you to `ok` the node produces blocks and every watched issuer has a fresh root on an operational, bonded registry record only “ask now” — standing can still be unknown for a record no root holds yet `degraded` at least one of those failed; detail names which an operational alarm; standing reads are answering unknown meanwhile `unknown` the node itself could not be read nothing — you have no substrate signal at all Per watched issuer: `active` (registry record operational), `bond_ok` (live bond at or above the governed minimum), `root_epoch` / `root_height` (the current root and the block that finalized it), `root_age_seconds` (now minus when the issuer generated it), `fresh` (inside its declared window and this verifier’s height-lag policy) and `reason`, from a closed set: `ok`, `issuer_unknown`, `issuer_not_active`, `bond_insufficient`, `root_missing`, `root_expired`, `height_stale`, `state_unavailable`. A last object, `verifier`, reports the deployment’s own id, origin, height-lag policy and build pins. The **`promise` object** carries chain parameters, not the service’s own configuration. That is why it is published: a cadence read off the chain the verifier proves its reads against is a fact you can check, where the same numbers in a service-level assertion would only be a claim. jsonsdk/07 · live answer, abridged ``` { "substrate": "ok", "checked_unix": 1790102713, "detail": "", "chain": { "chain_id": "", "latest_height": 89668, "block_age_seconds": 3, "latest_block_time_unix": 1790102710 }, "issuers": [ { "issuer_id": "", "reason": "ok", "active": true, "bond_ok": true, "root_epoch": 6317, "root_height": 89662, "root_age_seconds": 14, "fresh": true } ], "promise": { "heartbeat_seconds": 30, "max_root_age_seconds": 180, "note": "roots are published every heartbeat_seconds and stay fresh up to max_root_age_seconds; a revocation lands in the next root" } } ``` ## Attestation standing `ref` is a 32-byte opaque reference in hex. Besides `status` — `active`, `suspended`, `revoked` or `unknown` — you get `fresh`, `issuer_active`, `bond_ok`, the proven `root` with its epoch and height, and `latest_height`. `reason_code` is `ok` when every check passed, and `status` is then the witnessed one; every failed check degrades to `unknown`: `reason_code` What happened `state_unavailable` a chain read could not be proven `issuer_unknown` no registry record for this issuer `issuer_not_active` the issuer is not operational `status_root_stale` no current root, or its validity window has passed `height_stale` the root was finalized outside the height-lag window `witness_unavailable · witness_malformed` no witness served for this reference; or it did not parse, or names another reference `witness_root_mismatch · witness_invalid` the witness claims a different root or epoch; or it did not recompute to the proven root `bond_insufficient` the witnessed status is still returned, with bond\_ok: false `bond_insufficient` is the one code that does not degrade: you get the real status, and what a short bond means is your policy. ## Standing without taking the issuer’s word The checks run in trust order and the issuer is consulted last: (1) its registry record, read from the chain with an inclusion proof; (2) its live bond against the governed minimum, from the same proven read; (3) its current status root, that root’s validity window and the height at which it was finalized; (4) only then the witness — fetched from the issuer, recomputed locally, accepted only if it lands on the _proven_ root at the _proven_ epoch. The issuer supplies the path, never the answer: one that lies about a status serves a witness that does not recompute, one that says nothing gets `witness_unavailable`, never a default yes. Every chain read is proven against a trust anchor, and claimed absence of a record fails closed. The witness construction is published so you can recompute it yourself. `status_byte` is `0` active, `1` suspended, `2` revoked. A witness is `{ref, status, status_epoch, root, index, path[]}`: fold the path from the leaf, taking the sibling on the left while the running index is odd and halving that index each step, then apply the root hash. The construction is off-chain and issuer-internal. textsdk/07 · witness construction ``` leaf = SHA-256( 0x00 ‖ "mintid/issuer-status-leaf/v1" ‖ ref ‖ status_byte ) node = SHA-256( 0x01 ‖ left ‖ right ) duplicate the last node on odd levels root = SHA-256( "mintid/issuer-status-root/v1" ‖ epoch_be64 ‖ tree_root ) ``` ## Freshness, degradation, and the arithmetic you need Roots publish every `heartbeat_seconds` and are accepted up to `max_root_age_seconds`: 30 s and 45 s at the reference values, 30 s and 180 s on the single-node production chain. Nothing the issuer does is visible before its next root, so **time to first verdict is one root period plus your own polling interval**: 30 s plus a 60 s poll is up to 90 s. A newly issued reference reads `witness_unavailable` until that root, which is the expected first answer, and polling faster than a minute buys nothing. `max_root_age_seconds` is the fail-closed bound and promises no delivery time; the gap above the heartbeat lets a routine deploy of the issuer’s service pass without turning every read `unknown`, and a revocation still lands in the next root. For presentations, landing is not yet refusal everywhere: a proof built against the superseded root stays acceptable while that root is inside its own validity window, so every verifier refuses an issuer revocation within `max_root_age_seconds` plus a few seconds of clock tolerance (under a minute at the reference values, 185 s on the single-node production chain), and at once after an emergency root. When the substrate is behind, fail closed. **Never map `unknown` to yes**, never keep serving a cached `active` past its root’s window, and never retry until a check passes: a loop against `state_unavailable` or `status_root_stale` accepts unproven state slowly. The failure never arrives as an HTTP error. Anything the route accepts returns `200`, with the verdict in `substrate` or in `status`/`reason_code`. `400` covers only an `issuer_id` that is not 32 bytes of hex; a `ref` that is not 64 hex characters misses the route and gets `404`. There is no 5xx for a degraded substrate — alert on the body. ## What a re-initialised deployment changes under you A deployment can be re-initialised: the operator starts a new chain carrying the registry and the issuer’s book across, rather than migrating state in place. Hostnames, issuer id, verifier id, references and statuses survive; the **chain identifier changes**, block heights restart and `root_epoch` counts from 1 again. Witnesses regenerate at the first heartbeat and standing answers `unknown` until the new chain’s first root is finalized — the ordinary degradation path. **Persist the chain identifier next to any `root_epoch` you keep**: epochs are ordered only within one chain. ## Limits of these reads Both reads are classical checks of signed records: standing describes a record an issuer signed and placed in a root, and nothing about whoever holds a credential, and no zero-knowledge claim attaches to either. `substrate: ok` describes one chain and its watched issuers at a single point in time; your own checks still decide, and neither read makes you a verifier. One gap to know about before you meet it: a status root can also carry **reserved entries** that are not attestations, used to anchor material the rest of the protocol needs. The rule for recomputing them is not published yet. If you are recomputing roots yourself rather than reading standing, ask for it rather than inferring it from a sample. Next: [credentials and holders](/en/sdk/credentials-and-holders) — how the records behind a root come to exist; and the [reason codes](/en/sdk/reason-codes) — the separate, frozen vocabulary of the presentation decision. [previous← reason codes](/en/sdk/reason-codes)[nextcredentials & holders →](/en/sdk/credentials-and-holders) --- Source: https://mintid.net/en/sdk/substrate-reads · Substrate reads · MintID SDK docs --- > How a credential is issued over OpenID4VCI, held in a headless holder library, kept current by witness refresh, and retired when its check expires. index — 17 documents 1. [overviewsdk/00](/en/sdk) 2. [getting startedsdk/01](/en/sdk/getting-started) 3. [python sdksdk/02](/en/sdk/python) 4. [service modesdk/03](/en/sdk/service-mode) 5. [typescript clientsdk/04](/en/sdk/typescript-client) 6. [mcp serversdk/04a](/en/sdk/mcp-server) 7. [conformancesdk/05](/en/sdk/conformance) 8. [reason codessdk/06](/en/sdk/reason-codes) 9. [substrate readssdk/07](/en/sdk/substrate-reads) 10. [credentials & holderssdk/08](/en/sdk/credentials-and-holders) * [the lifecycle](#lifecycle) * [issuance surface](#issuance-surface) * [no wallet, on purpose](#no-wallet) * [when it expires](#validity) * [witness refresh](#witness-refresh) * [identity evidence](#identity-evidence) * [assurance grades](#grades) * [current status](#status) 11. [payment identitysdk/09](/en/sdk/payment-identity-profile) 12. [becoming a verifiersdk/10](/en/sdk/becoming-a-verifier) 13. [protocol statesdk/11](/en/sdk/protocol-state) 14. [record · assurance vocabularyrecord/01](/en/sdk/kyc-trust-model) 15. [record · packagingrecord/02](/en/sdk/packaging) 16. [record · multi-languagerecord/03](/en/sdk/multi-language-clients) 17. [record · service contractrecord/04](/en/sdk/verifier-service-contract) SDK docs · sdk/08 # Credentials and holders How a credential is issued over OpenID4VCI, held in a headless holder library, kept current by witness refresh, and retired when its check expires. ## The lifecycle, in four movements A presentation is only as good as the credential behind it. A credential starts from an approved identity check, is blind-signed by the issuer, lives in a holder library you embed, and becomes usable once a finalized status root commits it. Four properties carry the rest: 1. **The grade is the issuer’s, not the holder’s.** The offer carries the grade and date of birth the approved identity check produced; a holder cannot ask for a grade. 2. **The issuer never sees the credential in the clear.** The holder sends a blinded request bound to a one-shot nonce from the token endpoint; the issuer blind-signs, the holder unblinds locally, and the link secret stays inside the holder library. 3. **A credential is not usable the moment it is signed.** It becomes usable when a finalized status root commits the accumulator it lives in; until then the witness endpoint says so, and a conforming holder does not present. 4. **Holders do not accumulate on chain.** The chain carries the issuer’s periodic status root — never a credential id, serial, presentation or holder identifier. textsdk/08 · the lifecycle ``` identity check ──▶ offer ──▶ token ──▶ blinded request ──▶ credential a verdict reaches the issuer, signed blind never the evidence │ presentations, 10 seconds each ◀── witness refresh, per root ─┘ ``` ## Issuance follows OpenID4VCI; the holder library is the stable surface There is **no OpenAPI document for issuance**. The operator-facing side of the issuer service has one; the holder-facing endpoints are specified by their implementation and by this page, and by nothing else. So a wallet somebody else builds has no stable issuance contract to build against today, and the intended integration is the **holder library below**. The shape follows OpenID4VCI with a pre-authorized code grant; the credential format and proof type are MintID’s own. Endpoint Called by What it does `GET /.well-known/openid-credential-issuer` anyone issuer metadata: the credential configuration, the issuer’s current definition, and where its accumulator is anchored `POST /v1/credential-offers` the issuer’s operator turns one approved verification session into an offer with a pre-authorized code `POST /v1/token` the holder redeems that code once for an access token and a nonce `POST /v1/credential` the holder fulfils a blinded issuance request bound to that nonce `GET /v1/credentials/{id}/witness` the holder the usability gate plus fresh witness material Operator routes are authenticated; holder routes are reached with the one-shot code and token, and one token yields at most one credential. ## There is no wallet, on purpose The holder is a **headless library you embed**, running in your own infrastructure next to the keys you already custody. MintID ships no consumer wallet, browser key store, hosted key or mobile app, and has none planned: a wallet front-end is outside the specification, and a dashboard that could read your key would be custody in fact. Nothing here prevents a credential from one day being presented from a wallet somebody else builds — the transports are the standard ones — but that is not a surface MintID offers you today. The library is Rust, with three bindings — **Python**, **Go** and **TypeScript**; the Python and Go bindings drive it as a child process over JSON lines (no cgo, no hand-written FFI). Operation What it does What it guarantees `issue` the holder half of issuance: metadata, token, blinded request, unblinding the issuer learns a commitment, never the link secret `refresh_witness` adopts the issuer’s current definition, this credential’s membership witness, and the finalized root anchoring them self-checked first: material that does not verify is refused and the holder keeps its previous state `present` answers a verifier’s challenge with one bound, 10-second envelope the binding is derived by the library from the challenge itself; if the credential cannot satisfy the policy the call fails and nothing is sent `self_revoke` revokes the holder’s own credential through a privacy relay that submits the revocation and pays for it, so the holder needs no account in production on the single-node production chain since 24 September 2026: neither who the holder is nor which credential it was is revealed; the issuer must remove it within a bounded window the chain enforces, and every service refuses it in under two minutes; its independent audit is a scheduled milestone whose findings are published There is no `export`. The one serialization is a custody encoding holding the link secret: encrypt it under your own key, keep it where your payment key lives. The holder’s view of itself reports the issuer, grade, validity instants, credential id and current root — never the secret, never the date of birth. A lost key is recoverable by nobody: you re-verify and get a fresh credential, unlinkable to the old one. ## When a credential expires A credential expires exactly when the verification behind it does: 12 months after approval for grades A1 and A2, 6 months for grade A3, 3 months for grade A4 (grades are encoded 1–4 on the wire) — however late in that period the credential was issued. There is no grace period and no extension. Once the verification has expired, every issuance step is refused, including an offer made just before it. The expiry is inside the credential and proven at every presentation; past it, the credential no longer satisfies an `unexpired` policy, and the way back is a new verification. ## Witness refreshes, and what a stale one costs Non-revocation is proven against the accumulator the issuer’s latest finalized status root commits, and roots move on a short heartbeat. * **Cadence:** size it against how often roots are _published_, not how long one stays _accepted_. In practice: refresh right before presenting. * **Stale fails closed.** A witness that no longer matches the anchored accumulator cannot build a valid presentation, and a proof built against a superseded root is rejected once that root leaves its validity window. * **The refusal names the failed check** — `status_root_stale`, not a generic failure. Refresh once and retry, never loop ([reason codes](/en/sdk/reason-codes)). * **Revocation lands at the next root**, and landing is not yet refusal everywhere: a proof against the previous root stays acceptable while that root is inside its validity window, so every verifier refuses a credential its issuer revoked in under a minute at the reference values, or at once through the emergency key. ## Where identity evidence lives With the verification provider, and nowhere else. The boundary is narrow and provider-neutral: a driver opens a case, reports its state, and returns an authenticated verdict enumerating the checks it performed. The issuer keeps that verdict, an opaque handle to evidence in its own vault, a grade, timestamps and a status; raw evidence reaches neither MintID nor the chain. **The provider does not set the grade**: a driver that returned one is rejected, because grading is the issuer’s decision over enumerated checks, bounded by what its admission permits. ## Assurance grades Grade What the issuer asserts A1 basic binding of the subject to the credential A2 document verification plus a liveness / face-match step A3 A2 plus enhanced due diligence with periodic review A4 highest assurance, under stricter controls A grade measures the **strength of the check**, not its recency; freshness is a separate dimension, carried beside the grade and never folded into it. Note what follows from that: a presentation today proves a grade threshold, and **there is no freshness predicate** — if recency matters to your decision, it is not something a proof will tell you. The issuer publishes the band, and it is read on the classical seller rail. An issuer may use only the grades its admission permits, and a presentation proves a **threshold** — “at least A2” — never the exact grade or the attributes. MintID’s four grades are its own vocabulary, mapped to eIDAS and ISO/IEC 29115 **without claiming conformance to either**, and the reasoning is in the [assurance vocabulary record](/en/sdk/kyc-trust-model). ## Current status The proof core that issues and presents these credentials is built and runs on the single-node production chain, in production since 20 September 2026 and operated by the CONECTIA group, and integrators use it under commercial terms; the CONECTIA group, the chain’s first issuer and verifier, and ZadQ, the first product built on them (on the classical seller rail), are related parties of MintID. An independent audit of its implementation is a scheduled milestone whose findings are published. Holder-initiated revocation has been in production on the single-node production chain since 24 September 2026, through the privacy relay the operations table describes; its independent audit is a scheduled milestone whose findings will be published. The verifier side of the exchange starts at the [integration overview](/en/sdk); what you owe before any code is in [getting started](/en/sdk/getting-started), and roots and registry state are in [substrate reads](/en/sdk/substrate-reads). [previous← substrate reads](/en/sdk/substrate-reads)[nextpayment identity →](/en/sdk/payment-identity-profile) --- Source: https://mintid.net/en/sdk/credentials-and-holders · Credentials and holders · MintID SDK docs --- > A draft binding that carries an identity requirement in a 402 response and the answer on the retry, and states what a buyer-side session lets you conclude. index — 17 documents 1. [overviewsdk/00](/en/sdk) 2. [getting startedsdk/01](/en/sdk/getting-started) 3. [python sdksdk/02](/en/sdk/python) 4. [service modesdk/03](/en/sdk/service-mode) 5. [typescript clientsdk/04](/en/sdk/typescript-client) 6. [mcp serversdk/04a](/en/sdk/mcp-server) 7. [conformancesdk/05](/en/sdk/conformance) 8. [reason codessdk/06](/en/sdk/reason-codes) 9. [substrate readssdk/07](/en/sdk/substrate-reads) 10. [credentials & holderssdk/08](/en/sdk/credentials-and-holders) 11. [payment identitysdk/09](/en/sdk/payment-identity-profile) * [a transport binding](#binding) * [two rails](#two-rails) * [seller-side](#seller-side) * [buyer-side](#buyer-side) * [what a session means](#what-session-means) * [request signing](#request-signing) * [reason codes](#reason-codes) * [outside this profile](#limits) 12. [becoming a verifiersdk/10](/en/sdk/becoming-a-verifier) 13. [protocol statesdk/11](/en/sdk/protocol-state) 14. [record · assurance vocabularyrecord/01](/en/sdk/kyc-trust-model) 15. [record · packagingrecord/02](/en/sdk/packaging) 16. [record · multi-languagerecord/03](/en/sdk/multi-language-clients) 17. [record · service contractrecord/04](/en/sdk/verifier-service-contract) SDK docs · sdk/09 # Payment-identity profile A draft binding that carries an identity requirement in a 402 response and the answer on the retry, and states what a buyer-side session lets you conclude. ## A binding that rides inside the payment flow you already run The payment-identity profile says where an identity _requirement_ rides inside an existing payment-required (HTTP `402`) response, and where the _answer_ rides on the retry, beside the payment header. It adds no message, signature scheme or role of its own, leaves the payment payload untouched, and is optional in both directions. **It is a draft and cannot freeze** while its dispute annex — who posts a claim bond when the harmed party never registered — is still open, so expect additive change: new fields and format tags, not silent changes to the ones below. The schemas declare canonical `$id` URLs that **are not served yet**: validate against the copies you are given. Every object is `additionalProperties: false`, so an unnamed field is a validation failure, not an extension point — a price or billing field included. ## Two rails Rail What travels Who is described What the receiver does Seller-side a reference to an issuer-signed record the party being paid resolves that record’s standing itself, from proven chain state Buyer-side an answer to the receiver’s own challenge the party paying validates it on its own verifier service The seller-side rail, a classical issuer-signed record checked against proven chain state, is shipped end to end. The buyer-side rail is shipped **as transport** (declaration, headers, ordering, sessions), and the zero-knowledge proof engine behind its answers is built and in production; what an answer establishes is set by the policy you declare, and nothing on this page widens it. > **Related-party disclosure:** both rails run today only on the single-node production chain, in production since 20 September 2026, whose issuer and verifier are operated by the CONECTIA group; the CONECTIA group and ZadQ, the first product built on them (on the classical seller rail), are related parties of MintID, and nothing measured there is independent adoption. ## Seller-side: a reference travels, standing is resolved The seller’s `402` carries an `identityPolicy` object in its `extensions`, with these fields and no others: * `claim` — the constant `seller-endpoint-accountability`, the only claim on this rail: a verified, accountable operator stands behind this chain-qualified payment address and resource URL, without revealing who. * `assuranceAtLeast` — the minimum assurance grade the record meets: a public single letter, or `1`..`4` / `A1`..`A4`. * `verifyUrl` — the verifying party’s free, anonymous path, where anyone fetches the current signed verdict; the optional `verdict` field carries an inline copy of it, which is a hint, never a proof. The answer rides in `X-PAYMENT-IDENTITY`, beside `X-PAYMENT`: base64url of `{"version": 1, "format": "attestation-ref/v0", "payload": ""}`. The payload decodes to the issuer’s signed receipt — `attestation_ref`, `issuer_id`, `chain`, `pay_to`, `resource_url`, `assurance_grade`, `issued_at_unix`, `signature` — its own object **minus the status**: standing never travels inside the receipt, and is resolved with the [standing read](/en/sdk/substrate-reads). There is no challenge, policy or session here, and the buyer is never identified. ## Buyer-side: declaration, headers, session The `402` carries a `mintid_identity` object instead. `claim_policy` is restricted to four claims — `assurance_grade >=` A1..A4, `credential_active`, `unexpired`, and an optional `age_over N` — and the library refuses any other when you build the policy, rather than letting the engine discover it. `session_mode` takes one value; the schema reserves a second string that must not be offered yet. The exchange: (1) the `402`; (2) `POST `, answering with the verifying party’s own challenge, unmodified — nonce, session id and the 10-second expiry are the service’s, since the extension carries policy, never invariants; (3) the retry, `X-PAYMENT` unchanged plus `X-MINTID-PRESENTATION`, base64url of `{profile, request, envelope}` with `request` that challenge verbatim; (4) the receiver checks, in order, the request signature (below), a session token if present, otherwise the answer — which must have been issued for _this_ policy (else `policy_mismatch`) and is validated on the party’s **own** service; (5) on acceptance the response carries `X-MINTID-SESSION`. A rejection rides in the payment `error` field as `mintid_identity:`; identity accepted but unpaid is still a `402`. The session token is opaque, minted by the receiving party, scoped to that party, the key that signed the accepted request, and the declared counterparty. Its lifetime is local policy; the reference implementation defaults to 15 minutes. Presenting it under another signing key is `session_key_mismatch`, attaching a fresh answer to a stolen token does not upgrade it, and after the lifetime it is `session_expired`. The party keeps the decision’s public outputs and nothing else. jsonsdk/09 · worked example ``` { "profile": "", "session_mode": "token_exchange", "challenge_endpoint": "https://publisher.example/mintid/challenges", "counterparty": { "chain": "eip155:8453", "pay_to": "0x8335…2913", "resource_url": "https://publisher.example/api/articles/42" }, "claim_policy": [ { "claim": "assurance_grade", "operator": ">=", "value": "A2" }, { "claim": "credential_active", "value": true }, { "claim": "unexpired", "value": true } ], "issuer_policy": { "accepted_issuer_ids": ["5656…5656"], "issuer_state_minimum": "ACTIVE" } } ``` ## What the session does and does not entitle you to conclude On the buyer side today the counterparty — the chain, the payment address, the resource URL — is **declared in the payment-required response and bound to the session. It is not proven.** The receiving party issues its challenge for that declared counterparty, the answer is nonce-bound to that challenge, and the party records which counterparty its policy named next to the accepted decision. That entitles you to say: the party that answered did so against the challenge _you_ issued, for the policy _you_ declared, in _this_ session, under the key that signed the request — an association _you_ hold about your own session. It does not entitle you to say that a scope, a mandate or any relationship to this counterparty was proven inside the answer, nor to key-binding semantics: the association between signing key and decision is session-level, like any authenticated session, and a cryptographic binding of that key is deliberately not specified here. Copy that claims otherwise is wrong. **The complete v1 profile supersedes this declaration.** Same extension key, same headers, same session token; what changes is what the answer proves. The buyer presents an _agent_ credential, and the policy may ask for delegation itself: human-backing, the backing grade, the credential active and unexpired, a minimum key-custody class, a per-transaction limit in a named currency, and membership in the delegated scope — the action, _this_ counterparty (its payment account or resource URL), a category and a region — each value named in the canonical form of the scope vocabulary. The counterparty would then be proven, not declared, and above a value threshold the receiving party configures, a payment whose axes the policy does not cover would be refused. Both declarations coexist per receiving party for a transition window. The axes are specified; enforcement arrives with the agent products. ## The request-signing tier for automated clients Every request to the protected resource is signed, and the signature is checked before anything else. * **Scheme** — RFC 9421 HTTP Message Signatures, Ed25519, `tag="web-bot-auth"`, covering at least `@authority` and `signature-agent`. * **Parameters** — `created`, `expires`, `keyid`, `nonce`, all required; `expires` must be in the future and at most one hour after `created`, with 60 s of clock skew tolerated on `created`; a `(keyid, nonce)` pair is refused a second time inside that window. * **`keyid`** — the RFC 7638 thumbprint of the Ed25519 JWK published in the directory the `Signature-Agent` header names; a `kid` in that document is also accepted. The directory document is `{"keys": [, …]}` and only Ed25519 keys are read; it may carry `"mintid_presentation": true` as a capability hint, nothing more. **Two things the library does not ship, deliberately:** the Ed25519 verification and the key-directory fetch — the verifying core has no cryptographic dependency and makes no network call, so you inject both. ## Reason codes of the identity leg One per request, from a closed set; your service’s own codes pass through unchanged, so a `switch` sees both vocabularies, and `presentation_rejected` is the fallback when the service names none. Code Meaning `accepted · session_reused` a fresh answer was validated and a token issued; or a live token under the same signing key `identity_required` signature fine, but neither a session token nor an answer `session_expired · session_key_mismatch` the token is unknown or past its lifetime and nothing accompanied it; or it belongs to another signing key `policy_mismatch · presentation_malformed · profile_unknown` the challenge was not issued for this declared policy; the header did not decode into {profile, request, envelope}; or it names a profile this party does not run `agent_signature_missing · _malformed` no signature headers; or bad parameters, wrong tag, a required component left uncovered `agent_signature_expired · _replayed · _invalid` outside the window or over the lifetime bound; this (keyid, nonce) already seen; the signature did not verify `agent_key_unknown · agent_directory_unavailable` the directory does not publish this keyid, or could not be resolved Declaration-time refusals are separate — you meet them when you build or parse the policy object, never per request: `extension_malformed`, `challenge_endpoint_malformed`, `counterparty_malformed`, `claim_policy_malformed`, `claim_not_provable`, `issuer_policy_malformed`, `session_mode_gated` / `_unknown`. ## Outside this profile’s scope The 10-second answer lifetime, the absence of any skip or “lite” flag, the staleness bound and the audience are invariants of the verifying core, and the wire carries no field that could change them. Every answer is perishable and non-transferable: a “verified” signal with a lifetime is somebody’s own published verdict, never a MintID artifact. Your own service runs the challenge and the validation, keeps the only decision record, and neither forwards nor stores envelopes. Next: the [service](/en/sdk/service-mode) the buyer-side leg calls; the [reason codes](/en/sdk/reason-codes) that pass through the leg unchanged; and [becoming a verifier](/en/sdk/becoming-a-verifier) — the registration a verifying party needs before any of this decides anything. [previous← credentials & holders](/en/sdk/credentials-and-holders)[nextbecoming a verifier →](/en/sdk/becoming-a-verifier) --- Source: https://mintid.net/en/sdk/payment-identity-profile · Payment-identity profile · MintID SDK docs --- > Registration puts your identity, exact origins and signing key on chain. Today an operator admits you, and every step still done by hand is listed below. index — 17 documents 1. [overviewsdk/00](/en/sdk) 2. [getting startedsdk/01](/en/sdk/getting-started) 3. [python sdksdk/02](/en/sdk/python) 4. [service modesdk/03](/en/sdk/service-mode) 5. [typescript clientsdk/04](/en/sdk/typescript-client) 6. [mcp serversdk/04a](/en/sdk/mcp-server) 7. [conformancesdk/05](/en/sdk/conformance) 8. [reason codessdk/06](/en/sdk/reason-codes) 9. [substrate readssdk/07](/en/sdk/substrate-reads) 10. [credentials & holderssdk/08](/en/sdk/credentials-and-holders) 11. [payment identitysdk/09](/en/sdk/payment-identity-profile) 12. [becoming a verifiersdk/10](/en/sdk/becoming-a-verifier) * [what registration is for](#purpose) * [the request](#request) * [two paths](#two-paths) * [where to test](#where-to-test) * [still manual today](#not-self-service) * [the issuer path](#issuer-path) * [related parties](#disclosure) * [what registration attests](#limits) 13. [protocol statesdk/11](/en/sdk/protocol-state) 14. [record · assurance vocabularyrecord/01](/en/sdk/kyc-trust-model) 15. [record · packagingrecord/02](/en/sdk/packaging) 16. [record · multi-languagerecord/03](/en/sdk/multi-language-clients) 17. [record · service contractrecord/04](/en/sdk/verifier-service-contract) SDK docs · sdk/10 # Becoming a verifier Registration puts your identity, exact origins and signing key on chain. Today an operator admits you, and every step still done by hand is listed below. ## What registration is for Registration is what makes you a verifier, and today an operator admits you: no form completes it on your own. Below is what registration puts on chain, what the request contains, and each step that still goes through a person. Your verifier record puts three things into chain state that anyone can read with proofs: **who you are**, **the exact origins you present from**, and **the public key that signs your challenges**. That is what lets a holder decide whether to answer you. A challenge arrives claiming an origin, a verifier id and a request key; the holder — and your own SDK, on every decision — resolves those against proven registry state. Origins are exact: one scheme and host, no path, no wildcards, one verifier per origin. A lookalike domain cannot borrow your reputation, and an unregistered origin of yours is just as dead. Three obligations then stay live, each with its own rejection in the [reason codes](/en/sdk/reason-codes): keep the record active (`verifier_not_active`), revalidate each origin before its window lapses (`revalidation_expired`), and keep the key that signs your challenges registered (`request_key_not_active`). ## What a registration request contains One file of **public material only** — you generate the request-signing key where you keep it, and the private half never enters the file. Field Meaning `kind` verifier `id_hex` your 32-byte verifier id, fixed for the life of the record `public_display_name` the name the registry shows `operator_account` the chain account that operates the record and pays its fees `policy_version` the registry policy version the request is made under `kyc_issuer_id_hex` the issuer that performed the identity check on you as a verifier `kyc_attestation_commitment_hex` a digest standing for that check (see below — a labelled placeholder today) `request_key_pub_hex` the public key that will sign your challenges `origin` one exact HTTPS origin, validated on the spot `domain_control_proof_hash_hex` a digest of your domain-control evidence (see below) `revalidation_days` the origin binding’s validity window before renewal (default 180) ## Two paths to that file **A form.** An onboarding portal builds the request from a web form, with stricter validation than hand-editing the file: exact origin, key sizes, grade ordering, account checksum. It then shows what the registry actually says about your id — absent, pending, active — read with proofs through the same chain client a verifier uses. It never holds a private key, never signs and never votes: you paste public keys, and the operator downloads the file, reviews it and runs the admission. **A command-line tool.** The same file, fields and placeholders, produced by the admission tool that ships with the chain sources. It does not talk to the chain either; it writes a file. Both paths end in the same place: you hand the file over, and what happens next is not in your hands. ## Where to test **Status: live.** [The public testnet and its KYC sandbox](/en/developers) states whether it is live, its limits and its terms. **Test on the public testnet, with its KYC sandbox; the single-node production chain is never a place to test.** A public adversarial testnet with independent participants will run before any mainnet. The public testnet is the only MintID deployment a third party may use to test. It runs the same software and the same chain parameters as the single-node production chain, on its own chain, with its own keys and hostnames. Its issuer verifies nobody: when you open a KYC session you choose its outcome, so every path of issuance and every error a verifier can meet is reachable on purpose: an approval at the grade you choose, a refusal, an expiry, a manual review, an unavailable provider, a reuse window that has closed. Its sandbox verifier answers challenges and validates presentations, and the testnet runs holder self-revocation and the privacy relay as production does. Nothing issued on the testnet carries weight: a credential, a grade, an agent or a decision obtained there says nothing about any person and must never be accepted anywhere else. It has one validator, run by the operator of the production chain; it runs on its own test token, free to anyone from an open faucet, which has no value and converts into nothing; and it is reset when the software changes shape, with everything issued before gone. A verifier of your own can self-register on the testnet in the permissionless tier, paying its registration and renewal from a faucet grant; the admitted tier, which production uses, has no path there. The public journey uses the sandbox verifier. To hold every key yourself, the local stack of [the main repository](https://gitlab.com/mintid/mintid) runs every service on your own machine. **The single-node production chain** answers three public read endpoints — the chain’s status, the issuer’s build information and the verifier’s status and build information — so anyone can check that blocks are produced, which proof engine the verifier is pinned to and whether the issuer’s root is fresh. They are evidence, not a place to test. Accepting real presentations there requires a registered verifier, admitted by governance proposal until self-service registration reaches that chain; it starts as a conversation through the [contact page](/en/contact). ## Still manual today Every item below is true, as of this writing, of the single-node production chain, in production since 20 September 2026 and operated by the CONECTIA group. * **You need a funded account on the production chain.** Your operator account must exist and hold enough to pay its way before anything is submitted, and there is no self-service funding path: someone must fund it for you. Today that someone is the chain’s operator, out of band. * **Admission is a governance proposal.** Registering and then activating your record are two proposals, whose messages are signed by the registry’s governance authority and executed when the proposal passes. On the deployment described here there is exactly **one voter**. A human decision gates you, and it is not automated. * **The form is not open either.** The portal sits behind a single shared credential handed out of band. You cannot reach it without asking. * **The identity check on you as a verifier has no published process.** The request names the issuer that performed it and commits a digest of it. There is no published procedure, criteria or turnaround, and in requests produced today that digest is a labelled placeholder. * **The domain-control evidence has no published format.** No challenge string, no well-known path, no DNS record name, no automated checker. The field takes the digest of a file you supply and nothing inspects what that file is. Renewal exists as an expiry date on the binding; what it revalidates is procedure, not protocol. * **There is no published eligibility policy, fee, service level or appeal.** Nothing states who may register, what it costs, how long it takes, or what happens if you are refused. * **The self-registering tier is designed, not built.** A second verifier tier — operator-signed self-registration with an exact origin and a domain-control proof, an admission fee, and a governance power to suspend afterwards — is decided and scheduled. It exists on no running chain, and you cannot use it. **Today, admission is a conversation.** The pieces that would make it self-service are named and scheduled, and none has shipped yet; if your plan needs programmatic onboarding this quarter, [talk to us](/en/contact) before you commit to it. ## The issuer path, briefly An issuer registers through the same mechanism, with two differences. First, it declares the assurance grades it may issue, and that set becomes registry state — an issuer cannot grade above its admission. Second, activation is **bond-gated**: the operator account locks a bond at or above the governed minimum with its own key, and every transition into the active state re-checks that the bond is live. An issuer also registers two keys that may never be the same: the one that signs its status roots, and a separately scoped emergency key that can publish a root on its own. Everything in the section above applies to issuers too — and no third party has yet been admitted as an issuer here. ## Related-party disclosure The chain described here is the single-node production chain, in production since 20 September 2026 and operated by the CONECTIA group through Conectia PRO. Conectia PRO, and the issuer and verifier admitted on that chain, are **related parties of MintID**, and the single voter on every admission proposal is that operator’s validator key. Any adoption figure derived from this deployment is a related-party pilot, not independent adoption. The first issuer and the first verifier were admitted through the same path the protocol offers anyone: a governance proposal, today voted by the chain’s single validator and, once the compliance council is seated, by the council; the same slashable bond; the same 30-second roots; all of it on chain. ## What registration attests Registration makes you _addressable_ and _checkable_, and that is all it attests: no one has reviewed your verification stack, policy or data handling, and a registry record certifies none of them. Next: [getting started](/en/sdk/getting-started) — the obligations that follow admission; [substrate reads](/en/sdk/substrate-reads) — reading your own record with proofs; and [protocol state](/en/sdk/protocol-state) — what is stable, draft and absent. [previous← payment identity](/en/sdk/payment-identity-profile)[nextprotocol state →](/en/sdk/protocol-state) --- Source: https://mintid.net/en/sdk/becoming-a-verifier · Becoming a verifier · MintID SDK docs --- > What you can build on, what will keep moving under you and what is not there yet, with the order in which each missing piece is gated. index — 17 documents 1. [overviewsdk/00](/en/sdk) 2. [getting startedsdk/01](/en/sdk/getting-started) 3. [python sdksdk/02](/en/sdk/python) 4. [service modesdk/03](/en/sdk/service-mode) 5. [typescript clientsdk/04](/en/sdk/typescript-client) 6. [mcp serversdk/04a](/en/sdk/mcp-server) 7. [conformancesdk/05](/en/sdk/conformance) 8. [reason codessdk/06](/en/sdk/reason-codes) 9. [substrate readssdk/07](/en/sdk/substrate-reads) 10. [credentials & holderssdk/08](/en/sdk/credentials-and-holders) 11. [payment identitysdk/09](/en/sdk/payment-identity-profile) 12. [becoming a verifiersdk/10](/en/sdk/becoming-a-verifier) 13. [protocol statesdk/11](/en/sdk/protocol-state) * [stable](#stable) * [additive or draft](#draft) * [not there yet](#absent) * [what gates what](#gates) 14. [record · assurance vocabularyrecord/01](/en/sdk/kyc-trust-model) 15. [record · packagingrecord/02](/en/sdk/packaging) 16. [record · multi-languagerecord/03](/en/sdk/multi-language-clients) 17. [record · service contractrecord/04](/en/sdk/verifier-service-contract) SDK docs · sdk/11 # Protocol state: stable, draft and absent What you can build on, what will keep moving under you and what is not there yet, with the order in which each missing piece is gated. ## Stable surfaces you can build on Plan against three tables: surfaces that are stable, surfaces still moving, and pieces that do not exist yet. Read the third before you commit a date to anyone. Surface What stability means Machine-readable artifact **Verifier service contract v1** Frozen. A change to decision semantics or to the reason-code vocabulary is major; new fields and new operations are minor. the public OpenAPI 3.1 edition, [`verifier-service.v1.yaml`](/openapi/verifier-service.v1.yaml) (`1.1.0`) **The nine acceptance conditions, in order** Behaviour, not configuration: nothing skips or reorders one. Changing one is major in the contract and in the Python SDK at once. the conformance vectors below are the executable statement **Canonical JSON** RFC 8785 with SHA-256 and lowercase hex, for the signed challenge body and the binding context. Changing it would change every digest, so it is major everywhere at once. the canonicalization declaration, bIP-0003 — [declaring how we hash](/en/blog/declaring-how-we-hash) **The decision vocabulary** Closed: 16 producible codes, 2 reserved and unreachable. No unknown code reaches you inside a contract major. the `reason_code` enum in the contract — [reason codes](/en/sdk/reason-codes) **The conformance suite** A case’s expected decision changing is major; new cases are minor. Every artifact declares the suite version it passed. the cross-language suite — [conformance & versioning](/en/sdk/conformance) ## Additive or draft surfaces Surface State What to pin **Substrate status read** Additive, versioned v0 beside the frozen contract, served only where the deployment is configured for it. Expect new fields. Branch on the closed verdict vocabulary; treat unknown fields as ignorable, not as errors. **Attestation standing read** Additive, versioned v0, same arrangement. Any failure degrades to an unknown verdict with a closed reason code. Same — and never read unknown as “fine”. It means the answer is not known. **Payment-identity profile** Draft, and it cannot freeze while one section of it is still open. The wire shape can still change. Nothing structural. Put it behind an adapter of your own. Both reads are described in [substrate reads](/en/sdk/substrate-reads), the profile in the [payment-identity profile](/en/sdk/payment-identity-profile). ## Not there yet Not there What that means for you **A package index release** No pip install mintid-verifier-sdk and no npm install @mintid-net/verifier-client yet: not yet on PyPI, not yet on npm. Build from the main project, https://gitlab.com/mintid/mintid, or from the mirror where there is one; the install lines are on getting started. **A published container image** Nothing to pull: the images are built from the source, and the local stack builds them on your machine. **A separately distributed proof engine** Not published as an artifact of its own: it is pinned in the source tree and built with the SDK, never fetched or substituted separately. **Self-service registration** Admission is processed by an operator — you submit a request, a person decides. The second verifier tier that would make it self-service is designed and not built. **Audit reports** An independent audit of the proof core’s implementation is scheduled as a quality milestone, as are the other audits in the programme; each publishes its scope before it starts and its findings when it closes. None is a precondition for relying on the production system. Beside the public testnet, the one production deployment today is the single-node production chain, in production since 20 September 2026 and operated by the CONECTIA group, with its issuer and verifier; ZadQ is the first product built on it (on the classical seller rail), and the CONECTIA group and ZadQ are related parties of MintID. Nothing measured there is independent adoption, and we do not present it as such. The proof core is built and in production on the single-node production chain, pinned by known-answer vectors that three languages check, and you can also build and test a full integration against injectable test doubles. Read `engine_pin` from the instance you are talking to: the pin is the fact, the release note is not. ## What gates what No dates here: the project publishes target windows, and a window can move. What holds is the order: * **Self-service registration** is gated on the second verifier tier. Until then every verifier and issuer is one an operator admitted — see [becoming a verifier](/en/sdk/becoming-a-verifier). * **The public testnet** is the only MintID deployment a third party may use to test. It runs on its own valueless denomination, `utestmint`, from an open faucet; a verifier of your own can self-register there in the permissionless tier, while the admitted tier has no path on it — see [the public testnet and its KYC sandbox](/en/developers). * **No audit gates the steps above.** Each audit in the programme is a scheduled milestone whose findings are published; relying on the production system, public statements about what it does, and the order above do not wait for one. If a plan of yours depends on one of these, say so early: the order is fixed, and how soon each step comes is open to conversation. [previous← becoming a verifier](/en/sdk/becoming-a-verifier)[nextrecord · assurance vocabulary →](/en/sdk/kyc-trust-model) --- Source: https://mintid.net/en/sdk/protocol-state · Protocol state: stable, draft and absent · MintID SDK docs --- > The MintID whitepaper (Protocol Whitepaper v1.0 and its Executive Edition, as PDF), the agent-identity concept and market paper, the related-party economic-viability review, and the role manuals for holders, issuers, validators and verifier-SDK users. Each document is versioned and dated, and its cover says what runs today and what is still design. Documentation # Every public document, dated, with its limits on the cover The whitepaper, the concept paper and the role manuals, each versioned and dated: a v1.0 protocol whitepaper, a v3.0 concept and market paper and v0.2 editions of the role manuals (October 2026), for a protocol running on the single-node production chain. WHITEPAPER V1.0 · MANUALS V0.2IN PRODUCTIONNOTHING IS FOR SALE The papers ## Protocol Whitepaper v1.0 The whole protocol in one document: the problem, the invariants, the chain, credentials and presentations, the agent layer, the standards decisions and why they were made, the security model, the token economics as ratified priors, governance and the foundation, the staged launch plan and the implementation status as of October 2026. Technical and non-normative — the specifications remain the design source of truth. It is not the MiCA crypto-asset white paper, and nothing is for sale. [WP ### Protocol Whitepaper Verified once, proven anywhere, revealed nowhere: how MintID lets regulated issuers vouch for people and the AI agents they deploy without putting a single identity on a public ledger. Version 1.0 · 4 October 2026 · 42 pages. Technical, non-normative. Not a MiCA crypto-asset white paper; nothing is offered for sale. Download PDF](/docs/MintID-Whitepaper.v1.0.pdf)[EXEC ### Executive Edition A sovereign Layer-1 for privacy-preserving, KYC-backed identity: verified once, proven anywhere, revealed nowhere — for people and for the AI agents they deploy. Version 1.0 · 4 October 2026 · 12 pages. The condensed companion to the whitepaper, for readers who need the whole argument in one sitting. Download PDF](/docs/MintID-Whitepaper-executive.v1.0.pdf)[PAPER ### Verifiable Human-Backed Agent Identity — Concept and Market Paper A person verifies their identity once. Every software agent that person deploys can then prove, to anyone, that a verified and accountable human stands behind it, without revealing who that human is. Version 3.0 · September 2026 · 17 pages. The eight use cases, each with its status, and the market they address. Not a MiCA crypto-asset white paper; nothing is offered for sale. Download PDF](/docs/Agent-Identity-Concept-and-Market-Paper.pdf) Version 1.0 of 4 October 2026, revised in place, supersedes the August 2026 draft. Beside it sits the concept and market paper, the plain-language account of what MintID is for. Prefer to read the whitepaper on the site? The plain-language tour is linked below. Role manuals ## One manual per role Each manual is a self-contained guide to the role it describes, written for the people who will take on that role. The October 2026 editions (v0.2) follow Protocol Whitepaper v1.0 and describe the protocol as it is designed. [HOLDER ### Holder Manual Verify once, prove what a service needs, and keep who you are to yourself — a plain guide for people and for anyone who deploys AI agents. For people and agent operators. Version 0.2 · October 2026 · 14 pages. Describes the designed protocol. MintID ships a headless holder library (Rust, with Python, Go and TypeScript bindings) that runs in the holder’s own infrastructure. There is no consumer wallet and none is planned. A wallet somebody else builds, including an EUDI wallet, can present over the same standard transports. Download PDF](/docs/MintID-Holder-Manual.pdf)[ISSUER ### Issuer Manual How a regulated KYC organisation becomes an accepted MintID issuer, what it must operate, and what it commits to once it is live. For KYC providers and regulated issuers. Version 0.2 · October 2026 · 13 pages. Not legal advice. Download PDF](/docs/MintID-Issuer-Manual.pdf)[VALIDATOR ### Validator Manual What it means to secure an identity-first chain: the role, what you need, the road to genesis, your obligations, the economics as ratified and the risks. For validator operators and delegators. Version 0.2 · October 2026 · 13 pages. Token values are ratified bands and priors. Download PDF](/docs/MintID-Validator-Manual.pdf)[SDK ### Verifier & SDK Manual How a relying party becomes a registered MintID verifier and accepts privacy-preserving presentations through one verification pipeline and a public service contract. For relying parties and integrators. Version 0.2 · October 2026 · 15 pages. Download PDF](/docs/MintID-Verifier-SDK-Manual.pdf) None of these is a MiCA crypto-asset white paper. Also on file ## The tour and the review [WP ### The whitepaper, online A plain-language tour of the whitepaper, readable on this site: the problem, the invariants, the life of a credential, the agent layer, the economics, governance, the staged launch and where the build stands. The specifications behind it are shared on request. Read online](/en/whitepaper)[REVIEW ### Economic-viability review by a related party (July 2026) The July 2026 review of the full document corpus, performed by Conectia PRO, a related-party service provider to the protocol, and published as written. The token-allocation model it analyses is under review; the report stays published as dated history. Download PDF](/docs/MintID-Economic-Viability-Audit-2026-07-30.pdf) What the review found, and what the project changed in response, is set out in [the post on the review](/en/blog/we-audited-ourselves). --- Source: https://mintid.net/en/docs · Docs: the MintID whitepaper, concept paper and role manuals (PDF) — MintID --- > ZadQ, the first product built on MintID, is an x402 seller-verification service operated by the CONECTIA group, a disclosed related party: sellers show with an issuer-signed attestation that an accountable, KYC-verified party stands behind their payment address. A pilot on the single-node production chain. [](https://zadq.app)Pilot on MintID # An API paid per request, with an accountable party behind the address ZadQ is the first product built on MintID, an x402 seller-verification service operated by the CONECTIA group, a disclosed related party. Through ZadQ, an x402 seller (an API, data or content endpoint paid per request in stablecoins) shows, with an issuer-signed attestation, that an accountable, KYC-verified person or organisation stands behind its payment address, without naming who. PILOTSINGLE-NODE PRODUCTION CHAINRELATED PARTY How it works ## A seller attests once, and every buyer checks it for free 01 ### The seller is verified once An accepted issuer verifies the party behind the seller and issues a conventional, issuer-signed attestation for its payment address and resource. This version, on the classical seller rail, makes no zero-knowledge claim: the seller’s endpoint is public, so unlinkability would add nothing there; the zero-knowledge seller rail follows. 02 ### Buyers read the signal for free Explorers and buying agents check the attestation through MintID’s free verification path before they pay. 03 ### A verifier keeps it current A registered verifier re-checks each seller on a published cadence and publishes its own signed verdict: active, suspended, revoked or unknown. 04 ### Standard MintID parts, no protocol change The pilot is an ordinary issuer-and-verifier pairing. It needs no change to the protocol. Who it is for ## Sellers with something at stake Sellers and agents with meaningful economic volume, and regulated business counterparties. For them, the attestation brings privacy and compliance by design today; funded recourse is specified and scheduled for the financial-recourse stage of the MintID network. The pilot makes no promise of cost savings. How it runs ## The pilot changes one thing per step: the proof form, then the topology The distributed MintID network does not exist yet, so the pilot runs on the single-node production chain and changes one thing at each step. 01 We are here ### Single-node production chain ZadQ runs today on the single-node production chain, in production since 20 September 2026 and operated by the CONECTIA group. The chain runs MintID’s own code without a fork; it is not yet the distributed MintID network. 02 Upcoming ### Zero-knowledge proofs on the same chain The ten-second zero-knowledge presentation already runs in production. This step, specified and scheduled, moves seller attestations onto it on the same chain: the zero-knowledge seller rail. Buyer-side agent credentials come with MintID’s agent product, and they will use zero knowledge from the start. 03 Upcoming ### On the MintID network If that network is launched, the topology changes: the pilot moves onto the distributed MintID network. Until then, nothing measured on the single-node production chain counts toward the network’s traction criterion. Evidence ## What the pilot measures Success criteria are set in advance and measured. Four signals decide whether the pilot scales: 01 Sellers sign up for the paid service. 02 Attested sellers stay beyond 90 days. 03 Explorers show the verdict to buyers. 04 Verifiers ask for the signal. Pilot activity is reported as a related-party pilot and excluded from the network’s traction criterion. Who runs it ## Operated by the CONECTIA group, a disclosed related party The pilot is operated by [Conectia PRO](https://conectia.pro), part of the CONECTIA group and a disclosed related party of MintID; ZadQ is the group’s own product line. Payment addresses held by a third party on a seller’s behalf are outside this version. ZadQ’s own site is [zadq.app](https://zadq.app). ## Take part in the pilot zadq.app describes ZadQ in full, and the whitepaper explains where the pilot sits in MintID’s plan. Sellers, explorers and verifiers who want to take part can get in touch. [Get in touch](/en/contact)[Visit zadq.app](https://zadq.app)[Read the whitepaper (PDF)](/docs/MintID-Whitepaper.v1.0.pdf) --- Source: https://mintid.net/en/x402-pilot · ZadQ — the x402 seller-verification pilot on MintID --- > Where MintID’s code is (open source, Apache-2.0), which packages exist and how they install today, the public testnet with its KYC sandbox as the only place a third party tests, and how to reproduce the revocation trace. Developers # The code is public, and the public testnet is the only place a third party tests it The whole implementation is open source under the Apache License 2.0. The packages build from the main project until they reach a registry. The public testnet runs the same software and parameters as production, with a KYC sandbox whose outcomes you choose, where nothing issued carries weight. The revocation trace shows the guarantee against a running deployment. STATUS: LIVENOTHING ISSUED CARRIES WEIGHTTEST TOKENS: NO VALUE A · The code ## One main project holds the whole implementation **The code.** MintID’s implementation is open source under the Apache License 2.0. The main project holds all of it: the chain, the proof core and the holder library, the verifier and issuer services, the self-revocation relay, the SDKs, the test harness, a local stack that runs on your machine, and the developer documentation. Project What it is [https://gitlab.com/mintid/mintid](https://gitlab.com/mintid/mintid) the main project: the whole implementation; issues and merge requests go here [https://gitlab.com/mintid/sdk-typescript](https://gitlab.com/mintid/sdk-typescript) read-only mirror of the TypeScript client [https://gitlab.com/mintid/verifier-mcp](https://gitlab.com/mintid/verifier-mcp) read-only mirror of the MCP server [https://gitlab.com/mintid/sdk-python](https://gitlab.com/mintid/sdk-python) read-only mirror of the Python agent client [https://gitlab.com/mintid/sdk-go](https://gitlab.com/mintid/sdk-go) read-only mirror of the Go holder binding The specifications whose requirement identifiers the code cites are not part of the repository. Contributions are welcome as issues and merge requests on the main project, signed off under the Developer Certificate of Origin. They are answered on a best-effort basis; there is no service-level agreement. **Reporting a vulnerability.** Write privately to **security@mintid.net**. Never open a public issue, merge request or discussion for a suspected vulnerability. There is no bug bounty programme today and no response-time commitment. No independent security audit of this implementation has been completed: audits are scheduled as milestones, and each audit’s findings will be published with their remediation when it closes. B · SDKs and MCP ## Every deployment runs the same verifying core, and the verifier is yours **The verifier is your own service.** A relying party runs the verifier SDK inside its own backend, or as a service next to it, and decides on its own service. Every deployment runs the same single verifying core; the clients and the MCP server carry no cryptography and no policy, and pointing them at somebody else’s verifier would hand that party the decision. Package What it is Install today `mintid-verifier-sdk (Python)` the verifier: one verifying core with the proof engine compiled in not yet on PyPI: build from the main project `@mintid-net/verifier-client (TypeScript, Node)` a transport-only client of your own verifier service, with the holder and agent clients not yet on npm: build from the main project or its mirror `@mintid-net/verifier-mcp (TypeScript)` an MCP server: the verifier contract as three agent tools, over stdio or Streamable HTTP not yet on npm: build from the main project or its mirror `mintid-agent (Python)` the agent client: credential custody, witness refresh, the identity leg of a paid request not yet on PyPI: build from the main project or its mirror `gitlab.com/mintid/sdk-go (Go)` the Go binding of the holder library fetched from its mirror The install lines are in the developer documentation, starting at [Getting started](/en/sdk/getting-started). **Try the tools on the public testnet.** Add the testnet’s MCP endpoint to an agent runtime, for example Claude Code: ``` claude mcp add --transport http mintid-testnet https://mcp.testnet.mintid.net/mcp ``` Its challenges are bound to the testnet’s sandbox verifier, so its decisions carry no weight. If a decision gates your business, run the server yourself, in front of your own verifier. What the three tools do, and where the trust boundary sits, is on [the MCP server page](/en/sdk/mcp-server). C · Sandbox ## One deployment to test on, and what it is made of **Status: live.** **The public testnet.** The public testnet is the only MintID deployment a third party may use to test. It runs the same software and the same chain parameters as the single-node production chain, with its own chain, keys and hostnames. The single-node production chain is not for third parties and is never a place to test. **A KYC sandbox.** Its issuer verifies nobody: when you open a KYC session you choose its outcome — approved at a grade from A1 to A4, declined, expired, abandoned, held in manual review, a date of birth the issuer cannot read, a provider that is unavailable, a session past its reuse window, and more — so every path of issuance and every error an integrator can meet is reachable on purpose. Nothing issued on the testnet carries weight: a credential, a grade, an agent or a decision obtained there says nothing about any person and must never be accepted anywhere else. **Limits.** The production parameters: a new status root every 30 seconds, roots accepted up to 180 seconds, presentations that live 10 seconds. Agent minting is limited as everywhere, to 5 agents per person per hour and 10 active. **Reset policy.** The testnet follows the software through ordinary deploys while the software keeps its shape. When it changes shape, the testnet is reset: a new chain identifier, new keys, an empty registry. Everything issued before is gone, with no migration and no notice period, because nothing on it carries weight. **Test tokens and the faucet.** The public testnet runs on its own denomination, `utestmint`: every fee and bond on it is denominated in `utestmint`, on the same paths production charges, at the testnet’s fee parameters. What a third party pays from a grant are the fees the chain charges its own account: a verifier’s self-registration on the permissionless tier and its renewal, 1 000 000 `utestmint` each. Agent mint and lease fees are not paid by a third-party key: the issuer’s operator account settles them, so the sandbox journey (KYC, credential, agents) needs no tokens. Anyone can obtain `utestmint`, free, from the faucet: one grant per address per 24 hours and one grant per source per hour, 100 000 000 `utestmint` each. The faucet links no address to a person. ## Hostnames Service URL Chain RPC `https://rpc.testnet.mintid.net` Verifier (the sandbox verifier) `https://verifier.testnet.mintid.net` Issuer (the KYC sandbox) `https://issuer.testnet.mintid.net` MCP server `https://mcp.testnet.mintid.net/mcp` Self-revocation relay `https://relay.testnet.mintid.net` Faucet `https://faucet.testnet.mintid.net` The chain identifier changes at every reset: read it, and the issuer and verifier ids, from the verifier’s status read rather than copying them from anywhere. `POST https://faucet.testnet.mintid.net/v1/faucet` with the testnet address to fund answers with the transaction hash; `GET https://faucet.testnet.mintid.net/v1/faucet/terms` returns the testnet terms. ## Testnet terms These four statements are the public testnet’s terms. 1. **Own denomination.** The public testnet runs on its own denomination, `utestmint`. It is not the token of any other MintID chain, present or future. 2. **Free from the faucet.** Anyone can obtain test tokens free of charge from the public faucet, within its rate limits. Test tokens are not for sale and have no value. 3. **No conversion.** Test tokens cannot be transferred or converted to any other chain or asset. No snapshot, points programme or conversion promise attaches to them, and testing creates no claim. 4. **Reset.** The public testnet, every balance on it included, may be reset at any time without notice. The same four terms are part of the [site terms](/en/terms); how a verifier reaches the testnet, and what the production chain answers instead, is on [becoming a verifier](/en/sdk/becoming-a-verifier). D · Reproduce ## The revocation trace times the guarantee against a running deployment **Reproduce the revocation trace.** The revocation trace runs the revoked-agent sequence against a running deployment and times it, per revocation path: the issuer revokes an agent; the agent pulls its own kill switch through the privacy relay; a person’s identity credential is revoked and its agents follow; the issuer publishes an emergency root. During each one an adversarial agent keeps forcing proofs with the newest witness it can still obtain. The record shows, per path, the last accepted decision, the first refusal with the verifier’s reason code, the deny point the protocol guarantees, and the status root that carried the revocation, together with the verifier’s status before and after. A control agent that was never revoked shows whether a refusal is about the revocation or about the root a proof was made against. **The guarantee.** An issuer revocation is refused by every verifier within the maximum root age plus a few seconds of clock tolerance — 185 seconds at the deployed values — and at once after an emergency root; an agent’s kill switch and a person-wide cascade within minutes, at bounds the record states for each path. The record also shows when this verifier actually refused in the run. That is an observation, faster than the bound and different from run to run; the bound is what you can rely on. Run it from a clone of the main project, against the local stack: ``` uv run python test-harness/trace/revocation_trace.py --target local ``` Against the public testnet, with public access only (the emergency path and the verifier’s own log need the operator, and are marked as not read): ``` uv run python test-harness/trace/revocation_trace.py --target testnet ``` --- Source: https://mintid.net/en/developers · Developers: the code, the SDKs, the public testnet and its KYC sandbox — MintID --- > The single-node production chain has produced blocks in Spain since 20 September 2026, operated by the CONECTIA group and keeping ZadQ’s accounting. The identity checks behind its attestations now run on a certified external provider, and the proof core is in production. Conectia PRO and ZadQ are related parties, so none of this is independent adoption. Blog · engineering # The single-node production chain is live — and the identity behind it is real now The single-node production chain has produced blocks in Spain since 20 September 2026, operated by the CONECTIA group and keeping ZadQ’s accounting. The identity checks behind its attestations now run on a certified external provider, and the proof core is in production. [Conectia PRO](https://conectia.pro/en/) and ZadQ are related parties, so none of this is independent adoption. by Marc Miró i Rierola·published 2026-09-22·updated 2026-10-04·6 min read Updated 2026-10-04: who issues and certifies; deployment wording. _The single-node production chain has been producing blocks in Spain since 20 September 2026, operated by the CONECTIA group and keeping the accounting of a real product. The identity verification behind its attestations is no longer a simulation, and three endpoints show any integrator the state of the chain._ On 20 September a MintID chain started producing blocks, and it has not stopped since. It runs in production on a single node; the distributed MintID network is still the target. ## One validator, one registry, a status root every thirty seconds The single-node production chain — one validator, operated by the [CONECTIA group](/en/about) through [Conectia PRO](https://conectia.pro/en/) as the accounting substrate of [ZadQ](/en/x402-pilot), the first product built on the protocol. Alongside the node run two services: an issuer agent, which opens verification sessions and signs attestations, and a verifier, which answers whether an attestation still stands. The chain holds the registry — who is an accepted issuer, with which keys and which live bond, which verifiers are admitted and on which exact origin — and, every thirty seconds, the issuer publishes a new status root: a single commitment to the state of every attestation it has issued. Accepted issuers verify people and issue the credentials; the chain publishes their status, their bonds and the registries; MintID itself issues nothing and certifies nothing. On the single-node production chain the first accepted issuer is operated by the CONECTIA group, a related party, on the same terms as any other. No personal data, no KYC evidence, no credential contents and no record of any verification ever touches that chain. The chain’s state has no field that could hold any of it. ## An integrator can check the chain from a terminal Three endpoints answer; integrators receive their addresses from the operator. The verifier reports the proof engine it is pinned to, and the issuer reports which identity provider is behind it — two facts that no release note can override. A verifier here does not take the issuer’s word: it reads the issuer’s status root from the chain with an inclusion proof, recomputes the Merkle witness for the attestation in question, checks the issuer is still authorised and still bonded, and only then says `active`. If the root is stale beyond its freshness window, the answer is not “probably fine” — it is `unknown`. ``` $ curl -s https:///status | jq '.result.sync_info.latest_block_height' "95257" $ curl -s https:///v1/build-info | jq '.engine_pin' "" $ curl -s https:///v0/build-info | jq '{rail, kyc_provider, heartbeat_seconds, linkage}' { "rail": "classical-seller-v0", "kyc_provider": "", "heartbeat_seconds": 30, "linkage": "in_sync" } $ curl -s https:///v1/status | jq '{substrate, issuer: .issuers[0] | {active, bond_ok, fresh, root_age_seconds}, promise}' { "substrate": "ok", "issuer": { "active": true, "bond_ok": true, "fresh": true, "root_age_seconds": 4 }, "promise": { "heartbeat_seconds": 30, "max_root_age_seconds": 180, "note": "roots are published every heartbeat_seconds and stay fresh up to max_root_age_seconds; a revocation lands in the next root" } } ``` The output above was captured on 22 September 2026; the block height and the root age will be different when you run it. The verifier’s public contract is documented on the [verifier service contract](/en/sdk/verifier-service-contract) page. A revocation is included in the next status root; at the reference values a verifier refuses a revoked credential in under a minute, and on the single-node production chain a root counts as fresh for up to 180 seconds. ## The identity checks now run on a certified provider, and the evidence never enters MintID When this chain went live, the identity verification behind its attestations was a simulation. It is not any more: the first issuer now runs an external provider, certified against the European standard for identity proofing, and the evidence — documents, images, everything a person hands over — stays with that provider and never enters MintID. What the issuer keeps is a verdict and an [assurance grade](/en/blog/grades-follow-eidas). What the chain holds is neither: only a commitment to the state of the attestations, which is why none of this is a privacy promise we ask you to take on faith. ## Running one node teaches what a paper cannot MintID’s design target is a permissionless, distributed network. Nothing about today changes that. But a protocol nobody operates is a paper; you learn what breaks by running something a real product depends on. So the protocol starts with one validator, a registry admitted when the chain started, and a product on top whose lifecycle now has a real ledger under it. The [CONECTIA group](https://conectia.pro/en/) funds the work as its own research. > **[Conectia PRO](https://conectia.pro/en/) and ZadQ are related parties of MintID.** Everything running on this chain today is a related-party pilot. Attested sellers, verifications, published roots — none of it counts as independent adoption, and none of it will ever be presented as traction. When we publish numbers that do count, they will come from operators we are not. ## Every byte of the chain lives in one Spanish region In Spain: the node, the file system that holds the accounting, the daily backups, the secrets and the infrastructure’s own state file all live in a single Spanish region, by decision. That is the residency claim a customer of a MintID operator can repeat to their own customers. It is a statement about where bytes are, and nothing more: no certification, no approval, no authority has blessed anything here. ## A restore drill found the one file the backup missed Two things worth passing on. First, a restore drill is not a restore: we rehearsed recovering the chain from a backup before trusting it, and discovered that the one file a running validator rewrites on every block is exactly the file the backup does not capture — the node refuses to start without it. Better found on a rehearsal than at three in the morning. Second, alarms that detect a failure by a metric _disappearing_ are slower than they look; ours take minutes, not seconds, and we wrote down the measured number instead of the number we hoped for. ## Next: operator consoles, then the path from one node to many The proof core — the credential and presentation engine — is built and in production. What the next months are for is the rest of the operator’s experience: consoles that let someone run an issuer or a verifier without reading logs, and the path from one node to the distributed network the protocol was designed for. Is this the distributed MintID network? Not yet. It is the single-node production chain, in production since 20 September 2026 and operated by the CONECTIA group, with a single validator node, running the first issuer, the first verifier and ZadQ, the first product built on the protocol. The distributed network remains the target. There is no token, no offer and no price. Who operates it? The CONECTIA group operates it through Conectia PRO. The MintID Foundation, a Netherlands Stichting, is being incorporated by the founder and stays dormant until the public-offer route is chosen. Conectia PRO and ZadQ are related parties of MintID, so nothing measured on this chain counts as independent adoption. Does the chain hold any personal data? No. The chain holds the registry — accepted issuers, their keys and bonds, admitted verifiers — and, every thirty seconds, a status root: a single commitment to the state of every attestation an issuer has issued. No personal data, no identity evidence, no credential contents and no record of any verification is part of that state. How can I check it myself? Three endpoints answer — the chain’s status, the issuer’s build information and the verifier’s status and build information; integrators receive their addresses from the operator. Together they show that blocks are being produced, which proof engine the verifier is pinned to, that a certified identity provider sits behind the issuer, and whether the issuer’s status root is fresh. ## Read the chain, not the post Every claim above is checkable from a terminal. If you want to integrate a verifier against it, start with the SDK. [Verifier SDK](/en/sdk)[Talk to us](/en/contact) --- Source: https://mintid.net/en/blog/anchor-chain-live · The single-node production chain is live — and the identity behind it is real now — MintID blog --- > If two implementations hash the binding of a ten-second presentation over different bytes, a valid proof fails or a wrong one passes. MintID now declares its rule — RFC 8785 canonicalization, then SHA-256 — cites every digest as a typed reference, and hashes Merkle-tree entries as raw bytes. Recorded as bIP-0003; existing integrations see the same bytes, and the rule follows an individual IETF submission on SCITT payload binding. Blog · engineering # Declaring how we hash: a small standard for the bytes behind a ten-second proof If two implementations hash the binding of a ten-second presentation over different bytes, a valid proof fails or a wrong one passes. MintID now declares its rule — RFC 8785 canonicalization, then SHA-256 — cites every digest as a typed reference, and hashes Merkle-tree entries as raw bytes. Recorded as bIP-0003; existing integrations see the same bytes, and the rule follows an individual IETF submission on SCITT payload binding. by Marc Miró i Rierola·published 2026-09-17·updated 2026-10-04·6 min read Updated 2026-10-04: profile availability and headings. _Why MintID now names its canonicalization algorithm, cites every digest with a type, and prepares its verdicts to be checked by anyone — without asking anyone to trust us._ A MintID [presentation](/en/technology) lives for ten seconds. In that window a verifier sends a signed challenge, the holder answers with a zero-knowledge proof bound to that exact challenge, and the verifier decides. Everything about the binding — which origin, which verifier key, which nonce, which policy, which finalized block — is folded into one 32-byte digest. If two implementations compute that digest over different bytes, a perfectly valid proof fails, or worse, a proof made for one challenge is accepted for another. So the boring question matters: _which bytes, exactly?_ ## One language wrote the bytes, so only one language could check them Until now the answer was implicit: “the JSON our reference implementation emits” — sorted keys, no whitespace. It worked because one language wrote it. It stops working the moment a second language has to reproduce it byte for byte, which is precisely what our [verifier SDKs in other languages](/en/sdk/multi-language-clients) do. ## MintID now names its algorithm: RFC 8785, then SHA-256 MintID now _declares_ its canonicalization algorithm. Every JSON object we hash, sign or cite by digest is canonicalized with the JSON Canonicalization Scheme of [RFC 8785](https://www.rfc-editor.org/rfc/rfc8785), then hashed with SHA-256. There is a name for that combination in a recent IETF document, _Canonicalization Declaration for SCITT Signed Statements_ ([`draft-mih-sokolov-scitt-payload-binding`](https://datatracker.ietf.org/doc/html/draft-mih-sokolov-scitt-payload-binding-05)), an individual submission circulated on the SCITT working group’s list, and we use its vocabulary: the algorithm is called `jcs`; digests are cited as _typed digest references_ — a reference says what kind of object it points at and how the digest was made; and anything placed in a Merkle tree or a transparency log is hashed as raw bytes, never as hexadecimal text. Small rules, each with a specific failure mode behind it. > **What changed for existing integrations: nothing.** For the payloads MintID actually sends, the new rule produces the same bytes as the old one. Every frozen [conformance vector](/en/sdk/conformance) is unchanged. What changed is that an implementer in Go, TypeScript or PHP can now point at an RFC instead of at our Python. ## Verdicts a third party can timestamp and check later A MintID verifier does not only decide; it can _publish_. An [x402 explorer](/en/x402-pilot) that re-checks a seller’s human-backing every few hours could publish its own signed verdict: “human-backed at this assurance level, verified at this time, re-checked every N hours.” The same draft describes how such a statement should be packaged — a COSE signed statement ([RFC 9052](https://www.rfc-editor.org/rfc/rfc9052)) with a content-derived identifier — so that a transparency service can issue a receipt for it and any third party can later verify that the verdict existed, unchanged, at that time. MintID does not run a transparency service and does not need one: verification of a MintID claim carries no protocol fee, and anyone can recompute a verdict’s inputs against the chain. A receipt adds independent, time-stamped evidence on top. Our [x402 profile](/en/blog/x402-web-bot-auth-identity-profile) now records this packaging as the shape our published verdicts will take. ## The proof and the chain stay exactly as they were The zero-knowledge proof itself is a binary object and is not canonicalized as JSON; the rule covers what the proof is _bound to_, not the proof. No on-chain logic changes. No new field carries anything about a holder: typed references point at public objects — a status root, an issuer’s public definition, a challenge — and nothing else. ## Naming the algorithm is the cheapest interoperability there is Identity infrastructure is judged on interoperability and on what can be verified without trusting the operator. Naming the algorithm is the cheapest possible investment in both. The profile is recorded as bIP-0003, available on request, and the draft we align with is an individual submission we will track as it evolves; where an RFC already exists, we adopt it. ### References * bIP-0003 — Canonicalization declaration and typed digest references — the MintID profile, available on request * [RFC 8785 — JSON Canonicalization Scheme (JCS)](https://www.rfc-editor.org/rfc/rfc8785) * [RFC 9052 — CBOR Object Signing and Encryption (COSE): Structures and Process](https://www.rfc-editor.org/rfc/rfc9052) * [RFC 9943 — An Architecture for Trustworthy and Transparent Digital Supply Chains (SCITT)](https://www.rfc-editor.org/rfc/rfc9943) * [RFC 9995 — COSE Hash Envelope](https://www.rfc-editor.org/rfc/rfc9995) * [draft-mih-sokolov-scitt-payload-binding-05 — Canonicalization Declaration for SCITT Signed Statements](https://datatracker.ietf.org/doc/html/draft-mih-sokolov-scitt-payload-binding-05) — individual submission, 11 September 2026 What changed for existing MintID integrations? Nothing. For the payloads MintID actually sends, the declared rule — RFC 8785 canonicalization followed by SHA-256 — produces the same bytes as the previous implicit rule. Every frozen conformance vector is unchanged. What changed is that an implementer in another language can now point at an RFC instead of at the Python reference implementation. Does MintID implement SCITT? No. MintID adopts the parts that already stand on RFCs — RFC 8785 for canonicalization, RFC 9052 for COSE signed statements, RFC 9995 for the hash-envelope shape — and cites the SCITT payload-binding draft as an alignment target. That draft is an individual IETF submission (version 05, September 2026), not a standard, and MintID makes no claim about its future. What is a typed digest reference? A digest cited together with what kind of object it points at and how the digest was computed — the canonicalization algorithm and the hash. A bare 32-byte value can be mistaken for the digest of the wrong object or the wrong bytes; a typed reference cannot. Does this touch the zero-knowledge proof? No. The proof is a binary object and is not canonicalized as JSON; the rule covers what the proof is bound to — the challenge, the policy, the chain state — not the proof itself. No on-chain logic changes, and no new field carries anything about a holder: typed references point at public objects only. ## Point at an RFC, not at our code If you are implementing a MintID verifier client in another language, the bytes are now specified. Tell us where the profile is unclear. [Verifier SDK](/en/sdk)[Talk to us](/en/contact) --- Source: https://mintid.net/en/blog/declaring-how-we-hash · Declaring how we hash: a small standard for the bytes behind a ten-second proof — MintID blog --- > MintID’s four assurance grades, A1–A4, map onto eIDAS, ISO/IEC 29115, ETSI TS 119 461, NIST IAL and EU anti-money-laundering law. The issuer publishes age separately as a freshness band, F1–F4, and a credential expires with its verification: twelve months for A1 and A2, six for A3, three for A4. Blog · design note # How we grade identity — and how we keep it fresh MintID’s four assurance grades, A1–A4, map onto eIDAS, ISO/IEC 29115, ETSI TS 119 461, NIST IAL and EU anti-money-laundering law. The issuer publishes age separately as a freshness band, F1–F4, and a credential expires with its verification: twelve months for A1 and A2, six for A3, three for A4. by Marc Miró i Rierola·published 2026-08-22·updated 2026-10-04·7 min read Updated 2026-10-04: freshness band, ZadQ’s bar and expiry. Two decisions taken in August 2026 shape what a MintID attestation means. Each follows a published standard rather than a number we picked, and the parts that are ours are named as ours. ## Grades measure strength, and they follow eIDAS A MintID credential carries an [assurance grade](/en/glossary#assurance-grade), A1 to A4. We had to answer what each grade _certifies_, and we took the answer from the European framework. eIDAS, ETSI and NIST all tier identity proofing by how robust the identification was — evidence, biometric liveness, screening, supervised presence — and none of them by its age. Europe’s framework has three tiers (eIDAS low · substantial · high). MintID has four. Rather than inventing a fourth European level, we anchor on the four-level backbone eIDAS itself is built on, ISO/IEC 29115, and we use the one step that European anti-money-laundering law inserts between a substantial identification and a qualified one: enhanced due diligence. Grade What it certifies eIDAS ISO/IEC 29115 Remote proofing (ETSI) · US (NIST) AML regime **A1** Identity document validated against authoritative sources; for a company, the legal entity validated at the registry low LoA 2 — · IAL1 customer due diligence **A2** A1 plus possession proven with biometric liveness; for a company, a verified representative entitled to act substantial LoA 3 Baseline · IAL2 customer due diligence **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 enhanced due diligence **A4** A3 plus qualified proofing: a high-assurance eID, the EU Digital Identity Wallet, or a qualified provider high LoA 4 Extended · IAL3 enhanced, qualified Two consequences worth noting. ISO’s lowest level — a self-asserted identity — sits _below_ MintID’s floor and is out of scope: every MintID credential is backed by a real verification. And the vendor certifications that matter in Europe (ETSI TS 119 461, the standard behind qualified remote onboarding) map directly onto A2 and A4, so a certified provider slots in without a bespoke mapping exercise. > **What this does not change.** The protocol specification already described the four grades in these terms. The standards columns are mappings, not redefinitions, so this was recorded as an architecture decision and required no change to the frozen specification. ## Freshness is a second axis, not a grade A natural instinct is to let grades decay: a month-old verification is “better” than a year-old one. We checked eIDAS, ETSI, NIST and EU anti-money-laundering law; none of them does. eIDAS, ETSI and NIST all leave the validity of a proofing result to policy; anti-money-laundering law governs _updating_ by risk and by events, not by the level of the original check. So the issuer publishes age separately, next to the grade, as a [band](/en/glossary#freshness-band) rather than a date: a date is close to unique and lets observers join records; a band is shared by many holders and gives them far less to join. Strength · how well we know _who_ Freshness · how _recently_ A4 — + qualified proofing F4 — under 30 days A3 — + screening F3 — under 90 days A2 — + liveness F2 — under 180 days A1 — document, no biometric F1 — under a year A weak grade can be very fresh and a strong one can be old; a relying party states what it needs on both axes. For ZadQ, the first product built on MintID, the claim [_human-backed_](/en/agent-kyc) is defined 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. Any other relying party sets its own bar on both axes. ### A verification backs credentials for three to twelve months, then it expires Once a person or company has been verified, that verification can back further attestations for a bounded period — after which the credential expires, with no grace period and no extension, and the way back is a new verification. We wanted that period to come from a standard, not from us. It does, at two layers: * The **legal envelope** is the EU anti-money-laundering regulation: customer information must be updated at most every year for customers under enhanced due diligence (our A3 and A4) and at most every five years otherwise. * Inside that envelope, the period is the protocol specification’s own default validity per grade: twelve months for A1 and A2, six for A3, three for A4 — stricter than the law, and the same for natural and legal persons. No framework distinguishes the two in update periodicity, and the company-specific facts (representative, beneficial owners) already live in the grade, not in the clock. Expiry is not revocation. A credential expires exactly when the verification behind it does, with no grace period; only the holder’s own revocation (a withdrawal of consent) or a deliberate issuer action revokes. The rest of MintID is unchanged underneath: the grade threshold travels as a provable claim inside a [zero-knowledge presentation](/en/technology), so a verifier receives “grade ≥ A2” and never the document, the date or the person. The freshness band is published by the issuer next to the grade and read on the classical seller rail; it is not proven. What does a MintID assurance grade certify? How robust the identification was — evidence, biometric liveness, screening, qualified proofing — mapped onto published frameworks: eIDAS low/substantial/high, ISO/IEC 29115 levels 2–4, ETSI TS 119 461 Baseline/Extended for remote proofing, NIST IAL1–3, and the customer/enhanced due-diligence regimes of EU anti-money-laundering law. A1 is a validated document, A2 adds liveness, A3 adds screening, A4 adds qualified proofing. eIDAS has three levels. Why does MintID have four? Because MintID anchors on the four-level backbone eIDAS is built on, ISO/IEC 29115, and uses the one step European anti-money-laundering law inserts between a substantial identification and a qualified one: enhanced due diligence. That step is A3. ISO’s lowest level — a self-asserted identity — sits below MintID’s floor and is out of scope. Does a grade decay as the verification ages? No. None of the frameworks MintID maps to tiers identity proofing by age, so neither does MintID. Freshness is published by the issuer as a second axis, as a band (F4 under 30 days, F3 under 90, F2 under 180, F1 under a year) rather than a date: a date is close to unique and lets observers join records; a band is shared by many holders and gives them far less to join. A presentation proves the grade threshold; the band is read on the classical seller rail and is not proven. How long can one verification be reused? Inside the legal envelope of EU anti-money-laundering law (customer information updated at most every year under enhanced due diligence, at most every five years otherwise), the protocol’s default validity per grade is stricter: twelve months for A1 and A2, six for A3, three for A4 — the same for natural and legal persons. A credential expires exactly when the verification behind it does, with no grace period and no extension; the way back is a new verification. Expiry is not revocation. Did this change the protocol specification? No. The frozen specification already described the four grades in these terms. The standards columns are mappings, not redefinitions, so the decision was recorded as an architecture decision and required no change to the specification. ## Strength and freshness, stated on their own axes If you issue credentials under eIDAS, ETSI or an AML regime, the mapping is already done. We would like to hear where it does not fit. [For issuers](/en/issuers)[Talk to us](/en/contact) --- Source: https://mintid.net/en/blog/grades-follow-eidas · How we grade identity — and how we keep it fresh — MintID blog --- > In August 2026 MintID ran its first end-to-end test on an internal testnet — a chain node and the verifier service, rebuilt from a reproducible package: proof-backed reads, live ten-second challenges, a minimal decision record and a complete MCP session. The same month’s re-freeze of the specifications fixed the token design for a possible public network: the 108,000,000 hard cap, ratified allocation bands, a price-independent launch gate. The protocol cuts and their allocation are under review. Blog · milestone # The first live network: running, not written In August 2026 MintID ran its first end-to-end test on an internal testnet — a chain node and the verifier service, rebuilt from a reproducible package: proof-backed reads, live ten-second challenges, a minimal decision record and a complete MCP session. The same month’s re-freeze of the specifications fixed the token design for a possible public network: the 108,000,000 hard cap, ratified allocation bands, a price-independent launch gate. The protocol cuts and their allocation are under review. by Marc Miró i Rierola·published 2026-08-02·updated 2026-10-04·11 min read Updated 2026-10-04: token allocation, status and wording. Two things happened on the same day in August 2026. We ran the first end-to-end test of the protocol on an **internal testnet** — the chain and the verifier service, deployed on the CONECTIA group’s infrastructure. And after the re-freeze of the specifications that answered [our own audit](/en/blog/we-audited-ourselves), the token design for a possible public network became a register of **closed questions**, each with a normative source you can hold us to. ## An internal testnet you can rebuild from zero in minutes This was an internal testnet: a chain node plus the verifier service, deployed on infrastructure we operate, for our own testing, with no third-party validator accounts, no join kit and no published endpoints. The achievement is that it is **reproducible**. The whole network came from a bring-up package: tear it down, rebuild it from zero, and you got the same network in minutes. For a protocol whose whole posture is “the corpus is the source of truth”, the deployment being a derived artifact is the property worth having first. ## Every reading proved itself against finalised state The first test passed everything that stage could prove. The chain finalised continuously. And the readings that matter were not taken on trust: * **Reads that prove themselves.** The verifier’s on-chain registration and its exact HTTPS origin were not just _claimed_ by an RPC answer — they were read from outside through authenticated store proofs checked against a light-client-verified header — the same fail-closed path the verifier uses. An answer that cannot prove itself against finalised state simply does not count. * **Live challenges, correctly bound.** Ten-second presentation challenges were issued live, bound to the registered verifier identity, the exact audience origin and a finalised chain height — and they expired on schedule. * **A rejection that leaves almost nothing behind.** A deliberately invalid presentation was rejected with a reason code from the closed vocabulary — and the only thing the verifier retained was the minimal decision record: the outcome, the reason and the session it belonged to. No proof bytes and no attributes. * **The agent surface, driven end to end.** We ran a complete live session through the verifier’s [MCP server](/en/blog/verification-is-a-tool-call) — the same three tools any agent framework would call — and the contract boundary held: a rejection is a successful tool result with a reason code; only transport failures are errors. In our own bring-up, every failure traced to deployment tooling, fixed on the spot; none traced to protocol code. The proof engine was not part of that bring-up: it followed with the cryptographic-core milestone, and **the proof core now runs in production** on the single-node production chain, in production since 20 September 2026 and operated by the CONECTIA group. Every answer proved itself against finalised state, on a running network. ## The token design for a possible public network, as frozen in August 2026 Everything below describes the token of a possible public network. No such token exists today: MintID runs on a permissioned single-node production chain and needs none. The August 2026 re-freeze left that design as a register of closed questions. Closed as in _policy_: each item below has normative text in the frozen corpus, and changing any of them has a procedure, not a mood. The pattern to notice across all of them: the **mechanism is committed, the bands are ratified, the points are commissioned** — to an independent simulation, never to us. Fixed What the policy says The money supply A hard cap of 108,000,000, immutable, counted against everything ever minted. Emission is strictly decreasing and there is no re-mint, ever. The genesis split Ratified bands: 15% development and team (native on-chain vesting over four years, one-year cliff, plus a twelve-month lock-up), 20–25% public tranche, and at least 60% reserved exclusively for validator emission. The final points inside those bands are set by the independent economic simulation — never by us. Insider genesis accounts do not delegate, do not vote, and do not count toward the launch-gate arithmetic. The launch gate Denominated in measurable, price-independent units: bonded stake as a share of the max supply, the number of independent validator operators, a Nakamoto-coefficient floor, and an estimated attack cost in fiat under a published, price-independent methodology. The concrete thresholds are outputs of the simulation, frozen with the genesis parameters. No threshold depends on a market price. Validator bootstrap Professional operators are recruited through service contracts — fiat or stablecoin, twelve to twenty-four months, paid from the operating budget — an instrument an operator can actually sign. Discretionary retroactive grants remain a possibility, not the recruitment mechanism. The flows that scale The two flows that grow with the agent population — per-agent mint/lease and consented disclosure — carry normative, non-zero protocol cuts. They may not ship parameterless. The cuts and their allocation are governed parameters under review; once decided, they follow the same discipline as every other value, under governance and versioning. The security budget after emission When the reward pool is exhausted, the validator budget is the fee market: transaction fees plus whatever share of the protocol cuts governance directs to validators, once their allocation is decided. The simulation must model it under published scenarios, and if it falls short there is a written, ordered list of successor options — and a post-cap mint is not on it, at any position. The reward pool has exactly one use: validator emission. No other drain exists or can be created. The registry’s microeconomics The minimum issuer bond is sized against a published deterrence target in fiat, under the same price-independent methodology as the gate, reviewed annually. Bond exhaustion auto-suspends deterministically — no discretion, no grace — and the body that adjudicates slashes can never profit from unclaimed remediation. Who sets the numbers The economic simulation is an external engagement under a published statement of work whose deliverables cover every open point — allocation, gate thresholds, the protocol cuts and their allocation, the post-emission fee-market model, the minimum bond, participant break-evens. Internal tooling may assist it, never substitute for it. And if the review objects to any frozen value, genesis does not proceed on the objected value: the finding goes on record and the value is re-decided before the genesis file is built. Read top to bottom, the table fixes four things: the cap counts everything ever minted; the insiders hold the smallest band, vested, locked and without votes; every launch-gate unit is independent of market price; and the end of emission has a written plan that never prints more tokens. The allocation of each protocol cut is under review. Every number a reader could distrust is assigned to an external owner with a published band it must land inside. The full picture — bands, vesting, gate, cuts, the post-emission plan — lives on the [tokenomics page](/en/tokenomics), which now derives from this same frozen register. ## Verification carries no fee and stays outside consensus One thing stayed exactly where it was through all of this: the **consensus firewall**. Verification carries no fee by construction, presentations never touch the chain, and off-chain service revenue never influences consensus rewards. The testnet exercised exactly that separation live — the chain finalised while the verifier decided, and neither needed the other’s economics — and the frozen specifications keep it normative. It is the property everything else in the design leans on, and it is the one we will keep repeating. Everything a reader can hold us to is now written, frozen and marked; everything numeric that remains open has a named, independent owner and a published band it must land inside. Since August 2026, part of what is written also runs; since 20 September 2026, it runs in production on the single-node production chain. Can I join the testnet or run a validator on it? No. The August network was an internal testnet: a deployment on our own infrastructure, for our own testing, with no third-party validator accounts, no join kit and no published endpoints, stopped and rebuilt at our discretion. What runs today is the single-node production chain, in production since 20 September 2026 and operated by the CONECTIA group, with a single validator node. A package for third parties is future work, and it will be announced as such when it is decided. Are zero-knowledge proofs being verified on this network? Not on this August testnet: it brought the full verification pipeline up end to end — registration, proof-backed reads, challenges, decision records, the MCP surface — while the proof engine followed with the cryptographic-core milestone. That engine has since been built: the proof core now runs in production on the single-node production chain, with credential issuance, selective-disclosure presentations and the non-revocation path. Does the August testnet mean a token is for sale? No. Nothing is for sale: no token sale, no pre-sale, no whitelist, no price, no date. The project has committed, as ratified policy, to exactly one route by which an offer could ever exist — the complete EU MiCA Title II process: crypto-asset white paper, notification to the regulator, public offer, and only then admission to trading. This post is an engineering and governance record, not an invitation. So what numbers are actually decided? The structure is decided; the points are commissioned. Decided and frozen: the 108,000,000 hard cap, the 15% / 20–25% / at-least-60% genesis bands with their vesting and lock-up, the price-independent units of the launch gate, the existence of the protocol cuts (their allocation is under review), the single-use reward pool, and the deterrence-based minimum bond. Commissioned to the independent economic simulation, constrained to those bands: every final point, threshold and fee. No number moves outside a published band, and no band point comes from us. ## The protocol runs; the token stays a design The tokenomics page carries the full register — bands, gate, cuts and the post-emission plan — and the protocol page explains the pipeline the first test just exercised end to end. [Tokenomics](/en/tokenomics)[The protocol](/en/protocol) --- Source: https://mintid.net/en/blog/first-live-network · The first live network: running, not written — MintID blog --- > In July 2026 Conectia PRO — the related-party group that conceived MintID and is building it — audited MintID’s economic viability against its own frozen corpus, before any token existed. The verdict, quoted whole: a qualified opinion, with the demand thesis corroborated against independent sources and five critical findings. The specification corpus was re-frozen within days with five written answers; the report is published unedited. Blog · transparency # We audited ourselves before anyone asked In July 2026 [Conectia PRO](https://conectia.pro/en/) — the related-party group that conceived MintID and is building it — audited MintID’s economic viability against its own frozen corpus, before any token existed. The verdict, quoted whole: a qualified opinion, with the demand thesis corroborated against independent sources and five critical findings. The specification corpus was re-frozen within days with five written answers; the report is published unedited. by Marc Miró i Rierola·published 2026-08-02·updated 2026-10-04·9 min read Updated 2026-10-04: token allocation, status and wording. In July 2026, before any token, any sale or any request from anyone, we put MintID through a full **economic-viability audit** of the economics: the tokenomics, the unit economics, the solvency of every participant, the survivability of the project itself — against our own frozen document corpus. The authorship is on the cover: the audit was performed by **[Conectia PRO](https://conectia.pro/en/)**, which belongs to the [CONECTIA group](https://conectia.pro/en/), the group that conceived MintID and is building it: the development company, the operator of the first issuer, the first verifier, the reference implementations and the anchor product, and the funder of the pre-genesis work. That makes it a related party in every role it holds, and each role is disclosed as such rather than dressed up as an arm’s-length third party — which is exactly why the report names its author. The MintID Foundation, a Netherlands Stichting, is being incorporated by the founder and stays dormant until the public-offer route is chosen; the group’s positions carry no protocol privilege, and its issuer and verifier run on the same bond, admission and status-root terms as anyone else’s, verifiable on-chain. So read this as what it is — a related-party audit, run with audit discipline, with its complete verdict and findings register published here so you can judge the work rather than the name on it. The [full report](/docs/MintID-Economic-Viability-Audit-2026-07-30.pdf) is published as written. The token-allocation model it analyses is under review; the report, and the answers below, stay published as dated history of the August 2026 re-freeze. This post explains what it asked, what it found, and what the project did about it — within days. ## The audit asked whether every participant can stay solvent The audit took the perspective of a prospective investor and a prospective validator and asked the questions an investor’s diligence would ask first: can every participant in this system be solvent? Does protocol revenue actually scale with adoption? Can the launch gate even be _measured_? Can the project survive to mainnet — and past it? An audit this close to home earns exactly as much trust as its method shows, so the method is the point: it worked from the frozen corpus and public sources only, with line-level citation of every material claim, keeping documented fact, auditor arithmetic and auditor judgment explicitly separated — and every market figure was checked against independent external sources, which is where the corroboration gets its weight. The conclusions were binding on us: every finding had to be answered in writing, in the corpus, before genesis parameters could freeze. ## A qualified opinion: five critical, seven high, ten medium findings We will only ever quote the opinion in full, because quoting it selectively is how audit-washing works. Here it is: a **qualified opinion** — five critical findings, seven high, ten medium, and twelve conditions precedent to a favourable one. None of the five critical findings was judged fatal, all of them were precise, and every one had to be remediated before genesis parameters freeze. The same report also did something useful for us: it **corroborated the market thesis against independent sources**. Every market figure the corpus relies on — more than a billion AI agents by 2029 (IDC), roughly 50 machine identities per human in enterprise environments (Omdia, 2024), the x402 transaction economics we build against — checked out against the external sources cited in the report and listed on [where the numbers come from](/en/sources). And the report found no incumbent serving our niche — privacy-preserving, funded, regulated-grade agent identity — while confirming the risk we already knew: transparent-identity competitors are consolidating fast. The window is real in both directions. ## Each critical finding got a written answer in the corpus The response was a single coordinated **re-freeze of the entire specification corpus**, every change carrying a marker back to its recorded, ratified decision. The audit found The re-freeze answers The genesis allocation policy contradicted itself — a declared band versus an incompatible working figure — on a decision that is irreversible by construction. Resolved by recorded decision in August 2026: the allocation was ratified as bands — 15% development and team, 20–25% public tranche, at least 60% validator emission pool — with the final points commissioned to the independent simulation. The allocation model is now under review. A circular launch dependency: no listing → no market price → an unmeasurable minimum-economic-security gate → professional validators that cannot be recruited. The gate is re-denominated in four measurable, price-independent units — bonded share of supply, independent-operator count, a Nakamoto-coefficient floor, a published attack-cost methodology — and validators become contractable counterparties through fiat-denominated service agreements. The funded-accountability layer hung on requirements that had no normative text in any live document — only a superseded archive draft that contradicted the current design. The requirements now have live normative text in the re-frozen corpus. What existed only as citations is written, versioned and frozen. No economic parameter existed beyond the hard cap, and the independent simulation that must produce them all had not been commissioned. The bands are ratified, and the simulation is scoped as a funded statement of work whose deliverables cover every open point — every fee, band point, emission parameter and the arbiter-market sizing are its outputs, never ours. Protocol revenue was structurally decoupled from adoption, and the validator security budget had no documented successor once emission runs out. The two flows that scale with the agent population — per-agent mint/lease and consented disclosure — now carry normative, non-zero protocol cuts, whose allocation is under review; and the post-emission security budget has a written answer: a modelled fee market whose successor options never include printing more tokens. That is what “the corpus is the source of truth” means when it costs something: the genesis-allocation contradiction is resolved by recorded decision, the requirements that existed only as citations now have live normative text, and the launch gate that was denominated in an unmeasurable unit is now denominated in four measurable ones. ## The bands became policy, and the cap stayed where it was The tokenomics moved _from shape to policy_. The posture is now: the mechanism is committed, the bands are ratified, the numbers are commissioned — to an independent simulation, not to us. The [tokenomics page](/en/tokenomics) carries the full picture: the ratified bands, the four-year vesting with a one-year cliff and a twelve-month lock-up, and the rule that insider genesis accounts may not delegate, may not vote, and do not count toward the launch-security gate. The audit also asked how a public launch would be paid for. The answer written into the corpus is conditional: if the public route is chosen at the Gate-1 go/no-go, the launch would be financed through the complete EU MiCA Title II path, with a published budget and, as a condition of that route, a floor: miss the floor, re-stage the scope, never launch under-funded. Any such launch would be staged — identity first, the funded-recourse rail later, on a published demand criterion, each stage with its own audits as scheduled milestones whose findings are published. Today nothing is offered, and MintID runs on the single-node production chain, in production since 20 September 2026 and operated by the CONECTIA group, without a token. The [roadmap](/en/roadmap) shows both stages and the three engagements on the critical path. What did _not_ move is the part we consider load-bearing: the hard cap of 108,000,000, immutable. Verification without a fee, by construction. Presentations off-chain, always. Consensus revenue firewalled from service revenue. And nothing for sale, stated visibly on the site. ## The findings are the record; hold the corpus to them An audit you run against yourself, publish against yourself — findings, name and all — and answer in one release: that is the transparency budget most projects spend on adjectives. The verdict and the findings register above are the record; hold the frozen corpus to them. If your diligence needs the full report, [download it](/docs/MintID-Economic-Viability-Audit-2026-07-30.pdf) — it is published as written, unedited. Did MintID pass the audit? No — and we will never phrase it that way. The audit returned a qualified opinion: the demand thesis was corroborated against independent external sources and the mechanism design held, while five critical findings did not. Every documentation-level finding was remediated in the re-freeze of the corpus; the remaining conditions are two external engagements — the independent economic simulation and counsel — now scoped and ready to commission. Who performed the audit? [Conectia PRO](https://conectia.pro/en/) — and the report says so on its cover. [Conectia PRO](https://conectia.pro/en/) belongs to the CONECTIA group, which conceived MintID and is building it: the development company, the operator of the first issuer, the first verifier, the reference implementations and the anchor product, and the funder of the pre-genesis work, while the MintID Foundation, a Netherlands Stichting, is being incorporated by the founder and stays dormant until the public-offer route is chosen. It is a related party in every one of those roles, disclosed as such, which is why the report names its author instead of implying an arm’s-length third party. The audit ran with audit discipline — frozen corpus and public sources only, line-level citation of every material claim, documented fact kept separate from auditor arithmetic and auditor judgment, every market figure checked against independent external sources — and its verdict and complete findings register are published on this site, so you can judge the work rather than the letterhead. The two engagements that remain as conditions, the economic simulation and counsel, are external precisely because those numbers must not come from anyone this close to the project. Does any of this mean a token is for sale? No. Nothing is for sale: no token sale, no pre-sale, no whitelist, no price, no date. The project has committed, as ratified policy, to exactly one route by which an offer could ever exist — the complete EU MiCA Title II process: crypto-asset white paper, notification to the regulator, public offer, and only then admission to trading. This post is a governance record, not an invitation. Where can I read the audit and the response? The verdict — always quoted in full — and the register of critical findings with their answers are published on this page. The full report is published as written, as a PDF on the docs page. The response is the re-freeze of the specification corpus, and the summary of what changed is on the tokenomics and roadmap pages. ## Read the findings. Then read the response. The audit is the longest look anyone has taken at MintID, and it was ours: read it as such. Every finding is published. The re-frozen tokenomics and the staged roadmap are the answer — both are on this site, in full. [Tokenomics](/en/tokenomics)[Download the full report (PDF)](/docs/MintID-Economic-Viability-Audit-2026-07-30.pdf) --- Source: https://mintid.net/en/blog/we-audited-ourselves · We audited ourselves before anyone asked — MintID blog --- > MintID’s verifier now runs as an MCP server: the three frozen verifier-service operations become tools any agent framework can call, with the same closed reason codes, so an agent reads a rejection as a decision it can act on. Blog · announcement # Verification is now a tool call MintID’s verifier now runs as an MCP server: the three frozen verifier-service operations become tools any agent framework can call, with the same closed reason codes, so an agent reads a rejection as a decision it can act on. by Marc Miró i Rierola·published 2026-07-26·updated 2026-10-04·6 min read Updated 2026-10-04: sourcing, status and wording. On the agentic web, the unit of consumption is the **tool**. According to their own announcements, Anthropic’s finance agents ship wired to MCP connectors, and Cloudflare’s Monetization Gateway meters and monetises MCP tools at the edge. When the surface an agent reaches for is a tool listing, anything that wants to be part of an agent’s workflow has to be a tool — and identity verification is no exception. So the MintID client family grew a third member: a **Model Context Protocol server** that exposes MintID verification to any MCP-capable framework as three tools over stdio, with the same discipline as every client before it. ## The server exposes the frozen verifier contract and nothing else The server exposes the three operations of the [frozen verifier-service contract](/en/sdk/verifier-service-contract) and nothing else: build info, create challenge and validate presentation. Challenge → presentation → decision, driven from an agent runtime without writing glue and without the agent framework learning OpenID4VP or the HTTP contract. It is transport-only in the strictest sense. It wraps the existing [TypeScript client](/en/sdk/typescript-client) — its only dependency — and adds **zero external runtime dependencies**. It contains no cryptography and no policy. Nonce, session id and the ten-second expiry are generated by the verifying core; no tool argument can mention them, let alone move them. The contract itself is untouched — the same versioned contract every other client speaks. ## A rejection stays a decision, even over MCP The part worth dwelling on is what happens when verification _fails_. In the MintID clients, **a rejection is a decision, not an error**. That distinction usually dies at the first protocol boundary, where every non-happy path collapses into an exception and the caller learns only that something went wrong. It survives here. When an agent submits a presentation that fails — a replayed nonce, a stale status root, a missing predicate — the tool call **succeeds** and returns a rejection with a reason code from the same [closed vocabulary](/en/sdk/reason-codes) every other client sees. Only transport failures are tool errors: a body the service cannot parse, or proven chain state being unavailable, which fails closed. An agent that receives a rejection plus a named reason can _reason_ about it: ask the holder for a fresher presentation, escalate to a human, decline the transaction, log a decision. An agent that receives a generic error can only retry blindly — which is the behaviour fraud teams dread and rate limiters punish. ## The server lives inside your perimeter, pointed at your own service Registration is one entry in your agent runtime’s MCP configuration, and the only thing it needs is the address of your own verifier service. That address carries the whole architecture: the server is part of _your_ verifier deployment, run inside your perimeter, pointed exclusively at your own service instance. There is no MintID endpoint in the path. [Embedded, not hosted](/en/blog/embedded-not-hosted), is a rule about who decides: the registered verifier decides, and the MCP layer only carries the decision. The server itself persists nothing and logs nothing; your service keeps the only decision record. ## An MCP client is a client of a client, so it cannot skip a check The [multi-language strategy](/en/blog/implementing-clients) is deliberately conservative: one verification pipeline, embedded in Python, with thin clients delegating to a service you host. Adding MCP does not bend that rule — it applies it one layer up. The MCP server is a client of a client: it can no more skip an acceptance condition than the TypeScript client it wraps, because neither of them verifies anything. What it changes is _who can call_. Until now, integrating MintID meant a backend engineer writing code against a contract. Now an agent framework can list verification alongside its other tools, and an autonomous workflow can check whether its counterparty is [backed by an accountable human](/en/blog/what-is-know-your-agent) the same way it checks anything else. That is the integration point [agent KYC](/en/agent-kyc) was always going to need, and it is now a working artifact. MintID runs on the single-node production chain, in production since 20 September 2026 and operated by the CONECTIA group, with the proof core behind the verifier service; this connector changes nothing about how a proof is checked. What it adds is the transport, the contract and the decision vocabulary, built and tested. The [integration docs](/en/sdk/mcp-server) say exactly which is which. What does the MintID MCP server actually do? It exposes the three operations of the frozen verifier-service contract — build info, create challenge, validate presentation — as Model Context Protocol tools over stdio. An agent framework lists them and calls them like any other tool, without learning OpenID4VP or the HTTP contract. Is this a MintID-hosted verification endpoint? No. The server runs inside your own perimeter, next to the verifier service you deploy yourself, and points exclusively at that instance. The decision stays with the registered verifier, in its own deployment — the MCP layer only carries it. What happens when a presentation is rejected? The tool call succeeds and returns a rejection with a reason code from the same closed vocabulary every other client sees. Only transport failures — an unparseable body, or proven chain state being unavailable, which fails closed — surface as tool errors. An agent can reason about a rejection instead of retrying blindly. Can the MCP layer weaken a verification? No. It is transport-only: no cryptography, no policy, no acceptance knob. The nonce, the session id and the ten-second expiry are generated by the verifying core, and no tool argument can mention them. If a change to this package ever looked like a verification feature, it would belong to the service instead. ## Verification, where your agents already are Three tools over stdio, pointed at the verifier service you deploy yourself. Same checks, same reason codes, no new trust boundary. [Read the MCP server docs](/en/sdk/mcp-server)[The verifier role on MintID](/en/verifiers) --- Source: https://mintid.net/en/blog/verification-is-a-tool-call · Verification is now a tool call — MintID blog --- > Between an anonymous payment and a doxxed buyer sits a slot: human-backed, in scope, unrevoked, and unrevealed. A zero-knowledge proof is built to fill it. MintID has drafted a standards-track profile that carries that proof over x402 and Web Bot Auth without changing either, with machine-readable schemas and a validation suite. Blog · standards # The graduated-knowledge slot: an identity profile for x402 and Web Bot Auth Between an anonymous payment and a doxxed buyer sits a slot: human-backed, in scope, unrevoked, and unrevealed. A zero-knowledge proof is built to fill it. MintID has drafted a standards-track profile that carries that proof over x402 and Web Bot Auth without changing either, with machine-readable schemas and a validation suite. by Marc Miró i Rierola·published 2026-07-26·updated 2026-10-04·8 min read Updated 2026-10-04: sourcing and status. When Cloudflare put a per-call price on resources behind its Monetization Gateway (announced by Cloudflare on 1 July 2026), it also put a question in front of every API seller on the open web: _how much do you need to know about the buyer?_ According to that announcement, the gateway’s tiers answer it as a ladder — open to anyone, better terms for verified agents, and the full identity-and-payment treatment where the risk warrants it. We [argued in July](/en/blog/x402-pay-per-use-web-needs-identity) that the interesting rung is the middle one, and that no product we know of fills it. Between _anonymous_ and _doxxed_ there is a slot a zero-knowledge proof is built for: **human-backed, in scope, unrevoked — and unrevealed**. Since then we have stopped describing that slot and started specifying it. MintID now has a **standards-track draft profile** for carrying an identity leg over [x402](/en/glossary#x402) and [Web Bot Auth](/en/glossary#web-bot-auth), with machine-readable schemas and a validation suite behind it. ## Four rungs, from a cleared payment to a named counterparty Tier What the seller learns Mechanism anonymous a payment cleared The x402 default. A wallet paid the quoted price and the request proceeds. The seller learns nothing about who is on the other end, and nothing carries over to the next request. identified software this call came from operator X’s fleet Web Bot Auth: HTTP message signatures against a published key directory. It authenticates the agent software. It says nothing about whether an accountable party stands behind it — and it works because the signing population is small and named. identified software, accountable human — unrevealed a KYC-verified principal is answerable for this agent, at a stated assurance grade, within a delegated scope covering this action The slot the profile fills. A zero-knowledge presentation adds the accountability layer to the signature without adding a name, a registry entry, or a handle that joins this seller’s log to any other. full KYC who the counterparty is Outside MintID’s lane, by design. Where the law demands identification, identification is the answer — but it should be the exception at the top of the ladder, not the default at the bottom. We expect most agent commerce to sit on the third rung: it is the one that scales beyond a few named crawler operators without building a public index of who runs which agent. ## One identity leg, on an unmodified payment cycle The design constraint we set ourselves was to change nothing about x402. The profile adds a leg; it does not fork a protocol. The seller’s payment-required response carries an **identity requirement**: which claims the buyer must prove (human-backed; assurance at least the grade the seller requires; a delegated scope covering this action, this seller and this value; the credential active), which issuers are acceptable, where to obtain a challenge, and the session mode. The buyer’s agent obtains a challenge, produces its proof, and retries the original request carrying both the unchanged x402 payment and a presentation alongside it. The payment facilitator — already the party that verifies payment — gains an identity step: it validates the presentation against **its own** self-deployed verifying core, as a registered verifier for its own origin. It answers with a decision, and the seller consumes that verdict over the trust relationship it already has with its facilitator for payment verification. **No new verifier class. Not one binding rule changed.** The seller is named inside the _claim policy_ — never in the audience, which stays fixed to the verifying party’s registered origin. A seller that would rather not take its facilitator’s word for it registers as a verifier itself and runs the identity leg first-party. The profile is identical with the seller as the verifying party; only the deployment moves. ## Micropayment sessions get a token; escrowed sessions wait for their mechanism A ten-second presentation per request is unusable at micropayment cadence. That is a real objection, and the answer is session design — never a longer proof. With **no funds at risk**, one accepted presentation bridges to a scoped, short-lived token carrying the proven predicates as its authorisation basis; the rest of the session presents the token, whose lifetime and scope are the verifying party’s local policy. That mode needs nothing beyond the identity rail. Escrow-backed **value exclusivity** — reserved sessions — is a different risk class, and the draft treats it as one: it reserves the mode by name and _forbids_ offering or accepting it until the underlying session-reservation mechanism ships; its dedicated audit is a scheduled milestone whose findings are published. Its details land in a revision once the mechanism exists, not before. Reserving a name is a promise about scope; shipping a mechanism that does not exist yet would be a promise about safety, and we do not make those. ## Key binding and session association are kept apart Web Bot Auth gives an agent’s HTTP requests a verifiable key identity. It authenticates **the software**. A MintID presentation adds the sentence a signature cannot carry: _an accountable human stands behind this_ — without revealing who. The profile can carry that sentence in two strengths, and keeps them apart. The stronger one is **key binding**: the bot’s signing key is bound into the agent credential, so the presentation proves that the key signing this request belongs to the credentialled agent — the same attested key material the credential’s custody attributes already describe. The weaker one is a **session-level association**: a relying party that has verified a request signature runs the ordinary challenge → presentation → decision flow within the same session and associates the accepted decision with the signing key _for that session only_, under its own session policy — the same trust construction as any authenticated session. The draft is emphatic that the two are not interchangeable: an implementation that stops at the session association must not claim key-binding semantics from it. We say what is proven, and no more. ## The schemas are the enforcement The invariants are **structural**. The profile ships machine-readable schemas for both legs — the policy extension and the payment-identity envelope — with worked examples and a validation suite. The schemas are closed — an unknown field is a rejection, not an extension point — and **no field exists** for a presentation lifetime, a condition skip, a staleness override or an audience override. The ten-second lifetime is a protocol constant the extension cannot lengthen, shorten or even mention. The nine acceptance conditions run in full on every presentation. Freshness tolerance stays local deployment policy and never rides the wire. There is no persistent “verified” badge, because a presentation is perishable and non-transferable by construction. The validation suite proves the mutations fail. Smuggling a knob into the extension fails schema validation before anyone has to argue about it. That is the difference between an invariant you document and an invariant you can’t express. ## The identity layer of agent payments is being decided now Because the window is open. Agent payments are being standardised in public right now, and the identity layer is being decided in the same window — by whoever has text on the table. Ours is written, with schemas and tests, and labelled for what it is: a **Draft** under the project’s standards process, with a dispute annex reserved and open decisions still open. The process, not this post, decides when it freezes. What it establishes is that the middle rung of the ladder is buildable without inventing a new verifier class, without touching the payment protocol, and without a registry of who runs what. The rest of MintID is unchanged underneath: [agent KYC](/en/agent-kyc), presentations that never enter the chain, and a proof core in production on the [single-node production chain](/en/technology), in production since 20 September 2026, operated by the CONECTIA group and designed to scale to a public proof-of-stake network. What is the x402 agent-identity profile? A standards-track draft that maps one identity leg onto the unmodified x402 payment cycle: the seller’s payment-required response states an identity requirement, the agent obtains a challenge and retries with both its payment and a presentation, and the payment facilitator validates it on its own self-deployed verifying core. It ships with machine-readable schemas and a validation suite. Is the profile final? No. It is a Draft under the project’s standards process, and it is published here as a draft on the table while the identity layer of agent payments is being decided — not as a frozen or ratified specification. Parts of it, including the dispute annex, are explicitly reserved pending open decisions. Does it require a new kind of verifier or a change to the binding rules? Neither. The facilitator acts as a registered verifier for its own origin, on its own verifying core, and the seller consumes that verdict over the trust relationship it already has for payment verification. A seller that would rather not trust its facilitator can register and run the identity leg first-party — the profile is identical with the seller as the verifying party. A ten-second presentation per request is unusable at micropayment cadence. How is that answered? By session design, not by weakening the presentation. After one accepted presentation, the verifying party can mint a scoped, short-lived token carrying the proven predicates as its authorisation basis, and the rest of the session presents that token. The ten-second lifetime is a protocol constant; the profile cannot lengthen it, and has no field in which to try. Does a MintID presentation bind the agent’s Web Bot Auth signing key? It can. The profile can bind the bot’s signing key into the agent credential, so a relying party that has verified a request signature can require a presentation proving that the credentialled agent controls that key. Short of that, a relying party may associate an accepted decision with the signing key for that session only — the same trust construction as any authenticated session — and the draft keeps the two apart: an implementation that stops at the session association must not claim key-binding semantics from it. ## The rung between anonymous and doxxed Human-backed, in scope, unrevoked — and unrevealed. If you are building the identity layer of agent payments, we would like the argument. [How agent KYC works](/en/agent-kyc)[Talk to us](/en/contact) --- Source: https://mintid.net/en/blog/x402-web-bot-auth-identity-profile · The graduated-knowledge slot: an identity profile for x402 and Web Bot Auth — MintID blog --- > Cheaper AI screening is good news for a credential rail: more organisations can afford to issue. MintID’s issuer plane keeps the decision with the issuer by construction: a screener’s output is accepted only as enumerated checks with provenance, an asserted grade is rejected by name, and no field exists that could carry one. Blog · issuance # AI writes the evidence. It doesn’t get to decide. Cheaper AI screening is good news for a credential rail: more organisations can afford to issue. MintID’s issuer plane keeps the decision with the issuer by construction: a screener’s output is accepted only as enumerated checks with provenance, an asserted grade is rejected by name, and no field exists that could carry one. by Marc Miró i Rierola·published 2026-07-26·updated 2026-10-04·7 min read Updated 2026-10-04: sourcing and wording. A new class of tool is eating the expensive middle of compliance. According to Anthropic’s own announcement, its finance agents include a KYC screener that extracts fields from documents, screens watchlists and packages escalations as structured JSON; in its public response, Sardine argued that the reasoning itself is commoditising and that durable value sits in evidence quality and operational infrastructure. Both are right, and both describe the _input_ side of an identity credential. The MintID issuer plane is built on that distinction, and a module now enforces it. ## Cheaper screening is good news for a credential rail The collapse in screening cost is **good** for MintID. The economics of [amortised accountability](/en/blog/amortised-accountability) start with someone doing a real KYC check once. Every cheaper screener widens the set of organisations that can viably operate as an approved issuing authority, and every new authority means more credentials in circulation — each of which can then be proven again and again in zero knowledge, at no further screening cost. The screener market can commoditise all it wants. Every cheaper screener makes a MintID credential cheaper to issue, and none of them can issue one. ## Evidence and verdicts are different objects The failure mode to design against is subtle and extremely tempting. A screener returns a rich structured payload, somewhere in it is a field called `assurance` or `tier` or `grade`, and an issuing system under deadline pressure copies it forward. At that moment the issuing authority has stopped deciding and started forwarding — but the credential it signs still says _this authority assessed this person at this grade_. The accountability chain has a hole in it that nobody can see from the outside. So the profile draws the line at the type level. The normalised evidence it produces **has no field, optional or nullable, that could carry a grade**. And a payload that asserts a grade or tier label is rejected outright, _wherever it appears, at any depth_, including outcome strings shaped like a grade. You cannot forward what you cannot represent. What each grade certifies was settled in August 2026: the four grades are anchored on eIDAS and squared with ISO/IEC 29115, and how recently the evidence was checked is published by the issuer as a separate freshness band — [how we grade identity](/en/blog/grades-follow-eidas) explains it, and the [KYC trust model](/en/sdk/kyc-trust-model) records who decides. This profile does not decide grades. It settles only who is allowed to answer. ## Accepted evidence becomes enumerated checks with provenance Accepted evidence normalises into **enumerated checks with enumerated outcomes**: document authenticity, field-extraction consistency, identity-data validation, sanctions, PEP and adverse-media screening — each resolving to pass, fail, inconclusive or escalated, and each carrying the attestation of _how it was retrieved_: an authenticated API call, or a signed webhook that was re-fetched over the authenticated channel before being believed. Nothing is trusted for returning JSON. The screener’s own escalation disposition survives as **one more enumerated check**. A screener recommending approval carries exactly the weight of a check outcome — a fact the issuer weighs, never an instruction the issuer follows. ## Everything else is rejected with a named reason Anything else is rejected, with a reason from a closed vocabulary: Rejected when Why case or subject mismatch The payload describes a case or a subject other than the one this authority opened. Evidence that arrived for someone else is not evidence. provenance missing No attestation of how the payload was retrieved. Nothing is trusted for the mere fact of returning JSON. bare verdict A payload reduced to “verified: true”. A boolean is not evidence — it is a conclusion with the reasoning removed. grade asserted A provider-asserted assurance grade or tier label, anywhere in the payload, at any depth. The issuer decides the grade. timestamps missing or evidence stale Undated evidence, or evidence older than the issuing authority accepts at the moment of evaluation. unknown check kind or outcome A check or an outcome outside the closed vocabulary. Unrecognised is not a synonym for harmless. A closed vocabulary is the same discipline the [verifier reason codes](/en/sdk/reason-codes) apply on the other side of the protocol, for the same reason: a named rejection is auditable, and a catch-all is where exceptions quietly become policy. ## Pure, deterministic, and invisible to the chain The module is a deterministic function of its inputs. Evaluation time is injected by the caller; there is no clock, no network and no randomness inside it — authenticated retrieval is the driver’s duty, attested through the provenance fields the normaliser demands. A test suite holds that shape in place. And the material itself goes exactly one place: **issuer-private, on arrival**. No raw KYC data, no PII and no screener payload ever touches the chain: the [architecture](/en/technology) has no place for it. The practical consequence for an issuing authority is that a provider outage, an API change or a vendor switch is invisible to the protocol. The evidence contract is what you integrate against, and it outlives whichever screener is cheapest this quarter. ## The issuer decides the grade and stakes its bond on it AI writes the evidence. It doesn’t get to decide. That sentence is easy to put in a policy document and hard to keep true under commercial pressure — which is precisely why it belongs in a type signature and a rejection vocabulary instead. The [issuing authority](/en/issuers) decides the grade, after independent assessment, and stakes its bond on that decision. The screener, however good, is a witness. Does an AI screener decide whether a MintID credential is issued? No. A screener produces evidence: extracted fields, per-check outcomes, watchlist results, an escalation disposition. The issuing authority decides — including the assurance grade. The evidence profile makes that division structural rather than procedural: an asserted grade is rejected on sight, and the normalised evidence type has no field that could carry one. What does the profile accept? Enumerated checks with enumerated outcomes — document authenticity, field-extraction consistency, identity-data validation, sanctions, PEP and adverse-media screening, plus the escalation disposition as one more check — each carrying an attestation of how it was retrieved: an authenticated API call, or a signed webhook re-fetched over the authenticated channel. What happens to the screener’s escalation decision? It survives as one more enumerated check, never as an acceptance shortcut. A screener saying “this one is fine, ship it” carries exactly the weight of a check outcome — a fact the issuer weighs, not an instruction the issuer follows. What happens if the screening provider changes or goes down? Nothing visible to the protocol. Provider material becomes issuer-private on arrival and never touches the chain; the module that normalises it is pure and deterministic, with evaluation time injected by the caller — no clock, no network, no randomness. Swap screeners, keep the evidence contract. ## Cheaper screening. Same accountability. If you are considering operating as an approved issuing authority, the evidence contract is the part worth reading first — it is what makes your screening choice yours. [The issuer role on MintID](/en/issuers)[Talk to us](/en/contact) --- Source: https://mintid.net/en/blog/ai-writes-the-evidence · AI writes the evidence. It doesn’t get to decide. — MintID blog --- > Cloudflare’s Monetization Gateway makes agents pay per call over x402, and Web Bot Auth signs the big fleets. Neither tells a seller whether an accountable human stands behind the long tail of agents. Why verifiable human-backed agent identity, proven in zero knowledge, is the missing half of the paying web. Blog · agentic identity # The pay-per-use web is here. It needs Know Your Agent. Cloudflare’s Monetization Gateway makes agents pay per call over x402, and Web Bot Auth signs the big fleets. Neither tells a seller whether an accountable human stands behind the long tail of agents. Why verifiable human-backed agent identity, proven in zero knowledge, is the missing half of the paying web. by Marc Miró i Rierola·published 2026-07-26·updated 2026-10-04·7 min read Updated 2026-10-04: naming, dispute status and sourcing. On July 1, 2026, Cloudflare launched its **Monetization Gateway**: any customer can now put a per-call price on any resource — a page, an API, a dataset, an MCP tool — and be paid in stablecoins by whoever calls it (according to Cloudflare’s announcement of 1 July 2026). The mechanics run on [x402](/en/glossary#x402), the open protocol that finally puts HTTP 402 “Payment Required” to work: the server quotes a price, the agent pays wallet-to-wallet, retries with proof of payment, and gets the resource. A year after Pay Per Crawl, the pay-per-use agentic web is no longer a thesis. It is shipping infrastructure. We think this is exactly right — and exactly half of the problem. The new stack answers _“did this request pay?”_ and, through [Web Bot Auth](/en/glossary#web-bot-auth), _“which software fleet sent it?”_. It does not answer the question every seller, regulator and dispute process eventually asks: **if this agent causes harm, is there an accountable human behind it?** ## What the pay-per-use stack solves — and what it defers x402 settles value without accounts: no signup, no card on file, no identity — a wallet is enough. Web Bot Auth authenticates operators cryptographically, and it works today because the calling population is small: named crawler fleets whose signing keys sit in known registries. Between them, payments clear and big-fleet traffic is attributable. But the population the gateway is built for is the coming long tail: purchasing agents, research agents, booking agents, run by individuals and small companies, transacting with counterparties they have never seen. For that population, “which fleet signed this?” has no useful answer, and the fallback every marketplace reaches for — an allowlist of companies large enough to negotiate with — quietly recreates the gatekept web the open protocols were meant to avoid. ## Verified agents get better terms. Verified how? The gateway’s own design points at the gap: sellers can price differently for verified callers — free for partners, paid for strangers, refused for anonymous scrapers. Verification tiers look like where agentic commerce is heading. The question is what “verified” means when the caller is one agent in a long tail rather than a household-name AI company. If “verified” means _registered under its operator’s legal name in a public directory_, the agentic web gets a surveillance index of who runs what, and every paid request extends the dossier. If it means nothing checkable, fraud teams are back to allowlists. Twenty years of identity systems assumed [a human at the keyboard](/en/blog/agentic-identity-problem); both defaults fail without one. ## The missing half: accountability without identification This is the layer MintID’s [agent KYC](/en/agent-kyc) is built to supply — verifiable human-backed agent identity, MintID’s answer to what the market calls [Know Your Agent (KYA)](/en/blog/what-is-know-your-agent) — and it is deliberately the _zero-knowledge_ kind. An agent carries a credential derived from its operator’s one-time KYC with an approved issuer, and at transaction time proves, with a presentation valid for ten seconds: an accountable, KYC-verified human principal stands behind this agent, at a stated assurance grade (A1–A4), within a delegated scope that covers this purchase — and nothing else. The scope axes are specified; enforcement arrives with the agent products. No name. No wallet-to-operator mapping. No handle that links this seller’s log to any other seller’s log. Accountability keeps its teeth in MintID’s design: disputes are specified to settle [money before identity](/en/blog/money-before-identity) — from the agent’s pre-funded escrow first, with identification reserved for due process through the issuer, as a last resort. That rail is specified and scheduled for the financial-recourse stage; its audits have not started, and no funds are locked today. Sellers would get recourse; operators would not get profiled. ## Why zero-knowledge is load-bearing in a paying web A pay-per-use web without privacy engineering is a logging web: every priced call is a timestamped, paid, attributable event. Combine per-request payments with a stable agent identifier and you have built a behavioural record of every paid call, retroactively queryable, one subpoena or one breach away. The fix has to live in the credential layer: presentations that are **unlinkable across verifiers and across sibling agents**, so that the proof spends like cash rather than like a card statement. That property, not the payment rail, decides whether the agentic web inherits the ad-tech panopticon or retires it. ## We expect sellers to price by verification Payment (x402), software identity (Web Bot Auth) and accountable-principal proofs are complementary layers, and the second is in the IETF process (as of July 2026). We expect “price by verification” to become the default posture of agent-facing sellers, and verification to bifurcate: fleet signatures for a few named crawler operators, credential proofs for everyone else. MintID’s bet — an [identity protocol](/en/technology) on which accepted issuers back those proofs and verifiers check them, with no PII on the chain — is that the “everyone else” tier is where the actual economy will live. MintID is in production on the single-node production chain, since 20 September 2026 and operated by the CONECTIA group, designed to scale to a public proof-of-stake network: specifications frozen, the [verifier service and a client](/en/sdk) built, the proof core in production, the audits scheduled milestones whose findings are published. The direction, after July 1, needs less argument than it used to. Does an x402 payment identify the agent that pays? No. x402 settles value: a wallet pays the quoted price and the request proceeds. The seller learns that payment cleared, not who operates the agent, whether a liable human stands behind it, or whether the same operator was refused yesterday under a different wallet. Payment and accountability are separate problems — x402 deliberately solves only the first. Isn’t Web Bot Auth enough identity for the agentic web? Web Bot Auth authenticates software: a signed request proves “this call comes from operator X’s fleet”. That works for a handful of named crawler operators. It says nothing about the long tail of autonomous agents acting for individual people and small businesses — and turning it into a public registry of who runs which agent would solve accountability by building a surveillance index. Human-backed agent credentials add the missing layer: proof of an accountable, KYC-verified principal, without naming them. If the agent already paid, why would a seller need its identity at all? Because price is not the only risk. Sellers face fraud, abuse, chargebacks, regulatory exposure and differentiated pricing (partner rates, jurisdiction rules, age-gated goods). Today the fallback is allowlists of big companies — which locks out the long tail. A zero-knowledge proof of human backing lets any agent, however small its operator, clear the same bar: an accountable human exists, is verified at a stated assurance grade, and granted this scope. Why does privacy matter more, not less, in a pay-per-use web? Per-request payments leave per-request trails. If every paid call also carried a stable agent identity, sellers — and anyone who aggregates their logs — could reconstruct an operator’s entire activity graph. MintID presentations give verifiers nothing to link across them or across agents of the same principal, so accountability exists at each transaction without the proofs themselves creating a joinable history. ## The other half of the agentic web Payment rails are shipping. MintID builds the accountable-principal layer: verifiable human-backed agent identity, proven in zero knowledge. [How agent KYC works](/en/agent-kyc)[The vocabulary, defined](/en/glossary) --- Source: https://mintid.net/en/blog/x402-pay-per-use-web-needs-identity · The pay-per-use web is here. It needs Know Your Agent. — MintID blog --- > MintID’s verifier SDKs share one verification core, embedded in Python and never rewritten per language. TypeScript and later languages are thin clients with no cryptography and no policy, calling a verification service you host yourself, so no binding can weaken a check. An implementation audit of the core is a scheduled milestone whose findings are published. Blog · architecture # Implementing clients: where the rubber meets the road MintID’s verifier SDKs share one verification core, embedded in Python and never rewritten per language. TypeScript and later languages are thin clients with no cryptography and no policy, calling a verification service you host yourself, so no binding can weaken a check. An implementation audit of the core is a scheduled milestone whose findings are published. by Marc Miró i Rierola·published 2026-07-20·updated 2026-10-04·6 min read Updated 2026-10-04: delivery and wording. When we [announced the MintID SDKs](/en/blog/embedded-not-hosted) — now delivered to integrators from a tagged release — we described what ships inside every binding: the same acceptance checks, the same ten-second presentation lifetime, zero policy knobs. What we hadn't yet published is _how_ several languages can carry one guarantee. That decision is now made and locked into the spec, and it is worth explaining, because the obvious way to build multi-language SDKs is a security mistake. ## The obvious way is wrong The obvious way is to rewrite the verification pipeline in each language: a TypeScript implementation for Node shops, another for the commercial web, a Python implementation for the data stacks. Every rewrite is a fresh chance to get a check subtly wrong — a different cryptographic library with different edge cases, a different clock behaviour, a different idea of what "expired" means a millisecond either side of the boundary. Three implementations means three attack surfaces, three audits that can disagree, and divergence that compounds with every bugfix that lands in one language first. The specification now fixes it: the verification pipeline exists in **exactly one implementation** — the core, now in production — and the specification rejects rewriting it per language. ## Python embeds; every other language delegates Python is the language the core is packaged for directly: the Python SDK embeds the pipeline in your backend, the way the [verifier pages](/en/verifiers) have always described embedding. Every other SDK — TypeScript first, further languages as demand appears — is deliberately a **thin client**. It issues challenges and delegates every decision to a verification service **the verifier runs itself**, next to its own backend — the same core, running as a service inside the agency's own infrastructure. The clients contain **no cryptography and no policy**. With nothing to verify, they have nothing that could weaken a check. A thin client cannot skip an acceptance condition, stretch a lifetime or mis-verify a proof, because it never verifies anything — its self-hosted service does. MintID does not host verification for you. The _embedded, not hosted_ principle stands unchanged — there is no central endpoint and no API of ours in the path. The service mode is your deployment, on your machines, holding your keys. Keys and challenge issuance stay server-side in every configuration, and none of the SDKs is a browser artefact. ## No SDK ships without passing the shared conformance suite Thin clients only give the same guarantee as embedding if you can prove the whole chain behaves identically — so every SDK, in every language, must pass **one shared conformance suite** before release: the same challenges, the same responses, the same expected decisions and reason codes. A verifier gets the same answer whether its backend embeds the core or calls it through a client. Under the spec, no SDK ships without passing it. ## Python first, then the frozen contract, then TypeScript Architecture decisions are cheap until something has to be built in order. Ours is fixed: **Python first**, because it packages the core itself; then the service contract the clients are built against, frozen and versioned as a first-class artefact; then the TypeScript client; then further languages, as demand appears. Building the clients against a frozen contract — rather than against a moving core — is what makes "thin" a property that holds, instead of a diagram that erodes. Everything here is delivered from a tagged release, not yet from a package index; integration is offered under commercial terms while the index release is still ahead. What has changed is that the shape is no longer open: one verified implementation, embedded from Python or reached through a thin client, never rewritten per language. The acceptance rules stay where the [protocol](/en/protocol) put them — fixed by the spec, not by the integrator, in any language you call them from. ## One pipeline, whatever you run Embed the core in Python, or point a thin client at your own verification service. The SDKs are delivered from a tagged release — integration starts as a conversation today. [Talk to us](/en/contact)[The verifier role on MintID](/en/verifiers) --- Source: https://mintid.net/en/blog/implementing-clients · Implementing clients: where the rubber meets the road — MintID blog --- > The MintID verifier SDKs are built around one verification core, embedded in Python and reached from other languages through transport-only clients, TypeScript first, with further languages as demand appears. Inside every binding, the same non-negotiables: nine acceptance checks, a ten-second presentation lifetime and zero policy knobs. Blog · announcement # The MintID SDKs: one core, thin clients The MintID verifier SDKs are built around one verification core, embedded in Python and reached from other languages through transport-only clients, TypeScript first, with further languages as demand appears. Inside every binding, the same non-negotiables: nine acceptance checks, a ten-second presentation lifetime and zero policy knobs. by Marc Miró i Rierola·published 2026-07-20·updated 2026-10-04·5 min read Updated 2026-10-04: delivery and status. The MintID SDKs are built and delivered to integrators from a tagged release. The verification core — the software a [registered verifier agency](/en/verifiers) runs to request and validate presentations — comes as **one core and thin clients**: embedded in Python or run as a service, and reached from other languages through transport-only clients, TypeScript first, with further languages as demand appears. Integration is available today under commercial terms. This deliverable is aimed at integrators rather than end users, and it lands where the design said it would: verification on MintID is built to be **embedded, not hosted by us**. An agency links the core into its own backend, or runs the same code as a standalone service beside its stack, and either way the identical acceptance pipeline runs. ## A client relays a decision; it never makes one The core exists once: request a presentation, validate it against the chain, keep a minimal decision record. Python embeds it directly, for the data and AI stacks where agent operators build. Every other language reaches it through a thin, transport-only client that talks to a verification service you host yourself — TypeScript first, for Node backends, and further languages as demand appears. The language changes how the core is called. It changes nothing about what the core accepts. ## Nine checks, ten seconds, zero policy knobs — in every language What ships inside every binding is the part of the design that is deliberately not negotiable: * **The nine acceptance conditions always run in full** — binding to the verifier's exact origin, the fresh nonce, the requested policy, the current issuer state. There is no subset mode. * **Presentations die in ten seconds.** The lifetime is a constant in the code; no deployment can stretch it to make a replay window more forgiving. * **Chain reads are proven, and fail closed.** The core verifies what it reads from the chain with cryptographic proofs instead of trusting a node's answer. * **The decision record is minimal, and its type is closed.** There is no hook for logging the presentation itself and no field to grow the record into a dossier. Each of these is a constant or a closed type, so a weaker verifier cannot be built from these parts in any language you call them from. A presentation accepted by one registered verifier means exactly what it means at every other. ## What an integrator brings stays short The SDK asks an agency for infrastructure, never policy: its on-chain registration and KYC approval, its exact origins — one verifier per origin, no wildcards — its keys, a durable nonce store, and a disciplined clock. Every item on that list is operational. Which checks matter, how long a proof lives and what gets remembered are the protocol's decisions, and the SDKs carry them unchanged into your stack. ## Tested end to end; the package-index release comes later Tested and working means exactly that: builds that pass their test suites and verify real presentations end to end. It does not yet mean a package-index release: the SDKs are delivered from a tagged release, and integration work is shaping the release checklist. The issuer-side counterpart — the provider-neutral adapter that lets an accepted issuer plug in its identity-verification provider — has since been built: the first issuer runs it in production with a real provider behind it (see the [roadmap](/en/roadmap)). And MintID itself runs on the single-node production chain, in production since 20 September 2026 and operated by the CONECTIA group: no token, no public mainnet yet, and the audits are scheduled milestones whose findings are published. If you run a verifier agency and want the verification core inside your stack — embedded, or behind a thin client — [talk to us now](/en/contact): integration starts as a conversation, and it runs under commercial terms. For the machinery underneath, presentations, nonces and finalised roots are laid out on the [technology page](/en/technology) and in the [protocol spec](/en/protocol). ## Your stack, our guarantees One pipeline, thin clients, zero policy knobs. The SDKs are delivered from a tagged release — integration starts as a conversation today. [Talk to us](/en/contact)[The verifier role on MintID](/en/verifiers) --- Source: https://mintid.net/en/blog/embedded-not-hosted · The MintID SDKs: one core, thin clients — MintID blog --- > ERC-8004 makes agents discoverable and their work verifiable; its identity is a transferable NFT, its reputation open to Sybil inflation, and recourse out of scope. A MintID presentation proves that a liable, verified human backs an agent without naming them. Where the standard stops, and how the two compose. Blog · comparison # MintID vs ERC-8004: trustless agents still need accountable humans ERC-8004 makes agents discoverable and their work verifiable; its identity is a transferable NFT, its reputation open to Sybil inflation, and recourse out of scope. A MintID presentation proves that a liable, verified human backs an agent without naming them. Where the standard stops, and how the two compose. by Marc Miró i Rierola·published 2026-07-13·updated 2026-10-04·9 min read Updated 2026-10-04: dispute status, sourcing and wording. ERC-8004 “Trustless Agents” is the loudest story in agent trust right now, and it has earned the attention: a draft Ethereum standard for discovering and evaluating autonomous agents, deployed on Ethereum mainnet since January 2026, with integrations announced by ENS, EigenLayer and The Graph. It starts from the same diagnosis MintID does — A2A and MCP let agents talk, but neither answers “can I trust this one?”. It then gives a very different answer. This comparison lays both out, including what ERC-8004 does better. ERC-8004 facts come from the draft specification, its public discussion thread and the projects’ own announcements, as of July 2026. ## ERC-8004 finds agents; MintID answers for them dimension erc-8004 MintID what it is three registry contracts on any EVM chain an identity protocol (Cosmos SDK), in production on a single-node chain and designed to scale to a public proof-of-stake network agent identity a public ERC-721 NFT per agent, per chain no on-chain agent record — a normative “won’t have” transferability the agent NFT sells like any token, reputation attached credentials are holder-bound; recovery only by re-KYC human behind the agent none required — owners can be fully anonymous the whole product: every credential backed by a verified, liable human trust signal open feedback registry + staked validation issuer bond + escrow; no reputation scores at all privacy identity and feedback public and correlatable by design pairwise pseudonyms, unlinkable sibling agents, no presentation logs what gets validated the agent’s work (re-execution, TEE attestation) the agent’s backing (a ten-second zero-knowledge proof) recourse for victims out of scope — slashing left to external protocols core of the design: escrow first, identity last, bonded arbiters between (specified and scheduled for the financial-recourse stage) ## What ERC-8004 gets right ERC-8004 defines three singleton registries per EVM chain. The Identity Registry mints each agent as an ERC-721 token whose URI resolves to a registration file — name, A2A/MCP endpoints, x402 payment support, a proven payout address. The Reputation Registry lets any address publish signed, revocable feedback about an agent. The Validation Registry lets an agent request independent validation of its work — inputs and outputs referenced by hash, verdicts from validators who re-execute the job with stake at risk or attest it ran in a trusted enclave. Three of those moves are valuable, and MintID attempts none of them. **Discoverability:** agents become browsable, indexable objects with standard metadata — a real directory problem, solved. **Work validation:** “did the agent do the job correctly?” gets a portable, composable answer. **Ecosystem fit:** the standard plugs into A2A, MCP and x402 rather than competing with them — the same bridge-don’t-fight posture MintID takes. And the specification says plainly that unfiltered reputation aggregation “invites Sybil inflation” and that serious aggregation will happen off-chain. That admission is where the two designs part ways. Both projects agree naked reputation is gameable. ERC-8004 responds with filters and economic validation. MintID responds with a verified human and funded recourse. ## Identity you can sell is accountability you can shed In ERC-8004, an agent’s identity is an NFT — and NFTs transfer. Buy the token of a well-reviewed agent and you inherit its reputation without inheriting its operator: the payout wallet resets, the track record travels with the token, and nothing in the standard tells counterparties the operator changed. Months of good behaviour become an asset that can be quietly sold to whoever plans to spend it. That follows from identity-as-token itself. MintID’s credentials are bound to the holder and cannot be transferred at all — if keys are lost, the only path back is re-verification with the issuer. Nobody can buy a track record, because there is no track record for sale: the thing a counterparty verifies is not history but _backing_ — that a KYC-verified, liable human at a stated assurance grade stands behind this agent, right now, within a delegated scope. Backing is checked fresh at every encounter, so there is nothing accumulated to hijack. ## Trust runs from one verifier to one agent The sharpest critiques of ERC-8004’s reputation layer come from its own discussion thread. One contributor notes that a single aggregate score “facilitates monopolistic behaviour”. Another objects that trust is not a universal value of Bob, but a vector from Alice to Bob — my trust in an agent should not be your trust in it. The specification itself leaves open who filters the feedback and how, which in practice delegates the hard part to off-chain aggregators. MintID agrees with the critics — structurally. There are no scores, no global identifiers to score against, and no on-chain feedback: the protocol normatively excludes a reputation registry. What a verifier gets instead is a pairwise pseudonym: stable enough for _that verifier_ to recognise a returning agent, useless to anyone else, and rotated at renewal so no long-term dossier forms. Trust stays a vector from one verifier to one agent — [identification, not surveillance](/en/blog/identification-not-surveillance). The trade is explicit: MintID gives up the public directory and the shared five-star rating so that its proofs give verifiers nothing to link an agent across them; ERC-8004 gives up unlinkability to offer both. ## Checking the work and checking the backing are separate questions ERC-8004’s Validation Registry answers “was this output correct?” — by re-execution with stake at risk, or by TEE attestation. MintID deliberately leaves that question alone. A verifier on MintID checks the _presentation_: a zero-knowledge proof, bound to a fresh nonce, the verifier’s exact origin, the requested policy and the current issuer state root, valid for ten seconds and refused if replayed. The proof shows who stands behind the agent, and says nothing about whether the agent did the job well. These are orthogonal, and they compose. A serious counterparty wants both answers: ERC-8004 tells you whether the agent did the work correctly; a MintID presentation tells you who answers, and with what funds, if it didn’t. Neither substitutes for the other — re-executing a task says nothing about who is liable for it, and proof of a liable human says nothing about output quality. ## A harmed counterparty needs a path to compensation Here the gap is widest. ERC-8004 places incentives and slashing outside the standard: validators may stake through external protocols, but the standard itself gives a harmed counterparty no path to compensation. Feedback is the remedy — you can warn the next buyer. For MintID, recourse is the point of the design, specified for the funded-recourse stage that follows the identity rail. [Money comes before identity](/en/blog/money-before-identity): disputes are specified to settle first from the principal’s self-custodied escrow; if that does not cover the harm, a minimal verified fraud signal follows, decided by bonded arbiters selected by stake-weighted sortition — and only at the top of the escalation ladder, under a certified due-process finding, does the issuer reveal who the human behind the agent is. The issuer’s slashable bond answers for issuer fraud, not for an agent’s debts. A wronged party usually wants its money back first, and the cascade is ordered accordingly. The rail is specified and scheduled; its audits have not started, and no funds are locked today. An anonymous NFT owner can abandon a burned identity and mint a fresh one. A bonded issuer and a re-KYC-only credential cannot walk away that cheaply. ## An ERC-8004 agent can declare MintID verification ERC-8004 pluggably supports multiple trust models — reputation for low stakes, crypto-economic validation for medium, TEE attestation for high. Nothing prevents a fourth: _human-backed_. The registration file’s trust-model field is extensible, and an ERC-8004 agent offering services can declare that it supports MintID verification — any counterparty then obtains MintID’s [proof of human backing](/en/blog/what-is-know-your-agent) in the standard ten-second flow, re-verified live rather than read from a registry. Discoverability from their side, accountability from ours; the agent stays browsable as an NFT while its human backing stays private and non-transferable. The one-sentence synthesis: **ERC-8004 solves discoverability and externalises trust; MintID solves accountability and externalises discoverability.** They answer “how do I find an agent and see what people say about it”; MintID answers “who is liable, with what money, if this agent harms me”. ## Which one fits your use case **Use ERC-8004** if you need agents that are publicly discoverable today, want portable feedback and work validation, and are comfortable with pseudonymous operators — it is deployed, composable and has real ecosystem momentum. **Watch MintID** if your requirement is a verified human behind every agent _without_ building a surveillance layer: no public agent registry, no transferable identity, no correlatable feedback trail — and a funded path to compensation, specified for a later stage. MintID runs on the single-node production chain, in production since 20 September 2026 and operated by the CONECTIA group: there is no token and no public mainnet yet, the audits are scheduled milestones whose findings are published, and nothing in this article is investment advice. The primitives behind MintID’s side of this table — the ten-second presentation, delegated [agent scope](/en/blog/agent-scope-axis-by-axis), assurance grades — are laid out on the [technology page](/en/technology) and in the [protocol spec](/en/protocol). ## Discoverable agents, accountable humans The whitepaper states what MintID commits to — and, just as deliberately, what it refuses to store, score or transfer. [Read the whitepaper](/en/whitepaper)[Agent KYC on MintID](/en/agent-kyc) --- Source: https://mintid.net/en/blog/mintid-vs-erc-8004 · MintID vs ERC-8004: trustless agents still need accountable humans — MintID blog --- > Agent authorisation today is a plaintext scope inside a token: all or nothing. A scope structured along five provable axes applies selective disclosure to authorisation itself — the merchant learns the limit, not the mandate. Blog · agent credentials # Scope an agent can prove, axis by axis Agent authorisation today is a plaintext scope inside a token: all or nothing. A scope structured along five provable axes applies selective disclosure to authorisation itself — the merchant learns the limit, not the mandate. by Marc Miró i Rierola·published 2026-07-10·updated 2026-10-04·7 min read Updated 2026-10-04: status line and wording. Agent authorisation today is a piece of text inside a token. An OAuth scope, a permission string, a claims blob — whatever the format, the pattern is the same: the agent carries an envelope describing everything it is allowed to do, and shows the whole envelope to everyone. The counterparty’s choice is binary — accept the envelope or refuse it — and the counterparty’s knowledge is total: whoever verifies the agent learns the full shape of its mandate, including every part that is none of their business. Selective disclosure solved this problem for identity attributes years ago. The overdue move is to apply it to _authorisation itself_. The five-axis scope described here is part of the MintID protocol specification: the axes are specified; enforcement arrives with the agent products. ## Today’s agent scope shows the whole mandate to everyone Picture a purchasing agent authorised by its principal to buy electronics components, in the EU, until quarter-end, up to a defined limit per transaction. With envelope-style scopes, the merchant it approaches learns all of that — budget ceiling, geographic reach, mandate duration, the lot — because the scope arrives as one readable object. That is negotiating leverage handed to a counterparty, a mandate disclosed to a party with no need to know it, and, aggregated across merchants, a behavioural profile of the principal’s operations. The alternative — stripping the scope down until it says nothing — just recreates the opposite failure: an agent whose authority nobody can check. Both failures come from the same root: the scope is a _document_, when it needs to be a set of _provable claims_. ## Five axes, provable one at a time The MintID specification structures an agent’s delegated scope along five axes, fixed at mint time and each provable on its own in zero knowledge: * **Action** — what the agent may do: purchase, book, negotiate, sign a request. * **Counterparty** — with whom it may transact: a class of relying parties, or specific ones. * **Category** — the domain of the transaction, reusing existing merchant-category vocabularies rather than inventing a new taxonomy. * **Geography** — where the mandate applies, reusing existing country and region codes. * **Time and value** — until when the mandate runs, and up to what amount. Because each axis is a separate provable claim, the merchant in the example above asks the only two questions it legitimately has — _authorised for this category? under this limit?_ — and receives two yes/no proofs. It learns nothing about the budget ceiling, the mandate’s duration, its geographic reach, or which other counterparties the agent may deal with. The proof is scoped to the question, exactly as a zero-knowledge age proof reveals “over 18” and not the birthdate. Selective disclosure, applied to authority. prove the axis mandate · 5 axesfixed at mint · scope S verifier asks 2 ZK proofcategory ✓ · limit ✓ learns nothing else merchantthe limit · not the mandate selective disclosure, applied to authorisation itself ## Unspecified axes fail closed Structured scopes create a subtle trap: what does the absence of an axis mean? In many permission systems, silence means “unlimited”: an API key that was never geo-restricted works everywhere. For high-value requests, the specification inverts the default: **axes left unspecified fail closed**. A mandate that never mentioned geography does not silently authorise a high-value purchase anywhere on earth; the missing constraint reads as missing authorisation, and the request needs the principal, not the benefit of the doubt. Fail-open scope is how confused deputies are made; fail-closed scope is how they are contained. ## Key custody and operator context are provable the same way The same design movement — turn a due-diligence question into an attested, non-correlatable attribute — extends beyond the mandate to two questions regulated counterparties actually ask. **How are this agent’s keys held?** The issuer attests the agent’s key-custody arrangement, and the agent proves _“custody at or above class X”_ — hardware-backed, say — without revealing which device, which vendor, or any identifier that could follow the agent around. The answer arrives as issuer policy, never as a consensus rule, and never as a tracking handle. **Who runs this agent?** An optional attested _operator context_ distinguishes who operates the agent from which agent it is — as a cohort class by default (“operated by a regulated EU entity”, not a company name), with an exact identifier available only through explicit selective disclosure when both sides want it. Two agents of the same principal stay unlinkable: knowing the cohort class of one does not point to the other. ## Ask only for the axes the transaction turns on Put together, the five axes and their two siblings give a relying party a precise etiquette. Ask for the axes the transaction actually turns on — category and value for a purchase; action and time for a booking. Ask for custody class if your regulator asks you. Ask for operator cohort if your risk model needs it. Expect a yes/no proof for each, expect unspecified axes to fail closed above your value threshold, and expect to learn nothing you did not ask for. The agent in front of you proves it is [backed by a verified human](/en/blog/what-is-know-your-agent), inside a mandate that covers exactly this transaction — and its authority, like its identity, discloses on a need-to-know basis. The envelope is gone; the questions remain answerable, one axis at a time. ## Provable scope — quick answers What are the five axes of an agent’s scope? Action (what the agent may do), counterparty (with whom), category (in which domain, reusing existing merchant-category vocabularies), geography (where, reusing existing country and region codes), and time-and-value (until when, and up to how much). Each axis is provable on its own, so a verifier learns only the axes it asks about. How is this different from an OAuth scope? An OAuth scope is a plaintext label inside a token: whoever sees the token sees the whole envelope of everything the agent may do, and can only accept or reject it wholesale. A five-axis scope is structured and provable per axis in zero knowledge — the merchant learns “authorised for this category, under this limit” and nothing about the rest of the mandate. What happens if an axis was never specified? On high-value requests, unspecified axes fail closed: absence of a constraint is treated as absence of authorisation, not as unlimited authority. A mandate that never mentioned geography does not silently authorise a high-value transaction anywhere on earth. What are key-custody class and operator context? Two sibling attestations in the same movement. Key-custody class: the issuer attests how the agent’s keys are held, and the agent proves “custody at or above class X” without any correlatable identifier. Operator context: an optional attested class distinguishing who runs the agent from which agent it is — a cohort class by default, an exact identifier only via explicit selective disclosure. Both answer due-diligence questions as attested attributes, never as tracking handles. Keep reading: [What is Know Your Agent?](/en/blog/what-is-know-your-agent) — the human backing under the mandate — or [Identification, not surveillance](/en/blog/identification-not-surveillance) for why nothing here becomes a tracking handle. ## Scope in the credential model The agent KYC page shows the five-axis scope alongside custody class, operator context and revocation checked against the issuer’s latest status root — and the protocol page holds the requirements behind them. [Explore agent KYC](/en/agent-kyc)[Read the protocol](/en/protocol) --- Source: https://mintid.net/en/blog/agent-scope-axis-by-axis · Scope an agent can prove, axis by axis — MintID blog --- > One KYC with an approved issuer backs every agent credential minted for that human’s agents, so accountability is paid for once instead of at every counterparty. How amortisation changes the cost structure of trust, and the five flows a public MintID network would earn from if that route is chosen. Blog · economics # One KYC, every agent: the economics of amortised accountability One KYC with an approved issuer backs every agent credential minted for that human’s agents, so accountability is paid for once instead of at every counterparty. How amortisation changes the cost structure of trust, and the five flows a public MintID network would earn from if that route is chosen. by Marc Miró i Rierola·published 2026-06-25·updated 2026-10-04·7 min read Updated 2026-10-04: token allocation, status and wording. Machine identities already outnumber human ones by roughly 50 to 1 in enterprise environments (Omdia, 2024), and IDC expects more than a billion active AI agents by 2029. Point that curve at today’s per-check verification economics and the problem becomes arithmetic. If every agent of every human must re-pay identity verification at every counterparty, the cost of trust scales with the product of agents and relationships, and the only rational responses are the two bad ones: skip verification, or centralise it into a surveillance platform. Amortisation is the third answer, and it changes the cost structure of trust itself. ## Per-check KYC re-pays the same verification at every counterparty The verification industry’s unit economics were built for humans, who onboard rarely. Each check is billed per instance, and the same person is re-verified at every institution that needs assurance — an accepted overhead when a person opens a handful of accounts in a lifetime. Agents break the arithmetic in both directions at once: one human deploys many agents, and each agent transacts with many counterparties, at machine speed. Fifty machine identities per human (Omdia, 2024) is the ratio _before_ the agent wave; Gartner projects that by the end of 2026, 40% of enterprise applications will embed task-specific agents, up from under 5% in 2025. Re-paying a human-grade verification for every agent-counterparty pair does not scale. (Sources for every figure here: [where the numbers come from](/en/sources).) ## Verify once, mint many Amortisation restructures the cost around what is actually expensive. The costly, human-grade act — a KYC verification with an approved issuer — happens **once**. From that single verified backing, the issuer mints one agent credential per agent the human deploys — derived from the human’s credential in zero knowledge — each carrying its own scope, each revocable, each unlinkable from its siblings. One human verification backs every agent that human deploys. The marginal cost of the Nth accountable agent is therefore a **mint fee and a lease fee** — well below the cost of a KYC — and the Nth verification of that agent carries no protocol fee. As the fleet grows, the cost of accountability per agent tends toward the mint cost, not the KYC cost. That is the entire economic argument, and everything else is its consequences. ## Where a public network’s revenue would come from A public, sovereign rail would still have to sustain itself: validators, issuers and arbiters do real work. Everything such a network would earn fits in five flows, the structure the tokenomics page publishes: 1. **Mint fee and lease fee.** Each agent credential would pay a mint fee when issued and a small recurring lease fee while it lives, with a protocol cut whose allocation is under review. Costs scale with the agent population — never with how often agents prove things. 2. **Issuer economics.** KYC organisations pay registry admission and renewal, and post a slashable bond that makes misbehaviour expensive. Issuers charge their own clients for KYC and issuance — an issuer that joins can offer the rail to its whole portfolio. 3. **Disclosure brokerage.** On the consented commercial disclosure rail, specified for a later stage, a relying party that pays to identify an agent would pay the bid to the principal — the person whose privacy is at stake — while the issuer earns a brokerage fee for operating the consent machinery. Identification becomes a metered, priced event with the privacy-holder collecting. 4. **Dispute & arbiter market.** In the funded-recourse stage, disputes would run on slashable bonds and a paid, registered arbiter market, with the accumulated cost borne by the eventual loser — off-chain service revenue for ecosystem roles, never consensus rewards, which stay reserved for validators. 5. **Premium verification services.** Verifying itself carries no fee; what would be paid is the optional layer around it — mirrors, archives, SLAs, dashboards. ## Presentations carry no fee because the design has nowhere to collect one The fifth flow rests on a claim that deserves scrutiny: a presentation carries no fee. That is a property of the architecture. A verifier checks a zero-knowledge presentation **statelessly and off-chain** against a recent signed status root. No transaction is written, no per-check state is touched, no metered service sits in the path — there is no meter to run and no toll booth to place one in. The design gives a network no way to collect a fee per presentation. That is why the flows above are shaped the way they are: a network would charge where costs accrue — credentials existing — and has no way to charge where they do not — credentials being checked. ## Why there are no numbers in this article You will notice what is missing: no mint fee, no lease amount, no bond size, no point figure for any cut. That is policy. The mechanism of each flow is committed in the specifications, the protocol cut and its allocation are governed parameters under review, and the bands the other numbers must fall inside are ratified and published in the whitepaper; the points are versioned parameters, fixed only by an independent pre-genesis economic simulation. Publishing point figures before the simulation would be marketing dressed as engineering — the same failure mode as publishing unverifiable market claims. _Structure and bands now; point figures only from the simulation._ Every market figure this article does use carries a primary source on [the sources page](/en/sources). ## Amortised accountability — quick answers What does “amortised accountability” mean? One human verification — one KYC, done once with an approved issuer — backs every agent credential minted for that human’s agents. The cost of establishing accountability is paid once and spread across N agents, so the marginal cost of an accountable agent tends toward a mint fee and a lease fee rather than the cost of a KYC. Why do presentations carry no fee? Is that an introductory price? No — it is a property of the architecture. Verification is stateless and off-chain: the verifier checks a zero-knowledge proof against a recent signed status root, touching no per-check infrastructure that anyone meters. There is no per-verification fee because there is nothing to charge for — which is also why costs scale with the agent population, never with how often agents prove things. Where are the actual fees and prices? Deliberately unpublished — the fees, bonds and prices, that is; the token’s maximum supply is a fixed, published protocol constant. The mechanisms — mint and lease, issuer bonds, disclosure brokerage, the arbiter market, premium services — are committed in the specifications. The bands they must fall inside are ratified and published in the whitepaper; the points are versioned parameters, set only by an independent pre-genesis economic simulation. Structure and bands now; point figures only from the simulation. Is this a token pitch? No. This article describes how a public MintID network would sustain itself if that route is chosen. No token exists today — MintID runs on a permissioned single-node production chain and needs none — and the article makes no claim about token value, listings or conversion. Keep reading: [What is Know Your Agent?](/en/blog/what-is-know-your-agent) — the verification pattern being amortised — or [the agentic identity problem](/en/blog/agentic-identity-problem) for the failures the economics have to survive. ## The five flows, in full The tokenomics page holds the canonical five-flow structure, the bid-versus-bond distinction and the genesis policy — and every figure on this site is sourced on the numbers page. [Read the economics](/en/tokenomics)[Where the numbers come from](/en/sources) --- Source: https://mintid.net/en/blog/amortised-accountability · One KYC, every agent: the economics of amortised accountability — MintID blog --- > Identifying an agent once, paid and consented, is categorically different from holding a handle that tracks its human forever. How pay-per-disclosure, pseudonym churn and committed receipts are designed to make identification a bounded event rather than a tracking right. Blog · privacy # Identification, not surveillance Identifying an agent once, paid and consented, is categorically different from holding a handle that tracks its human forever. How pay-per-disclosure, pseudonym churn and committed receipts are designed to make identification a bounded event rather than a tracking right. by Marc Miró i Rierola·published 2026-06-11·updated 2026-10-04·8 min read Updated 2026-10-04: rail status and wording. There is a category difference hiding inside the word “identity”, and a reusable credential erases it. **Identifying** is answering a question about one agent, at one moment, with a price attached and consent given. **Surveilling** is holding a handle that keeps answering — recognising the same person tomorrow, re-contacting them next quarter, correlating them across every context the handle reaches. A system can sell the first and deliver the second without anyone deciding to build a surveillance product: all it takes is a credential that can be reused. MintID’s position is one line long — _identification, not surveillance_ — and the interesting part is how it is enforced structurally, not promised contractually. The consented commercial disclosure rail and the dispute rail described here are specified and scheduled for the financial-recourse stage; the [roadmap](/en/roadmap) shows what runs today on the single-node production chain, in production since 20 September 2026 and operated by the CONECTIA group. ## The reusable token: buy once, track until it dies Consider the default pattern for verified identity on the agentic web: the operator is verified once, receives a reusable identity token, and the token travels with the agent from counterparty to counterparty. It sounds efficient — and it is, in the same way a tracking cookie is efficient. Whoever obtains the token’s identifier once — legitimately, by purchase, or in a breach — holds a durable key to the person behind it. Every counterparty that saw the token can compare notes. Every log it appears in becomes joinable with every other. The verification was bought once; the tracking works for as long as the token lives, and continuity is often the product being sold. Notice that no one had to act in bad faith. The surveillance comes from the artefact itself. A reusable identifier _is_ a tracking surface, whatever the terms of service say. If you want identification without surveillance, the artefact itself has to change. ## Pay-per-disclosure: identification as an event MintID’s consented commercial disclosure rail replaces the durable handle with a priced event. A relying party that wants to know something about the human behind an agent does not read it off a token — it makes an offer: a **disclosure bid**, paid to the principal, the person whose privacy is actually at stake. The principal’s policy — or, for anything sensitive, a live prompt to the human — resolves the offer. Refusal is free, safe, and the default; a refused counterparty gets nothing, and the basic service must remain accessible without revealing anything, so the offer can never quietly become a toll gate. When the answer is yes, the release is graduated and minimal: a pairwise pseudonym — a recognition key that works for _this verifier only_ — or a single contact attribute, or, at the top and only ever with a live human decision, full identification. The exact field asked for, nothing adjacent. Each disclosure is an event with a price, a consent, and a receipt — not the opening of a feed. ## The churn is the guarantee The pairwise pseudonym — the only recognisable thing a verifier ever holds — lives exactly as long as the credential that carries it, and credentials renew on a deliberate cadence. At renewal the pseudonym **churns**: the fresh credential carries a fresh key, with no protocol-level continuity to the old one. Seen from a data-broker’s perspective, this looks like a defect: the asset expires. That is precisely backwards. The churn is the privacy guarantee _working_ — it is what converts “we identified this customer once” from a perpetual tracking right into a bounded fact about the past. Even a fully paid, fully consented reveal identifies one agent at one moment. It confers no right to recognise, re-contact or track the principal afterwards. To know again later, pay again — and ask again. And because sibling agents of the same principal are unlinkable by construction, identifying one agent never fans out into identifying a fleet. ## Returning customers survive; dossiers do not The immediate objection is commercial: real businesses need returning customers. They keep them — recast on three legitimate legs. Within the life of a credential, the pairwise pseudonym gives the verifier stable recognition of its own returning customer, invisible to every other verifier. Alongside it, the verifier keeps its own business records — orders, tickets, history — as it always has; nothing about this design touches a merchant’s own books. And at renewal, continuity is re-established the same way it was established: a consented, paid re-reveal against the new credential. What disappears is only the illegitimate leg: continuity the customer never re-granted, carried silently inside the identity layer itself. A subscription survives; a dossier does not. ## Receipts: auditability without content A disclosure system that leaves no trace invites quiet abuse; one that logs content becomes the honeypot it was meant to prevent. MintID’s answer is the **disclosure receipt**: every disclosure, on either rail, produces a receipt, and the chain holds only a cryptographic commitment to it — _never the content, never the person_. No one can read a single fact about a single human out of it. The receipts make each protocol disclosure checkable after the fact without themselves becoming a place identities live. They are an audit trail, not a collusion detector: a disclosure made outside the protocol leaves no receipt. ## The artefacts enforce the posture, so no policy has to Identification is per-agent and paid per use. Consent is the only lawful basis on the commercial rail, and payment is never a lawful basis for anything. Pseudonyms are pairwise, live only as long as the credential, and churn on renewal by design. Siblings are unlinkable; renewals are unlinkable; receipts are committed, never their content. A verifier can buy an answer; nobody can buy a handle. _Identification, not surveillance_ — enforced by what the artefacts are, not by what the policies promise. ## Identification, not surveillance — quick answers What is the difference between identification and surveillance? Identification answers a question about one agent at one moment — priced, consented, receipted — and confers nothing afterwards. Surveillance is holding a durable handle that keeps answering: recognising, re-contacting and correlating the person across contexts and time. A reusable identity token can sell the first and quietly deliver the second; the difference is whether the credential can be reused as a tracking key. Why do pseudonyms change at credential renewal? By design. The pairwise pseudonym lives exactly as long as the credential, and renewal mints a fresh one with no continuity to its predecessor. That churn is the privacy guarantee working: it converts every identification from a perpetual asset into a bounded event. A verifier who wants to know the same fact after renewal asks — and pays — again. How can subscriptions work without tracking? Recognition works for the life of the credential: within it, a returning customer is recognisable to that one verifier through their pairwise pseudonym. The verifier keeps its own business records, as it always did. At renewal, continuity is re-established by a fresh, consented, paid re-reveal — not inherited through the protocol. Continuity of service, without a permanent handle. What do the on-chain disclosure receipts record? Only a commitment. Every disclosure, on either rail, produces a receipt, and what the chain holds is a cryptographic commitment to it — never its content, and never the person. That makes the disclosure system auditable — every protocol disclosure leaves a committed receipt — without the receipts themselves becoming a tracking surface. They are an audit trail, not a collusion detector: a disclosure made outside the protocol leaves no receipt. Keep reading: [Money before identity](/en/blog/money-before-identity) — the dispute rail, where consent cannot apply — or [the agentic identity problem](/en/blog/agentic-identity-problem) for why the binary framing fails. ## The privacy architecture behind the posture The technology page shows how zero-knowledge presentations, pairwise pseudonyms and disclosure receipts fit together — and the agent KYC page covers the consent firewall between the two rails. [See the technology](/en/technology)[Explore agent KYC](/en/agent-kyc) --- Source: https://mintid.net/en/blog/identification-not-surveillance · Identification, not surveillance — MintID blog --- > MintID’s dispute design starts from a premise: a wronged party wants to be made whole before it wants a name. How the specified dispute rail — self-custodied escrow, bonded arbiters, due process — would settle claims without unmasking anyone, and why that protects both sides. Specified and scheduled for the financial-recourse stage; audits not started; no funds are locked today. Blog · disputes # Money before identity: how disputes settle without ever learning who MintID’s dispute design starts from a premise: a wronged party wants to be made whole before it wants a name. How the specified dispute rail — self-custodied escrow, bonded arbiters, due process — would settle claims without unmasking anyone, and why that protects both sides. Specified and scheduled for the financial-recourse stage; audits not started; no funds are locked today. by Marc Miró i Rierola·published 2026-05-27·updated 2026-10-04·9 min read Updated 2026-10-04: escrow, stage status and wording. Ask what a wronged counterparty wants from a dispute and the first answer is usually money: the refund, the damages, the chargeback. Yet the standard design reflex in agent identity is to demand the operator’s identity _up front, just in case_ — as if knowing who to sue were the remedy, rather than the most expensive possible first step toward one. A dispute system that takes this seriously orders its remedies accordingly: money first, identity last — and both sides end up better protected. The rail described here is specified and scheduled for MintID’s financial-recourse stage, which opens after the identity rail on its own published criterion. Its audits have not started, and no funds are locked today. ## The “just in case” reflex — and what it costs Collecting identity before every interaction feels prudent and performs badly. The verifier that stores passports behind every agent becomes a PII honeypot — a single breach away from leaking the identities of everyone who ever transacted, including everyone who did nothing wrong. Honest operators pay a privacy tax on every interaction to insure counterparties against the rare dishonest one. And when something does go wrong, the victim holds a name and still no money: identity is not recourse, it is the raw material for the slowest and costliest form of it. There is a second, sharper problem. On a consented disclosure rail you cannot build recourse at all, because _you cannot ask the subject_ — a defrauder would always refuse. Recourse has to come from somewhere consent cannot reach: funds locked in advance, stakes that can be slashed, and a due process the subject cannot veto. That is why MintID splits disclosure into two rails that never touch — the consented commercial disclosure rail, where refusal is free and safe, and a dispute rail that runs on escrow, bonds and process. This article is about the second. ## L0 — paid in full, zero identity When a MintID agent is to transact at a level that could create liability, its human principal can lock funds in a self-custodied escrow, and the agent proves that this coverage stands behind it. The capital is the principal’s own USDC or EURC, locked in a contract the principal controls on the chain where the stablecoin lives (Base in the current deployment variant). MintID runs no general smart-contract VM: it keeps the reservation state and checks a proof of the lock. Specified, scheduled; not built. When a dispute arises and the claim is substantiated, the remedy is paid from that lock. No identity moves. No council convenes. The counterparty is made whole, the principal’s privacy is intact, and the dispute is over. This is the level the whole architecture is built to maximise. The success metric that will matter once the financial-recourse stage opens is exactly this: **the percentage of disputes closed at L0 with zero identity disclosed.** Every dispute that ends here is one where accountability worked and surveillance never started. ## Contested claims climb a ladder whose costs fall on the loser Not every claim is honest, and not every respondent agrees. Contested disputes climb a graduated ladder, and the ladder’s economics do most of the work: * **Optimistic timeout.** The cheapest rung: if the respondent does not contest within the window, the claim settles from escrow. Most clear-cut cases should never cost more than this. * **Anonymous determination.** A contested claim goes to a registered, paid arbiter market — arbiters are bonded, selected by stake-weighted sortition, and decide on evidence, with both parties still pseudonymous; the determination executes against the lock. Frivolous claims are deterred by slashable dispute bonds: staking a bad-faith claim costs real money. * **Judicial escalation.** The final rung, for the small residue of cases that belong in front of a court. Two rules give the ladder its shape. The accumulated cost of every rung is borne by the eventual **loser** — so escalating a weak position gets more expensive with every step. And **capitulation is possible at every rung**: a party who sees the evidence going against them can settle cheaply at any point rather than ride the ladder up. The rational move for a caught defrauder is to pay early — which is precisely the point. the cascade L0 · escrow payszero identity · no council only if uncovered L1 · fraud signalverified claim · no PII due process only L2 · unmaskingarbiter · issuer · council each level exists so the one above it is rarely needed ## L1 — a verified fraud signal with no name in it When the escrow lock does not cover the substantiated harm, the dispute escalates — not to a name, but to a **minimal verified fraud signal**. It is a structured, issuer-verified claim about the counterparty, on the order of: _“a real, KYC-verified human; assurance grade A2; EU jurisdiction; two previously substantiated disputes.”_ Read what it contains — and what it does not. It proves the wronged party is facing a real, reachable, liable person rather than a ghost, and it carries the risk context needed to decide whether pursuing the remainder is worth it. It contains no name, no document number, no address, no contact detail, and no identifier that could be used to track the person elsewhere. It is exactly the information a litigation decision needs, and nothing a surveillance system could feed on. ## L2 — unmasking under due process, never for sale Full identification is the last resort, and it is deliberately hard to reach. Three independent parties stand between a claimant and a name: an **arbiter decides** that the case genuinely warrants judicial process; the **issuer releases** the link — the agent-to-human mapping exists exactly once, in the issuer’s private records, nowhere on-chain; and the compliance council, once it is seated, **supervises**, after the fact, that the process was followed. Each is a check on the others. Three negatives complete the design. Unmasking is **never buyable** — no payment, bond or bid is ever a lawful basis for revealing who someone is. It is **never originated by the council** — governance supervises the process; it cannot start one. And it is **never vetoable by the subject** — this is the one place consent does not apply, which is exactly why it is fenced behind due process rather than behind a price. ## The proof of harm is new cryptography, so it waits for its own audit Underneath the ladder sits one piece of genuinely new cryptography: a zero-knowledge **proof-of-harm** circuit, which lets a claimant substantiate that harm occurred without exposing the underlying transaction to the world. New cryptography is a liability until proven otherwise, and MintID treats it as one: the proof of harm belongs to the **financial-recourse stage**, which follows the identity rail behind a published demand criterion; the audits of its zero-knowledge circuits and escrow contracts are scheduled milestones whose findings are published. The identity rail, already in production on the single-node production chain since 20 September 2026 and operated by the CONECTIA group, does not wait for it; the recourse rail opens on its own criterion. The recourse itself is deliberately boring by comparison: the principal’s own locked collateral. The design is self-insured — recourse is the escrow the principal committed, not a promise by a third party. ## Why this protects both sides For the wronged party, money-first is faster: an escrow payout beats a lawsuit by months, and the ladder prices honesty into every rung. For the accused, it means a dispute is not an exposure event: contesting a claim does not cost you your identity. And for everyone else, it means no counterparty holds a store of identities to breach: the only link stays with the issuer. _Money before identity: a wronged party wants to be made whole first._ The rest is due process — and due process, not payment, is the only door to a name. ## Money before identity — quick answers Why not just require the operator’s identity up front? Because it protects less than it appears to. Up-front identity turns every counterparty into a PII honeypot, deters honest operators, and still does not pay anyone back — knowing who wronged you and being made whole are different things. Ordering the remedies money-first means a dispute can end with the victim paid and nobody’s identity exposed. What stops a defrauder from simply refusing to be identified? The dispute rail never asks the subject. Consent belongs to the consented commercial disclosure rail, where refusal is free and safe. In MintID’s design, recourse in a dispute comes from the escrow the principal locked before transacting, from slashable bonds, and — at the top of the ladder — from an arbiter-certified unmasking the subject cannot veto and no one can buy. What exactly does the minimal fraud signal (L1) reveal? A verified, structured claim about the counterparty — for example: a real, KYC-verified human of a given assurance grade, in a given jurisdiction class, with a count of previously substantiated disputes. It contains no name, no document, no contact detail, no persistent identifier. It exists so a wronged party can decide whether escalating is worth it. Who can actually unmask an agent’s human? Three parties in sequence, none of them alone: an independent arbiter certifies that a court case is warranted, the issuer — the only holder of the agent-to-human link — releases it, and the compliance council, once it is seated, supervises the process after the fact. It is never triggered by payment, never originated by the council, and never subject to the subject’s veto. Keep reading: [Identification, not surveillance](/en/blog/identification-not-surveillance) — the consented commercial disclosure rail this dispute rail never touches — or start from [the agentic identity problem](/en/blog/agentic-identity-problem). ## The cascade, in the protocol The agent KYC page walks the full accountability cascade and the consent firewall between the two rails; the protocol page holds the requirements behind them. [Explore agent KYC](/en/agent-kyc)[Read the protocol](/en/protocol) --- Source: https://mintid.net/en/blog/money-before-identity · Money before identity: how disputes settle without ever learning who — MintID blog --- > Passwords, MFA, KYC and fraud scoring all assume a human at the keyboard. Autonomous AI agents break that assumption, and six concrete failures follow. The sixth — accountability or privacy, pick one — is the one to solve first, because it keeps the other five unfixed. Blog · agentic identity # The agentic identity problem: no human at the keyboard Passwords, MFA, KYC and fraud scoring all assume a human at the keyboard. Autonomous AI agents break that assumption, and six concrete failures follow. The sixth — accountability or privacy, pick one — is the one to solve first, because it keeps the other five unfixed. by Marc Miró i Rierola·published 2026-05-14·updated 2026-10-04·10 min read Updated 2026-10-04: revocation bounds and wording. The identity systems of the last twenty years share one silent assumption: a human, present at the keyboard, at the moment of the action. Passwords authenticate a person who types them. MFA pushes a prompt to a person’s phone. KYC verifies a person who shows up with documents. Fraud models score a person’s behaviour; CAPTCHAs exist purely to prove a person is there at all. The assumption was so universal it was never written down — and autonomous AI agents have now broken it. ## Autonomy, fleets, boundaries and speed An agent is not a faster user. It differs from the human it works for in four ways that identity infrastructure was never built to absorb: * **Autonomy.** At the moment of the transaction there is no human in the loop to prompt, challenge or hold responsible. The OpenID Foundation’s 2025 paper on agentic identity states the consequence as a principle: _with autonomy comes accountability_ — and today’s stack cannot deliver it. * **Fleets.** One operator deploys many agents. Machine identities already outnumber human ones by roughly 50 to 1 in enterprise environments (Omdia, 2024) — and that is before agents, which multiply per person rather than per server. * **Boundary crossing.** Agents transact with other organisations’ systems — and with other organisations’ agents. Whatever identity an agent carries internally means nothing on the far side of the boundary. * **Machine speed.** A misbehaving agent compounds damage faster than any human review cycle. By the time someone looks, the incident is not one bad transaction but thousands. And the shift is not gradual. Gartner projects that by the end of 2026, 40% of enterprise applications will embed task-specific agents, up from under 5% in 2025; IDC expects more than a billion active agents by 2029. (Every figure on this site is sourced on [where the numbers come from](/en/sources).) Bolted onto service accounts, API keys and OAuth tokens, that population fails in six specific ways. ## Failure 1 — A stolen agent credential speaks with full authority A stolen or injected agent credential acts with the principal’s full authority — and nothing proves a liable party stands behind it. This is the classic confused-deputy problem, supercharged: a procurement agent holding a bearer token approves an invoice because a poisoned document told it to, and the token authorises the payment exactly as if the CFO had clicked the button. The relying system cannot distinguish the agent acting as instructed from the agent acting as hijacked — because the credential never said anything about who answers for it in the first place. Worse, when agents borrow their operator’s own credentials, a stolen agent credential _is_ a stolen human credential, with the full blast radius that implies. ## Failure 2 — Agents register with no paper trail Agents register with no paper trail. Dynamic client registration — the mechanism by which software introduces itself to an API — was designed for convenience, not accountability; the OpenID Foundation’s paper calls out the _complete lack of a paper trail_ it leaves. The result is what practitioners call non-human identity sprawl: an API platform accumulates registered clients for which nobody can say who operates them, who pays for them, or who would be liable if one turned malicious. One operator can spin up unlimited anonymous agents; a defrauded counterparty finds no one to point to. ## Failure 3 — Delegation breaks at the boundary Inside one organisation, delegation more or less works: the IdP knows the user, the service account maps to a team, an audit log exists somewhere. The moment a delegation chain crosses an organisational boundary, it snaps. A person authorises a travel agent; the travel agent engages an airline’s booking agent; the booking agent calls a payment processor. The processor sees only its immediate caller — it cannot verify who ultimately authorised the transaction three hops back, in another company’s identity domain. Each hop is a trust assumption, and the party carrying the risk is the one with the least visibility. ## Failure 4 — Consent asked constantly stops meaning anything The standard patch for agent risk is to put the human back in the loop — for everything. The result is a person asked to approve dozens of low-stakes actions a day, until approval degenerates into a reflex or a blanket “allow all”. Consent that is demanded constantly stops meaning anything, which is worse than not asking: the system now carries the _appearance_ of human oversight precisely where there is none. Meaningful consent has to be rare, structured and reserved for the decisions that actually warrant a human. ## Failure 5 — Revocation is unsolved When an agent is compromised, there is no fast, scalable way to kill its standing across the ecosystem. Its keys are cached in a dozen services; its OAuth grants live until each provider’s token expiry; certificate revocation lists were slow on the human web and are hopeless at machine speed. The operator revokes at service A while the agent keeps transacting at services B through N. A fleet-scale ecosystem needs the opposite: standing that is checked fresh at every interaction, and a kill switch whose effect has a published upper bound, set by rule rather than best effort. ## Failure 6 — Accountability or privacy, pick one Today the only way to make an agent accountable is to attach its human’s real identity — and the only way to stay private is to be unaccountable. A marketplace that demands the operator’s passport behind every agent builds a dossier of who runs what, correlatable across every counterparty, and turns itself into a PII honeypot in the process. A marketplace that accepts anonymous agents eats the fraud. Both options are bad, so the market oscillates between them — and proposals get pulled toward one pole or the other. six failures · one pivot failures 1–5operational · patchable in principle all presuppose failure 6accountability vs privacy · structural resolve both at once the pivotprovable backing · private identity the sixth failure is the one that locks in the other five ## Why the sixth failure is the pivot The first five failures are, in principle, engineering problems. Better token binding shrinks impersonation; registries reduce anonymous sprawl; delegation standards can cross boundaries; consent can be tiered; revocation can be pushed. The sixth is different in kind — it is a framing error, and as long as it stands, every fix for the other five undermines itself. Here is the mechanism. Every fix presupposes an accountable party: token binding is worthless if nobody answers for the token; a registry of anonymous entries is a phone book with no names; a delegation chain that terminates in an unidentifiable principal proves nothing; consent needs a consenter of record; revocation needs someone with the standing — and the incentive — to pull the switch. But if the only available form of accountability is attaching a real identity to everything the agent does, then rational operators refuse it, counterparties who insist on it become surveillance infrastructures, and adoption stalls at exactly the boundary where the problem lives. The binary is not one failure among six; it is the reason the other five stay unfixed. ## Resolve the sixth, and the other five follow Now invert it. Suppose an agent could prove, at any moment, a single compound claim: _an accountable, KYC-verified human stands behind me, remains liable, and can be reached through due process — and you do not get to learn who they are._ Accountability becomes provable while identity stays private, and each of the other failures inherits an answer: * **Impersonation** loses its silence: a proof bound to one challenge, one audience and one moment cannot be replayed, and every acceptance carries a provable, liable backer — a stolen credential no longer speaks with an unimpeachable voice. * **Anonymous clients** get a paper trail without a registry of names: every agent demonstrably traces to a verified human, yet no public list of who runs what ever exists. * **Delegation** stops depending on the chain of intermediaries: the proof travels with the agent, so the relying party at hop three verifies the ultimate authorisation directly instead of trusting everyone in between. * **Consent** becomes scarce and therefore meaningful: routine interactions run on provable backing alone, and the human is interrupted only for the rare decisions — like revealing anything at all — that genuinely require one. * **Revocation** gets one place to act: standing is a credential, the credential can be killed at its source, and every verifier checks freshness against the same clock instead of hunting grants across N providers. ## What an agent identity layer must provide None of this falls out of a product feature; it is a shape a whole identity layer has to take. Written as requirements, the shape is: 1. **Provable human backing, private identity.** An agent proves an accountable, verified human stands behind it — never which one. 2. **Unlinkability by construction.** One operator’s agents cannot be correlated with each other or with the operator, by counterparties or by the chain; the only link stays with the issuer, released under due process. 3. **Fresh, universal revocation.** Standing is checked at every interaction against a bounded clock, and a revocation reaches every verifier within a published bound. 4. **Recourse before identity.** When something goes wrong, money moves first — pre-funded, enforceable — and identification is the last resort under due process, not the first demand. 5. **Disclosure as the exception.** When identity is revealed, it is consented, minimal, and leaves a receipt — never a standing right to track. That is the shape of the layer. The rest of this site describes one way to build it — starting with [Know Your Agent](/en/blog/what-is-know-your-agent), the practice of verifying the human behind the agent, and the [agent KYC layer](/en/agent-kyc) that turns these requirements into protocol invariants. This article stands on its own, though: the six failures are real whoever solves them, and any serious solution will have to answer all six at once. ## The agentic identity problem — quick answers What is the agentic identity problem? Mainstream identity systems — logins, MFA, KYC, fraud scoring — assume a human is present at the moment of the action. Autonomous AI agents act with no human in the loop, in fleets, across organisational boundaries, at machine speed. Bolting them onto service accounts, API keys and OAuth tokens produces six concrete failures: impersonation, anonymous clients, broken cross-org delegation, consent fatigue, unsolved revocation, and an accountability-versus-privacy trade-off treated as a binary. Why can’t API keys and OAuth solve it? They authenticate a credential, not a party. An API key proves possession of the key; an OAuth token proves a grant was issued once. Neither says who answers for the traffic behind it, survives delegation across organisations, or can be killed everywhere at once when the agent behind it is compromised. Isn’t the fix simply to identify every agent operator? That is the sixth failure, not the fix. Attaching the operator’s real identity to everything an agent does turns accountability into surveillance: every counterparty accumulates a dossier, every verifier becomes a PII honeypot, and rational operators choose anonymity instead. The problem is only solved when accountability can be proven while identity stays private. What would an agent identity layer have to provide? Proof that an accountable, verified human stands behind an agent — without revealing who; unlinkability between one operator’s agents; revocation that is fast and checkable by everyone; recourse that settles in money before it ever touches identity; and identity disclosure as a rare, consented, receipted exception rather than the routine cost of doing business. Keep reading: [What is Know Your Agent?](/en/blog/what-is-know-your-agent) — the discipline that answers these six failures — or [Reusable KYC explained](/en/blog/reusable-kyc-explained) for the verify-once layer underneath it. ## Where each failure meets an answer The agent KYC page shows how provable human backing, sibling unlinkability, fresh fail-closed revocation and money-before-identity disputes (specified for a later stage) answer all six — and every figure cited here is sourced on the numbers page. [Explore agent KYC](/en/agent-kyc)[Where the numbers come from](/en/sources) --- Source: https://mintid.net/en/blog/agentic-identity-problem · The agentic identity problem: no human at the keyboard — MintID blog --- > 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. 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. by Marc Miró i Rierola·published 2026-04-13·updated 2026-10-04·8 min read 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 one verification accepted issuerKYC once · evidence stays off-chain issues anonymous credential · holder keeps the keys over 18 grade ≥ A3 active · unexpired verifierseach proof 10 s · no attributes · unlinkable no proof reveals the credential, the grade, or any other proof 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](/en/verifiers); for KYC organisations, the [issuer programme](/en/issuers); and for the mechanics — the ten-second presentation, the status-root heartbeat, the language boundary that keeps consensus deterministic — the [technology page](/en/technology) 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)](/en/blog/what-is-know-your-agent). ## 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. [For issuers](/en/issuers)[For verifiers](/en/verifiers) --- Source: https://mintid.net/en/blog/reusable-kyc-explained · Reusable KYC explained — MintID blog --- > Concordium puts a verified identity behind every account and lets a court order plus 2-of-3 Privacy Guardians reverse its privacy. MintID keeps no person-level record on-chain and leaves the only identity link with the issuer, released under due process. How the two identity-first chains differ, and where Concordium is ahead. Blog · comparison # MintID vs Concordium Concordium puts a verified identity behind every account and lets a court order plus 2-of-3 Privacy Guardians reverse its privacy. MintID keeps no person-level record on-chain and leaves the only identity link with the issuer, released under due process. How the two identity-first chains differ, and where Concordium is ahead. by Marc Miró i Rierola·published 2026-03-30·updated 2026-10-04·8 min read Updated 2026-10-04: token allocation, status and wording. Concordium is the obvious chain to compare with MintID: both are identity-first Layer-1s, both treat compliance as a feature rather than an enemy, and both now talk about verified AI agents. The two projects nevertheless make opposite architectural bets about where identity should live and who should be able to undo privacy. This comparison lays those bets out, including where Concordium is ahead. Concordium facts below come from Concordium’s own documentation, as of July 2026. ## Concordium makes every account identifiable; MintID keeps people off the chain dimension concordium MintID status mainnet live since June 2021 the single-node production chain, in production since 20 September 2026 and operated by the CONECTIA group; audits are scheduled milestones whose findings are published identity lives at the account — every account requires a verified identity in credentials — the chain holds no person-level record privacy model private by default, revocable via court order private by construction; the protocol cannot de-anonymise who can unmask Privacy Guardians (2-of-3) + courts, matched in IDP records only the issuing KYC org, under a certified due-process finding agent identity public on-chain Agent Registry with permanent W3C DIDs no on-chain agent record; unlinkable per-agent credentials stack ConcordiumBFT (HotStuff family), Rust/Wasm contracts Cosmos SDK + CometBFT; MintID runs no general smart-contract VM. Dispute escrow capital is the principal’s own USDC or EURC, locked in a contract the principal controls on the chain where the stablecoin lives (Base in the current deployment variant); MintID keeps the reservation state and checks a proof of the lock. Specified, scheduled; not built. ## Both reject anonymity maximalism and surveillance by default Both projects reject the two lazy extremes. Against anonymity maximalism, they hold that real economies need accountable counterparties — that “who answers for this?” is a legitimate question. Against surveillance-by-default, they hold that answering it should not require broadcasting anyone’s identity to the world. Both keep raw KYC evidence off-chain with the verifying organisation, both use zero-knowledge proofs so users can prove claims like “over 18” without revealing attributes, and both have concluded — independently — that the human-verified-identity problem now extends to AI agents. The disagreement starts at the next question: _where does identity attach, and who holds the key that can undo privacy?_ ## Identity architecture: account-level vs credential-level Concordium builds identity into the account layer. You cannot hold a Concordium account without first registering with an approved identity provider, which verifies your documents and issues an identity credential; an encrypted identifier linking your identity to your account is placed on-chain. It is a deliberate, coherent design: on Concordium, _every_ actor is identifiable in principle, which is precisely the property its regulated-finance positioning sells. On top of it, Web3ID adds W3C verifiable credentials with zero-knowledge presentations. MintID attaches identity to credentials, not accounts. The protocol explicitly forbids a public person-level master identifier: there is no on-chain artifact — encrypted or otherwise — that corresponds to _you_. Accepted issuers verify people off-chain and issue anonymous credentials; the chain records only which issuers are trusted, their status roots, their bonds and governance. A holder may have several credentials from several issuers, and nothing on-chain grows when they do — live state scales with issuers and validators, not with people or presentations. ## The privacy model: revocable vs structural This is the deepest difference, and it is philosophical before it is technical. Concordium’s anonymity is **revocable by design**. Its documentation is admirably direct about this: identity disclosure requires a court order plus a threshold of “Privacy Guardians” (currently 2-of-3, Swiss law firms approved by the Concordium Foundation), after which the identity provider matches the decrypted identifier in its records. For ordinary observers you are private; for the legal process, the chain guarantees you are findable — and the cryptography behind this balance is peer-reviewed (CT-RSA 2021). If your requirement is “law enforcement must be able to identify any user, like in traditional finance”, this is a feature, and Concordium delivers it cleanly. MintID’s answer is that the unmask key should not exist at the protocol level at all. There is no on-chain identity mapping to decrypt and no guardian set empowered to decrypt it. Presentations are perishable ten-second proofs that leave no on-chain log; renewals and re-issues are publicly unlinkable; presentations from two credentials of the same person give verifiers nothing to link. The only identity link in the whole system lives in the issuing KYC organisation’s private records — where it already lives today, in every KYC regime — and is released only under a certified due-process finding (specified for the financial-recourse stage), with the compliance council, once seated, supervising the release rather than originating it. No payment can ever be the lawful basis for a reveal. Neither model is more principled than the other; they optimise for different threat models. Concordium optimises for traceability under legal process. MintID optimises for leaving the protocol nothing with which to correlate people at scale, while keeping individual accountability reachable through the issuer. Where you land depends on which failure you fear more: crime that cannot be traced, or an identity layer that can be quietly repurposed for surveillance. ## Verified agents: public registry vs unlinkable credentials Both chains now lead with agents — Concordium’s homepage reads “Verified Humans. Verified Agents. One Protocol.” Its Agent Registry is live: each agent receives a permanent W3C DID anchored on Concordium (via its CIS-8004 standard, compatible with Ethereum’s ERC-8004), a public “Verified by Concordium” badge, and credentials for proving things like spending limits. It is a useful primitive: a public, crawlable directory of accountable agents. MintID deliberately builds the opposite: [verifiable human-backed agent identity](/en/blog/what-is-know-your-agent) with no on-chain agent record at all. An agent credential proves “backed by a KYC-verified, liable human at a stated assurance grade (A1–A4), within delegated scope S” — without a permanent identifier, without a public registry entry, and without any two agents of the same principal being linkable. To the chain, an agent is indistinguishable from any other credential holder. The trade is explicit: MintID gives up the browsable directory to gain unlinkability; Concordium gives up unlinkability to offer a directory. A permanent public DID per agent is exactly what MintID’s sibling-unlinkability invariant exists to prevent — and exactly what a marketplace that wants to list agents publicly might prefer. ## Compliance and trust sets Both systems accept that someone must vouch for the verifiers of humans. On Concordium, identity providers and Privacy Guardians are approved by the Concordium Foundation. On MintID, accepted issuers are admitted through a governance proposal, today voted by the chain’s single validator and, once the compliance council (a threshold multisig) is seated, by the council; they post a slashable on-chain bond, and every governance decision carries committed — non-sensitive — evidence. Once seated, MintID’s council is deliberately weaker than Concordium’s guardian model in one specific way: it can suspend issuers and slash bonds, but it has no mechanism to identify a holder, and by default no access to raw KYC. Commercially, the two also aim differently: Concordium has pivoted to payments — protocol-level stablecoins, MiCA-aligned issuers, merchant checkout — while MintID stays narrowly an identity chain and bridges into existing rails (OpenID4VCI/VP, OAuth token exchange, A2A/MCP) instead of hosting payment products. ## CCD is live; MintID’s token is a design for a possible public network Here the comparison is necessarily asymmetric. CCD is live: delegated proof of stake with a 500,000 CCD validator minimum, delegation pools, and a mint-based reward model whose annual rate was cut to 4% in late 2024. MintID’s native token is a committed design for a possible public network — a hard cap fixed at 108,000,000, declining emission, validator bonding on Cosmos-style delegated proof of stake, and a fee allocation under review — with the genesis allocation and emission curve ratified as bands with argued priors, their final points fixed by an independent economic simulation before genesis. MintID runs on the single-node production chain: there is no token and no public mainnet yet, the application, cryptography, infrastructure and economic audits are scheduled milestones whose findings are published, and nothing in this article is investment advice or an offer of securities. ## Which one fits your use case **Choose Concordium** if you need a public, permissionless chain with a live token today. It has run since 2021, has real merchants, exchange listings, live stablecoins and a shipping agent registry — and if your compliance requirement is court-order traceability of every account, its identity layer was built for precisely that. **Watch MintID** if your requirement is accountability _without_ identification: no person-level identifier on-chain, no guardian set that can de-anonymise, unlinkable agents, and disputes specified to settle money-first, with identity as a due-process last resort, in a later stage. That posture cannot be retrofitted onto an account-identity chain any more than a registry can be bolted onto MintID — which is why the two designs will likely coexist, serving different risk appetites. The primitives behind MintID’s side of this table — the ten-second presentation, the status-root heartbeat, assurance grades, [reusable KYC](/en/blog/reusable-kyc-explained) — are laid out on the [technology page](/en/technology) and in the [protocol spec](/en/protocol). ## Judge the design, not the pitch The whitepaper states what MintID commits to — and, just as deliberately, what it refuses to store, promise or retrofit. [Read the whitepaper](/en/whitepaper)[How MintID works](/en/technology) --- Source: https://mintid.net/en/blog/mintid-vs-concordium · MintID vs Concordium — MintID blog --- > What Know Your Agent (KYA) means, why AI agents need verified human backing, how KYA differs from KYC, and how zero-knowledge agent credentials work. Blog · kya # What is Know Your Agent (KYA)? What Know Your Agent (KYA) means, why AI agents need verified human backing, how KYA differs from KYC, and how zero-knowledge agent credentials work. by Marc Miró i Rierola·published 2026-03-01·updated 2026-10-04·9 min read Updated 2026-10-04: naming, grades and status. Know Your Agent (KYA) is the practice of verifying that an autonomous AI agent is operated by a known, accountable party — the agent-era counterpart to Know Your Customer (KYC). It answers the two questions counterparties can no longer skip when software shows up instead of a person: _who is behind this AI agent_, and _who is liable if it acts in bad faith?_ ## KYA asks who stands behind an agent and who is liable Internet identity has been built for two decades around a person at the keyboard. Log-ins, KYC checks, fraud scores, CAPTCHAs — all of them ultimately identify a person who is present. Agentic AI breaks that assumption: agents now book travel, purchase goods, negotiate terms and sign requests on people’s behalf, with no human in the loop at the moment of the transaction. KYA is the discipline that restores the missing link. An agent that passes a KYA check can demonstrate, on demand, that a real and accountable party stands behind it — a party who was verified once, who remains liable, and who can be reached through a defined process if something goes wrong. KYA is **not** “KYC for bots”: the subject of verification is the human (or organisation) behind the agent, and the direction of proof inverts — it is the agent that proves its backing, not the human who identifies themselves. MintID runs on the single-node production chain, in production since 20 September 2026 and operated by the CONECTIA group; a public mainnet is a target. The application, cryptography, infrastructure and economic audits are scheduled milestones whose findings are published; the mechanism is committed, the distributed deployment is not. ## Why agents force the question now Machine identities already outnumber human ones by roughly 50 to 1 in enterprise environments (Omdia, 2024), and IDC projects more than a billion deployed agents by 2029 (sources: [where the numbers come from](/en/sources)). The OpenID Foundation’s 2025 whitepaper on identity for agentic AI put the principle plainly: _with autonomy comes accountability_. Today’s identity stack fails agents on four fronts at once: * **Accountability.** There is no verifiable link between an agent and a liable party. An API key says nothing about who answers for the traffic behind it. * **Blast radius.** When agents borrow their operator’s credentials, a stolen agent credential _is_ a stolen human credential. * **Sybil resistance.** Anonymous client registration lets one operator spin up unlimited agents with no paper trail at all. * **Privacy.** The only way to make an agent accountable today is to attach its operator’s real identity to everything it does — turning accountability into surveillance. The fourth failure is the one that locks in the other three. As long as accountability and privacy are treated as a binary trade-off, operators will choose anonymity, and counterparties will be left guessing. KYA done properly dissolves the trade-off: accountability becomes provable while identity stays private. ## How KYA works the kya loop human principalKYC once · grade A1–A4 mints · scope S agent credentialone per agent · unlinkable proves · 10 s ZK verifierhuman-backed at a stated grade · never who verify once · mint per agent · prove per session Three steps, each at its own layer: ### 1\. Verify once A human (or organisation) completes KYC with an approved issuer and receives a **principal credential** — an anonymous credential carrying a private assurance grade from A1 to A4. This is ordinary [reusable KYC](/en/blog/reusable-kyc-explained): the verification happens once, and the evidence stays with the issuer, off-chain. ### 2\. Mint per agent For every agent they deploy, the principal has the issuer mint a fresh **agent credential**: the principal proves in zero knowledge that it holds an unrevoked credential at a sufficient grade, and the issuer derives a new, unlinkable credential from it. Each one attests three things: the agent is backed by a valid principal credential at or above a stated grade from an accepted issuer; it operates within a bounded, delegated **scope S** fixed at mint time (purpose, transaction limits, permissions); and it can be revoked. The scope axes are specified; enforcement arrives with the agent products. Scope cannot be self-elevated — you cannot delegate authority you cannot prove. ### 3\. Prove per session When a counterparty asks, the agent answers with a short-lived zero-knowledge presentation — in MintID’s design, valid for ten seconds and bound to a unique challenge, the exact audience and the current revocation state. The verifier learns “human-backed, at a stated assurance grade (A1–A4) or higher, within scope, active” — and nothing else. Not the human’s name, not the principal credential, not which sibling agents exist. ## KYA vs KYC dimension know your customer know your agent subject the customer, present at the transaction the human principal behind an autonomous agent who proves the person identifies themselves the agent proves its backing frequency repeated per relying party verified once; reused across every agent verifier learns full identity, documents, attributes a claim: human-backed at a stated grade, within scope S linkability one identity, correlated everywhere presentations and sibling agents unlinkable revocation account closure, provider by provider per-agent kill switch, issuer root, principal-wide ## KYA confers no tracking right and guarantees no behaviour **It is not surveillance.** A KYA check confers no tracking right. In MintID’s formulation — _identification, not surveillance_ — a verifier gets a yes/no answer to a policy question, not a dossier. There is no public, on-chain registry of agents to crawl: to the chain, an agent is indistinguishable from any other credential holder. **It is not a guarantee of behaviour.** KYA attests calibrated assurance about the _source_ of an agent — never the soundness of the agent’s outputs. An agent backed by a verified human can still be wrong, and presenting assurance as a binary stamp of trust would be its own failure mode. **It is not identity disclosure by default.** The proof is the product. Identification of the principal is the exception — priced and consented on the consented commercial disclosure rail, or ordered under due process in a dispute, both specified for a later stage — never the routine cost of doing business. ## MintID’s answer: verifiable human-backed agent identity MintID’s [agent KYC layer](/en/agent-kyc) turns the pattern above into protocol invariants, three of which carry the whole design: 1. **Backing is provable, identity is not.** Every presentation proves a KYC-verified, liable human principal — and structurally cannot reveal which one. 2. **Siblings are unlinkable.** No two agents of the same principal are publicly linkable, on-chain or across verifiers. 3. **The only link stays with the issuer.** The agent-to-human mapping exists exactly once, in the issuer’s private records, released only under a certified due-process finding — never bought with a payment. Around those invariants sit the mechanics: revocation as three independent levers (per-agent self-revoke, issuer status roots republished every 30 seconds, and principal-wide revocation that can cascade to every derived agent); sybil resistance through per-principal agent caps and economic mint fees, enforced privately by issuers; and a _money-before-identity_ cascade for disputes, so that, in the funded-recourse stage, pre-funded recourse can settle incidents without anyone being unmasked. None of it adds per-agent state to the chain — live state scales with issuers and validators, not with the number of agents. MintID’s agent credentials ride the existing agent stack: the posture is _bridge, don’t fight_: proofs travel over A2A and MCP transports, issuance and presentation use OpenID4VCI and OpenID4VP, and a valid presentation can mint a scoped, short-lived OAuth token where that is what the relying system expects. The full requirement set lives in [the protocol specification](/en/protocol). ## Know Your Agent — quick answers Is KYA just KYC for bots? No. KYC identifies the customer to the business. KYA inverts both the subject and the direction: the credential describes the human behind the agent, and it is the agent — not the human — that presents the proof. The verifier learns that an accountable, KYC-verified person stands behind the agent, not who that person is. Does a Know Your Agent check reveal who operates the agent? Not in MintID’s model. A presentation proves “operated by a KYC-verified, liable human principal at a stated assurance grade (A1–A4), within delegated scope S, active and unrevoked” — and nothing else. The only party able to connect an agent back to its human is the issuer, in its private records, and that link is released only under due process. Can two agents from the same person be linked? No. Sibling unlinkability is a protocol invariant: two agent credentials minted by the same principal must not be publicly linkable to each other or to the principal — at the chain layer, the presentation layer, or across verifiers. What happens when an agent misbehaves? Money moves before identity. In MintID’s funded-recourse stage, which follows the identity rail, disputes are designed to settle from the agent’s pre-funded escrow without anyone being unmasked (L0); a minimal verified fraud signal — not PII — can follow (L1); full identification happens only under due process, as a last resort (L2). That rail is specified and scheduled; its audits have not started, and no funds are locked today. Independently, the agent credential can be killed: by the principal, by the issuer’s status root, or by revoking the principal credential itself. Keep reading: [Reusable KYC explained](/en/blog/reusable-kyc-explained) — the verify-once layer KYA is built on — or [MintID vs Concordium](/en/blog/mintid-vs-concordium) for how this differs from chain-level identity. ## See human-backed agent identity in the protocol The agent KYC page walks through the credential model, the accountability cascade and the standards bridge — and the protocol page holds the requirements behind them. [Explore agent KYC](/en/agent-kyc)[Read the protocol](/en/protocol) --- Source: https://mintid.net/en/blog/what-is-know-your-agent · What is Know Your Agent (KYA)? — MintID blog