Getting started
What to register before you write code, how the SDK reaches you today, and what already runs in production: the verification pipeline and the proof core.
Before any code: become a verifier
The SDK accepts presentations only for a verifier that is registered and active: it resolves your origin against proven on-chain state on every decision. Complete these four steps before you write integration code; becoming a verifier explains how admission works today.
- Pass the verifier identity check and have your record admitted: it must be active on chain, and today an operator processes admission.
- Register every exact origin you present from, and renew each registration periodically. Origins are exact — no wildcards — and an origin resolves to one verifier only, so a lookalike domain can never impersonate you.
- Register your request-signing keys — the key that signs your challenges must be registered for your origin.
- Plan your infrastructure: access to chain nodes, whose answers are checked cryptographically so the nodes need no trust; a trust anchor you control, which today means a node you run yourself, since a light client that checks untrusted peers has not shipped; a crash-durable store for single-use challenges (the SDK ships one); a disciplined clock; and a place for the decision records.
Installation channels
The source. Everything is public under the Apache License 2.0 at https://gitlab.com/mintid/mintid (the whole implementation, the local stack and these pages), with a read-only mirror per SDK. Issues and merge requests go to the main project; a vulnerability goes privately to the address in its SECURITY.md, never to a public issue.
The packages. Released versions are on PyPI and npm; the main project (or the mirror, where there is one) is their source and can be ahead of them.
| Package | Install | Source (mirror) |
|---|---|---|
mintid-verifier-sdk (Python ≥ 3.12) | pip install mintid-verifier-sdk (0.5.1) | verifier-core/ |
mintid-proof-core (Python bindings of the proof core and holder library) | pip install mintid-proof-core (0.5.3) | identity-proof-core/python/ |
mintid-agent (Python agent client) | pip install "mintid-agent[ed25519]" (0.5.0; pulls in mintid-proof-core) | sdk/python/mintid-agent/ (https://gitlab.com/mintid/sdk-python) |
@mintid-net/verifier-client (Node ≥ 20, ESM + types) | npm install @mintid-net/verifier-client (0.4.0) | sdk/typescript/ (https://gitlab.com/mintid/sdk-typescript) |
@mintid-net/verifier-mcp | npm install @mintid-net/verifier-mcp (0.3.1) | sdk/mcp/ (https://gitlab.com/mintid/verifier-mcp) |
@mintid-net/holder (the holder in WebAssembly; browser and Node ≥ 20, ESM + types) | npm install @mintid-net/holder (0.1.1) | sdk/holder/ (https://gitlab.com/mintid/sdk-holder) |
| Go holder binding | go get gitlab.com/mintid/sdk-go/holder | sdk/go/ (https://gitlab.com/mintid/sdk-go) |
Platforms. mintid-verifier-sdk and mintid-proof-core compile the Rust proof engine in at a pinned version. The registry carries a prebuilt wheel for Linux x86-64 only; on any other platform (macOS, Linux on ARM, Windows) pip builds the package from its source distribution, which needs a Rust toolchain. From a clone of the main project the same holds: pip install ./verifier-core, pip install ./identity-proof-core/python. The mintid-holder binary, which the TypeScript identity and agent modules and the Go binding drive, is on no registry: cargo build --release -p mintid-holder in identity-proof-core/.
Where to test. On the public testnet, with its KYC sandbox, and only there; check its status line first. The single-node production chain is not for third parties and is never a place to test. Until the testnet answers, the local stack of the main project runs the same flows on your machine.
Every artifact records its release pins — SDK version, proof-engine version, the chain store-layout vectors it was checked against, the specification revision and the conformance-suite version — and a running service reports them through its build-info operation.
Current status — read before integrating
- The verification pipeline is complete: the acceptance conditions, proven chain reads, single-use challenges, decision records, the service, its contract and the TypeScript client all exist and are gated by a shared conformance suite.
- The proof core is built and runs on the single-node production chain, in production since 20 September 2026 and operated by Conectia: credential issuance, selective-disclosure presentations and the non-revocation path are implemented and pinned by known-answer vectors that three languages check. You can also build and test a full integration against injectable test doubles before you touch a chain.
- A given deployment may be running an older engine than this page describes. The pin is the fact, not the release note: read
engine_pinfromGET /v1/build-infoon the instance you are actually talking to. - Assurance grades (A1–A4) are set by accepted issuers, within the grades their admission permits. They are anchored on the eIDAS levels and mapped to ISO/IEC 29115 without redefining either. How recently the evidence was checked is a separate freshness band, published by the issuer next to the grade: a presentation proves the grade threshold, and the band is not a presentation predicate.
The 60-second mental model
sdk flow
one decision, one minimal decision record, per presentation