Your signature is not a transaction

When you trade on a normal DEX you sign a transaction. The chain executes it. What you signed was a call to a specific contract doing a specific thing at a specific price, and the only ways out are that it executes or it reverts.

When you trade through an intent system you sign something else. CoW Protocol states it plainly:

An intent is not an executable user transaction. It is a signed expression of trading constraints. Solvers compete to construct settlement solutions that satisfy those constraints, and the settlement contract verifies the user's signature and settlement conditions before execution.

That distinction is the whole design, and most of what follows from it. Nobody is bidding to be your transaction. Solvers are bidding to be the one who supplies your transaction, and the rules that decide which of them wins are not all the same kind of rule.

What is actually in the signature

The signed payload is a struct called GPv2Order.Data. Its fields are sellToken, buyToken, receiver, sellAmount, buyAmount, validTo, appData, feeAmount, kind, partiallyFillable, sellTokenBalance, buyTokenBalance.

Two fields carry the price bound. A sell order's limit price is the worst-case exchange rate you will settle for, explicit for limit orders or derived from a quote plus slippage tolerance for market orders. A buy order carries a maximum buy amount plus its limit price. The auction documentation writes the sell order acceptance set as y/π ≤ x: any fill where you receive fewer than x buy tokens for y sell tokens is not your trade.

The number that binds you is afterSlippage, which the intent-formation documentation defines as the final amount after your slippage tolerance has been applied, and states directly:

This is the value signed into the order, it is the minimum the user will receive (sell orders) or the maximum they will pay (buy orders).

So slippage sets a floor on what you accept, not a ceiling. Anything above that floor is surplus, and surplus is where the fee discussion starts.

You can cancel, with invalidateOrder(bytes calldata orderUid) on-chain and setPreSignature(orderUid, bool signed) for pre-signed orders. And it expires, since validTo is the UNIX timestamp until which the order is valid. Neither costs gas.

Who sets the price

Not the user, and not a pool. Solvers do, by competing.

CoW Protocol groups intents into a batch, then runs a competition:

The solver whose solution generates the greatest surplus for the batch is selected to submit the winning settlement solution.

The selection rule has three documented stages. First the protocol computes the best bid on each directed token pair, treated as the best possible execution against outside liquidity. That reference outcome then filters out batched bids scoring worse for a pair. Finally the survivors and the best single-pair bids combine into a winning set, under the constraint that all orders on the same directed token pair land in the same winning bid. The docs call this the Fair Combinatorial Auction, and state its fairness property as: each order receives as much as it would have received had that order been auctioned off alone.

A solver can also match you against another trader instead of routing to an AMM. Opposite sides of the same pair settle peer to peer, never touch on-chain liquidity, and skip LP fees. If only part of your order fills that way, the solver goes on-chain for the rest.

The competition is gated by money. Solvers are described as independent, bonded participants, and the standard bonding pool is funded with $500,000 USD in yield-bearing stable coins and 1,500,000 COW tokens. A reduced bonding pool requires $50,000 in yield-bearing stable coins or ETH and 500,000 COW tokens, ramping to $100,000 and 1,000,000 COW over the following year. Solver membership on the settlement contract allow-list is controlled by a DAO safe, the Solver controller at 0x423cEc87f19F0778f549846e0801ee267a917935, responsible for adding and removing solvers according to DAO-defined bonding rules.

Solvers are paid for winning, on a weekly cycle in COW. The reward is a Vickrey-Clarke-Groves style second-price mechanism:

performanceReward_i = cap(totalScore − referenceScore_i − missingScore_i)

The penalty side is explicit too. If a solver wins and does not settle, it can owe the protocol: the performance reward calculation can result in a negative value, in which case the solver is required to pay the protocol. Each unsettled order carries a penalty cap of min(φ_o × volume_o, c̄), where the global bound c̄ is the native token equivalent of 20 USD.

The economic point is in a note: there is no guarantee that per-auction rewards exceed execution costs, so solvers cover those costs by adjusting their reported score. That adjustment is how the solver's own margin comes out of the same surplus you are competing for.

The surplus split, including the fees

The user-facing line is that surplus belongs to you. The fee page says something more specific, and the fee page is the one with numbers.

Three protocol fee models are currently active. A surplus fee on out-of-market limit orders takes 50% of surplus, capped at 0.98% of total order volume. A quote improvement fee on market orders takes 50% of positive quote improvement, capped at 0.98% of volume. A tiered volume fee applies to all orders: 2 basis points on standard assets, 0.3 basis points on correlated assets such as stables and RWAs.

How the fee is collected matters as much as the rate:

