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 detail may ever leave the system. The project is research-stage; the specifications are available on request.
The three specifications form a strict hierarchy. SPEC-2 and SPEC-3 are normative but subordinate: where they conflict, the lower-numbered specification governs, and nothing downstream may weaken a SPEC-1 requirement.
The foundational specification. Requirements R1–R28 plus a normative Method cover the sovereign Layer-1, the validator and miner program, the issuer and verifier registries, the credential and status protocol, token economics, governance and operational controls. Current text: v1.2, frozen July 2026.
The agent-credential layer. Normative but strictly subordinate to SPEC-1 — where they conflict, SPEC-1 governs. It defines human-backed agent identity — minting, backing and scope predicates, and revocation — without weakening R1–R28.
The disclosure layer. It fixes how identity detail may ever flow out of the system: two strictly separated rails (commercial and dispute), the money-before-identity cascade (L0/L1/L2), the bid/bond economic split and on-chain disclosure receipts. The agent-layer requirement series runs R-A1 through R-A29 across SPEC-2 and SPEC-3.
We evaluated launching on an existing network — an Ethereum L2, Solana, BNB Chain — and chose a sovereign Layer-1. Not for vanity: because 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 — anywhere on it, ever. 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 45. On MintID that freshness 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 fake freshness. As a contract on a busy general-purpose chain, one congestion spike or outage would silently break that guarantee for every issuer at once.
Issuer registries, the compliance council, slashable issuer bonds, and the hard-capped token with its burn mechanics are native modules of the chain itself — not upgradeable smart contracts that a key holder could swap out. The rules of the network can only change the way the protocol says they can — by token-weighted on-chain governance.
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 this network is built for. Sovereign chain, permissionless validators, many issuers — the structure is the argument.
Running a sovereign chain has real costs, and we treat them as engineering requirements rather than footnotes: the specification now gates mainnet on published minimum economic-security thresholds (enough independent validators and enough value at stake, verified before genesis — not after), and the pre-genesis economic study evaluates supplementary shared security for the network’s first years. Where the design doesn’t need sovereignty, it doesn’t pretend to: escrow capital lives in USDC/EURC at launch (BTC and, gated on counsel, XMR are ratified later rails) on its own settlement rail, and only what needs the chain’s guarantees lives on the chain.
Each requirement is normative and testable. These eight set the privacy, custody, status and economic envelope the whole system is held to.
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 id. Losing a device never means exposing who you are to revoke it.
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 native token follows a hard-capped, declining issuance schedule with burns. Supply is bounded by protocol, not by operator discretion.
Chain state scales with the number of issuers, verifiers and validators — not with the number of holders. The system stays small no matter how many people use it.
No mainnet before independent audits. The launch gate requires external review of the application, cryptography, infrastructure and economics.
The implementation is partitioned so that the chain, the cryptography, the off-chain services and the test harness each own a clean boundary.
The chain itself, written in Go as Cosmos SDK modules: registries, status roots, staking, governance and the consensus state machine.
The cryptographic core in Rust: the anonymous-credential and zero-knowledge proof system, circuits and test vectors shared by issuers, holders and verifiers.
Off-chain issuer services: the software an accepted KYC organisation runs to issue credentials and publish status-root commitments to the chain.
Off-chain verifier services: the libraries and services a relying party uses to request and validate perishable, fully-bound presentations.
Integration and adversarial testing across the whole system, including the attacks the public testnet gate is designed to survive.
Delivery is staged from a specification freeze through to a public adversarial testnet and a security-gated launch.
Lock the normative specifications and the requirement set before any production code is written against them.
Stand up the sovereign Layer-1: consensus, the native token, the base Cosmos SDK modules and chain state.
Add the accepted-issuer registry, the compliance council, issuer bonding and the on-chain status-root commitments.
Register accepted verifiers and ship the online verification core that validates perishable, fully-bound presentations.
Deliver the anonymous-credential scheme and the issuance core so issuers can mint credentials holders prove in zero knowledge.
Implement the proof that lets a holder revoke their own credential without revealing their identity or the credential id.
Run a public adversarial testnet and pass the security-first launch gate — including independent audits — before any mainnet.
SPEC-1, SPEC-2, SPEC-3, the requirement set and the module map are shared on request while the project is in its research stage. Get in touch to receive them.