Updated 2026-10-04: who issues and certifies; deployment wording.
The single-node production chain has been producing blocks in Spain since 20 September 2026, operated by the CONECTIA group and keeping the accounting of a real product. The identity verification behind its attestations is no longer a simulation, and three endpoints show any integrator the state of the chain.
On 20 September a MintID chain started producing blocks, and it has not stopped since. It runs in production on a single node; the distributed MintID network is still the target.
One validator, one registry, a status root every thirty seconds
The single-node production chain — one validator, operated by the CONECTIA group through 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. 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. No personal data, no KYC evidence, no credential contents and no record of any verification ever touches that chain. The chain’s state has no field that could hold any of it.
An integrator can check the chain from a terminal
Three endpoints answer; integrators receive their addresses from the operator. 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 endpoint>/status | jq '.result.sync_info.latest_block_height'
"95257"
$ curl -s https://<verifier endpoint>/v1/build-info | jq '.engine_pin'
"<the proof engine the verifier is pinned to>"
$ curl -s https://<issuer endpoint>/v0/build-info | jq '{rail, kyc_provider, heartbeat_seconds, linkage}'
{ "rail": "classical-seller-v0", "kyc_provider": "<the operator's identity-verification provider>", "heartbeat_seconds": 30, "linkage": "in_sync" }
$ curl -s https://<verifier endpoint>/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. A revocation is included in the next status root; at the reference values a verifier refuses a revoked credential in under a minute, and on the single-node production chain a root counts as fresh for up to 180 seconds.
The identity checks now run on a certified provider, and the evidence never enters MintID
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.
Running one node teaches what a paper cannot
MintID’s design target is a permissionless, distributed network. Nothing about today changes that. But a protocol nobody operates is a paper; you learn what breaks by running something a real product depends on. So the protocol starts with one validator, a registry admitted when the chain started, and a product on top whose lifecycle now has a real ledger under it. The CONECTIA group funds the work as its own research.
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.
Every byte of the chain lives in one Spanish region
In Spain: the node, the file system that holds the accounting, the daily backups, the secrets and the infrastructure’s own state file all live in a single Spanish region, by decision. That 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.
A restore drill found the one file the backup missed
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.
Next: operator consoles, then the path from one node to many
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.