Verify a Receipt
Re-run Pakt's Rust verifier locally in the browser against the receipt's pinned proof and payload bindings.
The dashboard does not accept a server-provided “verified” flag. It loads the receipt and checks it locally with Pakt's Rust verifier compiled to WebAssembly (WASM).
Verification Proves Authorization, Not Execution
A verified receipt proves what Pakt authorized or refused for one exact action. It does not prove that the agent submitted the request or that the venue executed it.
Verify in the Dashboard
Open the receipt from the Pakt account dashboard. The browser verifier contains the committed guest image ID—the pinned Pakt verifier ID. It then checks:
- the proof against the pinned Pakt verifier ID;
- the stored Pakt root against the root committed by the proof;
- the freshness challenge and previous receipt history;
- the stored action bytes against the action committed by the proof;
- the recorded allow or refuse result; and
- the receipt's credential signature over the verified artifact.
The receipt credential signature is separate from the venue wallet signature. It records that the secure authorization boundary released the action. It cannot be submitted to Hyperliquid or Ethereum and cannot move funds.
The result is either verified or invalid. A malformed row, mismatched root, wrong image, unbound action, missing allow signature, or bad credential signature is a verification failure—not a warning to ignore.
What a Verified Receipt Proves
For an allowed action, verification establishes that the exact committed action satisfied the committed Pakt under the authenticated inputs in that proof, and that the stored credential signature is internally valid.
For a refused action, verification establishes the proof and its committed bindings without requiring a credential signature. Refusal is expected to be unsigned.
What It Does Not Prove
A valid authorization receipt does not prove that the MCP client submitted the request, that the venue accepted it, or that settlement completed. Establish those facts from the venue's own state and references.
Verification Is Local
The WASM module performs the cryptographic checks in the visitor's browser. It does not send the receipt back to Pakt and ask the server to verify itself.
Credential Authority Is Not Re-Attested
The Nitro receipt-credential key is generated anew on each enclave boot. The current stored receipt does not carry the AWS attestation document that bound that key to the measured enclave, so the browser can check the signature's integrity but cannot independently re-attest the key's Nitro authority. The dashboard states this limitation beside a successful result.