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.
Mission
Public trust infrastructure for identity — private by construction
MintID exists so approved 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.
Invariants
The principles we will not trade away
These guiding invariants hold across every design decision. They are constraints, not aspirations — the protocol is built so they cannot quietly erode.
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.
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.
Privacy and accountability
A deliberate balance: holders prove claims without exposing themselves, while immutable audit commitments keep issuers and verifiers accountable.
Security-first
No mainnet before independent application, cryptography, infrastructure and economic audits. The launch gate is a precondition, not a milestone to skip.
Sovereign, not reinvented
Sovereign from launch — own token, validators, consensus rules and governance — yet reusing mature infrastructure instead of reimplementing networking and consensus.
Sovereignty
Sovereign from launch, standing on mature infrastructure
MintID is sovereign from day one: its own native token, validator set, consensus rules, reward schedule, governance rules and chain state. But sovereignty is not the same as reinvention — it reuses Cosmos SDK and CometBFT rather than rewriting networking and Byzantine-fault-tolerant consensus, so the new code is the identity protocol, not yet another consensus engine.
Native tokenOwn validator setOwn consensus rulesOwn reward scheduleOwn governanceCosmos SDKCometBFT
Governance
A council, and an independent custodian
Two bodies share what is loosely called governance — and they are deliberately not the same. Software governance is token-weighted: protocol upgrades and versioned parameters are decided by on-chain governance. The compliance council is an operational body — a threshold-vote council, recommended 5-of-9 — that admits and removes issuers and verifiers, adjudicates and freezes bonds, recovers a compromised issuer’s keys through due process, and co-signs any reserve movement together with an independent custodian and auditor. The council supervises — it never originates — the due-process identity reveal, and it never changes the software.
Why trust MintID
Built like it has something to prove
Most identity projects ask you to trust their intentions. MintID is engineered so you don’t have to.
Audit-first, by rule
No mainnet without independent application, cryptography, infrastructure and economic audits — plus adversarial testnet exercises and a bug bounty. That’s a written requirement of the protocol specification, not a marketing pledge. The industry norm is one audit, or none.
We publish our own weaknesses
The project maintains a versioned register of every weak point found in its own design — what’s solved, what’s open, what’s deliberately accepted — through five public revisions and counting. Ask any other identity protocol for theirs.
Privacy as numbered requirements, not adjectives
“No personal data on chain”, “no tracking across renewals”, “state never grows with people” are numbered, testable requirements (R2, R-A29, R19) that auditors check — not slogans.
The strongest features are refusals
No bridges, no DeFi casino, no bearer tokens, no biometric database, no price promises. Every refusal removes an attack surface or a conflict of interest — and each one is written into the specification.
Honest numbers or no numbers
The token’s cap is fixed and published (93,924,792); its allocation waits for independent economic simulation. The genesis allocation will be published address-by-address, vested on-chain for years, custodied under multisig with an independent co-signer, and covered by the economic audit before it exists. No dump — structurally, not promisedly.
Regulation as a design input, not an obstacle
GDPR lawful bases are mapped per disclosure rail; MiCA posture is documented before the first token exists; EU AI Act accountability requirements shape the receipt design. Built in Europe, for regulated issuers, on purpose.
Who builds this
The first implementer, with no privileges
A protocol without a production implementer at launch is a specification. The fastest honest way to have one is to be it — under a structure that keeps neutrality intact.
First implementer
CONECTIA OÜ operates the first production issuer service — the first accepted issuer on the network, running its own KYC integration behind the same provider-neutral interface every issuer uses.
No privileges
The first implementer passes the same council admission, posts the same slashable bond, and publishes the same 30-second status roots as any other issuer. The dogfooding is verifiable on-chain — which is what turns the position into an argument instead of a risk.
Open references
The reference wallet and verifier implementations are built and operated by the first implementer under a permissive licence, and the cryptographic core is public and independently audited regardless of who runs it.
Steward, separate from operator
Genesis, treasury custody and governance neutrality belong to a dedicated MintID foundation — incorporation underway — kept structurally separate from the operating company that builds the software.
The structure is the argument: a neutral, multi-issuer rail is only credible if its first operator holds no special position on it.
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.