Published on Sat Aug 22 2026 00:00:00 GMT+0000 (Coordinated Universal Time) by Jacob Cavazos

Most DEX trades work the same way they have since 2020. You pick a token pair, the interface builds a transaction that calls a pool contract, you sign a transaction, and it executes on-chain at whatever price the pool offers at the moment it lands. You own the routing, the gas, the slippage, and the MEV risk. If the trade goes badly, that is your problem.

Intent-based execution is a different model. Instead of signing a transaction that specifies how to trade, you sign a message that specifies what you want. You say: “I have 1,000 USDC, and I want at least 0.3 ETH for it.” You do not specify which pool to use, what route to take, or how to handle gas. Someone else figures that out.

That someone else is called a solver. Solvers are off-chain actors who compete to fill your intent at the best price. The winner submits the execution on-chain, and you receive your output token. The competition happens off-chain, in milliseconds, before anything touches the blockchain.

This article explains how intent-based execution works, how it differs from traditional AMM swaps, how solvers compete, and what the trade-offs are. It covers public examples including UniswapX, CoW Protocol, and 1inch Fusion.

The Traditional Model: Transaction-Based Execution

To understand why intent-based execution exists, you need to understand what it replaces.

In the traditional model, the user does all the work. The frontend quotes a price, the user approves the spending, the user signs a transaction that calls a router contract, and the transaction goes into the mempool. The router executes the swap against one or more pools.

Every decision is the user’s responsibility. The route is chosen by the frontend’s algorithm, but the user pays for whatever that route produces. The user pays gas. The user bears slippage. The user is exposed to MEV because the transaction sits in the mempool where searchers can see it and sandwich it.

The user also bears the cost of poor routing. If the frontend picks a suboptimal route, the user gets a worse price. There is no competition for the user’s order. The frontend is a monopoly provider for that trade.

This model works, but it pushes all the execution risk onto the user. The user is a price-taker, a route-taker, and an MEV-taker all at once.

The Intent-Based Model

Intent-based execution flips the responsibility. The user specifies the outcome, and a third party takes responsibility for the execution.

Here is the flow:

1. The user signs an off-chain message describing the intent — for the technical details of how signature relay works, see Permit2 and Gasless Transactions. This includes the input token, the input amount, the output token, and a minimum output amount. The message is not a transaction. It does not go on-chain directly.

2. The signed intent is broadcast to a network of solvers.

3. Solvers calculate the best way to fill the intent. They look at on-chain liquidity, off-chain inventory, and their own strategies. Each solver computes a price they can offer.

4. The best price wins. The winning solver submits an on-chain transaction that executes the trade and delivers the output to the user.

5. The user receives the output token. The user never submitted an on-chain transaction.

The key difference is that the user signs an intent, not a transaction. The intent is a description of a desired outcome. The transaction that achieves that outcome is built and submitted by the solver.

This has several consequences that change the economics of the trade.

What Changes for the User

No Gas for the Swap

In the intent-based model, the solver pays gas for the on-chain execution. The user does not need to hold the native token to swap — this is the same friction point addressed by gasless swaps on Base. The solver’s gas cost is baked into the price they offer, but the user does not need to manage gas directly.

This does not mean gas is free. The solver’s cost is reflected in the price. But it means the user does not need ETH to swap USDC for a token, which removes a friction point.

Built-In MEV Protection

Because the user signs an off-chain message, there is no transaction in the mempool for searchers to sandwich. The solver’s transaction is submitted privately or through a mechanism that prevents front-running. The user’s intent is not visible as a pending swap until the solver’s transaction is already included, which is one of the execution cost advantages over traditional AMM swaps.

This does not eliminate all MEV. The solver’s transaction can still be subject to MEV. But the solver is a sophisticated actor who can use private relays, Flashbots, or other protection mechanisms. The user does not need to think about MEV because the solver absorbs that risk.

Price Competition

In the traditional model, the frontend is the only entity providing a price. In the intent-based model, multiple solvers compete for the same order. This competition pushes the offered price toward the best available execution.

If one solver can fill the order at a better price than another, the better price wins. The user gets the benefit of competition rather than the cost of monopoly.

