Slippage & Budget Caps: Risk Guards That Actually Help

Answer first — Risk guards in MEV are not optional and not generic. The four that matter most: slippage cap per route (defends against pool state moving between simulate and send), per-trade gas budget (defends against priority-fee storms making a trade uneconomic without the strategy noticing), per-session ETH/native budget (defends against bug cascades — when one trade losing turns into 50 trades losing in a row), and canary sizing for any new route or after any model change (defends against the case where everything looks fine in simulation but reality has a hidden gotcha). Set them all, calibrated to your actual strategy economics, and most blow-up scenarios become "lost the canary's worth" instead of "lost the session's worth." Skip any of them and the asymmetry is bad — small upside per trade, unbounded downside on the rare bad day.

Mastery path

• Risk management for MEV trading bots
• Crypto trading bot security best practices
• Desktop vs Telegram security revolution
• Safety & trust report 2026
• Slippage & budget guards (current)

What each cap is defending against

Risk guards aren't a single discipline — each cap defends against a specific failure mode. Setting them generically (one number across all routes) misses the point.

Slippage cap

Defends against: pool state moving between simulate and send.

A swap simulated 200 ms ago against pool reserves R₀ may execute against R₁ where R₁ ≠ R₀ because someone else's trade landed first. The slippage cap is the maximum acceptable difference between simulated and realised output. Tighter cap = more rejected trades but less downside per accepted trade.

Calibration:

• Stablecoin pairs: 0.05–0.1%. State barely moves; tight cap keeps you out of weird moments.
• Major pairs (ETH/USDC, ETH/USDT): 0.3%. Normal liquidity, normal volatility.
• Mid-cap pairs: 0.5%. Acceptable spread.
• Memecoins: 1.0% maximum. Beyond that, the strategy economics don't make sense unless you're sniping at launch (different problem).
• New launches: treat as a different strategy class with its own much higher tolerance, or don't trade at all.

Per-trade gas budget

Defends against: priority-fee storms making a trade silently uneconomic.

You queue a backrun expecting to pay 30 gwei priority fee. By the time you sign, the network is at 200 gwei because of an NFT mint storm. Without a cap, you pay the 200 gwei and lose money. With a cap, the strategy detects the over-budget gas and rejects the send.

Set the cap at roughly the priority fee that would still leave you profitable on this specific trade — not a chain-wide constant. The cap is per-trade, not per-strategy.

Refresh the underlying gas estimate immediately before signing, not at strategy entry. Stale gas estimates are how the cap quietly fails to fire when it should.

Per-session budget

Defends against: bug cascades — one losing trade turning into many.

A single lost trade is signal, not catastrophe. 50 lost trades in a row is something different — usually a model bug, sometimes a chain-wide condition (sequencer outage, fee market regime change, exploit) that means every trade is misvaluing reality.

The per-session budget is the line where you stop trading and investigate. Reasonable defaults:

• First-week sessions: $200 USD-equivalent total session budget. The point is to learn, not to scale.
• Stable production: 5× expected daily PnL of the strategy. If you lose 5 days' worth in a single session, the strategy is broken or the chain is broken.

When the session budget hits, the strategy stops itself. It does not "use the public mempool fallback" or "retry with bigger size" — those are stop-loss rationalisations that turn small losses into big ones.

Canary sizing

Defends against: the model passing simulation but failing reality.

When you deploy a new strategy, change a model, or add a new chain, do not start at full size. Start at one-tenth (or smaller). The canary's job is to expose:

• Hidden execution paths that simulation didn't reach (real wallet permissions, real network conditions, real builder behaviour).
• Latency that's worse in production than in sim because of cloud-provider quirks you don't see in dev.
• Fee mechanics specific to the chain that simulation simplified.

Run the canary for at least 50 trades before scaling up. If the canary's realised-vs-simulated PnL gap is under 10%, the model is honest and you can graduate the size. If the gap is wider, fix the model — don't scale up hoping the gap is statistical noise.

Common mistakes

• One cap across all routes. Stablecoin pairs and memecoin pairs need different slippage caps; one generic value is wrong for both.
• Per-trade gas cap based on the strategy's average, not the specific trade's profit. A strategy averaging $20/trade is fine paying $5 in priority fee for a $25 expected trade and not fine paying $5 for a $7 expected trade. Cap should scale with the trade.
• Session budget that's never been hit, never refreshed. If your session budget never fires, it's set too loose. Tighten it to where it would have fired during the last bad day, then live with the occasional false stop. Stops you can recover from, ruined sessions you can't.
• Canary running for 5 trades and graduating. Five trades is noise; 50 is signal. The full canary discipline matters more on chains where reorgs or sequencer behaviour can mask outcomes.
• Caps configured manually per strategy with no automation. When the chain regime shifts (new fee mechanic post-fork, blob-fee surge era, new validator set), every cap needs a re-evaluation. If the caps are buried in config that nobody maintains, they go stale and stop working.

Working configuration

Reasonable starting setup for a new live strategy:

1. Slippage cap per route (use the table above).
2. Per-trade gas budget = max priority fee that still leaves the specific trade profitable, refreshed pre-sign.
3. Per-session ETH budget at 5× expected daily PnL initially; tightened to the level where it would have caught the worst day in the last month after 30 days of running.
4. Canary sizing at 1/10× until 50 trades show <10% realised-vs-sim gap.
5. Hard stop triggers: simulation reverts > 30% (model bug), realised slippage > 2× cap (pool state weirdness), gas paid > 1.5× cap (cap calibration off).

The FRB Agent wires these into the strategy config so they're enforced at the agent level, not at "I'll remember" level.

Quarterly Cap Review

Risk guards set correctly at strategy launch drift over time as chain conditions evolve — new fee mechanics post-fork, new pool depth, new competition density. Schedule a quarterly review to avoid cap configurations that silently stop working:

1. Pull the worst single-session loss from the prior 90 days. Would the current per-session budget have triggered a stop before that loss reached its final size? If not, tighten the budget. If the budget would have stopped you well before, it may already be set appropriately — don't tighten purely because it never fired.
2. Pull average realised slippage per route across the last 500 trades. Compare to the cap for each route. If average realised slippage consistently runs near the cap ceiling, either the pool is thinner than the model assumed or competitive conditions have worsened — investigate before changing the cap number.
3. Review bundle failure rate trend over the quarter. A rising failure rate with stable strategy parameters usually signals that competitors have improved their sim-to-send speed, shifting the competitive equilibrium. Your latency budget may need attention before cap reconfiguration.
4. Check for protocol changes. Uniswap V4 hooks, new Aave risk parameters, Curve A-parameter changes — any protocol update that affects your strategy's core assumptions should trigger a cap review, not just a calendar review.

Cap calibration is not a one-time setup. It's a maintenance task that pays for itself when it catches the next bad day before it becomes an account-ending event.

References

• Inclusion probability 101
• Fixing failed bundles guide
• Risk management for MEV trading bots
• Reducing gas waste: private bundles vs public auctions
• MEV bot strategy by capital size 2026