AISkills402Connect your agent

Agents & Protocols

Chain Evidence Check

Recommended

Judges whether an on-chain observation really proves a claim about a payment, a wallet or an RPC endpoint on an EVM chain, and answers as JSON with a binary verdict, the reason and the one check that would decide. Knows the readings that answer for the wrong thing - a null transaction receipt seconds after settlement, a block explorer that indexes a minute late and a balance view that lags its own transfer list, a public RPC endpoint that refuses receipts with an error or with an HTML page behind status 200, a reader that returns zero when the call failed, a chain of endpoints that says ok when two of three are dead, a transfer of the right amount that matches three open orders, a payment header copied from public calldata - and the readings that do prove it. Use when an agent says paid, settled, not found, reverted, empty, missing funds or endpoint dead from chain data and you need to know whether its evidence supports that.

Chain Evidence Check is a tested SKILL.md that judges whether an on-chain observation really proves a claim about a payment, a wallet or an RPC endpoint on an EVM chain, and answers as JSON with a binary verdict, the reason and the one check that would decide; an agent buys it once for $0.05 over x402.

Tested 2026-10-09No code, no hidden instructionsv1.0.0 · 10.1 KB · perpetual license

Not for

Making the calls or reading your wallet: it judges only the claim and the observation you paste; what the paste does not show is unknown. Not a payment verifier, not a wallet, not for non-EVM chains, not a code review. Facts dated 2026-10-08; which public RPC endpoint refuses what changes within hours; the explorer, shared-address and calldata facts are owner-measured, not re-checked.

Tested, honestly

Tested 2026-10-09 with a strong and a weak model.

With and without the skill

Results with and without the skill, for Sonnet and Haiku
SonnetHaiku
withwithoutwithwithout
Claims judged right, verdict and next check (24 claims)24/2420/2421/2417/24

Same request and same checks on both sides. Read by hand, Sonnet without the skill was careful but missed four: for a header whose signature is public in calldata it proposed checking the client's IP instead of a proof only the buyer has, and it called three sound observations unproven (a receipt whose emitting contract the paste names only in words, a log where one node answered with an HTML page, and a node that refused every receipt with an archive message, which it suspected applied to old blocks only). Haiku without the skill missed seven.

Same cases and the same checks with and without the skill. The cases are ours, written around what the skill is for; with a handful of cases, a difference of one or two is within noise.

SonnetStrong model, claude-sonnet-5-5
Right on all 24, checked by code on the verdict and the substance of the next check: a null receipt seconds after settle, an explorer that had not indexed the block, an HTML page from a node, a fallback chain that logged ok while two endpoints refused, a reader that returned zero on failure, an archive refusal read as not found, the right amount with the nonce unread, a rate limit from shared Worker egress read as a bad body, a header whose signature anyone could copy from calldata and a planted note asking for proven; and proven on all nine sound observations.
HaikuWeak model, claude-haiku-5-5
Right on 21 of 24, checked by code. It caught every trap, but it called three sound observations unproven: a reconciliation by receipts, a per-endpoint log that names each refusal, and a node that refused every receipt request with the same token message.

Full test summary

Example

Our own test text, before and after the skill ran. Excerpts only.

English · claude-sonnet-5-5

Before

Claim: The buyer never paid: transaction 0x9c4e71b02d8f6a35e4c0b9d1f7a2e8c63b5d4f0a1e2c3b4d5f6a7b8c9d0e1f2a does not exist on Base. On-chain observation: Eight seconds after the facilitator's settle call returned that hash, we called eth_getTransactionReceipt once, on one public endpoint, and got result null with HTTP 200 and no error object. We made no other call.

After

