The commands on this page run against local localnet evidence. The provability format is identical on public GIWA Sepolia, where the first public Usage Root anchoring is still ahead of us and tracked on Live Evidence.
What a receipt is
A receipt is aUsageReceiptV1: a narrow, immutable EIP-712 typed-data statement the gateway signs after it observes provider usage for one request and fixes the pricing snapshot that applies. It is not an x402 payment receipt, not a wallet attestation, and not an on-chain transaction.
The V1 EIP-712 domain is exactly:
Get a receipt to verify
Retrieval from a running gateway is authenticated:GET /v1/receipts/:request_id under a project-scoped tok_ bearer key, which only ever sees its own project’s receipts. No public gateway origin is published yet, so that route is not reachable today. See Gateway API.
Verification does not need one. The published cross-language vector fixture is a complete receipt payload carrying its committed digest, signature, and recovered signer, and the steps below reproduce it from that payload alone. The fixture’s signing key is a development-only Anvil key: it is fixed public test data, not an operational secret.
Verify the signature yourself
Given the receipt’s typed data and signature, verification is mechanical.1
Recompute the EIP-712 digest
Rebuild it from the domain above and the Field order, integer widths, and the
UsageReceiptV1 fields exactly as serialized:costUsd scale of 1e-4 USD units are part of the immutable schema.2
Recover and check the signer
Recover the signer from the ECDSA signature and look the envelope’s
signerAddress up in the gateway’s signer registry under the receipt’s signerVersion. That field is not receiptSchemaVersion: the schema version is fixed at 1 for every V1 receipt, while signerVersion names the registered key generation the envelope was issued under. V1 receipts are EOA-signed; a future contract-wallet signer must use an explicit ERC-1271 path, never an ECDSA fallback.3
Recompute the leaf and hash the sibling path
Build the wallet-bound receipt leaf under the merkle domain
TOKSCALE_RECEIPT_LEAF_V1, then hash up the sibling path with TOKSCALE_RECEIPT_NODE_V1 domain separation.4
Compare against the attested root
Check that the computed root equals the epoch’s attested
receiptRoot, then resolve the EAS attestation UID and schema UID on-chain./receipts/verify: the holder pastes or deep-links the typed-data payload, the page recomputes the digest client-side with viem’s verifyTypedData, resolves the signer through the registry, recomputes the leaf, and renders the merkle path to the attested root with the attestation UID. No login is required, and disclosure stays holder-controlled.
The provability chain
One request becomes public evidence through four hops:Cross-language vector checks
The protocol is locked by fixed test vectors verified three independent ways: Rust (Alloy), TypeScript (viem), and Solidity (forge), so no single library is trusted twice. The receipt vectors run under one target, covering domain, digest, signature, and recovered signer:forge test --match-contract ReceiptAttestationV1Test:
Verification in the browser
The sealed harness proves the in-browser path end to end: a Playwright container with no credentials verifies a real issued receipt through/receipts/verify and seals the artifacts.
Next steps
- For the immutable receipt schema and its evolution rule, see UsageReceiptV1.
- For how epoch receipt roots anchor on-chain, see Receipt Attestation.
- For the full index of targets and pass markers, see Verification Log.
- For what the end-to-end harness pass covers, see Gateway Overview.