The SDK handles the part that is easy to get subtly wrong: runtime binding, recoverable deposits, exact proof inputs, fee bounds, spent-note checks, and unsigned calldata. Your app supplies the local prover, current Merkle membership, chain reads, and wallet transport.
Install from the monorepo workspace or a reviewed pair of SDK and core tarballs; the npm release is pending. Current deployment shows the runtime pinned by the package.

The boundary

proverRunner.fullProve is the small adapter to your in-process Groth16 implementation. It receives witness data and authenticated WASM and zkey locations. Do not replace it with a hosted callback: deposit and withdrawal witnesses contain secrets. The three chain adapters have narrow jobs:

Prepare and restore a deposit

The SDK rejects an absent proof, a proof with the wrong byte length, and any changed commitment, amount, chain, pool, context hash, or encrypted-payload hash. It returns an unsigned transaction; it never signs or broadcasts.

Prepare a withdrawal

Before returning calldata, the SDK checks membership and spent state, reads the active fee, builds and validates the proof statement, then reads the fee and spent state again. If either changed during proving, preparation stops and you rebuild.

What was actually verified

The repository’s package-consumer check packs both workspace packages, installs them into an empty project, runs deposit and recovery through the public client, type-checks a separate consumer, and bundles the browser entry. That check covers source-package consumption. npm distribution, deployment, relayer, wallet submission, and production readiness each have their own release checks.