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 of decision semantics, or removing, renaming or changing the meaning of a reason code, is major; new fields and new operations are minor, and so is adding a reason code that no request the deployment issued before can produce. | the public OpenAPI 3.1 edition, verifier-service.v1.yaml (1.8.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: 17 producible codes, 7 produced only for agent challenges (1.2.0–1.5.0, 1.8.0) and 2 reserved and unreachable — 26 values in the enum. 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. |
| Agent fee schedule | Governed on the chain: the reference amounts an issuer bills for minting and leasing an agent credential, and the share of them the protocol takes. Points move by governance inside published bands; on the single-node production chain the on-chain amounts are placeholders. Issuers show the current schedule on their build-info and policy reads. | The shape, not the numbers: read the schedule where you need it rather than hard-coding it. The protocol charges nothing to verify: no protocol fee, no usage tax, and a verifier that runs its own service pays nothing; operators price their own services (operated deployments, admission, onboarding, support) outside the protocol. |
| Published container images | Additive, from the first release that runs the image job: the verifier service, the chain node and the MCP server for every public release, in the public project’s registry. Each is built from the release’s tree with the same engine pin as that release’s packages, for linux/amd64 and linux/arm64, signed by digest with the release key, with a signed SBOM per platform, and listed in the release manifest; the verifier’s GET /v1/build-info names the release. The image is the service of the source with nothing configured: its flags are the service’s, and nothing it decides is set by the image. A compose in the public project runs it with a full node of your own beside it (service mode). | The digest from the release manifest, never a tag; check its signature (verify a release) and that build-info names the release you pinned. |
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 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 on the single-node production chain | There, the MintID Foundation admits verifiers under a published policy instead (becoming a verifier): eligibility, checks, a five-working-day answer, a public admissions log and a written appeal. Each decision is the Foundation’s and the operator executes it. The two remaining operator acts are the funding of your operator account on the permissionless tier (exactly the fee and the gas, after the checks: the chain has no faucet) and the two proposals of the admitted tier, which is available on request only. On the public testnet a verifier self-registers on its own, paid from a faucet grant (becoming a verifier). |
| The admission grant on chain | Specified, not deployed: the chain will write a verifier’s record only with the MintID Foundation’s signed admission grant, on either tier. It arrives with a chain change; until then registration works as described on becoming a verifier, and the Foundation’s decisions are executed by the operator. |
| 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 Conectia, with its issuer and verifier; ZadQ is the first product built on it (on the classical seller rail), and Conectia 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:
- Registration on the single-node production chain is gated on the MintID Foundation’s admission under the published policy: the permissionless verifier tier is on that chain, but the chain has no faucet, so once the Foundation has admitted a verifier the chain’s operator funds its account, with exactly the fee and the gas — see becoming a verifier. When the admission grant reaches the chain, the grant, not the funding, is the control. Production is never a place to test; admitted verifiers run there under that policy.
- 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.