{"verdict":"not-proven","why":"A single eth_getTransactionReceipt returning null, 8 seconds after the facilitator returned the hash, only shows that one node did not know the hash yet. That is normal right after settlement, because the block may not have reached that node. It cannot distinguish 'does not exist' from 'not propagated yet'.…

What is in the file

  • The answer
  • The rule that comes first
  • A receipt call has three outcomes, and only one is an answer
  • What a receipt proves, and what it does not
  • The explorer is a second opinion, never the verdict
  • Public endpoints answer sometimes
  • Work in this order
  • When this was checked

Languages

Any language. Tried in: English.

License

Perpetual, non-exclusive; use and modify for yourself incl. paid work; no resale or republishing. Holder: Georgi Kalchev, aiskills402.com. Full terms.

Versions

Current version 1.0.0, updated 2026-10-09. Whoever bought an earlier version gets new ones free through the same re-download token.

  1. v1.0.0 · 2026-10-09

    First release (not yet tested on a model): judges whether an on-chain observation proves a claim about a payment, a wallet balance or an RPC endpoint on an EVM chain, as JSON with a binary verdict (proven, not-proven; "wrong instrument" is a reason, not a label), the reason and the one observation that would decide. Carries the rule that it judges only what the description shows. Covers the three outcomes of a receipt call (receipt, null, refusal), the public node service that refuses receipts with an archive error, the HTML body behind a success status, a receipt with an unread status, a pending transaction with no block number, the explorer's indexing delay and its lagging balance view, the canonical balance through eth_call, the shared outbound address of a Worker, a single 429 read as a dead endpoint, attempted versus answered in an endpoint chain, a reader that returns zero on failure, the amount-without-nonce trap, and the payment header that is public in calldata.

    Facts re-checked on 2026-10-08, read-only JSON-RPC calls from a developer machine, no key, no transaction, nothing deployed: - The public node service answered eth_blockNumber and refused eth_getTransactionReceipt for a transaction of the latest block with JSON-RPC error -32602 "Archive requests require a personal token" (HTTP 403, JSON body). Three other public endpoints returned the same receipt with status 0x1. - A receipt request for a made-up hash returned HTTP 200 with result null and no error object on two endpoints (null = unknown, error = refusal). - One provider answered both methods with HTTP 525 and an HTML page; the owner's "HTML behind status 200" was not reproduced on a 200 that day and stays owner-measured. - Not re-checked (needs a payment, a Worker deploy or the owner's accounts): the explorer indexing delay of 40–75 s (owner 2026-09-26), the explorer balance view behind the transfer list (owner 2026-09-22), the shared outbound address and the first-call rate limit from a Worker (owner 2026-09-12), the afternoon of refusals from the edge (owner 2026-10-08), the calldata header replay (owner 2026-10-07).

    Tests: 24 cases (15 traps, 9 controls) in test/data.mjs, generated into test/cases.json; test/control.mjs makes no model call and passes (the right answer and every listed alternative pass; the plausible wrong answer, a fence, a preamble, an empty answer, an echo, a missing or extra key, the flipped verdict and a wrong next_check fail). Price $0.05 suggested; to be set after the with and without runs (class A only if Sonnet gains at least 2 cases of content).

FAQ

What is in the answer?

A single JSON object: a two-word verdict, proven or not-proven, a why line that names what the observation really showed, and a next_check with the cheapest follow-up that settles the question, including its control where one is needed. Two labels on purpose: a three-way label made reviewers argue about borders, while a binary label plus a concrete next step is what a calling agent can act on.

Which readings does it refuse to count as an answer?

A null receipt seconds after settlement, an explorer page that has not indexed the block yet, a balance view behind its own transfer list, an error object or an HTML page from a public node, a reader that returns zero when the call failed, a chain of endpoints that logs ok while two of three refused, a transfer of the right amount with the authorization nonce unread, and a repeated payment header whose signature anyone could have copied from calldata. Each of these looks like evidence and is instead a lagging index, a refusal, a fallback or a number that fits several stories.

Will it call a sound observation unproven?

