Protocol state: stable, draft and absent
What you can build on, what will keep moving under you and what is not there yet, with the order in which each missing piece is gated.
Stable surfaces you can build on
Plan against three tables: surfaces that are stable, surfaces still moving, and pieces that do not exist yet. Read the third before you commit a date to anyone.
| Surface | What stability means | Machine-readable artifact |
|---|---|---|
| Verifier service contract v1 | Frozen. A change to decision semantics or to the reason-code vocabulary is major; new fields and new operations are minor. | the public OpenAPI 3.1 edition, verifier-service.v1.yaml (1.1.0) |
| The nine acceptance conditions, in order | Behaviour, not configuration: nothing skips or reorders one. Changing one is major in the contract and in the Python SDK at once. | the conformance vectors below are the executable statement |
| Canonical JSON | RFC 8785 with SHA-256 and lowercase hex, for the signed challenge body and the binding context. Changing it would change every digest, so it is major everywhere at once. | the canonicalization declaration, bIP-0003 — declaring how we hash |
| The decision vocabulary | Closed: 16 producible codes, 2 reserved and unreachable. No unknown code reaches you inside a contract major. | the reason_code enum in the contract — reason codes |
| The conformance suite | A case’s expected decision changing is major; new cases are minor. Every artifact declares the suite version it passed. | the cross-language suite — conformance & versioning |
Additive or draft surfaces
| Surface | State | What to pin |
|---|---|---|
| Substrate status read | Additive, versioned v0 beside the frozen contract, served only where the deployment is configured for it. Expect new fields. | Branch on the closed verdict vocabulary; treat unknown fields as ignorable, not as errors. |
| Attestation standing read | Additive, versioned v0, same arrangement. Any failure degrades to an unknown verdict with a closed reason code. | Same — and never read unknown as “fine”. It means the answer is not known. |
| Payment-identity profile | Draft, and it cannot freeze while one section of it is still open. The wire shape can still change. | Nothing structural. Put it behind an adapter of your own. |
Both reads are described in substrate reads, the profile in the payment-identity profile.
Not there yet
| Not there | What that means for you |
|---|---|
| A package index release | No pip install mintid-verifier-sdk and no npm install @mintid-net/verifier-client yet: not yet on PyPI, not yet on npm. Build from the main project, https://gitlab.com/mintid/mintid, or from the mirror where there is one; the install lines are on getting started. |
| A published container image | Nothing to pull: the images are built from the source, and the local stack builds them on your machine. |
| A separately distributed proof engine | Not published as an artifact of its own: it is pinned in the source tree and built with the SDK, never fetched or substituted separately. |
| Self-service registration | Admission is processed by an operator — you submit a request, a person decides. The second verifier tier that would make it self-service is designed and not built. |
| Audit reports | An independent audit of the proof core’s implementation is scheduled as a quality milestone, as are the other audits in the programme; each publishes its scope before it starts and its findings when it closes. None is a precondition for relying on the production system. |
Beside the public testnet, the one production deployment today is the single-node production chain, in production since 20 September 2026 and operated by the CONECTIA group, with its issuer and verifier; ZadQ is the first product built on it (on the classical seller rail), and the CONECTIA group and ZadQ are related parties of MintID. Nothing measured there is independent adoption, and we do not present it as such.
The proof core is built and in production on the single-node production chain, pinned by known-answer vectors that three languages check, and you can also build and test a full integration against injectable test doubles. Read engine_pin from the instance you are talking to: the pin is the fact, the release note is not.
What gates what
No dates here: the project publishes target windows, and a window can move. What holds is the order:
- Self-service registration is gated on the second verifier tier. Until then every verifier and issuer is one an operator admitted — see becoming a verifier.
- The public testnet is the only MintID deployment a third party may use to test. It runs on its own valueless denomination,
utestmint, from an open faucet; a verifier of your own can self-register there in the permissionless tier, while the admitted tier has no path on it — see the public testnet and its KYC sandbox. - No audit gates the steps above. Each audit in the programme is a scheduled milestone whose findings are published; relying on the production system, public statements about what it does, and the order above do not wait for one.
If a plan of yours depends on one of these, say so early: the order is fixed, and how soon each step comes is open to conversation.