Glossary
MintID glossary
This glossary defines the terms the protocol uses, in the sense MintID uses them. Each entry is self-contained: it explains what the term means, why it exists and how MintID implements it. Every definition has its own anchor.
- §Know Your Agent (KYA)
- Know Your Agent (KYA) is the market’s name for verifying that a known, accountable party operates an autonomous AI agent. It is the agent-era counterpart to Know Your Customer (KYC). Before an agent can transact, a KYA check asks whether a real, liable human or organisation stands behind it if it causes harm. MintID provides verifiable human-backed agent identity through zero-knowledge credentials. These credentials prove that an accountable human backs the agent, and they do not reveal who that human is.
- §Agent KYC
- Agent KYC is how MintID delivers verifiable human-backed agent identity, which the market calls Know Your Agent. An AI agent carries a credential derived from its operator’s real KYC and issued by an accepted issuer. The agent then uses a zero-knowledge presentation to prove that an accountable, KYC-verified human backs it. This presentation does not disclose the human’s identity. Agent KYC is defined in MintID’s agent-identity specification. It runs on the same rail as human credentials and adds nothing new to the chain.
- §Provenance (of an agent)
- Provenance (of an agent) is what a signed manifest, an attestation or a signed run record proves. It shows which configuration an agent started with, where it ran and which calls it made. It is not agent identity. In MintID, agent identity is the credential’s claim that an accountable, KYC-verified principal stands behind the agent within a scope the principal fixed. The credential proves this claim and does not name the principal. A workload identifier, such as a SPIFFE identifier or a DID, names a process. MintID proves agent identity and claims neither provenance nor workload identity. A manifest, a run record or a workload identifier proves what ran and names a process. It never shows who answers for the agent.
- §Verifiable human-backed agent identity · zero-knowledge agent identity
- Verifiable human-backed agent identity, which the market calls privacy-preserving know your agent, is agent verification where the counterparty learns only that "this agent is backed by an accountable, KYC-verified principal." The counterparty learns nothing else. It receives no name, no passport and no persistent handle that tracks the operator across services. This resolves the trade-off between accountability and privacy that plaintext agent registries and transferable agent NFTs cannot solve. Counterparties get verifiable accountability, and the person behind the agent is not tracked.
- §Zero-knowledge presentation
- A zero-knowledge presentation is a cryptographic proof that a credential holder generates to convince a verifier that a claim is true. For example, it can prove that the holder is over 18, that a credential is valid, or that a verified human backs an agent. The presentation does not reveal the underlying data or create a linkable identifier. In MintID, presentations are bound to the verifier’s challenge and expire after ten seconds. They are never logged on-chain.
- §Reusable KYC
- Reusable KYC means completing identity verification once with an accepted issuer. The holder can then prove facts from that verification anywhere and any number of times, without repeating the check or re-exposing documents. One verification backs many proofs and, through agent credentials, many agents. Reusable KYC replaces the per-service KYC cycle, where every counterparty re-collects and re-stores the same passports and selfies.
- §Verifiable credential
- A verifiable credential is a digitally signed attestation where an issuer vouches that facts about a subject are true. Third parties can check it cryptographically without contacting the issuer. In MintID, credentials stay with the holder and are never stored on-chain. Only the zero-knowledge presentations derived from them circulate.
- §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 presentations and to the issuance event. The verifier learns the proven claim and nothing else. MintID uses anonymous credentials in the Hyperledger AnonCreds lineage, with the exact construction frozen. This construction combines blinded issuer signatures, a holder secret, selective disclosure and predicate proofs. It lets accountability and privacy coexist.
- §Selective disclosure
- Selective disclosure means revealing only the specific attributes a transaction needs, such as an age bound, an assurance grade or a spending limit. Every other attribute of the credential stays hidden. MintID applies selective disclosure to authorisation too. An agent proves its scope axis by axis, so a merchant learns only the limit that matters and does not see the whole mandate.
- §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. The only link between the two lives in the issuer’s accountability escrow, a private record that never holds funds, and nothing public connects them.
- §Issuer
- An issuer is an accepted KYC organisation, admitted under the MintID Foundation’s published policy, that verifies people once, off-chain, and issues reusable credentials to them. MintID issuers publish signed status roots and lock a slashable bond that is cut for proven fraud or negligence. They never see where holders later present their credentials. The chain records issuer approvals and status roots. It never records the KYC files.
- §Principal control surface
- The principal control surface is your issuer’s own page, where you sign in with a passkey. There you see what your verification backs, end it if your keys are lost, and answer consent requests. The page holds no credential and no key.
- §Passkey
- A passkey is a key on your own device that signs you in to your issuer’s control surface. It is not your credential’s key.
- §Verifier
- A verifier is any relying party, such as an exchange, a marketplace, an API or a merchant checkout, that requests a zero-knowledge presentation before acting. MintID verifiers are themselves KYC-approved, registered on-chain for exact web origins and admitted by the MintID Foundation on either tier. They check a ten-second proof against current chain state, keep a minimal decision record, and never receive, store or forward personal data. Integration runs through the MintID verifier SDKs.
- §Verifier admission
- Verifier admission is admission under the published policy, decided by the MintID Foundation and executed by the operator. On either tier, an accepted issuer has verified a responsible person behind the verifier. The permissionless tier is self-submitted with a Foundation admission grant and is the default; the admitted tier is on request only. Every decision is recorded in the admissions log, marked “related party” where it concerns a related party. Requests reach the operator through ZadQ.
- §Free verification
- The protocol charges nothing to verify. There is no protocol fee and no usage tax, so a verifier that runs its own service pays nothing. Operators price their own services, such as operated deployments, admission, onboarding and support, outside the protocol.
- §Decision record
- A decision record is the verifier’s own record of a presentation decision. It is closed, minimal and never published. It holds no presentation, proof, claim value or pseudonym. It is not a trace, a receipt or a trust record, and the chain is not a transparency log for it. The revocation-trace record is separate. The test harness publishes the revocation-trace record as the measured record of a revocation’s propagation.
- §Dispute retention record
- A dispute retention record is what a verifier keeps, for the claim window only, about an agent presentation it accepted, so that a claim can be filed on it. It is never published and never written to the chain.
- §Pairwise pseudonym
- A pairwise pseudonym is the value an agent presents to one relying party. The value is the same every time the agent returns there, and it is unrelated to what any other relying party sees. It lets a business recognise an agent and does not reveal who stands behind it.
- §Validator
- A validator is a node operator that runs CometBFT consensus. On the public proof-of-stake network that MintID is designed to scale to, a validator stakes to secure the network. Today the single-node production chain, in production since 20 September 2026, has one validator, which Conectia operates. Validators order transactions and check cryptographic evidence, including signatures, bonds and status roots. They never process passports, biometrics or KYC files, because none of that ever touches the chain.
- §Distributed network
- The distributed network is the future MintID network with independent validators, issuers and verifiers. It opens only after the chain matures through its programmed waves and the first implementation proves itself in production with independent relying parties. After that come the public adversarial testnet, Gate 1 and genesis. The distributed network is distinct from the operator running several nodes.
- §Effect instant
- The effect instant is the moment a revocation takes effect: the latest moment every conforming verifier refuses the credential, set by the path the revocation took. Before it, the principal answers for conforming acceptances; after it, there are none.
- §Status root
- A status root is a small, signed cryptographic commitment that an issuer publishes on-chain at least every 30 seconds. It summarises the validity state of every credential the issuer has issued, and it does not list the credentials. A verifier treats a root older than the maximum root age as stale and fails closed. The reference value for the maximum root age is 45 seconds, and the single-node production chain uses 180 seconds. A presentation proves membership in the current root in zero knowledge. This lets revocation work, including holder self-revocation, while the chain learns nothing about individual credentials.
- §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 is a validated identity document (eIDAS low, ISO/IEC 29115 LoA 2, NIST IAL1). A2 adds possession proven by biometric liveness (eIDAS substantial, LoA 3, ETSI TS 119 461 Baseline, IAL2). A3 is A2 plus sanctions and PEP screening at onboarding and at every renewal, with the result and the lists’ version recorded, and a second independent evidence (proof of address, or the identity document’s chip read). Short of any of these, the verification is graded A2 (enhanced due diligence (counsel)). A4 adds 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. For companies, these grades apply in a later phase that combines KYB with biometric verification of an authorised representative. Today the first accepted issuer verifies persons only. A person who acts for a business represents it, and the business itself is not verified. A grade measures verification strength, never age. The credential carries the grade as a private claim, and a verifier receives only a threshold proof such as “grade ≥ A3”.
- §Freshness band (F1–F4) · recency band
- A freshness band is the issuer-held band (F1–F4) that says how recently a holder’s evidence was verified. It sits alongside the assurance grade as a second dimension. The issuer publishes it as a band (F4 under 30 days, F3 under 90, F2 under 180, F1 under a year) and never as a date, so observers cannot correlate records by timestamp. The band is read on the classical seller rail, which uses issuer-signed attestations rather than zero-knowledge presentations. It is not a presentation predicate, because a presentation proves only the grade threshold. Bands are independent of grades, so a strong grade can be old and a weak grade can be fresh. For ZadQ, the first product built on MintID, “human-backed” means at least A2 with a published freshness band of F1. This policy is evaluated on the issuer’s session and attestation state on the classical seller rail. Each grade also has a default validity inside the EU anti-money-laundering update periods: twelve months for A1–A2, six months for A3 and three months for A4. The credential expires exactly when the verification behind it expires, with no grace period. Expiry is not revocation. A subscription at an operator neither extends nor shortens a credential’s validity.
- §MintID Foundation
- The MintID Foundation is the protocol’s authority. It admits issuers and verifiers under a published policy, and it issues, certifies and verifies nothing. Conectia operates the single-node production chain under its mandate.
- §Compliance council
- The compliance council is the threshold-vote body for admission, bonds and treasury co-signing, and the MintID Foundation’s organ once seated. It is built on-chain and is not yet seated. Operating by a threshold vote recommended at five of nine members, it would take the Foundation’s gates on its behalf: 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 the council is seated, the Foundation decides admissions under its published policy, and the operator executes them as governance proposals that the chain’s single validator votes on. The council never changes software or protocol parameters, which belong to token-weighted, on-chain governance on a public network. On a due-process identity reveal, the council reviews only after the fact.
- §Dispute cascade
- The dispute cascade is how MintID’s dispute rail handles harm caused by an agent: notice and private settlement, an arbiter’s offer, a fraud signal, and identity only under the arbiter’s certified finding. No funds are held at any step. The dispute cascade is specified, not built.
- §Dispute key
- The dispute key is held jointly by an agent’s issuer and the MintID Foundation. Every agent presentation carries an encrypted reference to the agent that only the two together can open, and only for a claim recorded on chain. The dispute key is specified.
- §Anchor product (ZadQ)
- The anchor product is ZadQ, an x402 seller-verification service and the first product built on MintID. Conectia operates ZadQ, a disclosed related-party position. ZadQ runs as a pilot on the single-node production chain, which is not yet the distributed network. Nothing measured there counts as independent adoption or toward the distributed network’s launch criteria.
- §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 from wallet to wallet, and retries with proof of payment. Now maintained under the Linux Foundation, x402 is a settlement rail of the emerging pay-per-use agentic web. It prices requests and does not identify anyone. Products built on MintID address that identity gap, first for sellers through ZadQ and then for buying agents.
- §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". It provides a uniform listing-and-invocation surface that agent frameworks speak natively. Because MCP is becoming the consumption unit of the agentic web, identity verification has to be reachable as a tool. MintID provides an MCP server that exposes the operations of its verifier-service contract. The verifier runs this server inside its own perimeter against its own service.
- §Web Bot Auth
- Web Bot Auth is an IETF Internet-Draft built on HTTP Message Signatures (RFC 9421). Under this draft, a bot or agent cryptographically signs its requests so origins can verify which operator is calling. Web Bot Auth authenticates the agent’s software identity, showing which platform or crawler is calling. By itself, it says nothing about the accountability of the principal behind an autonomous agent. MintID’s human-backed agent credentials add that accountability layer.
See the vocabulary at work
Agent KYC brings these ideas together in the protocol. It lets an AI agent prove in zero knowledge that an accountable human stands behind it, and it does not reveal who that human is.