# ReceiptSure Transaction Verification

> ReceiptSure Transaction Verification is a paid API for AI agents from receipt.schemasure.com, paid per call via x402, $0.02/call, status unknown (last checked 2026-10-11).

Verifies that a mined Base blockchain transaction executed the intended token transfers and approvals by decoding receipt logs and comparing them against declared expected movements.

## Facts

- Endpoint: POST https://receipt.schemasure.com/v1/tx/receipt-verify?utm_source=zero.xyz
- Price: $0.02/call
- Payment: x402
- Status: unknown
- Last checked: 2026-10-11
- Activations on Zero: 0
- Tags: x402
- Canonical page: https://www.zero.xyz/c/receiptsure-transaction-verification-c463f137
- Structured record (JSON): https://api.zero.xyz/v1/capabilities/cap_YAeMoQR9lEPcSokQxNNPM

Status and success rate cover calls made through Zero and Zero's own probes. Third-party monitors may report differently.

## How to call it through Zero

Zero handles the 402 payment challenge and records the run. With the Zero CLI installed (`npm i -g @zeroxyz/cli`):

```sh
zero fetch --capability receiptsure-transaction-verification-c463f137 -d '<json body>'
```

Example prompt: Can you check whether Base transaction 0xabc123...def456 actually sent 1000000 USDC (that's 1 USDC in base units) to 0xRecipient...address? I want to know if it matched, was short, or missed entirely.

## When to prefer this

Use this endpoint when an AI agent has just submitted or observed a Base transaction and needs programmatic confirmation that token movements matched intent — especially before releasing goods, updating records, or proceeding to the next workflow step. Prefer it over simple success/fail checks when fee-on-transfer tokens, multi-hop DeFi, or unexpected recipient risk is a concern. It is the right choice when you need per-transfer granularity with matched/missing/short/unverifiable verdicts rather than a binary confirmation. Not suited for Ethereum mainnet or other EVM chains — Base only.

## Known failure modes

- Transaction hash has no receipt yet (not yet mined) — returns unknown status
- Transaction reverted on-chain — reported as revert with no matched transfers
- Fee-on-transfer tokens deliver less than declared amount — reported as short
- Native ETH transfers cannot be verified via logs — reported as unverifiable
- Recipient address not found in any log — reported as missing
- Undeclared recipient appears in logs — flagged as unexpected outflow
- Malformed transaction hash (not 64 hex chars) — schema validation error
- More than 32 expected_transfers entries — rejected by schema
- Amount declared as zero — rejected by schema validation

## How this service works

Check whether a mined Base transaction did what your agent meant it to do. Fetches the receipt, decodes its ERC-20, ERC-721 and ERC-1155 transfer and approval logs, and reports each declared movement as matched, missing or short, with the observed amount beside the expected one. Catches reverts, success with no effect, fee-on-transfer skims and transfers to recipients you never named. Returns unknown rather than guessing. Not a guarantee that a transaction was safe.

## Output

Returns a per-transfer verdict for each declared expected movement: matched (log found and amount correct), missing (no matching log found), short (log found but transferred less than expected), or unverifiable (native ETH transfers that emit no log). Also reports any token outflows to undeclared recipients, whether the transaction reverted, and the observed amount alongside the expected amount for each entry. Returns 'unknown' rather than guessing when information is ambiguous.

## Request schema (JSON Schema)

```json
{
 "type": "object",
 "properties": {
  "tx_hash": {
   "type": "string",
   "pattern": "^0x[0-9a-fA-F]{64}$",
   "description": "The Base transaction to check. A hash with no receipt yet answers unknown."
  },
  "expected_transfers": {
   "type": "array",
   "items": {
    "type": "object",
    "required": [
     "to",
     "amount"
    ],
    "properties": {
     "to": {
      "type": "string",
      "pattern": "^0x[0-9a-fA-F]{40}$",
      "description": "The intended recipient."
     },
     "from": {
      "type": [
       "string",
       "null"
      ],
      "pattern": "^0x[0-9a-fA-F]{40}$",
      "description": "The sender, when you know it. Naming it is what lets undeclared recipients be judged: outflows are only held against you when they leave the account that signed the transaction, or leave a declared sender in the asset you said it would send."
     },
     "asset": {
      "type": [
       "string",
       "null"
      ],
      "pattern": "^0x[0-9a-fA-F]{40}$",
      "description": "Token contract. Omit or null for native ETH, which emits no log and is therefore reported unverifiable rather than matched."
     },
     "amount": {
      "type": "string",
      "pattern": "^[0-9]+$",
      "description": "Base units, not display units: 1 USDC is \"1000000\". Must be above zero."
     },
     "token_id": {
      "type": [
       "string",
       "null"
      ],
      "pattern": "^[0-9]+$",
      "description": "ERC-721 or ERC-1155 token id, when the movement names one."
     },
     "asset_kind": {
      "enum": [
       "native",
       "erc20",
       "erc721",
       "erc1155",
       "unknown"
      ],
      "type": "string",
      "description": "Optional. Inferred from asset and token_id when absent."
     }
    },
    "additionalProperties": false
   },
   "maxItems": 32,
   "minItems": 1,
   "description": "What you intended to move. Each entry is checked against the decoded logs and reported as matched, missing, short, or unverifiable."
  }
 }
}
```

## More

- Live health (JSON, refreshed every minute): https://www.zero.xyz/c/receiptsure-transaction-verification-c463f137/health.json
- [Zero catalog index](https://www.zero.xyz/llms.txt)
- [Other services from receipt.schemasure.com](https://www.zero.xyz/host/receipt.schemasure.com/llms.txt)