Cowswap
Cowswap lets you review a swap before signing and track its settlement.
Last updated -Cowswap presents the swap terms before your wallet authorizes an order. Review the selected tokens, network, amount, minimum output, and recipient before signing. After submission, use the order record to distinguish an open instruction from a completed trade. A wallet signature or approval receipt alone doesn’t confirm that the swap settled. The useful confirmation connects your order to its executed amounts and receiving address, with a separate destination check when the trade crosses networks.
Key takeaway: A signed order authorizes execution, while a matching settlement record confirms the token amounts that actually changed hands.
Fixed Sell Amounts and Fixed Buy Amounts
A sell order fixes the quantity offered for exchange, while a buy order fixes the quantity requested. That difference determines which side of the quote you need to examine most closely. For a specified sell amount, inspect the minimum buy amount. For a specified buy amount, inspect the maximum sell amount that the order permits.
The direction matters when reading an exchange rate, too. Switching from buy tokens per sell token to sell tokens per buy token gives the reciprocal rate. Compare the actual token amounts before relying on the displayed rate. A limit order adds a chosen price and validity period, but this review still starts with the amount that you intend to fix.
The Account and Tokens Behind the Quote
The connected account must hold the selected sell token on the network where the order executes. Check the account address alongside the network selection, especially when your wallet contains several accounts. Token names and symbols don’t uniquely identify contracts. The contract address and network identify the selected token more precisely. A balance on another network doesn’t supply an ordinary same-network swap. Also distinguish the native asset used for network fees from its wrapped token balance; the two can require different approval and submission actions.
Spending Approval and Trade Authorization
A token approval grants spending permission, while the order specifies the trade that you authorize. For ordinary ERC-20 swaps, CoW Protocol uses the GPv2VaultRelayer to pull the sell token during settlement. The allowance must cover the required amount. An existing approval can remove the need for another approval transaction, provided that it still covers the intended trade.
Inspect the spender and allowance in the approval request. A broad allowance extends permission beyond the amount of this particular swap. It doesn’t enlarge the sell amount inside your signed order, but it remains a separate permission. Where the token and wallet support a permit-based approval, the interface can request a signature instead of an initial approval transaction. A gasless approval option therefore depends on compatibility; it isn’t a property of every token or wallet.
Expected Output and the Acceptable Minimum
The expected output describes the quote, while the minimum received amount states the lower output boundary for the specified sell amount. Slippage tolerance allows adverse movement between quoting and execution. Raising it can lower the acceptable output; it doesn’t improve the quoted exchange rate. Price impact concerns how the trade’s size affects available execution prices. A permissive slippage setting doesn’t remove that effect. Read the output after the displayed costs, and inspect the updated amounts whenever you change the input or settings.
The Details Inside the Signature
The order signature covers trading parameters, including the tokens, amounts, recipient, and validity. Wallets that display typed structured data can expose these details for review. Compare them with the intended swap, especially the receiving address. A familiar token pair doesn’t make an unexpected recipient acceptable.
CoW Protocol binds an order signature to its settlement contract deployment on a particular chain. The network context therefore belongs beside the amount and recipient checks. Signing is the authorization boundary: after submission, editing the swap form doesn’t rewrite the existing order. Changed terms require a replacement or a new order, with the original order’s status accounted for first.
Submission and the Order Record
An accepted order enters the order book, where solvers can consider it for execution. Its order identifier lets you follow that instruction without confusing it with an approval transaction.
The activity history and CoW Explorer provide access to the order record. An open status means the order awaits execution. Expired and cancelled statuses describe different reasons why further execution should stop. Neither label, considered alone, explains every earlier event for an order that permits partial fills. Preserve the full order identifier when matching records; a shortened display makes nearby entries easier to scan but contains less identifying information.
An order identifier and a settlement transaction hash serve different purposes. The first identifies your instruction. The second identifies an on-chain transaction that executed a batch of trades.
What Does a Filled Status Confirm?
A filled status confirms execution of the order, and its settlement details identify the transferred amounts and receiving account. In programmatic records, the corresponding completed status can appear as
fulfilled. Match the record to your order before treating that status as confirmation of your swap.
For an ordinary swap that requires a full fill, inspect the settlement transaction associated with the completed order. A partially fillable limit order needs a different reading: one execution can leave an unfilled remainder. Its fill history shows the individual executions and cumulative amounts. A successful transaction attached to one fill doesn’t prove that the entire limit order finished.
Executed Amounts Within a Batch
A CoW Protocol batch settlement can execute multiple orders in one on-chain transaction. The transaction can therefore contain transfers unrelated to your own amounts. Use the batch’s order list to locate your instruction, then examine its sold amount, bought amount, and recipient. Keep the record’s fee definitions in view when reconciling amounts; a field that already includes a fee shouldn’t have that fee added again. The order’s execution details are more useful for this comparison than the transaction’s aggregate token movements.
A Pending Display After Submission
In this hypothetical example, an ordinary same-network swap still appears pending in the browser after submission. You have its order identifier. You could refresh the existing record or sign a newly quoted trade. Both choices concern the same intended exchange, but a new signature could authorize another order while the first remains executable.
Refresh the original order in the activity history or look it up in CoW Explorer before signing another trade. In this example, the record now shows a full fill and supplies a settlement transaction. Its sell token, buy token, amounts, and recipient match the submitted instruction. The receiving account’s token balance reflects the completed transfer.
The pending browser display was stale, so no replacement order is needed. If its record still showed an open order, refreshing alone wouldn’t establish completion or authorize a second trade.
Cancellation Before a Replacement
Cancellation concerns an order that may still execute, so a cancellation request isn’t the same as a confirmed stop. Ordinary orders can support off-chain cancellation through the order service or on-chain invalidation through a transaction. Off-chain cancellation depends on the service processing the request and stops the order book from offering the order for execution; its signature remains valid on-chain. On-chain invalidation prevents further fills once confirmed and requires network fees.
Either method can lose a race against settlement before it takes effect. Check the final order status and any recorded fills before sizing a replacement. Cancellation doesn’t reverse completed token transfers. For a partially filled order, the executed portion remains executed, and only the outstanding portion remains relevant to cancellation. These distinctions prevent a replacement from repeating an amount that the original order already traded.
Destination Receipt for a Cross-Network Swap
A cross-network swap needs confirmation of destination delivery as well as source-chain execution. Its swap and bridge records describe different parts of the transfer. Review the destination network, receiving address, and final minimum amount before authorization. After the swap settles, a bridging-in-progress status still means the destination transfer is unfinished. This cross-network flow supports only off-chain cancellation during the swap phase. Once the swap executes and the Account Proxy submits the bridge deposit, the bridge transfer cannot be canceled. Confirm the final amount at the destination address. If the bridge instead refunds funds to your Account Proxy under its provider’s policy, recover them to your wallet and verify receipt there.
Cowswap: frequently asked questions
Why Does My Signature Request Mention Gnosis Protocol?
The signing domain retains the name Gnosis Protocol from the protocol’s earlier naming. That name alone doesn’t indicate a mismatched request. The signing domain also includes the chain and verifying contract, which identify the deployment. Review those details together with the order amounts and receiver; a familiar domain name by itself doesn’t establish that every parameter matches your intended swap.
Does a Zero Receiver Address Send My Bought Tokens to the Zero Address?
The zero address in a CoW Protocol order’s receiver field means that the order signer receives the bought tokens. It functions as a special value in that specific field. This behavior doesn’t apply to an ordinary token transfer addressed to the zero address. When the order contains a nonzero receiver, that explicit address determines the recipient.
How Can I Find a Swap After Losing Its Order Identifier?
CoW Explorer can search orders by the account address that placed them. Use the relevant network and distinguish the intended order through its tokens, amounts, and submission time. Account history can contain several similar trades, so matching only the token pair can select the wrong record. Opening the matching entry provides its order details and any associated execution information.
Will Rejecting the Order Signature Undo an Earlier Approval?
Rejecting an order signature doesn’t revoke a token approval that already confirmed on-chain. The approval and order authorization are separate actions. An earlier approval transaction can therefore leave an allowance in place even though you never submit the swap. Its network fee also remains spent. Changing that allowance requires a separate approval-management action rather than rejecting the later signature.
Why Can My Native Token Balance Fall Before the Swap Completes?
A native-token swap through Eth-flow deposits the native asset in an on-chain order-placement transaction before the swap settles. That deposit can reduce your wallet balance while the order still awaits execution. This differs from an ordinary ERC-20 order that spends tokens at settlement. An unsuccessful Eth-flow order can require a refund, and the initial transaction’s network fee isn’t refunded with the trading funds.
Does an Expired Limit Order Mean None of It Traded?
An expired limit order can have earlier executions when it permits partial fills. Expiry ends the remaining validity period; it doesn’t undo fills that already settled. Inspect the cumulative sold and bought amounts and the individual fill history. Those records distinguish an entirely unfilled order from one that traded part of its amount before the remaining portion expired.