{
  "id": 14288210,
  "title": "Receipts, not screenshots: a practical guide to verifying on-chain claims",
  "url": "https://urgent.news/2026/10/13/receipts-not-screenshots-a-practical-guide-to-verifying-on-chain",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-10-13T20:46:50.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/kaminariresearch/receipts-not-screenshots-a-practical-guide-to-verifying-on-chain-claims-20el"
  },
  "original_language": "en",
  "account": "Receipts, not screenshots: a practical guide to verifying on-chain claims\n\nWhen someone claims they performed an action on-chain, screenshots are not enough to prove it. A real receipt is needed: showing exactly what ran, what came back, and a way anyone can follow the steps. I use this checklist when auditing on-chain claims for bounties.\n\nFirst, every number should have a block attached to it. A claim of receiving 0.5 BNB is untestable without more details. Instead, state: \"At block 39,769,979, eth_getBalance(treasury) returned X; at block 39,769,978 it returned Y; the difference equals the receipt line, down to the wei.\" This way, anyone can replay the transaction.\n\nFor an audit of a buyback, post the receipts that show N tokens bought with M BNB, and the treasury balance after the transaction. Reconcile the numbers field-by-field: locate the swap transaction, note its block, read the treasury balance just before and after the transfer, and ensure the delta matches the spent amount. Check for continuity between consecutive receipts and verify pool parameters if price impact is claimed. Present the results in a table with claim line, on-chain value, block number, and verdict. Discrepancies should be flagged, not smoothed over.\n\nIn another audit, I traced an EIP-7702 delegation. A naive approach using eth_getCode was insufficient. I found only two transitions using binary search, but the actual number was six. Four of those transitions happened in a 45-second window, and three sponsors submitted authorization tuples for the same authority during the same nonce. A code-state search missed this complex sequence. To address this, enumerate transactions instead of state. Read the full block, filter for type-0x4 transactions, and scan the authorization list. Scan the code boundary with repeated eth_getCode reads across multiple RPCs. Verify the results on several providers to ensure accuracy.\n\nBefore believing any on-chain claim, verify: does every number have a block number? Is there a replay command or exact call that reproduces the result? Are the deltas closed to the wei? For multi-step claims, check for continuity between steps. For \"who did it\" questions, read transactions (filter by type, scan authorization lists), not just state. Ensure the raw output is public, so others can verify your findings. If all six conditions are met, you have a receipt. If any condition is missing, it's a screenshot. Publish receipts by default, not just screenshots. Most agent work leaves no record, making it hard to prove failures. If your agent produces artifacts with block pins and replay paths, you can prove what happened without being present. I packaged these checks as agent skills: the Onchain Claim Verifier and Crypto Wallet Safety Check. These distilled versions of the audits above are available for free. Feel free to comment with disagreements, and provide block numbers to support your arguments.",
  "summary": "Receipts, not screenshots: a practical guide to verifying on-chain claims If a bot tells you it did something on-chain, \"trust me\" is not evidence. A screenshot is not evidence either. The only thing that settles the question is a receipt : what ran, what came back, and a replay path that anyone — who was not there — can follow. I run an autonomous research agent that audits on-chain claims for…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}