Slippage Tolerance

Why does a loose slippage tolerance directly become an attack surface for MEV sandwich attacks? How exactly are the two connected?

A sandwich attack's operating principle essentially exploits the gap between your set slippage tolerance and the actual execution price — the looser the slippage tolerance, the larger this exploitable gap becomes; the connection between the two is very direct.

The concrete steps of a sandwich attack: an attacker's bot continuously monitors the pending transaction pool (mempool) on-chain; once it spots a transaction with large-enough size and loose-enough slippage tolerance (e.g., your Agent intends to swap 1 ETH for a token, slippage tolerance set at 3%), the attacker does three things: front-run your transaction by buying the same token first (pushing the price up), letting your transaction execute at an already-inflated price (but as long as the execution price stays within your set 3% tolerance, the transaction still executes successfully, doesn't fail); then immediately after your transaction, the attacker sells off the tokens just bought (after your buy order pushed the price even higher, selling at that higher price for profit). Through this whole process, your transaction genuinely does execute successfully (since the price movement stays within your set tolerance), but the actual amount of tokens you receive is less than you should get at the normal market price — that shortfall is the attacker's source of profit.

Why slippage tolerance is the key parameter attackers target: for this attack to succeed, the prerequisite is 'your transaction can't fail from the price being pushed up' — if slippage tolerance is set very tight (e.g., 0.1%), the attacker's slight price push causes your transaction to revert and fail outright, making the attacker's manipulation attempt wasted effort (they might even lose money, having spent their front-run transaction's block space without profiting from you); if slippage tolerance is set loose (e.g., 3-5%), the attacker has a large manipulation window to push the price up close to that ceiling while your transaction still executes successfully, guaranteeing the attacker's profit. This means how loose or tight your slippage tolerance is directly determines 'whether launching a sandwich attack against you is worthwhile for the attacker' — the looser the tolerance, the larger the potential profit margin, making your transaction a more attractive target for attackers.

If my Agent needs to dynamically calculate slippage tolerance based on market conditions, what data should it reference specifically, and how should this calculation logic be designed?

Dynamically calculating slippage tolerance's core logic is inferring the tolerance from 'roughly what reasonable price fluctuation range this transaction faces under current market conditions,' rather than applying a fixed percentage. Concretely, three data dimensions can be referenced.

Dimension one: the trading pair's real-time liquidity depth. The deeper the liquidity of a trading pair (e.g., a mainstream token paired with a stablecoin, usually with a large liquidity pool), the smaller the price impact of the same transaction amount, allowing a relatively tight slippage tolerance; the shallower a trading pair's liquidity (e.g., a newly listed, low-volume token), the larger the same transaction amount's price impact, requiring a relatively looser tolerance, or the transaction easily fails. Concretely, before submitting a transaction, query the trading pair's current liquidity pool size in real time, calculate 'what percentage of the liquidity pool this transaction amount represents' — the higher that percentage, the higher the needed slippage tolerance should theoretically be.

Dimension two: recent price volatility. You can query this token's recent (e.g., past 1 hour or past 24 hours) price fluctuation range — if recent volatility is sharp, meaning the likelihood of natural price movement between transaction submission and on-chain inclusion is higher, slippage tolerance should be raised accordingly, avoiding transaction failure from normal fluctuation; if recent prices are stable, a relatively tighter tolerance can be used, lowering the risk of MEV attack exploitation.

Dimension three: transaction amount relative to the liquidity pool's proportion (echoing dimension one, but more precise). The larger the transaction amount, the larger the price impact itself, and the higher the needed slippage tolerance should be — but there's an important distinction here: 'price impact caused by the transaction itself' and 'slippage tolerance' are two different concepts. The former is an effect your transaction will definitely have on price (can be precisely calculated in advance); the latter is extra buffer space reserved for 'the market shifting again before your transaction confirms.' Slippage tolerance's calculation should add a volatility-derived buffer on top of the transaction's own price impact, rather than conflating the two.

Concrete implementation recommendation: rather than calculating all this data from scratch yourself, most decentralized exchange interfaces or APIs usually already provide a 'suggested slippage setting based on current market conditions' feature — an Agent can prioritize querying and adopting this suggested value as a baseline, then fine-tune based on its own risk preference (e.g., adding a small safety margin on top of the suggested value), rather than completely reinventing a calculation logic from scratch.

If an Agent's transaction fails because slippage exceeded tolerance, which of the three failure types discussed in the earlier retry-strategy article does this fall under, and how should it be handled?

