My Arbitrage Journey

Description and use

The author built an automated flashloan arbitrage bot on Arbitrum, but initial tests were misleading due to state contamination. Isolated testing and simulation checks revealed all trades were unprofitable, confirming market efficiency and HFT competition.

Problem

Build a production‑grade flashloan arbitrage bot on Arbitrum and discover why it ultimately fails.

Outcome

The bot initially appeared profitable due to flawed testing, but realistic isolation and fee analysis showed all trades were unprofitable, confirming that DEX‑to‑DEX arbitrage on Arbitrum is dominated by HFT bots and fee structures.

Workflow

• 1. Set up Node.js + Ethers v6 to monitor real‑time prices via WebSockets. 2. Use Balancer V2 for 0% fee flashloans. 3. Write and test Solidity ArbitrageExecutor contract with Foundry. 4. Deploy contract and link to Node.js bot. 5. Run Foundry tests on a forked mainnet; observe initial profit. 6. Identify state contamination by running isolated tests. 7. Build a Node.js scanner to monitor price differences across Uniswap V3, Camelot V3, and PancakeSwap. 8. Add staticCall simulation and minPnl guard to prevent costly failed transactions. 9. Pause bot and analyze lessons learned.

Evidence

I built a Solidity contract that could hold the logic: request a flashloan, swap on DEX 1, swap back on DEX 2, repay the loan, and sweep the profit.

Source

SUCCESS! pnl (wei): 21742847117914354 (A profit of ~$52)

Source

The $52 profit was actually false.

Source

Once I accepted that my test was flawed, I built a Node.js scanner to check the real‑time price differences across Uniswap V3, Camelot V3, and PancakeSwap for multiple mid‑cap Arbitrum tokens.

Source

If I hadn't added that, every time the bot detected a gap, it would send the transaction to the Arbitrum network, fail on‑chain, and burn gas. At $0.10 per failed transaction, it might look small, but it's still data.

Source