The problem with a bare hash

A transaction hash is a terrible answer.

It proves something happened, sure. But what happened? Which contract emitted the signal? Which event name should your agent care about? Which address was the buyer, the payer, the owner, or the recipient?

That gap matters for agents. A router can’t make a good call from 0x9b... alone. An LLM can guess from a block explorer page, but that’s slow, brittle, and easy to misread when the receipt has a stack of logs.

tx-receipt-decode is for the next step after an agent finds or receives a hash. Send the hash and chain. Get back the receipt details in words and fields an agent can route on.

Price: $0.005 per call, paid through x402 in USDC on Base mainnet.

What you send

The call is small on purpose. You need the transaction hash and the chain. 

{
  "tx_hash": "0x5f8f0d0d74b3c3d4b1d4c2f8d0e1a7b9c6a8f2e3b4c5d6e7f8a9b0c1d2e3f4a5",
  "chain": "base"
}

That’s enough for an agent that just watched an address, followed a payment link, or received a hash in chat.

What should the router know before it calls? This endpoint belongs to the edge-market cluster. The registry currently has 680 paid endpoints across 14 clusters, with prices from $0.001 to $5. At $0.005, this is a cheap inspection call. Good fit for triage.

Call it when the transaction matters enough to read, but not enough to hand a user a raw receipt.

What comes back

The useful parts are the decoded logs.

A raw receipt gives you topics and data. That’s fine for a script with ABI context already loaded. It’s less fine for an agent deciding what to do next.

tx-receipt-decode returns the pieces that make the event readable: 

{
  "chain": "base",
  "tx_hash": "0x5f8f0d0d74b3c3d4b1d4c2f8d0e1a7b9c6a8f2e3b4c5d6e7f8a9b0c1d2e3f4a5",
  "status": "success",
  "logs": [
    {
      "log_index": 0,
      "contract_address": "0x0000000000000000000000000000000000000000",
      "contract_name": "ExampleToken",
      "event_name": "Transfer",
      "decoded_args": {
        "from": "0x1111111111111111111111111111111111111111",
        "to": "0x2222222222222222222222222222222222222222",
        "value": "2500000"
      }
    }
  ]
}

Names change the task. Transfer is easier to route than 0xddf252ad.... contract_name helps an agent avoid sending the user a wall of hex. decoded_args lets the next step compare addresses, amounts, and role labels without scraping text.

And yes, keep the raw addresses. Agents need exact values.

Before and after for an agent

Before: 

The transaction 0x5f8f...f4a5 succeeded on Base.

That’s thin. It tells the user almost nothing.

After: 

The Base transaction succeeded. It emitted a Transfer event from ExampleToken:
from 0x1111...1111 to 0x2222...2222 for 2500000 base units.

Now the agent can ask a better follow-up. Did the user expect that recipient? Should it format the token amount? Should it look up the token decimals? Should it pass the decoded event into a payment, portfolio, or alert flow?

The hash started the work. The decoded receipt tells the agent where to go.

Routing rules that work

Use tx-receipt-decode when the user gives a transaction hash and asks any version of “what happened?” Also call it when another endpoint returns a hash and the next action depends on emitted events.

Good triggers: 

Decode this Base tx: 0x...
What did this transaction do?
Which contract events fired in this transaction?
Did this payment emit a Transfer?
Explain this receipt to a non-technical user.

Skip it when the user only wants a block explorer link. Skip it when the task is balance lookup. For contract source review, call a contract-focused endpoint instead.

For LLM routing, the core intent phrase is simple: transaction receipt decoding for EVM chains. Input is tx_hash plus chain. Output is receipt status, logs, event names, decoded args, and contract names.

Where it fits in an x402 flow

A paid agent can chain this cleanly.

First, it receives a hash. Then it pays $0.005 through x402. Then it gets structured receipt data and writes a user-facing answer, or passes the decoded events into the next paid call.

No subscription step. No account setup in the agent path. The payment is attached to the call.

That matters for small tasks. A wallet agent shouldn’t need a monthly plan to decode one Base transaction. A support agent shouldn’t paste a user’s hash into five tabs. A trading agent shouldn’t guess from calldata when the receipt already has the event trail.

One hash in. Named events out.