Arb Lab and the spread you keep

Price gaps between two pools look simple. One pool shows one rate, another shows a different rate, so the trade looks obvious. In practice, the visible gap is only the starting point. Size changes the path. Fees stack. The pool you hit first changes what the second pool will quote when you arrive. If you care about execution, you need to separate the displayed spread from the spread you keep.

That is the problem Arb Lab puts in front of you. Its prompt is narrow and useful. Two pools drift apart. How much of the gap is actually yours? For a practitioner, this is the core question in any cross-pool arbitrage model. The answer sits in the mechanics of the pools, the fee model, and the trade size, not in the headline difference between two spot prices.

You do not need to open the page to understand the engineering point. Any system that compares two pools and highlights a spread faces the same failure mode. It reports a gross difference and leaves you to learn, too late, that your own order moves both venues against you. A good tool forces the accounting into the open.

Start with the gross gap, then reduce it

The first thing to inspect in a cross-pool setup is the difference between the observed prices before any trade. This is the gross gap. It is easy to compute and easy to misuse.

If Pool A implies a lower price for an asset than Pool B, the naive plan is clear. Buy in A. Sell in B. The mistake is treating both quoted prices as fixed for the full order. In pool-based systems, they are path-dependent. Your trade changes reserves, so the next marginal unit trades at a worse rate than the first.

This means the gross gap is only a signal to investigate. It is not the answer. A sound model reduces the gross gap by at least four components:

• entry fee on the first swap
• exit fee on the second swap
• slippage in the first pool as size increases
• slippage in the second pool as size increases

If the tool shows you a shrinking edge as you increase size, that is a feature, not a bug. It reflects the shape of the underlying pool function.

For a constant-product pool, the slippage curve is nonlinear. Small trades often look efficient. Larger trades degrade fast. That is why any arbitrage workflow built on top-of-book style spot numbers tends to overstate what you keep.

Verify with reserve math, not intuition

The right way to check an arbitrage estimate is to walk the trade through each pool with the pool formula and fee deduction applied in sequence. Intuition is weak here. Reserve math is concrete.

At a high level, you want to verify three things.

1. The starting reserves in both pools.
2. The fee taken from the input or output side of each swap.
3. The exact order of operations across the two pools.

For a simple constant-product pool, the effective input is reduced by the swap fee. The output amount then comes from the invariant relationship between the input-side and output-side reserves. After the first trade, the reserves are different. Those new reserves define the next marginal price in that pool. The second pool behaves the same way.

A basic verification workflow looks like this:

• record the reserves for Pool A and Pool B
• compute the spot price implied by each reserve ratio
• choose an input size
• subtract the fee according to the pool rule
• calculate output from Pool A using the post-fee input
• feed the output into Pool B, again applying its fee rule
• compare final proceeds against initial cost

If your result differs from the displayed spread by more than a small rounding effect, the gap comes from impact and fees. That is what you want to see surfaced.

This is where many lightweight calculators go wrong. They blend price comparison with profit estimation and hide the transition. A better design keeps these stages separate. First, there is an observed divergence. Second, there is a simulated execution. Third, there is the retained edge after both trades. The user should be able to tell which stage reduced the number.

Read the signal in trade size sensitivity

One of the most useful signals in this class of tool is sensitivity to size. If a small input shows a positive retained edge and a larger input does not, the system is telling you the opportunity is shallow.

That matters because arbitrage is not a binary condition. The question is not whether Pool A and Pool B disagree. The question is over what size range the disagreement survives execution.

A robust arbitrage simulator should help you inspect:

• the break-even size where fees and slippage erase the gap
• the size where profit peaks before declining
• how fast the edge compresses as order size grows
• whether both pools share the same fee rate or not

Even without opening the interface, you can infer what a good implementation demonstrates. It should show that the best trade size is often smaller than users expect. Pushing more volume through a visible spread often harms the outcome because each marginal unit gets a worse route than the last.

This is the same engineering pattern you see in many optimization problems. The visible opportunity is monotonic in one dimension, but the retained value is not. More size does not imply more gain. Systems that fail to model this tend to suggest oversized trades.

Common failure modes in arbitrage tools

Cross-pool arbitrage looks straightforward enough that many implementations stop too early. The common errors are predictable.

Treating quoted prices as executable for full size

This is the main one. A spot price is a local property. It describes the pool before your trade, not after it. Applying it to the entire order inflates expected proceeds.

Applying fees in the wrong place

Fee handling often drifts in small ways with large consequences. Some models subtract a fee once when there are two swaps. Others apply the fee to the wrong side of the trade. In chained execution, these details change the final result.

Ignoring route order

If the setup allows more than one execution order, the sequence matters. Buy-then-sell is not interchangeable with sell-then-buy unless the state transitions are symmetric and the fee structure matches. In pool systems, they often do not.

Hiding the reserve update

When a tool outputs only a final profit number, you lose the ability to audit the path. The reserve change after the first leg is not an implementation detail. It is the core of the estimate.

Forgetting nonlinearity near larger sizes

Linear approximations are fine for tiny trades. They break down as size grows relative to pool depth. If the interface makes a large trade look like a scaled-up small trade, the model is teaching the wrong lesson.

These are not edge cases. They are the default ways this class of system goes wrong. A useful demo counters them by making the shrinkage from gross spread to retained edge visible and reproducible.

What this demonstrates about system design

Arb Lab points at a broader engineering principle. When a system surfaces an apparent edge, it should model the user’s own impact before presenting the edge as actionable. This applies well beyond pool arbitrage.

Any pipeline that starts with a public state and ends with your own transaction needs a transition layer between observation and expectation. In trading systems, that layer includes fees, path dependency, and state mutation. In other domains, it could be queue position, retries, contention, or rate limits. The pattern is the same. Public conditions do not survive contact with your own action.

For practitioners building simulators, screeners, or execution logic, the lesson is simple. Expose intermediate values. Let users verify formulas. Make size sensitivity obvious. Show where the number changed, not only the final number.

That style of design builds trust because the reader can audit the mechanics. It also prevents a common product mistake, where a clean headline metric hides the only part that matters, the amount left after execution.

What to watch next

The next thing to watch in a tool like this is how it handles more realistic friction. The first layer is pool math and swap fees. After that come routing choices, external transaction costs, and state changes between quote and execution. Each layer reduces the share of the visible gap you keep.

If you evaluate systems in this category, focus on whether they make those reductions inspectable. The strongest signal is not a large displayed spread. It is a clear path from observed divergence to retained outcome, with assumptions you can check line by line.