SDK docs · sdk/05

Conformance & versioning

"Every SDK behaves identically" as a CI gate: the cross-language conformance suite, semver promises, and the release pins every artifact carries.

The cross-language conformance suite

"Every SDK behaves identically" is not a promise here — it is a CI gate. A committed set of JSON vectors derived deterministically from the reference implementation: for each case, a canonical challenge, a holder envelope, a declarative description of the proven on-chain state ("world"), and the frozen expected decision. Coverage is total by construction and CI-asserted:

  • one accepted case (plus policy-nuance positives),
  • at least one rejection for each of the nine acceptance conditions,
  • every producible reason code in the vocabulary.

Every SDK must pass the suite before release:

  • the Python SDK replays every vector through the library and through the service HTTP surface;
  • the TypeScript client replays every vector through real HTTP against the reference service running with test doubles;
  • the committed vectors are byte-compared against regeneration on every CI run — the suite cannot drift from the reference implementation silently.

A release declares the suite version it passed (also readable at runtime via build_info().conformance_suite_version).

Version numbers and what they promise

Everything follows semver with one shared rule: decision semantics are major.

ArtifactMajor meansMinor means
mintid-verifier-sdk (Python)public surface or accepted-behavior changeadditive surface
OpenAPI contract verifier-service.v1decision semantics or reason-vocabulary changeadditive wire surface
Conformance suitea change to any case’s expected decisionnew cases
@mintid/verifier-clienttracks the contract major

Release pins (what an artifact tells you about itself)

Every SDK artifact records, programmatically readable:

  • engine_pin — the exact proof engine compiled into the package. While the anonymous-credential core is pre-launch, the pin marks the build as a placeholder and the engine refuses every proof (fail closed): a non-verifying build can never masquerade as a verifying one. The marking disappears only when the audited engine lands.
  • state_vectors_version and state_vectors_sha256 — the chain store-layout vectors this build was release-gated against; a mismatch with the target chain blocks the release outright.
  • Engine pin bumps are reviewed release changes — never automatic, not overridable by dependency resolution, not substitutable through any supported install path.

What this buys you as an integrator

You can treat any two artifacts declaring the same contract major and the same suite version as decision-equivalent: same inputs, same accept/reject, same reason code, in any language. That equivalence is re-proven by CI on every change, which is the entire point.