Reserve proofs (zero-knowledge)

A reserve proof shows that an issuer's reserves meet the required backing ratio and composition rules (the 40/60-style policy), while the individual holdings stay private. As a verifier, you get a pass or fail, and if it fails, the name of the rule that was broken.

This works differently from List reserves. With that endpoint, you're trusting Nuvanté's reporting pipeline. With a reserve proof, you're trusting arithmetic you can check. In sandbox, the policy check runs against the issuer's real simulated reserve data, so if you under-fund a sandbox issuer, the proof really does fail.

Generate a fresh proof for a sandbox issuer:

POST https://sandbox-api.nuvante.io/api/v1/reserves/323e4567-e89b-42d3-a456-426614174002/proof/generate

{
  "data": {
    "issuerId": "323e4567-e89b-42d3-a456-426614174002",
    "result": {
      "pass": true,
      "keyId": "reserve-policy-v1-sandbox"
    },
    "artifact": {
      "issuerId": "323e4567-e89b-42d3-a456-426614174002",
      "keyId": "reserve-policy-v1-sandbox",
      "generatedAt": "2026-08-19T11:04:33.000Z",
      "pass": true,
      "snapshot": {
        "reservesGbp": "1200000.0000000",
        "supplyIssued": "1000000.0000000",
        "centralBankDepositRatio": 0.4
      }
    }
  }
}

Now try under-funding the sandbox reserve on purpose (using the admin reserve-adjustment tool or the /reserve-proofs page in the portal) and generate the proof again:

{
  "data": {
    "issuerId": "323e4567-e89b-42d3-a456-426614174002",
    "result": {
      "pass": false,
      "keyId": "reserve-policy-v1-sandbox",
      "failedRule": "backing_ratio_below_threshold: 0.3500 < 0.4"
    },
    "artifact": { "pass": false, "failedRule": "backing_ratio_below_threshold: 0.3500 < 0.4", "..." : "..." }
  }
}

The failed rule name tells you exactly which check didn't pass. In production, only the pass or fail result and the rule name are shared. The underlying figures stay private.

You can send any proof artifact to the verify endpoint to get a fresh pass or fail against the sandbox policy. Nothing is regenerated from live data:

POST https://sandbox-api.nuvante.io/api/v1/reserves/proof/verify
Content-Type: application/json

{ "artifact": { ...artifact from generate or GET... } }

If the proof was generated under any key other than reserve-policy-v1-sandbox, you'll get a 400. That makes the boundary between sandbox and production easy to test.

Issuer tenant admins can generate and view proofs at /reserve-proofs in the portal. The page shows a live pass or fail, and you can open the full artifact. To trigger a failing proof on purpose, adjust the sandbox reserve composition on the Reserves page. Testing the failing case matters just as much as testing the passing one.