A minimum accepted price is the lowest AMM execution rate a swap may accept; one SDK example uses a five-minute retry window before refund eligibility. The limit is checked during execution, after the deposit is witnessed, so it protects against a poor fill at that point rather than guaranteeing the quoted output.
What does the minimum accepted price actually constrain?
It is a floor for the swap’s AMM execution price: available liquidity must produce an equal or better rate for the trade to proceed. A price below the floor causes that attempt to revert, leaving the input available for another attempt while the retry window remains open.
The floor is distinct from a net-output guarantee. Chainflip’s protocol documentation says slippage protection is enforced at the AMM level; deposit, broadcast and broker fees are charged outside it. So a fill that satisfies the AMM price floor can still produce a smaller final wallet balance after fees. Include those costs when deciding whether your threshold protects the outcome you care about.
There are two supported forms of price protection, though oracle protection is not available for every asset:
- Minimum accepted price: the minimum AMM rate or output accepted for the swap.
- Maximum oracle price slippage: a basis-point bound on deviation from the oracle price, when supported.
For a cross-chain swap, this logic runs alongside the protocol’s execution process: validators witness the source-chain deposit, the State Chain schedules execution through the JIT AMM, and the output is sent on the destination chain if the swap succeeds. The Chainflip protocol uses this sort of price floor as a retry-and-refund condition, so it helps to think of the floor and the retry duration as a pair.
What happens after an attempt misses the floor?
The protocol does not accept the below-floor result. It retries the swap after a short block delay, giving liquidity providers another opportunity to price the trade; the first retry in Chainflip’s documented example is scheduled five State Chain blocks after the failed attempt. The retry duration is a block-based window, not a fixed promise about wall-clock completion.
For a regular swap, if an acceptable execution does not happen within that window, the input is refunded to the specified refund address. The refund still takes a source-chain transaction, and the protocol’s documentation says applicable refund and broadcast fees may reduce what comes back. A longer window gives the market more time to meet your floor, but leaves funds pending longer.
With DCA, the rule applies to each chunk. A failed chunk is retried and pushes back later chunks; if it exhausts its retry allowance, that chunk and the remaining input are refunded together. Chunks already swapped successfully still go to the destination address. That partial completion is easy to overlook when estimating how much of the original deposit could be returned.
How should you choose the floor and retry duration?
Set the minimum from your acceptable execution rate, not from a desire to avoid every refund. A floor close to the current estimate rejects smaller adverse moves but can miss during ordinary price movement or thin liquidity. A looser floor is more likely to execute promptly, at the cost of accepting a worse rate.
For example, suppose you split 5 BTC into five 1 BTC chunks and set a minimum of 50,000 USDC per BTC. At 50,100, the first chunk passes; at 49,900, the second fails and retries. If it later executes at 50,070, the swap continues. If it keeps missing until its retry allowance ends, the first chunk’s output is still paid out, while the unswapped 4 BTC is refunded. These figures illustrate the mechanism, not a current quote.
Choose retry time based on how long you can leave the trade pending and how much movement your floor allows. The SDK documentation shows a sample quote recommending 0.5% slippage tolerance and five minutes, but recommendations vary with the quote and market conditions. In repeated use, compare the floor against the estimated AMM rate, then check whether the resulting minimum still makes sense after external fees.
What failure modes change the outcome?
A strict floor can turn low liquidity, a sharp market move or an unusually large order into repeated failed attempts followed by a refund. It does not make the original quote firm, and a retry cannot create liquidity; it only gives the market more blocks to offer an acceptable price. For multi-pool routes, each leg is part of the execution, so a route can fail its price condition even if one pool alone looks adequate.
Before depositing, verify that the refund address is valid for the source asset and chain, and that you can receive a refund there. Also distinguish the AMM price floor from the final amount after fees. The Ethereum.org documentation describes block timing in terms of slots and confirmations; together with the protocol’s block-based retry window, that is why a duration in minutes should be treated as an estimate rather than an exact deadline.
In short, the minimum accepted price decides whether an execution attempt is good enough, while the retry duration decides how long the protocol keeps trying. Tune both to your acceptable net outcome and wait time; with DCA, account for successful chunks as well as the portion that could be refunded.
Top comments (0)