Development of the MintID SDKs has started. The verification core — the software a registered verifier agency runs to request and validate presentations — is being packaged as an SDK in three languages: TypeScript, PHP and Python. We expect the first builds tested and working in a couple of weeks.
This is the protocol's first deliverable 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.
One verification core, three languages
Each SDK wraps the same core: request a presentation, validate it against the chain, keep a minimal decision record. TypeScript covers the Node backends where most agent-facing services already live; PHP meets the platforms that still run much of the commercial web; Python covers the data and AI stacks where agent operators build. 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.
These are constants and closed types, not settings — a weaker verifier cannot be built from these parts, in any of the three languages. 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.
What "a couple of weeks" means — and what it doesn't
Tested and working means exactly that: builds that pass their test suites and verify real presentations end to end. It does not mean general availability — how the packages will be distributed is a decision we haven't announced, and the first integrations will run with design partners, whose constraints are shaping the packaging decisions that remain open. The issuer-side counterpart — the provider-neutral adapter that lets an accepted issuer plug in its identity-verification provider — is a later deliverable of the implementation plan, on the roadmap after the verifier SDKs. And MintID itself remains a research-stage protocol: no live token, no mainnet before independent audits.
If you run a verifier agency and want the verification core inside your stack — in TypeScript, PHP or Python — talk to us now: the design-partner window is exactly the couple of weeks in the headline. For the machinery underneath, presentations, nonces and finalized roots are laid out on the technology page and in the protocol spec.