A MintID chain has been producing blocks in Spain since 20 September, keeping the accounting of a real product. The verification behind its attestations is no longer a simulation. Here is what it does, what it does not do, and how to check both yourself.
On 20 September a MintID chain started producing blocks, and it has not stopped since. It runs in production on a single node, it is not yet the distributed MintID network, and saying so plainly is part of the point of this post.
What went live
A single-validator MintID chain called mintid-anchor, stewarded by the MintID Foundation and operated under it by Conectia PRO as the accounting substrate of ZadQ, the first product built on the protocol. Alongside the node run two services: an issuer agent, which opens verification sessions and signs attestations, and a verifier, which answers whether an attestation still stands. The chain holds the registry — who is an accepted issuer, with which keys and which live bond, which verifiers are admitted and on which exact origin — and, every thirty seconds, the issuer publishes a new status root: a single commitment to the state of every attestation it has issued. That is how MintID certifies the claims it issues. No personal data, no KYC evidence, no credential contents and no record of any verification ever touches that chain. That is not a policy we apply; it is what the state is capable of holding.
What you can check without trusting us
Three endpoints answer publicly. The verifier reports the proof engine it is pinned to, and the issuer reports which identity provider is behind it — two facts that no release note can override. A verifier here does not take the issuer’s word: it reads the issuer’s status root from the chain with an inclusion proof, recomputes the Merkle witness for the attestation in question, checks the issuer is still authorised and still bonded, and only then says active. If the root is stale beyond its freshness window, the answer is not “probably fine” — it is unknown.
$ curl -s https://rpc.anchor.mintid.net/status | jq '.result.sync_info.latest_block_height'
"95257"
$ curl -s https://verifier.anchor.mintid.net/v1/build-info | jq '.engine_pin'
"proof-core 0.2.0"
$ curl -s https://issuer.anchor.mintid.net/v0/build-info | jq '{rail, kyc_provider, heartbeat_seconds, linkage}'
{ "rail": "classical-seller-v0", "kyc_provider": "idenfy", "heartbeat_seconds": 30, "linkage": "in_sync" }
$ curl -s https://verifier.anchor.mintid.net/v1/status | jq '{substrate, issuer: .issuers[0] | {active, bond_ok, fresh, root_age_seconds}, promise}'
{ "substrate": "ok",
"issuer": { "active": true, "bond_ok": true, "fresh": true, "root_age_seconds": 4 },
"promise": { "heartbeat_seconds": 30, "max_root_age_seconds": 180,
"note": "roots are published every heartbeat_seconds and stay fresh up to max_root_age_seconds; a revocation lands in the next root" } }The output above was captured on 22 September 2026; the block height and the root age will be different when you run it. The verifier’s public contract is documented on the verifier service contract page.
What is no longer simulated
When this chain went live, the identity verification behind its attestations was a simulation. It is not any more: the first issuer now runs an external provider, certified against the European standard for identity proofing, and the evidence — documents, images, everything a person hands over — stays with that provider and never enters MintID. What the issuer keeps is a verdict and an assurance grade. What the chain holds is neither: only a commitment to the state of the attestations, which is why none of this is a privacy promise we ask you to take on faith.
Why a single node, and why now
MintID’s design target is a permissionless, distributed network. Nothing about today changes that. But a protocol nobody operates is a paper, and the honest way to learn what breaks is to run something real that someone depends on. So the protocol starts with one validator, a registry admitted at genesis of this chain, and a product on top whose lifecycle now has a real ledger under it. The work is funded by Conectia as its own research, and it is described exactly as what it is.
Conectia PRO and ZadQ are related parties of MintID. Everything running on this chain today is a related-party pilot. Attested sellers, verifications, published roots — none of it counts as independent adoption, and none of it will ever be presented as traction. When we publish numbers that do count, they will come from operators we are not.
Where it runs
In Spain. Not “in the EU” — in Spain: the node, the file system that holds the accounting, the daily backups, the secrets and even the infrastructure’s own state file live in a single Spanish region. That was a decision, not a default, and it is the residency claim a customer of a MintID operator can repeat to their own customers. It is a statement about where bytes are, and nothing more: no certification, no approval, no authority has blessed anything here.
What we learned building it
Two things worth passing on. First, a restore drill is not a restore: we rehearsed recovering the chain from a backup before trusting it, and discovered that the one file a running validator rewrites on every block is exactly the file the backup does not capture — the node refuses to start without it. Better found on a rehearsal than at three in the morning. Second, alarms that detect a failure by a metric disappearing are slower than they look; ours take minutes, not seconds, and we wrote down the measured number instead of the number we hoped for.
What comes next
The proof core — the credential and presentation engine — is built and in production. What the next months are for is the rest of the operator’s experience: consoles that let someone run an issuer or a verifier without reading logs, and the path from one node to the distributed network the protocol was designed for.