What We Found Analyzing Real Wallet Activity on Base

We pulled the full transaction history of our own payment wallet on Base. What we found was a window into the real on-chain environment AI agents operate in — including an address poisoning attack we caught in the act.

Most discussions about AI agent security are theoretical. We wanted to show what it actually looks like when you examine real on-chain data. So we analyzed the DJD Agent Score payment wallet — the address that receives x402 micropayments for API calls.

Here is what the data showed, the attack we discovered, and why this matters for anyone building in the agent economy.

The Wallet

Our x402 payment wallet on Base mainnet:

0x3E4Ef1f774857C69E33ddDC471e110C7Ac7bB528

This is the address specified in our fly.toml as the PAY_TO target. Every paid API call routes USDC here through the x402 facilitator. We pulled the full ERC-20 transfer history using Etherscan’s export and Base RPC eth_getLogs queries.

The Real Transfers

The legitimate USDC activity broke down cleanly:

Direction	Amount	Counterparty	Method
IN	24.39 USDC	Coinbase Hot Wallet	Transfer
OUT	5.00 USDC ×3	0x21DD37E3…e7Be10	TransferWithAuthorization
OUT	3.36 USDC	0x930fEb56…CBb7a	TransferWithAuthorization
IN	0.01 USDC	0xfc6087…2B09	Transfer

The initial 24.39 USDC came from Coinbase (tagged as “Coinbase 42” on Etherscan — one of Coinbase’s hot wallets at 0x40EbC1…). The outgoing transfers used EIP-3009 TransferWithAuthorization, which is the mechanism x402 facilitators use to move funds with off-chain signed approvals.

Key insight: TransferWithAuthorization (EIP-3009) is how the x402 protocol works under the hood. The payer signs an off-chain message authorizing a specific transfer, and the facilitator submits it on-chain. This is why you see the facilitator address as the transaction sender, not the actual payer.

The Address Poisoning Attack

Mixed in with the legitimate transfers, we found something else: eight zero-value transfers of a token called “ꝭꝒꝓꝚ” sent to an address that looked almost identical to one of our real counterparties.

The Scam

Address Poisoning via Fake Tokens

Real address: 0x21DD37E3E4eA6CCC0a5C98A4944702eDE6e7Be10

Scam address: 0x21DDF52114F53CcFe37ddd3DC503853B52C6Be10

The attacker created a token with a name that uses Unicode lookalike characters to visually impersonate USDC. The token name “ꝭꝒꝓꝚ” uses characters from the Lisu script (Unicode block U+A4D0) that resemble Latin letters U, S, D, C.

The scam address was chosen to match the first four and last four characters of our real transaction partner. If someone copies the address from their transaction history without carefully checking the middle bytes, they send funds to the attacker.

How Address Poisoning Works

The attack follows a specific playbook:

Step 1: Monitor the mempool for USDC transfers to identify active wallets and their counterparties
Step 2: Generate a “vanity” address that matches the first and last few characters of a real recipient
Step 3: Deploy a fake ERC-20 token that visually mimics USDC (in this case, using Unicode Lisu characters)
Step 4: Send zero-value transfers of the fake token from the target wallet to the scam address, polluting the transaction history
Step 5: Wait for the victim to copy-paste the wrong address from their history

The attacker bears almost no cost — sending zero-value ERC-20 transfers on Base costs fractions of a cent. But a single successful poisoning can yield thousands in stolen funds.

Why This Matters for AI Agents

Here is the thing: AI agents are even more vulnerable to this attack than humans.

When an autonomous agent needs to send funds, it often references recent transaction history to find the right address. If the agent’s address resolution logic does a fuzzy match on “starts with 0x21DD and ends with Be10,” it will match the poisoned address. Unlike a human who might notice the middle bytes look different, a poorly designed agent will happily send real USDC to the scam address.

This is exactly the kind of threat that reputation scoring can help mitigate:

Transaction graph analysis can detect when a wallet’s history contains suspicious zero-value token transfers from unknown contracts
Counterparty scoring can flag addresses that appear in poisoning campaigns across multiple victims
Token contract verification can identify fake tokens that impersonate established assets using Unicode tricks

The Forensic Methodology

We used two approaches to pull this data:

1. Etherscan ERC-20 Export

Etherscan’s token transfer CSV export captures all ERC-20 events for an address. This is the easiest way to see the full picture — including fake tokens that won’t show up in standard wallet UIs.

2. Direct RPC Queries

We queried Base’s RPC endpoint using eth_getLogs filtered by the ERC-20 Transfer event signature:

Topic 0: 0xddf252ad1be2c89b69c2b068fc378daa
         952ba7f163c4a11628f55a4df523b3ef

Filter: address = 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913
        topic1 or topic2 = our wallet address

Filtering by the real USDC contract address is the key differentiator. The RPC query only returns genuine USDC transfers, while the Etherscan export shows everything — real and fake tokens alike. Comparing the two is how we identified the poisoning attack.

What You Can Learn from Your Wallet

If you’re running an x402-enabled agent or API, here is how to audit your own payment wallet:

Export your ERC-20 history from Etherscan/Basescan and look for tokens you don’t recognize
Compare addresses character by character — don’t trust first-4/last-4 matching
Filter RPC logs by contract address to isolate real USDC transfers from noise
Check for zero-value transfers — these are almost always poisoning attempts
Score your counterparties using DJD Agent Score to identify suspicious wallets before transacting

Check any wallet’s reputation score to identify suspicious activity patterns:

Score a Wallet

DJD Agent Score analyzes on-chain behavioral patterns to assign reputation scores to AI agent wallets. Scores are published to the ERC-8004 Reputation Registry on Base mainnet.