> Development of the MintID verifier SDKs has started — TypeScript, PHP and Python — and we expect the first builds tested and working in a couple of weeks. Inside every binding, the same non-negotiables: nine acceptance checks, a ten-second proof lifetime and zero policy knobs. Blog · announcement # The MintID SDKs are in development: TypeScript, PHP and Python Development of the MintID verifier SDKs has started — TypeScript, PHP and Python — and we expect the first builds tested and working in a couple of weeks. Inside every binding, the same non-negotiables: nine acceptance checks, a ten-second proof lifetime and zero policy knobs. by Marc Miró i Rierola·published 2026-07-20·updated 2026-07-20·5 min read Development of the MintID SDKs has started. The verification core — the software a [registered verifier agency](/en/verifiers) 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](/en/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](/en/contact): 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](/en/technology) and in the [protocol spec](/en/protocol). ## Your stack, our guarantees Three languages, one pipeline, zero policy knobs. The SDKs are in development — integration starts as a conversation today. [Become a design partner](/en/contact)[The verifier role on MintID](/en/verifiers) --- Source: https://mintid.net/en/blog/embedded-not-hosted · The MintID SDKs are in development: TypeScript, PHP and Python — MintID blog