Updated 2026-10-23: the issuer-revocation bound as deployed (185 seconds); 2026-10-19: the operator’s name and related parties.
The single-node production chain has produced blocks in Spain since 20 September 2026. Conectia operates it and it keeps 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.
How the single-node production chain operates
The single-node production chain is the accounting ledger of ZadQ, the first product built on the protocol. It has one validator. Conectia OÜ (Estonia, registry code 16847069), trading as Conectia PRO, a disclosed related party, operates it. An issuer service and a verifier run alongside the node. The issuer service opens verification sessions and signs attestations. The verifier answers whether an attestation still stands. The chain holds the registry of accepted issuers, with their keys and live bonds, and the registry of admitted verifiers, each on its exact origin. Every thirty seconds, the issuer publishes a new status root. A status root is a single commitment to the state of every attestation that the issuer 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. Conectia, a related party, operates the first accepted issuer on the single-node production chain on the same terms as any other issuer. No personal data, KYC evidence, credential contents or record of any verification ever touches that chain. Its state has no field that could hold any of it.
An integrator can check the chain from a terminal
Three endpoints report the live state of the system, and integrators receive their addresses from the operator. The verifier reports the proof engine it is pinned to. The issuer reports its identity provider on its own build-info route, which integrators receive on request. The verifier checks the chain directly before it answers active. It reads the issuer’s status root from the chain with an inclusion proof, recomputes the Merkle witness for the attestation in question, and checks that the issuer is still authorised and still bonded. The Merkle witness is the proof that the attestation is included in that root. If the root is older than its freshness window, the verifier answers 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://<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" } }We captured the output above on 22 September 2026, so the block height and the root age will be different when you run it. The verifier service contract page documents the verifier’s public contract. The next status root includes any revocation. At the reference values, a verifier refuses a revoked credential in under a minute. On the single-node production chain, a root counts as fresh for up to 180 seconds, so a verifier refuses a revoked credential within 185 seconds.
The identity checks now run on a certified provider, and the evidence never enters MintID
When this chain first went live, the identity verification behind its attestations was a simulation. Today, the first accepted issuer uses an external provider certified against the European standard for identity proofing. All verification evidence, including documents, images, and everything a person submits, stays with that provider and never enters MintID. The issuer keeps only a verification verdict and an assurance grade. The chain holds neither of these. It records only a cryptographic commitment to the state of the attestations.
Why MintID starts with a single node
MintID is designed to become a permissionless, distributed network. Operating the protocol under a live product reveals operational issues that specification work alone cannot surface. For that reason, the network starts with a single validator, an initial registry admitted when the chain launched, and a live product whose lifecycle runs on the chain. Conectia funds this work as its own research.
Conectia and ZadQ are related parties of MintID. Everything running on this chain today is a related-party pilot. None of the attested sellers, verifications or published roots count as independent adoption, and we will never present them as traction. When we publish numbers that do count, they will come from operators other than us.
Data residency in a single Spanish region
By decision, the validator 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 region in Spain. A customer of a MintID operator can repeat that residency claim to their own customers. It is a statement about where the bytes are and nothing more. There is no certification and no approval, and no authority has endorsed anything here.
Operational lessons from backup drills and monitoring
Running the node surfaced practical lessons. First, we rehearsed recovering the chain from a backup before trusting it. We found that the backup did not capture the one file that a running validator rewrites on every block. The node refuses to start without it. It was better to find this in a rehearsal than in a real outage. Second, alarms that detect a failure when a metric disappears are slower than they look. Ours take minutes to fire, and we recorded the measured delay.
Next steps for operator tooling and multi-node consensus
The proof core is the credential and presentation engine, and it is built and in production. The next months are for the rest of the operator’s experience. This includes 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.