Four decisions shape live oracle slippage protection

A live oracle slippage guard needs four decisions: which price to trust, how old it can be, how far execution may diverge and what happens when a check fails. Together, those rules decide whether a swap proceeds at an acceptable price or reverts before settlement.

Slippage is the price movement between submitting a transaction and its execution; price impact is the effect of the trade itself on a pool’s price. Uniswap’s developer documentation treats them as separate risks and describes minimum output and transaction deadlines as ways to bound execution.

That distinction matters when swaps cross chains, where the route can involve separate settlement steps. For the native-asset mechanics behind one such route, the fuller account of chainflip explains how swaps work without wrapping assets.

Which price should the guard trust?

Use a reference that matches the assets and market the trade actually uses. A feed for a wrapped token may not track its underlying asset exactly, and an exchange pool can be moved by the same trade the guard is checking.

Chainlink’s Data Feeds documentation says feeds aggregate data onchain and recommends checking the specific feed configuration. Uniswap’s v3 documentation describes pool oracles that can provide time-weighted historical prices; averaging dampens brief price moves, but it can also lag a fast market. The better reference depends on whether the guard needs a broad market benchmark or a price tied closely to the execution venue.

How fresh must the oracle price be?

Set a maximum age for the last update, then reject or pause execution when the price is older. Chainlink says Data Feeds update when a deviation threshold is crossed or a heartbeat expires, rather than streaming continuously, and advises consumers to check the update timestamp.

A freshness limit should reflect the asset’s volatility and the transaction’s path to execution. A slower feed may be adequate for a deep, stable market; a volatile asset or delayed cross-chain settlement needs a tighter limit or an additional check. Treating every recent timestamp as safe ignores whether the market has moved since that update.

How wide should the allowed price band be?

Set the maximum permitted difference between the oracle reference and expected execution price, and express it as a minimum output for exact-input swaps. A narrow band limits adverse execution but increases failed transactions; a wide band improves completion odds while allowing a worse fill.

The band must account for ordinary pool price impact as well as movement while the transaction is pending. If it only allows for network delay, a large trade can fail despite an unchanged oracle; if it absorbs large price impact, the guard may approve a poor execution. There is no universal percentage: calibrate against the route’s liquidity, trade size and settlement delay.

What should happen when a check fails?

Make the failure rule explicit: revert, pause, or use a separately validated fallback. For most swaps, reverting is the clearest default because it prevents settlement outside the user’s stated limit. A fallback can keep a service running, but it should have its own source, freshness limit and price band rather than silently widening the original rule.

A practical guard checks these conditions before releasing the trade:

• The feed is for the correct asset pair and network.
• The latest update is within the configured age limit.
• The expected output meets the minimum-output rule.
• The transaction remains valid only until its deadline.

Uniswap’s swap documentation says a deadline makes a pending transaction revert once its validity window expires. At execution, the contract should recheck the price and timestamp, then either settle within the band or revert; that final check is where the four decisions become protection.