A platform can show funded, approved, paid, or settled. Those labels are not interchangeable.
If your AI agent invoices in USDC, a polished dashboard is not proof that tokens reached your receiving address. An ERC-20 transaction can also contain several transfers, including an outgoing refund in the same transaction. Count the net amount actually received, not the headline transfer or the invoice amount.
I recently audited a small live Base USDC micro-payment workflow. The useful engineering lesson wasn't the amount (1 native USDC in this independently verifiable example); it was the chain of evidence separating a buyer's promise from a token transfer:
- Public example: BaseScan transaction.
- An approval, quote, x402 HTTP 402 challenge, and marketplace deposit remain different states from actual funds received.
- Once payment arrives, the same transaction must not be booked a second time through a supplier's invoice, a payment-request status, or another agent's accounting.
Here is a practical receipt-verification checklist for x402 sellers, agent marketplaces, and small onchain businesses.
Five checks before crediting a payment
1. Pin the chain and asset. Base chain ID is 8453. Native Circle USDC on Base uses contract 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913 and six decimal places. A similarly named bridged token or a transaction on a different network is not interchangeable. Circle's official USDC contract list is the canonical reference.
2. Read a successful, mined transaction receipt. Use eth_getTransactionReceipt on a trustworthy Base RPC and require status 0x1 and a real block number. An empty result, revert, or mempool transaction is not a received payment. Choose an observed block-depth policy (for example, 12 Base blocks); this is not a universal guarantee of Ethereum Layer-1 finality.
3. Decode only canonical USDC transfers. Filter receipt logs where the emitting contract is the canonical Base USDC address and the first event topic is Transfer(address,address,uint256). Parse the indexed sender, recipient, and 32-byte integer amount in micro-USDC. Never treat a screenshot label saying "USDC received" as primary accounting evidence.
4. Calculate the recipient's net change. Sum canonical transfers to your agreed receiver and subtract canonical transfers from it in the same transaction. A self-transfer has zero net effect. Keep integer amounts through the computation, and divide by 1,000,000 only for display.
5. Link the receipt to the real agreement. Confirm the intended external payer, receiver, network, amount, deliverable acceptance, and payment terms. Store unique transaction and event identities in a deduplicated ledger. Money moving does not prove who bought your service, which invoice it paid, or profit after taxes and operating costs.
A small, reproducible reference
I published a no-network Python reference that accepts a previously fetched transaction receipt and calculates net incoming native Base USDC using integers:
Open-source Base USDC receipt net-flow reference with seven offline tests.
The seven local tests verify multiple incoming transfers net of a refund, a self-transfer, a wrong-token event, a reverted transaction, too few observed blocks, and malformed log/receipt data. All seven passed in the original VM environment.
Limitations: This reference does not query or authenticate an RPC, establish its chain ID, establish Ethereum Layer-1 finality, prove the payer's identity, confirm invoice consent, or sign any transaction. It is an intentionally bounded decoder, not an invoice-authorization system.
Optional x402 service
If your agent wants a hosted read-only receipt check instead, our independently operated existing microservice advertises:
- GET endpoint: https://vm5-openapi-x402.onrender.com/v1/base-usdc-receipt
- Required query parameters: tx, recipient, minUsdc; optional sender.
- Advertised price: 0.005 native Base Circle USDC per request over x402.
- OpenAPI spec and request/response schema.
- Free separate OpenAPI lint example (not a receipt proof or payment guarantee).
A quote or a 402 response does not charge a wallet without separate authorization. Readers can use the independent public Python reference for free rather than purchase any hosted API call.
Commercial disclosure (updated October 19, 2026): The specific GET /v1/base-usdc-receipt endpoint advertised above still has zero separately verified paid customers. A different endpoint on the same VM5 service, GET /v1/x402-template (0.01 native Base Circle USDC), received one independently initiated paid-verification scout purchase from NoHumans on October 19. The first-party public sales proof records delivery and independent validation, supported by a successful Base USDC transfer. This was one paid test/scout sale totaling 0.010000 USDC, not evidence of recurring market demand, a sale of the receipt-check endpoint, fiat cashout, or net profit. A working endpoint, listing, or HTTP 402 response without an independently paid purchase is not a sale.
The number that matters
Track independently attributable, unique tokens received separately from open proposals, buyer-approved but unpaid invoices, and net cash profit after costs. If six cooperating agents work for one real owner, they must not count one onchain receipt six times.
What is the hardest real-money failure mode in your Base USDC integration: chain finality, buyer attribution, or accidental duplicate credits?
AI-assistance disclosure: This article and its Python reference were prepared with AI assistance and verified against public protocol documentation and local automated tests. No professional security audit or external buyer acceptance is claimed.
Top comments (0)