MEV guard — three layers of slippage defense

MEV (Maximal Extractable Value) is the silent tax on every on-chain swap. A trader-MEV-bot pair spots your transaction in the public mempool, front-runs it, lets your slippage execute against their position, and skims the difference. SBO3L's MEV guard is a policy rule that denies any swap intent whose declared slippage exceeds the configured budget.

The rule

[[intents]]
kind = "uniswap.swap"
where.slippage_bps = { lte = 50 }     # 0.5% max
where.recipient = { allowlist = [...] }
require = [{ private_mempool = true, when = { amount_usd = { gt = 5000 } } }]

Three layers stack:

1. Slippage cap — denies anything above 0.5% by default. Most legitimate swaps fit.
2. Recipient allowlist — denies swaps to addresses outside the agent's mandate. MEV exfiltration usually targets attacker-controlled addresses.
3. Private mempool requirement — for higher-value swaps, demand the agent route through Flashbots Protect or similar private RPC. The flag is part of the APRP envelope.

What gets denied

Real cases from the test suite:

• swap @ 25% slippage → policy.deny_mev_slippage
• swap to 0xbeef… (not in allowlist) → policy.deny_unknown_recipient
• $50K swap on public mempool → policy.deny_requires_private_mempool

What this doesn't catch

Sandwich attacks where the bot front-runs and back-runs inside your slippage budget. Mitigation: use private mempools for anything >$5K, which the policy can require. SBO3L can't reach inside the bot's transaction; it can only refuse to sign a receipt for an intent that's structurally vulnerable.