How to Use a Base Block Explorer
A Base block explorer, such as Basescan or the Blockscout explorer for Base, shows every transaction, address, token, and contract on the network. Use it to confirm a payment's status, check that the token transferred was native USDC, verify contract source code, and trace where funds went. Always confirm you are viewing Base rather than another network.
Reading a transaction
Paste a transaction hash into the search box and check these fields in order.
Network. Confirm the explorer is for Base mainnet, not Ethereum or Base Sepolia. The same hash format and address format appear everywhere.
Status. Success or failed. A failed transaction still consumed gas and moved no tokens.
Block and timestamp. When it was included. Recent transactions show as confirmed by the sequencer; explorers may separately indicate when the batch was posted to Ethereum.
From and to. For a token transfer, the to field is usually the token contract, not the recipient. The recipient appears in the token transfer section.
Token transfers. The list of tokens that actually moved: sender, recipient, amount, and token contract. This is the section that answers whether a payment arrived.
Transaction fee. The gas cost paid in ETH.
Input data and logs. The function called and the events emitted. Useful when a transaction interacted with a smart account or payment contract rather than a simple transfer.
Smart account transactions look different
When a payment comes from a smart account, the outer transaction is often submitted by a bundler or relayer and calls an entry point contract. The actual transfer appears in the token transfers and logs. Do not conclude a payment came from the bundler address just because it is shown in the from field.
Confirming a USDC payment
Find the token transfer, not just the transaction. A transaction can succeed while transferring a different token, a different amount, or nothing at all to the address you expected.
Check the token contract address. Click the token in the transfer and compare its contract address with Circle's published address for native USDC on Base. Tokens with the same name and symbol can be created by anyone, and a bridged version of USDC also exists on Base under a similar name.
Check the amount and decimals. USDC uses six decimal places. An explorer shows the adjusted amount, but raw values in logs and APIs are integers that need dividing.
Check the recipient. Compare the full address, not just the beginning and end. Address poisoning attacks create lookalike addresses and send tiny transfers so they appear in history.
Check the token page. A token's page shows its contract, holders, and whether the source is verified. A token with few holders and an unverified contract posing as a stablecoin is a warning sign.
Explorers in a payment system
Contract verification. Explorers let developers publish source code matched to deployed bytecode. Read the verified source of any contract you are about to pay or approve. Unverified contracts cannot be read this way.
Address labels. Explorers label some known addresses, such as major contracts and exchanges. Labels are helpful and not authoritative; confirm important addresses from their owners.
Explorer APIs. Explorers offer APIs for transaction and token history, which are convenient for dashboards and alerts. They are rate limited and can lag or go down. A payment system should confirm payments from its own RPC connection or indexer and use explorer data as a secondary check.
Linking in records. Store the transaction hash with every payment record, and generate an explorer link from it for support and audit. That lets anyone see the onchain evidence for a disputed payment in seconds.
Testnet explorers. Base Sepolia has its own explorer instances. Test payment flows there and confirm that the records your system writes match what the explorer shows before enabling mainnet.
For agent payments at volume, explorers are where people investigate. Monitoring and reconciliation should run on your own data, with the explorer as the shared reference everyone can check.
When the explorer and your system disagree
If your system shows a payment the explorer does not, check the network, the transaction hash, and whether the transaction was ever broadcast. If the explorer shows a payment your system missed, check your RPC connection and event subscription for gaps. Either way, the chain is the source of truth, and the discrepancy is a bug to fix.
Frequently asked questions
- What is the block explorer for Base?
- Base has more than one. Basescan, from the team behind Etherscan, and a Blockscout-based explorer for Base are widely used. Both show transactions, addresses, tokens, and contracts on Base mainnet, and Base Sepolia has its own explorer instances for testing.
- How do I confirm a USDC payment on Base?
- Open the transaction on a Base explorer, confirm the status is successful, and find the token transfer section. Check that the token contract matches Circle's published native USDC address on Base, that the amount is correct, and that the full recipient address matches.
- Why does the from field show an address I do not recognise?
- Payments from smart accounts are often submitted by a bundler or relayer that calls an entry point contract, so that submitter appears in the from field. The actual sender and recipient of the tokens appear in the token transfers and logs.
- Should a payment system rely on explorer APIs?
- Not as its only source of truth. Explorer APIs are rate limited and can lag or fail. Confirm payments from your own RPC connection or indexer, use explorer data as a secondary check, and store transaction hashes so anyone can verify a payment directly.