The main project, Apache-2.0, and its read-only mirrors.
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.
the credential
The four questions
Four questions a relying party asks about an agent
Each one comes with something you can check: the component that answers it, the word for where it stands, and the artefact or page where you check it yourself.
- 01
Is a real, accountable person behind this agent?
The agent proves, in ten seconds and in zero knowledge, that a KYC-verified principal backs it. The relying party learns the answer, never the person.
pip install "mintid-agent[ed25519]" - 02
Is it acting within the scope that person set?
The scope is fixed when the agent is minted and proven per axis; an out-of-scope request is refused by name.
- 03
Has it been switched off?
The person or the operator revokes the agent without asking the issuer and without telling the network which credential died; every service refuses it within one status root.
componentholder self-revocation
- 04
Can I check it myself, without trusting the operator?
You run the verifying code in your own perimeter, against proven chain state, and keep a minimal decision record: never the proof, never the person.
pip install mintid-verifier-sdk
What none of this proves: which configuration the agent runs or what it did; that is provenance, a different layer.
The code
Where the code and the packages are
One main project under Apache-2.0 holds the whole implementation; the packages carry released versions, and the read-only mirrors follow the main project.
The Python packages: the verifier SDK, the proof core and the agent client.
The TypeScript packages: the verifier client and the MCP server.
The Go holder binding.
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 worksAGENTSEvery 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 identityKILL SWITCHThe 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 worksBUYING AGENTA 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 checksSELLERA 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 ZadQCONSENTIdentification, 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 firewallMANDATEA 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 railsRECOURSEMoney 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 identityStart 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.
In plain English
The eight words this site uses, one line each
- credential
- The signed record an issuer gives a person after verifying them once. It lives with the person, never on the chain.
- holder
- The person, or the agent, who keeps the credential and the only key that can use it. Nobody else holds a copy.
- issuer
- An accepted KYC organisation that verifies people once and issues their credentials. It posts a bond and publishes status, never people.
- verifier
- Any service that asks for a proof before acting and checks it in its own perimeter, against the chain’s state.
- presentation
- The ten-second proof a holder sends to answer one question. It shows the answer is true and reveals nothing else.
- status root
- A small signed summary an issuer publishes on the chain at least every 30 seconds, saying which credentials are still valid without listing them.
- bounded agent
- An agent minted with a preset scope. It proves each action is inside that scope, and an out-of-scope request is refused by name.
- kill switch
- The holder or the operator switches a credential or an agent off, without asking the issuer and without telling the network which one died.
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.
Prove the claim, not the identity
Zero-knowledge proofs answer the question asked and reveal nothing else.
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.
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.
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
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.
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 worksVerifiers
Services that need an answer — “over 18?”, “a real person behind this agent?” — and get it without storing personal data.
See how the role worksValidators
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 worksStatus
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, read how the technology works, or see ZadQ, the first pilot.