@zkproofport-app/sdk 0.2.13 → 0.2.15

package/dist/offChainVerifier.d.ts

@@ -11,19 +11,22 @@
  * (through mopro's native Barretenberg); it was only the JavaScript side that
  * had no such thing.
  *
- * HOW IT WORKS. `bb` proofs are checked by `acirVerifyUltraKeccakHonk(proof,
- * vk)` — the keccak variant, matching how these proofs are produced. Two things
+ * HOW IT WORKS. Proofs here are made with `--oracle_hash keccak` and ZK on, so
+ * the matching check is `acirVerifyUltraKeccakZkHonk(proof, vk)`. Two things
  * have to line up:
  *
- *   The version. The verification key format is not stable across bb releases:
- *   the pinned build emits a 1816-byte key where bb 0.87.0 and 1.2.0 emit 1760.
- *   `@aztec/bb.js@1.0.0-nightly.20250723` is the WASM build of the same bb the
- *   circuits were compiled with. A different one will reject valid proofs.
+ *   The version. `@aztec/bb.js@1.0.0-nightly.20250723` is the WASM build of the
+ *   same bb the circuits are compiled with. Versions are not interchangeable:
+ *   measured on the Korea Mobile ID age circuit, the pinned bb writes a 16256-
+ *   byte proof where bb 1.2.0 writes 16224 for the identical circuit and
+ *   witness — and the verification key comes out the SAME either way, so the
+ *   key cannot warn you. A mismatch shows up only as verification failing.
  *
- *   The oracle hash. Proofs are generated with `--oracle_hash keccak` so the
- *   Solidity verifiers can check them, so the poseidon-flavoured verify — which
- *   is what `BarretenbergVerifier.verifyUltraHonkProof` uses — says false for a
- *   perfectly good proof.
+ *   The flavour. There are four verify entry points and picking the wrong one
+ *   is not a polite false. `acirVerifyUltraZKHonk` (poseidon) answers false for
+ *   a perfectly good proof, and `acirVerifyUltraKeccakHonk` — keccak without ZK
+ *   — TRAPS the WebAssembly with a bare "unreachable", which looks exactly like
+ *   a corrupt proof, a mismatched key, or a missing SRS.
  *
  * THE PROOF ARRIVES IN TWO PIECES. The mobile app splits what Barretenberg
  * produced into `proof` and `publicInputs` before sending it, because the
@@ -48,9 +51,8 @@ export interface OffChainVerifyOptions {
 /**
  * Verify a proof off-chain, against its verification key.
  *
- * Needs `@aztec/bb.js` at the pinned version. It is an optional peer dependency
- * — the WASM is large and most callers verify on-chain — so the failure to have
- * it installed says so plainly rather than surfacing as a module-not-found.
+ * Needs no setup from the caller: the verifier ships with this SDK and is
+ * loaded on first use.
  *
  * @param circuit - Canonical circuit identifier
  * @param proof - Proof bytes as hex, WITHOUT public inputs (as the relay sends it)

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@zkproofport-app/sdk",
-  "version": "0.2.13",
+  "version": "0.2.15",
   "description": "ZKProofport SDK for requesting zero-knowledge proofs from the ZKProofport mobile app and verifying them on-chain",
   "main": "dist/index.js",
   "module": "dist/index.esm.js",
@@ -32,6 +32,8 @@
     "prepublishOnly": "npm run build"
   },
   "dependencies": {
+    "@aztec/bb.js": "1.0.0-nightly.20250723",
+    "buffer": "^6.0.3",
     "qrcode": "^1.5.3",
     "socket.io-client": "^4.8.0"
   },
@@ -45,19 +47,14 @@
     "tslib": "^2.8.1",
     "typedoc": "^0.28.16",
     "typescript": "^5.3.3",
-    "vitest": "^4.0.18",
-    "@aztec/bb.js": "1.0.0-nightly.20250723"
+    "vitest": "^4.0.18"
   },
   "peerDependencies": {
-    "ethers": "^5.7.0 || ^6.0.0",
-    "@aztec/bb.js": "1.0.0-nightly.20250723"
+    "ethers": "^5.7.0 || ^6.0.0"
   },
   "peerDependenciesMeta": {
     "ethers": {
       "optional": true
-    },
-    "@aztec/bb.js": {
-      "optional": true
     }
   },
   "keywords": [