Surplus Handling

Intent-based systems often have explicit rules about surplus. If the market moves in the user’s favor between intent signing and execution, the surplus may be passed to the user, shared with the solver, or retained by the protocol. The rules vary by system.

This is an important design choice. In the traditional model, surplus stays with the user by default because the user receives whatever the pool price is at execution — but as we explain in understanding DEX aggregator fees, surplus retention is one of the six hidden cost components. In intent-based models, surplus handling is a parameter of the system.

How Solvers Compete

Solvers are the core of the intent-based model. They are off-chain actors who compute optimal execution paths and submit on-chain transactions to fill intents.

A solver’s job is to find the cheapest way to deliver the user’s required output. This involves:

• Scanning on-chain liquidity across all relevant pools and DEXs.
• Considering off-chain inventory. Some solvers hold tokens and can fill from their own balance, avoiding on-chain routing entirely.
• Computing multi-hop routes that minimize total cost including gas.
• Estimating price impact and slippage for each route.
• Bidding a price for the intent.

The solver that bids the best price wins the right to fill the intent. The competition mechanism varies by protocol.

In some systems, solvers submit bids in an auction. The highest-bidding solver wins. In others, the protocol selects the solver that offers the best price to the user directly. The auction design matters because it determines whether solvers are incentivized to reveal their true best price or to shade their bids.

Solvers profit from the spread between the price they offer the user and the actual cost of execution. If a solver can fill the order for less than they quoted, they keep the difference. This is the incentive that drives solvers to find better routes and better execution.

Public Examples

Several protocols implement intent-based execution. Each has a different design, but they share the core pattern of user-signed intents and solver competition.

UniswapX

UniswapX is Uniswap’s intent-based execution layer. Users sign an off-chain order specifying the input and output tokens and the minimum output. Solvers compete to fill the order. The winning solver executes the swap on-chain and delivers the output.

UniswapX routes through both Uniswap pools and external liquidity sources. Solvers can use any on-chain venue to fill the order, which means the execution is not limited to Uniswap liquidity. The system includes a Dutch auction mechanism where the price improves over time if no solver fills immediately, which creates an incentive for fast execution.

UniswapX charges no protocol fee on swaps. Solvers pay gas and compete on price. The user benefits from competition and from MEV protection because the order is not broadcast as a pending transaction.

CoW Protocol

CoW Protocol (formerly CoW Swap) uses a batch auction model. Intents are collected over a short time window, and solvers compete to settle the entire batch. The solver that offers the best total surplus across all orders in the batch wins.

The batch model enables Coincidence of Wants (CoW) matching. If two users want to trade opposite directions, the solver can match them directly without going through an AMM. This avoids pool fees and price impact for the matched portion. The remainder is routed through on-chain liquidity.

CoW Protocol’s batch settlement also provides MEV protection. Because all orders in a batch settle at the same uniform clearing price, there is no ordering advantage to extract. Sandwich attacks are not possible within the batch.

1inch Fusion

1inch Fusion is 1inch’s intent-based mode. Users sign an order with a price that decays over time, starting at a favorable level and becoming less favorable if no solver fills it. This Dutch auction structure incentivizes solvers to fill quickly at the best price.

Solvers compete to fill Fusion orders using 1inch’s routing across all integrated DEXs. The decaying price mechanism means that if a solver can fill at the initial price, they will do so immediately. If not, the price decays until a solver finds it profitable.

Fusion orders include MEV protection because they are not broadcast as pending transactions. The solver’s execution transaction is submitted privately.

How It Differs From AMM Swaps

The differences between intent-based execution and traditional AMM swaps can be summarized:

Who builds the transaction. In an AMM swap, the user’s frontend builds the transaction. In intent-based execution, the solver builds the transaction.

Who pays gas. In an AMM swap, the user pays gas. In intent-based execution, the solver pays gas.

MEV exposure. In an AMM swap, the user’s pending transaction is visible and sandwichable. In intent-based execution, the user signs an off-chain message with no mempool exposure.

Price discovery. In an AMM swap, the price is whatever the pool offers at execution time. In intent-based execution, the price is determined by solver competition.

