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
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.
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.
The agent-credential layer. It defines human-backed agent identity — minting, backing and scope predicates, and revocation — without weakening the base protocol.
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.
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.
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.
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.
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.
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.
Each of these eight is a normative, testable requirement in the specification corpus; together they set the privacy, custody, status and economic envelope.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Admission, authority state, signing and emergency keys, permitted grades and the bond — locked, frozen, slashed or released, with remediation held per adjudicated case.
The latest signed root per issuer, with freshness bounds enforced as consensus rules, and emergency updates under strict ordering and rate limits.
KYC-approved relying parties: a commitment to their KYC attestation (never the attestation), request-signing keys, exact origins, periodic revalidation and suspension.
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.
Threshold-vote proposals with evidence commitments and policy versions; reserve-movement commitments, timelocks and co-signature state.
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.
What exists today, stated at the level of capabilities, so that nobody mistakes specification for delivery.
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.
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.
The full acceptance pipeline, single-use challenges, authenticated chain reads and an audit trail behind a versioned service contract.
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.
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.
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.
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.
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.