Updated 2026-10-19: the operator’s name.
The MintID SDKs are built and delivered to integrators from a tagged release. The verification core — the software a registered verifier agency runs to request and validate presentations — comes as one core and thin clients: embedded in Python or run as a service, and reached from other languages through transport-only clients, TypeScript first, with further languages as demand appears. Integration is available today under commercial terms.
This deliverable is aimed at integrators rather than end users, and it lands where the design said it would: verification on MintID is built to be embedded, not hosted by us. An agency links the core into its own backend, or runs the same code as a standalone service beside its stack, and either way the identical acceptance pipeline runs.
A client relays a decision; it never makes one
The core exists once: request a presentation, validate it against the chain, keep a minimal decision record. Python embeds it directly, for the data and AI stacks where agent operators build. Every other language reaches it through a thin, transport-only client that talks to a verification service you host yourself — TypeScript first, for Node backends, and further languages as demand appears. The language changes how the core is called. It changes nothing about what the core accepts.
Nine checks, ten seconds, zero policy knobs — in every language
What ships inside every binding is the part of the design that is deliberately not negotiable:
- The nine acceptance conditions always run in full — binding to the verifier's exact origin, the fresh nonce, the requested policy, the current issuer state. There is no subset mode.
- Presentations die in ten seconds. The lifetime is a constant in the code; no deployment can stretch it to make a replay window more forgiving.
- Chain reads are proven, and fail closed. The core verifies what it reads from the chain with cryptographic proofs instead of trusting a node's answer.
- The decision record is minimal, and its type is closed. There is no hook for logging the presentation itself and no field to grow the record into a dossier.
Each of these is a constant or a closed type, so a weaker verifier cannot be built from these parts in any language you call them from. A presentation accepted by one registered verifier means exactly what it means at every other.
What an integrator brings stays short
The SDK asks an agency for infrastructure, never policy: its on-chain registration and KYC approval, its exact origins — one verifier per origin, no wildcards — its keys, a durable nonce store, and a disciplined clock. Every item on that list is operational. Which checks matter, how long a proof lives and what gets remembered are the protocol's decisions, and the SDKs carry them unchanged into your stack.
Tested end to end; the package-index release comes later
Tested and working means exactly that: builds that pass their test suites and verify real presentations end to end. It does not yet mean a package-index release: the SDKs are delivered from a tagged release, and integration work is shaping the release checklist. The issuer-side counterpart — the provider-neutral adapter that lets an accepted issuer plug in its identity-verification provider — has since been built: the first issuer runs it in production with a real provider behind it (see the roadmap). And MintID itself runs on the single-node production chain, in production since 20 September 2026 and operated by Conectia: no token, no public mainnet yet, and the audits are scheduled milestones whose findings are published.
If you run a verifier agency and want the verification core inside your stack — embedded, or behind a thin client — talk to us now: integration starts as a conversation, and it runs under commercial terms. For the machinery underneath, presentations, nonces and finalised roots are laid out on the technology page and in the protocol spec.