Reports
Investigation rounds on optimising @moromoro/moro-sdk. Each round lives at /report/<n>/.
Is there arbitrage between pools on HyperEVM or BSC? 489 scan rounds, none after gas
Hybra V3 ↔ V4 overnight, every HyperEVM pool pair with optimal sizing, and yuyasugano/pancake-bakery-arbitrage re-run on BSC through the SDK. Cycles profitable before gas appear almost every round, the best under a cent; none survive gas. The repo's own router pairs lose at every size. MoroFlashArb executes on both chains' forks, with the SDK building the Moro router leg.
Report #7SDK 1.4.0: the new BNB router executes 0.0001 % splits
New MoroRouterV1 / MoroSwapV1 / MoroPreTradeV1 on BNB Chain take 1e6-scale volumes. What the fine grid buys (+36.9 bps on a thin trade, ≤ 0.25 bps on liquid pairs), and why the refinement had to become staged (a single jump ran 15 minutes; staged adds ~0.3 s).
Report #6"Splits in splits": what splitting at every hop is worth, and how to get it
Prototype on real state: ≤ 1 bps on liquid trades, +13 / +20 bps on mid-size BNB trades. The router already executes paths sequentially, so phase 1 (sequential simulation + greedy allocation) needs no contract change. Plan, effort, acceptance criteria.
Report #5Gas constants measured on real swaps, and a bug the fork found
Real swaps on Anvil forks: every BNB split swap had reverted since 1.1.0 (fixed in 1.3.3); HyperEVM's per-hop gas re-measured on 15 swaps (mean estimate error 24 % → 12 %, shipped in 1.3.4); what still blocks BNB split constants.
Report #4Best-rate round 3: does a finer split step buy a better price?
0.1 % volume steps gain 0–0.5 bps on liquid pairs and +102 bps on a thin 1,000 ETH → CAKE trade; reached in ~90 ms with a coarse-to-fine search (SDK 1.3.2); blocked on-chain by the router's integer-percent volumes.
Report #3Optimisation round 2: one shared memory for every SDK
SDK 1.3.0 shares what it learns (missing pools, empty pools, decimals) through a built-in Redis, and detects empty pools. A fresh process starts warm: HyperEVM calls −26 %, bytes −26 %, BNB requests −20 %, Δ price 0.00 bps on 18 / 18 cases. Why pool state is not cached (Redis 330 ms away). The built-in credential this round shipped was removed in SDK 1.3.5.
Report #2Optimisation round 1: same prices, 92 % fewer requests
SDK 1.2.0 A/B-tested against the published 1.1.0 at pinned blocks: HyperEVM 26 → 2 requests per quote, wasted calls 735 → 0, BNB calls −34 % and 13–37 % faster, Δ price 0.00 bps on all 18 cases. What changed, what it cost, what is next (shared KV cache).
Report #1Where the SDK's RPC calls really go
74 % of multicall calls on HyperEVM and 36 % on BNB hit pools that do not exist or are empty. Root cause, batch-size findings, the tempting wrong fix (fewer correspondent tokens), ranked plan R1–R10 targeting 26 → 2 requests per quote, and RPC provider options.