SDKs & Reference Kit

The Reference Kit is a runnable path: assemble an envelope in your language of choice, hit a real Gate, and watch both the allow path and the named rejects behave. It packages the same curriculum DEMO-HACK teaches for developers who want code first.

What you get

• The prover path: canonicalize the request, challenge the circuit, respond, and assemble the envelope.
• The Gate path: recompute the binding server-side, burn the nonce before validate, then run twin validation.
• Language-shaped examples for the client assembly step (six-language target coverage).
• Hooks into Verify so each named reject stage is a falsifiable, runnable test.

Start with the quickstart if you only care about one endpoint. Keep the Reference Kit around after that as your oracle for the question you will ask most often during integration: does my client still assemble a conforming envelope?

What breaks and how to verify

If the allow path stops returning 2xx, the most common cause is a canonicalization change in your body serializer, not a Gate misconfiguration. Run the Kit against your local integration before you run it against a staging Gate; a passing Kit and a failing staging Gate almost always means a configuration mismatch on Gate itself.

Hand-rolling request signatures and middleware checks is how ambient credentials sneak back into production. Import two libraries instead: a client SDK that assembles an envelope before each request, and Gate middleware that enforces it inside your process.

The Node middleware is the reference implementation available in evaluation today; other languages track the Reference Kit. If your service is not on Node yet, run Gate as a reverse proxy in front of it. The wire contract is identical, so your client code does not care which form factor enforces the envelope.

Gate middleware (Node)

You embed Gate in an Express-compatible application ahead of the route handler you want to protect (product details). You declare an endpoint_id, the policy string, a freshness window, and a ledger endpoint. Incoming requests must present a conforming envelope before your handler runs; anything missing or inconsistent returns a named 4xx and never reaches your business logic.

Client libraries

The client SDK wraps challenge and respond against the circuit binary (or the agent respond path, for machine-to-machine callers), reserves a nonce from the ledger, and fills the published binding fields. In a human ceremony this is fronted by Pass+. Node is the evaluation reference implementation; other languages ship as Reference Kit examples first, then as first-class SDKs.

Configuration surface

Everything below is per protected endpoint, so you can tune posture per route rather than per service:

• endpoint_id, the policy_hash source string, and the method allow-list for the route.
• TTL or use-count and the freshness window (how far tau can drift before Gate rejects).
• Fail-open versus fail-closed behavior, with break-glass rules for ledger outages.
• Audit mode: hash_only for privacy-sensitive routes, full capture where evidence matters more.

A green demo path is not proof that replay, retarget, and tamper paths are closed. Conformance is the falsifiable suite that proves your Gate integration actually enforces the protocol: allow path, envelope binding, burn ordering, and every named reject stage.

Verify and the DEMO-HACK adversary path exercise attacks that should land on named reject stages. Your integration conforms when the same stages fire against the Gate you actually shipped, not when a demo container passes in isolation.

Minimum checks

• Allow path: a valid envelope returns 2xx and the side effect happens exactly once.
• Replay: identical envelope bytes on a second attempt reject at the nonce stage.
• Body tamper without re-prove: mutated body against the original envelope rejects at the request-hash stage.
• Endpoint retarget: swapping endpoint_id to a different route rejects at the endpoint stage.
• Policy loosen: weakening the policy_hash rejects at the policy-hash stage.
• Stale tau outside the freshness window rejects at the freshness stage (when the server enforces a window).

How to run and verify

Run the suite in CI against a staging Gate that points at a durable ledger (not an in-process burn set), because a non-durable ledger will make replay checks pass spuriously in a single-process test. Green Conformance is evidence for the Deployment Security Package conversation with your security team; wire it into the same CI that gates deploys.