Methodology
Most arbitrage is an accounting error waiting to be discovered.
Comparing two screens produces spreads constantly. Comparing two executions produces them rarely. The entire methodology is designed to keep the platform honest about which of the two it is looking at.
Principles
Six rules the engine is built around.
Executable, never indicative
A mid price is an average of two prices you cannot trade at. Every leg is reduced to the amount actually received for a specific size, from a quoter call or a depth walk.
Cost before conclusion
Nothing is called an opportunity until the entire cost stack has been subtracted. The engine's default answer is no.
Rejection is a result
Rejected candidates are recorded with the reason and the failing input, because the distribution of rejections is the real description of a market.
Provenance on every input
Each cost input is tagged verified or estimated. A calculation built partly on estimates is presented as exactly that.
Invariants over intuition
Balances, quantities and ledger totals are checked against invariants on every simulated fill. A violated invariant discards the result rather than reporting it.
Time is a cost
Between detection and simulated execution the market moves. Candidates are re-quoted and decay is measured, not assumed away.
Pipeline
The five stages, in order.
- 01
Capture
Server-side adapters read Base pools and centralized order books.
- 02
Normalize
Every venue reduced to an executable buy and sell side for a given size.
- 03
Cost
Fees, price impact, depth, gas, latency and buffer subtracted.
- 04
Confirm
The spread is re-quoted; anything that decayed is discarded.
- 05
Simulate
Two-leg paper fill booked against a reconciled inventory ledger.
Cost stack
Theory versus execution reality.
Each subtraction below is computed per candidate, per route and per size. The diagram is schematic: the platform publishes no return figures.
Why most visible spreads are not opportunities
Schematic of the cost stack the engine applies · not a measured return
Inventory
A two-leg trade needs capital on both legs.
This constraint eliminates a large share of otherwise attractive candidates, which is precisely why it is modeled rather than ignored.
Base leg
Simulated on-chain balances in the Base asset and USDC. Swaps consume and produce inventory on this side only.
Exchange leg
Simulated venue balances. A sell needs the asset already on the exchange — capital cannot teleport between legs mid-trade.
Rebalancing burden
Repeated one-directional trades drain one side. The simulator tracks the drift and the transfer cost a real operator would eventually pay.
Simulation
What paper execution means here.
Paper execution is not a spreadsheet of hypothetical profits. It is the same code path a live engine would take, with the final order submission replaced by a simulated fill and a ledger write.
Two legs, in sequence
Both legs are simulated with the timing relationship a real execution would have, including the exposure window between them.
Fills against real depth
Simulated fills consume the depth that was actually quoted, not an idealised infinite book.
Reconciled ledger
Every fill updates two-sided inventory and is reconciled; discrepancies are surfaced, not smoothed.
No custody, ever
No key can move funds. There is no deposit path, no withdrawal path and no order submission path.