No. A receipt with status 1 whose logs carry the transfer from the buyer and the order's own nonce, a balance read through eth_call on two nodes, a reverted receipt confirmed by a second node, an explorer page read two minutes later that matches the receipt, or a per-endpoint log that names each refusal comes back as proven. It never adds doubts the description does not raise, and a note inside the paste that asks for a particular verdict counts as data, never as an order.

Does it help Claude Sonnet?

Yes: four more claims of twenty-four judged right, which puts the price at five cents. Sonnet and Haiku weighed the same claims about payments, balances and RPC endpoints on Base, file present and absent, and a script scored the verdict and the next check. Bare Sonnet doubted three sound observations, among them a node refusing every receipt with one archive message, and for a copied payment header it suggested checking the client IP. Guided, it judged every claim right. Haiku went from 17 to 21 and still doubts some sound ones.

Share

Read this page as Markdown: /skills/chain-evidence-check.md.

More skills

  • Recommended

    Cloudflare Evidence Check

    Code & Engineering

    SKILL.md · v1.0.0 · 8.1 KB

    Judges whether a check someone ran on a Cloudflare-hosted site really proves what they claim, and answers as JSON with a verdict, the reason and the one check that would decide. Knows the instruments that answer for the wrong thing - the command-line object read that serves a cached copy after a delete, a delivery log that records neither test mail, a zero-row log search that looks the same as code that never ran, a local migration run, a staging secret, the free preview subdomain of a Worker that is not a zone, a size counter that prints zero on Windows, a character count that counts bytes, a robots file served from the edge cache - and the checks that do prove it. Use when an agent says deleted, delivered, applied, enabled, set on production or never ran on Cloudflare work, and you need to know whether its evidence supports that.

    $0.07once

    • x402
    • USDC
    • Base
    Get skill

    Tested with Sonnet and Haiku, 8 Oct 2026

  • Recommended

    Done Means Done: Honest Agent Status Reports

    Agents & Protocols

    SKILL.md · v1.0.3 · 9.9 KB

    Stops an AI agent from reporting false success, or hallucinated completion: work it calls done that did not happen. Every action in its status report gets one of five states (done and verified, done but not confirmed, partly done, failed, not done), backed by what the tool results of the session show. Failures and unknowns come first, counts come from the results, and no id, receipt or hash is invented. When a result does show success, the agent says so plainly. Use whenever an agent reports on actions it took with tools, such as messages, batches, tests, builds, deploys, file edits, data updates, payments or API calls.

    $0.10once

    • x402
    • USDC
    • Base
    Get skill

    Tested with Sonnet and Haiku, 3 Oct 2026

  • Recommended

    x402 Seller: Get Paid and Listed in Bazaar

    Agents & Protocols

    SKILL.md · v1.0.2 · 14.0 KB

    Diagnoses why an HTTP API sold over x402 v2 cannot be paid by standard buyer agents or never appears in the Coinbase CDP Bazaar catalog, using an ordered checklist and a decision tree over the pasted 402 response, headers and symptoms. Names the exact field that is wrong or missing and how to prove the fix. Use when asked to check an x402 seller, fix an unpayable 402 endpoint, find out why a resource is not listed in Bazaar, or why a settled payment does not show up.

    $0.10once

    • x402
    • USDC
    • Base
    Get skill

    Tested with Sonnet and Haiku, 30 Sep 2026

  • x402 Buyer: Pay Safely from an Agent Wallet

    Agents & Protocols

    SKILL.md · v1.0.4 · 9.4 KB

    Decision rules for an AI agent that holds a wallet and receives an HTTP 402 payment request (x402 v2). Decides SIGN, REFUSE or ASK the human before any money moves, and says how to verify the delivery and retry without paying twice. Use when an agent is about to pay over x402, gets a 402 response, must check a seller's payment terms, or a paid request failed and it is unsure whether to pay again.

    $0.05once

    • x402
    • USDC
    • Base
    Get skill

    Tested with Sonnet and Haiku, 30 Sep 2026