Routing. In an AMM swap, the frontend’s router determines the route. In intent-based execution, each solver computes their own route, and the best route wins.

Surplus. In an AMM swap, surplus stays with the user. In intent-based execution, surplus handling depends on the protocol’s design.

The Trade-Offs

Intent-based execution is not strictly better than traditional AMM swaps. There are trade-offs.

Latency. Intent-based execution adds a round of off-chain communication. The user signs an intent, solvers compute bids, and the winner executes. This takes time. For most trades, the latency is acceptable. For trades that need immediate execution, the delay can be a disadvantage.

Solver centralization. The solver market is competitive in theory but can concentrate in practice. Running a profitable solver requires infrastructure, low-latency access to chain data, and inventory. If only a few solvers can compete effectively, the price competition weakens.

Complexity. Intent-based systems are more complex than direct AMM swaps. The user is trusting a protocol and a set of solvers to execute correctly. While the smart contracts enforce the minimum output, the user is relying on the system’s auction design and solver incentives to produce good prices.

Liquidity dependence. Solvers still route through on-chain liquidity. If the on-chain liquidity is thin, the solver cannot magic a better price. Intent-based execution improves the execution process, but it does not create liquidity that does not exist.

When Intent-Based Execution Helps Most

Intent-based execution provides the most value in specific scenarios:

• Large trades where MEV risk and price impact are high. Solver competition and private execution reduce MEV extraction.
• Cross-chain or multi-hop trades where optimal routing is complex. Solvers can compute routes that a frontend might miss.
• Trades where the user does not want to hold gas tokens. The solver pays gas.
• Trades on pairs with fragmented liquidity. Solvers can aggregate across venues more effectively than a single router.

For small, simple trades on liquid pairs, the difference between intent-based and traditional execution is smaller. The overhead of solver competition may not produce a meaningfully better price.

The Direction of the Market

Intent-based execution is becoming the default for sophisticated DEX users. UniswapX, CoW Protocol, and 1inch Fusion all represent a shift away from the user-as-executioner model toward the user-as-intent-signer model.

The reason is simple. The traditional model asks the user to bear every execution risk: gas, slippage, MEV, routing. The intent-based model transfers those risks to solvers who are better equipped to manage them. Solvers have infrastructure, inventory, and expertise. Users have a wallet and a signed message.

This does not mean traditional AMM swaps will disappear. They remain the fallback execution mechanism that solvers themselves use to fill intents. The AMM is the liquidity layer. The intent-based system is the execution layer on top of it.

The future is likely a mix. Users will sign intents for most trades, and solvers will route through AMMs and other venues to fill them. The user interacts with the intent layer. The solver interacts with the liquidity layer. The separation of concerns is the point.

Orkid is building in this intent-based execution space. You can read more at orkidlabs.xyz. But the model described above is general. It applies to any protocol that uses signed intents and solver competition. Understanding the model is more useful than understanding any single implementation, because the model is where the industry is heading.

Frequently Asked Questions

What is intent-based execution?

Intent-based execution is a trading model where a user signs an off-chain message specifying what they want, such as a minimum output amount for a given input, rather than specifying how to execute the trade. A third party called a solver determines the optimal execution path and submits the on-chain transaction. The user never interacts with the blockchain directly.

How do intent-based swaps work?

Intent-based swaps work by having the user sign a message defining their swap constraints, which is then broadcast to a network of competing solvers. Solvers evaluate the intent, determine the best execution route, and submit settlement transactions. The winning solver executes the trade and delivers the output tokens to the user’s wallet.

What is a solver in DeFi?

A solver is a participant in an intent-based execution system that fills user-signed intents by finding and executing the optimal transaction path. Solvers compete with each other to offer the best price, which benefits the user. Solvers pay for gas and bear execution risk, earning profit from any surplus between the user’s minimum price and the actual execution price.

Are intent-based swaps safe?

Intent-based swaps are generally safe because the user’s signed message enforces strict output constraints that cannot be violated by the solver. The cryptographic signature ensures the solver cannot take the user’s tokens without delivering the specified minimum output. The main risk is that an intent may go unfilled if no solver finds it profitable, requiring the user to resubmit.

Written by Jacob Cavazos