Light is not ZK. There is no WASM prover.

Available, and not

Three packages, two runtimes, no WebAssembly. @affix-io/sdk and @affix-io/sdk-light declare engines.node >= 18, ship as Node ESM and have no browser export field. @affix-io/sdk-web is the browser and edge client: Web Crypto and Fetch only, no Node APIs, distributed as source by AffixIO rather than published on npm. There is no WASM build for either proving path. That is the packaging statement. Everything else on this page follows from it.

How a web application verifies a carrier

The shape that works: the browser is a camera and a display, the server holds the key, AffixIO is the verifier. Nothing in that sentence is optional.

1. Capture The browser opens the camera or accepts a pasted carrier. Decode it with any QR or barcode library. You now hold a string, not a decision.
2. Authenticate on your origin A short-lived session cookie or bearer token that your own backend issued to the operator. This is what authorises the next hop, not an AffixIO key.
3. Forward Your backend calls POST /v1/verify or POST /v1/gate/verify with the AffixIO key and the carrier payload. The key never leaves that host.
4. Decide The browser receives a boolean, a reason code and whatever of the response you choose to surface. On a 409 it receives a double-spend signal and stops, rather than retrying.
5. Audit Your backend keeps X-Request-Id, the digest and the reason code. Optionally it listens for the matching webhook or pulls the evidence export later.

// browser: never holds AFFIX_API_KEY
const carrier = await scan();                 // string from the camera
const session = await getOperatorSession();   // your own cookie / token

const result = await fetch("/internal/verify", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    "Authorization": `Bearer ${session}`,
  },
  body: JSON.stringify({ carrier }),
});

const { admitted, reason_code, request_id } = await result.json();
renderGate(admitted, reason_code, request_id);

// your backend: the only place that holds AFFIX_API_KEY
app.post("/internal/verify", requireOperator, async (req, res) => {
  const upstream = await fetch("https://api.affix-io.com/v1/gate/verify", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      "Authorization": `Bearer ${process.env.AFFIX_API_KEY}`,
      "Idempotency-Key": crypto.randomUUID(),
    },
    body: JSON.stringify({ carrier: req.body.carrier, gate_id: process.env.GATE_ID }),
  });

  const body = await upstream.json();
  res.status(upstream.status).json({
    admitted: body.admitted ?? body.valid ?? false,
    reason_code: body.reason_code,
    request_id: upstream.headers.get("X-Request-Id"),
  });
});

Two separate credentials, two separate lifetimes. The operator session lasts for a shift. The AffixIO key lasts until you rotate it. Conflating them is how keys end up in source maps.

On WASM

People ask for a WASM build for two different reasons, and the answers differ.

To prove in the browser. Zero-knowledge proving is not supported and will not be soon. UltraHonk through Barretenberg is a large native footprint in its current packaging, and shipping it as WASM would be a different product with different testing and different size budgets. Light proving is a different question: @affix-io/sdk-web does it on Web Crypto with no WASM at all. The constraint there is not the runtime, it is the secret. Whoever holds the Light secret can mint proofs, which makes untrusted browser code the wrong place for it and an edge worker you control the right one.

To verify something in the browser. Merkle inclusion is already a handful of SHA-256 calls and works with Web Crypto today. ML-DSA-65 verification is possible in principle once a verified WebAssembly implementation of the algorithm is something you are prepared to maintain; AffixIO does not currently ship one. Until it does, verify signatures on a host you control.

If a WASM prover becomes something AffixIO is prepared to support, it will appear as a versioned package with its own documentation, not as a silent addition to the existing Node packages. Until then, assume proving stays on a host you control.