Strictly speaking, this failure doesn't cleanly fall into any single one of the transient, structural, or loop failure types discussed in the earlier retry-strategy article — a more nuanced judgment logic is needed to decide how to handle it, because the root cause of 'slippage exceeding tolerance' can be either transient market fluctuation or a sustained shift in market conditions, and the two require different responses.

Judgment method: re-query current market conditions to see if the price has stabilized. After a transaction fails due to slippage, don't immediately retry with the original parameters — first re-query the current market price and liquidity status, comparing it to the market conditions at the time the original transaction was submitted. If, upon re-querying, the price has returned close to its originally expected level (indicating the earlier movement was brief and transient), this scenario suits the exponential backoff retry logic mentioned earlier, retrying with the original or a near-original slippage setting; if, upon re-querying, the price shows a sustained, clearly directional movement (e.g., a large transaction permanently shifted the liquidity pool's price, not a transient fluctuation but a new price level), this scenario shouldn't retry with the original parameters — instead, recalculate a slippage tolerance appropriate for the 'new market condition,' or re-evaluate whether this transaction is still worth executing at the new price (for an arbitrage-type transaction, if the price has moved significantly, the original arbitrage margin may have already vanished, and retrying could actually cause a loss).

This judgment logic echoes the earlier principle that 'structural failure needs a changed strategy rather than plain retry': if slippage failure stems from a substantive shift in market conditions, plain retry (even with a looser slippage setting) isn't solving the problem — it's blindly trying to force the transaction to 'execute no matter what,' which could execute the transaction at an already unfavorable price, causing unnecessary loss. A better approach: if several consecutive slippage failures occur and re-querying confirms market conditions have genuinely continued shifting, trigger the degradation path mentioned in the earlier retry-strategy article (e.g., flag it as 'market conditions have shifted, this transaction's necessity needs re-evaluation' rather than indefinitely loosening slippage tolerance to force execution).

An additional cost consideration: a transaction that fails due to slippage, even without successfully executing, usually still consumes some Gas fee (since the transaction is submitted and executes on-chain up to the moment it reverts, this process still consumes computational resources), meaning slippage-failure retries should also apply the 'per-task total-cost cap' design mentioned earlier, avoiding repeated slippage-failure retries accumulating substantial Gas cost while never successfully completing any actual operation.

In a multi-agent system, if Sub-agent A is responsible for judging market timing and Sub-agent B is responsible for actually executing the transaction, who should decide the slippage tolerance?

This question can apply the earlier Handoff entry's principle that 'an execution-type Agent shouldn't rely entirely on the handoff package's conclusion for its final decision.' The answer: Sub-agent A can provide an initial slippage tolerance recommendation, but the final actual value should be re-verified and confirmed by the executing Sub-agent B at the moment of execution, rather than wholesale copying A's number.

Why Sub-agent A alone can't decide: when Sub-agent A judges market timing, it relies on market data it queried at that moment, but between A completing its judgment, handing off the task to B, and B actually submitting the transaction, there may be a time gap (even a short one) — market conditions may have already shifted within that gap. If B directly uses the slippage tolerance written in A's handoff package without re-verifying, it might execute the transaction with a tolerance calculated from an 'already-stale market snapshot' — exactly echoing the earlier Handoff entry's risk that 'information in the handoff package may no longer be current by the time the receiving side uses it.'

Concrete division of labor recommendation: Sub-agent A (judging timing)'s handoff package, beyond the 'recommend executing the transaction' conclusion, should also attach the market snapshot data it used at the moment of judgment (liquidity depth and volatility queried at that time), giving B a basis to judge 'how much time has passed since these data were captured relative to my current execution moment, and whether they're still applicable.' Sub-agent B (executing the transaction), before actually submitting the transaction, should use the dynamic calculation logic from Q2, independently calculating a slippage tolerance based on real-time market data it re-queries at the moment of its own execution, rather than directly carrying forward A's number. If B's recalculated recommended value differs substantially from A's original recommendation (indicating market conditions have shifted significantly within that window), that itself is a signal worth pausing to confirm — it can trigger the earlier-mentioned logic of 're-evaluating whether this transaction should still execute under the new conditions,' rather than blindly forcing the transaction through with the recalculated slippage tolerance.

The core principle this design echoes: slippage tolerance, like any other 'time-sensitivity-critical' parameter, shouldn't be treated as a static value that gets passively passed through a Handoff and used unchanged — it should be re-verified by the executing Agent at the point closest to actual execution. This is a design detail especially worth attention when a task distributed across multiple Agents has high real-time-sensitivity requirements.