> 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. index — 12 documents 1. [overviewsdk/00](/en/sdk) 2. [getting startedsdk/01](/en/sdk/getting-started) 3. [python sdksdk/02](/en/sdk/python) 4. [service modesdk/03](/en/sdk/service-mode) 5. [typescript clientsdk/04](/en/sdk/typescript-client) 6. [mcp serversdk/mcp](/en/sdk/mcp-server) 7. [conformancesdk/05](/en/sdk/conformance) 8. [reason codessdk/06](/en/sdk/reason-codes) 9. [substrate readssdk/07](/en/sdk/substrate-reads) 10. [credentials & holderssdk/08](/en/sdk/credentials-and-holders) 11. [payment identitysdk/09](/en/sdk/payment-identity-profile) 12. [becoming a verifiersdk/10](/en/sdk/becoming-a-verifier) 13. [protocol statesdk/11](/en/sdk/protocol-state) * [stable](#stable) * [additive or draft](#draft) * [not there yet](#absent) * [what gates what](#gates) 14. [record · assurance vocabularyrecord/01](/en/sdk/kyc-trust-model) 15. [record · packagingrecord/02](/en/sdk/packaging) 16. [record · multi-languagerecord/03](/en/sdk/multi-language-clients) 17. [record · service contractrecord/04](/en/sdk/verifier-service-contract) SDK docs · sdk/11 # 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`](/openapi/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](/en/blog/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](/en/sdk/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](/en/sdk/conformance) ## 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](/en/sdk/substrate-reads), the profile in the [payment-identity profile](/en/sdk/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](/en/sdk/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. [previous← becoming a verifier](/en/sdk/becoming-a-verifier)[nextrecord · assurance vocabulary →](/en/sdk/kyc-trust-model) --- Source: https://mintid.net/en/sdk/protocol-state · Protocol state — stable, draft, absent — MintID verifier SDK docs