Fees are not charged as separate transfers. They are part of the execution of an order: the user receives less of the buy token (for sell orders) or pays more of the sell token (for buy orders) than they would have in a fee-free execution.

The documentation's worked example matters because of its last line. A user sells 1 ETH and the quote promises 10,000 USDC after network fees. Three policies apply in order: a 50% quote improvement fee capped at 0.98% of volume, a 2 bps protocol volume fee, and a 1% partner volume fee. The user receives 9,902.96901 USDC, with 107.03099 USDC of total fees split as 7.001 USDC protocol and 100.02999 USDC partner. And then:

The last step recovers the fee-free execution of the order: without fees, the user would have received 10,010 USDC for their 1 ETH.

The fee-free execution was 10,010, not the quoted 10,000. The quoted number and the best reachable number are not the same number either. Solvers keep the fee amounts as part of the settlement, and weekly accounting charges them, converted to the chain's native token.

One tension is unresolved in the documentation. The price-improvement page states that all orders can capture surplus and that you receive the difference between quote and execution price, and CoW Swap's interface documentation lists forwarding 100% of order surplus to the user as a feature. The fee page states a 50% surplus fee and a 50% quote improvement fee. No fetched page reconciles them. Read together: surplus is yours, and half of the improvement component is charged as a protocol fee.

Two rules on-chain. Everything else is off-chain or social.

This is the part that should govern how much weight any of the rest carries.

CoW Protocol's competition-rules page sorts its own rules into three classes, and lists exactly two as smart-contract enforced:

• Limit price constraint: an order cannot be executed if its limit price is violated.
• Solver submitting a transaction needs to be whitelisted.

The settlement contract's documented guarantees match that list: the signature matches the user's address, the order is not expired, was not previously filled, and current prices are equal to or better than specified. settle is permissioned, callable only by solvers passing allow-list authentication.

Everything else is elsewhere. Scores, UDCP compliance and winner selection are enforced by the off-chain infrastructure. The rest is governance:

Social consensus rules are not enforced by the smart contract or the autopilot.

CoW Protocol's best-of-baseline-liquidity rule, EBBO, sits in that third bucket: uniform clearing prices should be in line with or better than what users get elsewhere, with Ethereum mainnet baseline liquidity defined as Uniswap v2/v3, Sushiswap, Swapr, Balancer v2 and Pancakeswap against base tokens WETH, DAI, USDC, USDT, COMP, MKR, WBTC and GNO. Enforcement is procedural. Monitoring tools flag settlements, a violation must be certified within 3 months, the accused solver can challenge with a different reference block within 72 hours, and non-compliance means deny-listing plus escalation to a CoW DAO Snapshot vote, which slashes the bond and repays the user if it passes.

That is a functioning accountability system. It is not a contract revert. The difference matters when you decide how much of your order depends on it.

The clearest signed-but-not-enforced case is CoW Hooks. Hook parameters are signed by the user with the order as part of the app data, and pre-hooks execute before any order signature is checked while post-hooks execute after all orders in a batch settle. The reference page states two cautions:

Hook execution is not guaranteed, meaning that your order may still get matched even if the hook reverted.

Hook execution is not enforced by the CoW Protocol smart contracts. Solvers must include them as part of the social consensus rules.

The same page notes that hooks execute through the HooksTrampoline, that anyone can execute calls using it, and that you must not expect a call to the trampoline to be trusted. And appData itself is documented in the settlement contract as "Extra information about the order. Not enforced by the smart contract outside of signature verification."

Who is allowed to compete

Across five systems in this space, three run permissioned or registration-gated solver sets. This is where intent-based execution differs most from the open order book, and it is not usually disclosed in the interface.

UniswapX is the cleanest case, because the documentation says it outright:

UniswapX has one permissioned role (quoter) and one permissionless role (filler).

The quoter row reads "Permissioned, vetted by Uniswap Labs", and the auction-types page explains that because of the nature of the system this set of market makers is permissioned and known to Labs, putting it in one line: "Quoters are permissioned, while fillers are permissionless." The off-chain RFQ winner holds an exclusivity window of about 24 seconds, or 2 blocks, on mainnet, then the order decays into an open Dutch auction anyone can fill. The cosigner sets the window per order, and the Uniswap Interface and API currently set the cosigner to Uniswap Labs. A quoter that wins exclusivity and does not fill is described as "fading" and triggers a circuit breaker.

