Infrastructure that can prove who vouched, never who was vouched for
MintID exists so accepted 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.
the blueprint
Invariants
The principles we will not trade away
These invariants hold across every design decision, and the protocol is built so that none of them can quietly erode.
∅
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.
KEY
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.
O(1)
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.
FAIR
Privacy and accountability
A deliberate balance: holders prove claims without exposing themselves, while immutable audit commitments keep issuers and verifiers accountable.
AUDIT
Security-first
Independent application, cryptography, infrastructure and economic audits are committed, scheduled quality milestones, each published with its findings — while the single-node production chain already runs, carrying the first issuer and the first verifier.
CHAIN
Own rules, proven infrastructure
The design gives a public network its own validators, consensus rules, governance and token from launch, and reuses mature infrastructure instead of reimplementing networking and consensus.
Sovereignty
The new code is the identity protocol; consensus comes from Cosmos SDK and CometBFT
MintID runs its own chain: it is an identity protocol in production on the single-node production chain, designed to scale to a public, permissionless proof-of-stake network. Today that means its own consensus rules and chain state; a public network would add its own validator set, reward schedule, governance and native token. MintID reuses Cosmos SDK and CometBFT rather than rewriting networking and Byzantine-fault-tolerant consensus, so the code it writes is the identity protocol.
Two bodies share what is loosely called governance, and they are deliberately not the same. On a public network, token-weighted, on-chain governance would own the software: upgrades and versioned parameters. The compliance council is designed as an operational body — a threshold vote, recommended 5-of-9 — that admits, suspends and revokes issuers and verifiers, adjudicates bonds, forces a key rotation when an operator key is lost, and co-signs protected treasury actions, with an independent custodian’s signature on any reserve movement. It never changes the software, and on a due-process identity reveal it reviews only after the fact. The council is constituted as an organ of the MintID Foundation before any white paper is signed, and until then it is not seated: admissions are governance proposals, today voted by the chain’s single validator.
Why trust MintID
Built like it has something to prove
Each card below points to something you can check yourself: a published report, a numbered requirement or a written commitment.
Audit-first, by rule
Two independent chain and protocol audits, a specialist cryptography audit, an infrastructure penetration test and an independent token and economic review are committed quality milestones, scheduled and published with their findings — alongside a public adversarial testnet, a funded bug bounty and an incident-response exercise. The commitment is written into the specifications.
Reviewed before genesis — published in full
In July 2026 the project had its own design reviewed for economic viability: the token model, the economics of each participant, survivability. The review was performed by Conectia PRO, part of the group that builds MintID and therefore a related party, as the report’s cover discloses. It is published in full, together with what changed in response. It is not the independent economic review — that review, and the independent simulation, are still ahead.
The whitepaper names what could go wrong — competitive timing, the two-sided cold start, cryptographic delivery, regulation, economics, related-party concentration and fail-closed operation — and what the design does about each.
Privacy written as numbered, testable requirements
“No personal data on chain”, “no tracking across renewals” and “state never grows with people” are numbered, testable requirements that auditors check.
Six refusals, written into the specification
No identity data on-chain, no shielded transfers, no dividends, no price support, no minting beyond the cap, no social recovery. Every refusal removes an attack surface or a conflict of interest — and each one is written into the specification.
108,000,000 is the only frozen number
The cap is fixed and published: 108,000,000 tokens. The genesis allocation is ratified as bands — development 15%, public sale 20–25%, reward pool at least 60% — with priors of 15, 25 and 60%, which the independent simulation validates or argues against before genesis. Every genesis address will be published and labelled; development tokens would vest on-chain over four years and stay locked for a year after genesis, and insider accounts could neither delegate nor vote while that applies.
GDPR and MiCA shaped the design from the first draft
GDPR lawful bases are mapped per disclosure rail; the MiCA posture was fixed before any token exists; AI Act conformity is on the counsel list. Built in Europe, for regulated issuers, on purpose.
State of the project
One validator has been producing blocks since 20 September 2026
Today MintID runs on the single-node production chain, in production since 20 September 2026 and operated by the CONECTIA group as a disclosed related party, carrying the first issuer, the first verifier and the ZadQ pilot while the distributed network is built. 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. The code is open source under Apache-2.0. The MintID Foundation, a Netherlands Stichting, is being incorporated by the founder and stays dormant until the public-offer route is chosen. The public network and any token come later, if traction is demonstrated and that financing route is chosen.
In production · single nodeOpen source · Apache-2.0Foundation being incorporated · dormantNo token · nothing for sale
Who builds this
The CONECTIA group runs the first issuer on the same terms as anyone
A protocol without a production implementer at launch is a specification. The CONECTIA group chose to be that implementer, under a structure that keeps neutrality intact.
BUILD
First implementer
The CONECTIA group, which conceives and builds MintID, operates MintID’s first accepted issuer — behind the same provider-neutral KYC interface every issuer uses — and its first registered verifier: today in production on the single-node production chain, and from block 1 on the distributed network. The group is a related party, and every role it holds is disclosed as such.
EQUAL
No privileges
The first issuer and the first verifier were admitted through the same path the protocol offers anyone: a governance proposal, today voted by the chain’s single validator and, once the compliance council is seated, by the council; the same slashable bond; the same 30-second roots; all of it on chain. That is what turns the position into an argument instead of a risk.
OPEN
Open references
The first implementer operates the first issuer service and the first verifier service and publishes the holder library under a permissive licence. MintID ships no wallet. The cryptographic core is the same, whoever runs it.
ZADQ
The anchor product
ZadQ, an x402 seller-verification service, is the first product built on MintID and the group’s own product line, a disclosed related party. It runs as a pilot on the single-node production chain, on the classical seller rail, not yet on the distributed network, and nothing measured there counts as independent adoption or toward the distributed network’s launch criteria.
The MintID Foundation, a Netherlands Stichting, is being incorporated by the founder and stays dormant until the public-offer route is chosen: it holds no treasury, enters no contracts, seats no sponsors and receives no services. The single-node production chain is operated by the CONECTIA group as a disclosed related party. The code is published under an Apache-2.0 licence. On the public-offer route, the Foundation performs the genesis, holds the treasury and the lock-up commitments, publishes the Genesis Allocation Statement and, as offeror, fixes the notification authority under MiCA: the Dutch AFM. The Foundation has no protocol revenue role and no debt relationship with the implementing group in either direction.
FOUNDER
The founder, disclosed
Marc Molas, founder of MintID and beneficial owner of the CONECTIA group, is founder-director of the Stichting at incorporation and recused from every Foundation decision that concerns the group.
The founder holds a disclosed economic interest in the development contractor, holds no office in it once the Foundation is active, and takes no part in any Foundation decision concerning it.
A neutral, multi-issuer rail is only credible if its first operator holds no special position on it.
The three specifications turn these invariants into normative, testable requirements. Read the protocol, or get in touch to request the specifications.