Is there arbitrage between pools? 489 scan rounds on HyperEVM and BSC, and pancake-bakery-arbitrage re-run through the SDK

สรุปสั้น: สแกนหา arbitrage ระหว่าง pool ด้วย SDK รวม 489 รอบบนสองเชน: Hybra V3↔V4 ข้ามคืน (158 รอบ), ทุกคู่ pool บน HyperEVM (299 รอบ ประมาณ 7,244 cycle ต่อรอบ) และทำซ้ำ repo pancake-bakery-arbitrage บน BSC (32 รอบ 7,623 cycle ต่อรอบ) โดยใช้ตัวหาขนาดเทรดที่ดีที่สุดของ SDK ไม่มี cycle ไหนได้กำไรหลังหัก gas มี cycle ที่ได้กำไรก่อนหัก gas ทุกรอบ (1,471 บน HyperEVM, 200 บน BSC) แต่มากสุดแค่ $0.0015 และ $0.0074 ขณะที่ gas ต่อธุรกรรมอยู่ที่ $0.0066 และ $0.0134 คู่ router ของ repo ต้นฉบับขาดทุนทุกขนาด (ที่ 1,000 BNB ขาดทุน 83–95%) เพราะ pool นอกจาก Pancake แทบไม่มีสภาพคล่องแล้ว ฝั่ง execution: สัญญา MoroFlashArb ทำงานบน fork ทั้งสองเชน รวมถึง flash จาก CL pool บน HyperEVM แล้วขายผ่าน Moro router แบบ split ที่ SDK สร้าง calldata ให้

In short: across 489 rounds the SDK found cycles that make money before gas in almost every round, and none that survive gas. The largest was $0.0074 on BSC and $0.0015 on HyperEVM, against $0.0134 and $0.0066 of gas per transaction. The 2021 repo's own router pairs lose at every size today. The execution path it sketches, a flash swap repaid in the callback, works on both chains' forks, and with the SDK the second leg can be a full Moro router split.

A cycle is start token → intermediate on one pool, then back on a different pool. Each round fetches pool state once (createRouteScanner + fetchAllReserves), then prices every cycle in memory with the SDK's pool models. The optimizer (optimizeCycleSize) searches the size that maximises profit: a two-leg cycle's profit is concave in size for constant-product and concentrated-liquidity pools and gas does not depend on size, so a ternary search finds the true optimum. BSC rounds took a median of 3.6 s.

Prices between pools on both chains sit within a fraction of a basis point of each other once fees are paid. The optimizer finds a profitable size almost every round, but it is small because a larger trade moves the pool faster than the spread pays. The overnight Hybra run agrees: its closest pairs were USDC/USDM (−$0.002 at $50) and USDC/USD₮0 (−$0.003 at $10). On BSC the recurring closest cycle was BUSD→USDT→BUSD DODO:V1USDT → PNCK:V3F100, best in 20 of 32 rounds.

BSC, last round: the best cycle per start token and mode at $1,000.

yuyasugano/pancake-bakery-arbitrage (2021–22) is a Node loop and a flash-swap contract. On every new BSC block it calls the contract's check() for six hard-coded BNB/BUSD router pairs (Pancake V2 against Panther, Ape and Bakery), asks each router's getAmountsOut for a fixed 1,000 BNB round trip, and when the profit clears $0.60 after gas it sends startArbitrage: borrow BUSD from one V2 pair, sell it on the other router, repay the pair in BNB inside pancakeCall.

The market it was written for is gone

The repo's exact question through the SDK (block 121,752,392, BNB $714.89)

WBNB → BUSD → WBNB on every ordered pair of Pancake V2, Ape, Panther, Bakery and Biswap. At the repo's 1,000 BNB ($715k) the second pool is far too small, so the trip loses most of its value; at 1 BNB it still loses 91–233 bps, and the optimizer finds no profitable size for any pair. A 2,001-point log grid on the closest pair (PANCAKEV2 → BISWAP) peaks at -4.3e-09 BNB for a 0.000001 BNB trade: the only "profitable" size is no trade.

Which pools can lend (read from pool bytecode)

Bugs and risks in the repo

• The block deadline never binds. block.number + process.env.BLOCKNUMBER concatenates a number and the string "3", so block 7920991 becomes 79209913.
• The callbacks trust any caller. pancakeCall and the other eight never check that the caller is a real pair or that the swap was started by the contract, and _data chooses the router the contract approves. Anyone can make it approve a router of their choice for tokens it holds; impact is limited because profit is forwarded to the owner.
• Bakery can only ever be leg 2 (no flash swap), yet two of the six pairs start from Bakery.
• One fixed size per pair. Profit is concave in size; a single 1,000 BNB check says almost nothing about whether a smaller trade pays.
• Two RPC calls per pair per block plus estimateGas, with a 1,500 ms budget that now spans three BSC blocks; prices from CoinGecko every five minutes; an 18-decimal assumption in the profit maths; transactions broadcast to public nodes at +22 % gas, where they can be copied.

Two things learned on the way. getDepositAddress returns Moro's deposit contract for a route, not the pool (3,234 bytes, owner-controlled, calls pool.swap itself), so a flash leg needs the real pool address. And HyperEVM's small blocks carry 3,000,000 gas (measured at the head); a flash cycle with a ten-route split used 711k, so it fits, but a wider split may not.

• React to trades, don't poll. A cycle only opens when a swap moves one pool. Re-price only the pairs touched in the latest block (from Swap events) instead of every pair every round: far fewer pools per fetch, and the check happens while the gap exists.
• Drop pools with no depth. The overnight run found stale prices with nothing behind them; a depth filter ($1,000 vs $100 price ratio) belongs in the registry, not in the report.
• Three legs through routing tokens (A → B → C → A) reach gaps two legs cannot; the scanner API extends naturally.
• Cheaper execution first. Gas is the binding cost on both chains: a lean single-callback contract and fewer split paths move the break-even more than any search improvement.
• HyperCore spot against HyperEVM pools is the venue native to Hyperliquid and was not measured here.