Protocol state — stable, draft, absent
What you can build on, what will keep moving under you, and what is simply not there yet — with what gates what, and no dates.
Stable surfaces you can build on
This page exists so you can plan: what you can build on, what will keep moving under you, and what is simply not there yet. Read the third table 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.
What does not exist yet
| Not there | What that means for you |
|---|---|
| A package index release | No pip install mintid-verifier-sdk, no npm install @mintid/verifier-client. Both are built from the repository at a tag; integration starts as a conversation, not a download. |
| A public sandbox, hosted test network or published container image | Nothing you can point a client at on your own. The only way to exercise the protocol is a deployment someone gives you access to. |
| A 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. |
The one deployment that exists today — the single-node production chain, its issuer, its verifier, and the first product built on them — is operated by a related party of MintID. Nothing measured there is independent adoption, and we do not present it as such.
The proof core is built and in production: issuance, selective-disclosure presentations and the non-revocation path are implemented and pinned by known-answer vectors that three languages check. You can still 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, not the release note.
What gates what
No dates here. The project publishes target windows, not commitments, and a window is not a date. The order is what is worth knowing:
- 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.
- A public test network is gated on it: it would put presentations in front of parties nobody admitted, through a registration path that does not exist. It cannot come first.
If a plan of yours depends on one of these, say so early. The order is fixed; which one gets pulled forward is a conversation.