1inch gates resolvers behind identity verification. The onboarding guide requires KYC or KYB plus a compliance survey and states: "This step is mandatory and no whitelisting will be enabled until the verification and survey have been completed." Approval mints an Access NFT granting order fulfillment. Resolvers can also apply for off-chain auction access, placing them inside the auction's exclusive phase rather than only the decay phase, under an SLA of a 500 millisecond quote response and a minimum 90% fill rate for exclusive orders on a rolling 7 calendar day period. 1inch documents that mechanism as currently in a testing phase. For accuracy: the same documentation states that whitelisting, farming and Unicorn Power-based exclusivity or eligibility mechanisms are currently disabled for Fusion and Limit Orders per 1IP-89, applying only if enabled through a governance vote.

CoW Protocol runs a bonded allow-list maintained by DAO safe, with the amounts stated above. Across documents the opposite: "Running a relayer is permissionless, anyone can operate one," with exclusivity opening to any relayer once it expires. LI.FI requires solvers to register for an API key while leaving integrator endpoints fully open, and describes KYB'd solver networks and integrator-controlled solver selection as features, which is gating under the integrator's choice rather than a fixed protocol allow-list.

The pattern: the venues that advertise the most control over execution quality are the ones that chose who is allowed to compete for it. Nothing here is hidden from anyone willing to read the resolver docs. It is simply not in the swap interface.

What the standard actually promises

ERC-7683 is the attempt to make this interoperable, and it is explicit about its own limits. It is marked Draft, requires EIP-7930, and defines the shape you have been reading about: "An order is an offer of payment in exchange for the fulfillment of a set of requirements."

The non-prescription is deliberate:

Intent protocols also need room to differ in how users create orders, how funds are authorized, how settlement is verified, how prices are determined, and whether execution is escrow-first, fill-first using resource locks, or auction-based. This ERC does not require protocols to use a common escrow, settlement contract, or fill function.

The disclaimer belongs in any honest reading of it:

This ERC standardizes how a protocol describes an order to solvers; it does not standardize or guarantee the security of the protocol that ultimately settles the order.

What it imposes is on solvers, not users. A resolver must guarantee that an order may only abort as explicitly specified in revert policies, and conditions a resolver cannot verify must be surfaced as named assumptions the solver must validate before fulfilling. The security considerations shift timing risk onto solvers too: they are exposed from the time they commit capital, approvals or transactions until their expected payment is final and spendable.

Read that sequence carefully. The standard's protection is aimed at the party filling the order, not the party signing it. A signer gets a limit price and whatever the protocol's social consensus is worth.

What a trader can do with this

Read the fee schedule before the trade, not after. The protocol fee on a market order is 50% of positive quote improvement, capped at 0.98% of volume. That is a real, predictable deduction from the improvement you were shown, and it is charged inside the execution rather than shown as a line item.

Treat your signature as a floor you set, not a trade you made. Nothing commits you to a route, a solver or a moment. The price is discovered after you sign, in a competition you are not party to.

Ask who was allowed to compete. On UniswapX, quoters are vetted by Uniswap Labs. On 1inch, resolvers cleared KYC or KYB and hold an Access NFT. On CoW Protocol, solvers posted a bond and sit on a DAO-controlled allow-list. Each is a deliberate quality choice, and each reduces the number of parties your order is priced against.

Distinguish contract-enforced from consensus-enforced in any claim you read. The limit price is a revert. EBBO is a forum post and a Snapshot vote. Hook execution is neither. CoW Protocol is unusually candid about which side of the line each rule sits on, and that candor is the reason this is checkable at all.

Watch the number that is not the number you were given. A 10,000 USDC quote corresponded to a 10,010 USDC fee-free execution and a 9,902.96901 USDC settled amount. Three different numbers, and only the last one settled.

The wider point

Intent-based trading moved the trust boundary rather than removing it. The user stops signing a route and starts signing a constraint, which is a genuine improvement: the price floor is enforced by a contract, and a failed or cancelled order costs no gas. But the machinery deciding your actual price moved off-chain into a competition, and that machinery is permissioned in three of the five systems examined here, run by a single autopilot per chain that explicitly does not verify that a solver's transaction matches its claimed score, and governed by rules the documentation itself says are not enforced by the smart contract.

None of that is a scandal. It is the cost of the price improvement, and the trade is stated in the same documents. The useful thing is knowing which guarantee you are holding.

Risk note: cryptocurrency trading, leveraged perpetual futures, and automated algorithmic strategies carry significant risk of rapid and total financial loss. Never risk funds you cannot afford to lose completely. Intent and solver-based execution adds counterparty and infrastructure risk beyond spot price exposure: an order may settle at a different price than the quote, a solver competition may produce no acceptable fill, fees are deducted from the execution rather than displayed, and some signed parameters are enforced by off-chain governance rather than by contract code. Nothing in this article is investment advice, a recommendation, or an offer to sell any product.