How Oracle Slippage Limits Work in Chainflip Internal Swaps

A Chainflip internal swap checks the available execution price against a live oracle limit before exchanging assets already held in a Chainflip account. The request names the input and output assets, amount, retry duration and price limits; the State Chain schedules it, then the AMM checks the limit when the swap is due to execute. If the check fails, the protocol can retry instead of accepting a price outside the chosen boundary.

That route skips an external deposit and withdrawal: the output of a successful swap, or refunded input, is credited to the account balance. It is faster to initiate and avoids ingress and egress fees, though a standard two-block delay still applies between scheduling and execution. For a separate look at how chainflip minimums compare with exchange withdrawal costs, see this fuller explanation.

What does the oracle slippage limit check?

The oracle limit compares the AMM’s expected output with the price implied by Chainflip’s oracle for the assets. The LP API accepts this limit as max_oracle_price_slippage, measured in basis points. A basis point is one hundredth of a percentage point, so the setting expresses the maximum permitted deviation from the oracle price.

Think of the oracle as a reference mark beside the AMM’s order book: it gives the protocol a yardstick for judging the offered execution. It does not set the swap price. Liquidity providers’ orders still determine the actual price, and the limit decides whether that price is close enough to the reference to proceed.

This is a relative, live-price guard. It differs from min_price, an absolute floor specified for the swap. Because the oracle reference can move, the same execution price may pass the live limit at one check and fail it later. The internal swap request can include both limits, so the swap must satisfy the configured protections.

What happens when an internal swap breaches the limit?

If the price falls outside the permitted oracle deviation, the AMM does not execute that attempt. The request remains eligible for retries during its configured retry duration. LPs can update their orders while it waits, and a later attempt can pass if the available execution price returns within the limit.

If the retry window ends without a qualifying execution, the unfilled input is refunded to the account balance. That gives the operator a clear choice: tolerate a wider oracle deviation to prioritize execution, or set a tighter limit and accept a longer wait or refund. The limit protects execution quality; it does not guarantee that a swap will complete.

For a DCA request, the swap is split into chunks that execute over time. Price protections apply to each chunk, so one chunk may execute while a later one waits or fails its checks. This can spread execution across changing prices, but a strict limit can also delay the remaining chunks.

How should an operator set the limit?

Set the guard by balancing price protection against the chance of delay. A narrow limit rejects more execution prices; a wider one gives LP orders more room to qualify. The right setting depends on the asset pair, liquidity and how urgently the account needs the swap completed.

• Check that oracle slippage protection is available for both assets in the pair; it is not supported for every asset.
• Use max_oracle_price_slippage for the live relative limit and min_price when the request also needs an absolute price floor.
• Choose a retry duration that gives LPs time to offer a qualifying price, while keeping the wait acceptable.
• For DCA, account for each chunk being checked separately and for the remaining chunks to be delayed if one cannot pass.

These limits are checked at the AMM level. They do not include fees charged outside that layer, so a passing oracle check is not a promise that every cost is covered by the price guard. For an internal swap, the practical benefit is direct: assets already on Chainflip can be exchanged without an external withdrawal, while the operator controls how far execution may depart from the oracle reference and how long the protocol should keep trying.