Set a treasury swap’s price boundary before requesting execution. That boundary tells you how much worse the final exchange rate may be than the one you reviewed. If you only swap a few times a year, a written target and a quick quote check can prevent a rushed trade from spending more of the treasury’s value than intended.
Separate price impact from slippage before setting a limit
Price impact is the change in price caused by the size of your trade; slippage is the difference between the price you saw and the price you actually receive. They are related, but a tight slippage setting cannot fix a poor quote or thin liquidity. For a treasury swap, compare the expected output with an independent market reference, then decide the lowest output the team will accept.
For example, if a quote offers 50,000 units of a stablecoin for the treasury’s tokens, a 0.5% tolerance implies a minimum of 49,750 units, before any separate fees. Treat that figure as an illustrative boundary, not a recommended setting. The right limit depends on the trade size, token volatility, available liquidity, and how quickly the team needs execution.
Choose a limit that fits the trade and its deadline
Set the minimum acceptable output in the asset the treasury will receive, and record it in the approval request. A narrow limit protects the exchange rate but may leave the order unfilled; a wider limit makes execution more likely while accepting a worse result. I would decide that trade-off before opening the swap screen, not while a quote is counting down.
For a stablecoin-to-stablecoin trade, the reference price may be close to one-to-one, but token depegs and pool imbalance can make that assumption unsafe. For a volatile-token trade, refresh the reference price immediately before approval and use a deadline that reflects the treasury’s need. If execution is optional, a limit order can wait for the price; if it is time-sensitive, the team may need to accept a wider boundary or reduce the trade size.
Check the quote’s route and execution model
Review the token pair, network, input amount, expected output, minimum output, and any displayed fee before signing. To make that review concrete, compare the quote in cowswap with the treasury’s recorded target, because a batch auction can use solver-chosen routes and the final result must still meet the order’s terms. A displayed estimate is not the same thing as an executed trade.
CoW Swap’s batch auctions collect orders and let solvers compete to execute them using on-chain liquidity; some trades can also benefit from Coincidence of Wants, where orders directly offset one another. That process affects how a swap is routed, but the treasury still needs a clear acceptable output. Check whether the interface shows a minimum received amount or a limit price, and make sure it matches the approved boundary. If it does not, stop and resolve the difference before signing.
Recheck the order before approving it
Before you submit, confirm that the quote is still current and that the approval covers the intended token and amount. Token approvals can authorize a contract to spend tokens, so use the amount needed for the trade if the wallet or interface allows it. A quote that has expired, a changed output, or an unexpected approval is a reason to review the transaction again.
After execution, compare the settled output with the recorded minimum and save the transaction details with the treasury’s records. If the order expires or fails, do not simply loosen the limit: check whether the market moved, the quote was stale, or the size exceeded available liquidity. Then obtain a fresh quote and have the team approve the revised terms.
- Compare the quote with an independent market reference.
- Set and record the minimum acceptable output before signing.
- Check the pair, network, amount, fees, and approval.
- Confirm the settled output or investigate a failed order.
Top comments (0)