Which USDC? Contract Addresses, Bridged Tokens and Spoofed Transfers on Base
GetAgentCap team · published 9/30/2026
On-chain, "USDC" is only a symbol string, and anyone can deploy a token that uses it. If you identify an agent's spend by symbol instead of by contract address, you can double-count bridged balances and pick up fake transfers.
The symbol is not the asset
An ERC-20 token's name() and symbol() values are whatever its deployer chose. Nothing stops a new contract from calling itself USDC with 6 decimals.
The only reliable identity is the contract address on a specific chain. Spend tracking should allowlist addresses and ignore symbols completely.
Native USDC versus USDbC on Base
Circle's native USDC on Base is 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913. Circle issues it directly, and it is the token x402 facilitators settle in on Base.
USDbC, at 0xd9aAEc86B65D86f6A7B5B1b0c42FFA531710b6CA, is the older bridged version from before native issuance. It is a different contract with its own balance. Treat it as a separate asset and report it separately, even if you value both at one dollar.
Spoofed and dust transfers
Attackers deploy lookalike tokens and emit Transfer events that appear to involve your agent's address. Sometimes they send dust. Sometimes they emit events that make it look like your agent sent funds.
An ERC-20 Transfer log only shows that a contract emitted an event. If that contract isn't on your allowlist, the event tells you nothing about the agent's real spend.
Address poisoning
A related attack sends zero-value or dust transfers from an address whose first and last characters match a counterparty your agent pays regularly. The goal is to get a human or an agent to copy the wrong address from history.
A tracker should flag new counterparties that share a prefix and suffix with a known one. It should also never show a truncated address as the only identifier.
Filtering on-chain data correctly
When querying logs, filter by the token contract address and the Transfer topic, then by the indexed from and to topics. Do not scan all Transfer events and match on decoded symbols.
Read decimals from your allowlist rather than trusting a contract call. Native USDC and USDbC both use 6 decimals, and a spoofed token can report any value.
Why this matters for budgets
A spend cap that counts spoofed outbound events fires false alerts. One that merges USDbC with native USDC hides which asset actually ran low.
Allowlisting by chain ID and contract address, with each asset reported on its own line, keeps the budget tied to money the agent actually moved.