A Solver is a specialised participant in an intent-based blockchain system that searches for a way to satisfy a user’s requested outcome under the conditions specified by that user. Instead of receiving a fixed sequence of transactions to execute, a Solver receives an Intent and determines how that outcome can be achieved using available liquidity, routes, inventory, bridges, smart contracts, or other execution resources.
Solvers are particularly important in intent-based decentralised trading and cross-chain systems. A user might request at least 3,000 USDC in exchange for 1 ETH without specifying which liquidity pool should be used. Solvers can evaluate different execution strategies and compete to provide an acceptable or superior result.
This makes the Solver fundamentally an optimisation and execution participant. The Intent describes what the user wants, while the Solver determines how to deliver it. The final actions still settle through blockchain transactions and smart contracts, but much of the routing complexity is transferred away from the user.
What Does a Solver Actually Solve?
The word “Solver” can make the role sound more abstract than it is. In practice, a Solver operates under constraints and searches for an execution strategy that satisfies them while remaining economically attractive.
Consider a user who wants to exchange Token A for at least 5,000 units of Token B. Several decentralised exchanges may offer liquidity, individual pools may have different prices and depths, and splitting the order across venues may produce a better result than routing everything through one pool.
A Solver can evaluate these possibilities before proposing or executing a solution. Depending on the protocol, it may also use its own inventory rather than routing the entire order through public liquidity.
The optimisation problem can include:
- exchange rates available across multiple liquidity venues;
- price impact caused by the proposed trade;
- blockchain gas and execution costs;
- liquidity depth and route capacity;
- user-defined minimum output or maximum input;
- solver inventory available for direct fulfilment;
- cross-chain fees and settlement requirements;
- execution deadlines and changing market conditions.
The “optimal” solution does not necessarily mean the mathematically best price available anywhere in the market. The Solver must operate within the rules of the particular protocol, available liquidity, time constraints, and its own economic incentives.
Different intent systems can also define competition differently. Some choose the solution producing the best user outcome, while others use auctions or protocol-specific mechanisms to determine which Solver receives the right to fulfil an Intent.
How Solvers Compete for Intents
Intent-based systems can create a market in which several Solvers evaluate the same user request. Instead of the application choosing one execution route before the user signs, competing participants can attempt to discover better fulfilment strategies.
A simplified Solver process can work as follows:
- A user signs an Intent containing the desired outcome and execution constraints.
- The Intent becomes available to eligible Solvers through the protocol’s order-distribution mechanism.
- Solvers analyse liquidity, prices, gas costs, inventory, and possible execution paths.
- Each interested Solver determines whether it can satisfy the Intent profitably.
- Solvers submit quotes, solutions, or bids according to the protocol’s competition mechanism.
- A winning solution is selected and the required transactions are executed.
- Settlement verifies that the user’s signed conditions have been satisfied.
This competition can produce better execution because Solvers have an incentive to search beyond a single predetermined route. If one Solver can deliver 5,010 tokens while another can deliver 5,030 under otherwise equivalent conditions, a well-designed auction can favour the second result.
However, competition only works effectively when multiple Solvers can participate on reasonable terms. If one participant controls most relevant liquidity or order flow, the theoretical benefits of an open Solver market can become much smaller.
Solver vs DEX Aggregator vs Searcher
Solvers share some characteristics with other specialised participants in cryptocurrency markets, but their role is distinct.
A DEX aggregator searches across liquidity venues to find routes for a trade. An MEV searcher identifies profitable transaction sequences, arbitrage opportunities, liquidations, or other extractable value. A Solver starts with a user’s desired outcome and attempts to produce an execution that satisfies it.
| Participant | Primary Objective | Main Input | Typical Output |
| Solver | Fulfil a user’s Intent | Outcome and constraints | Valid execution solution |
| DEX aggregator | Find an efficient trading route | Swap request | Routed swap |
| MEV searcher | Capture an on-chain opportunity | Blockchain state and pending activity | Transaction or bundle strategy |
| Market maker | Provide liquidity and prices | Market demand and inventory | Quotes and liquidity |
| Block builder | Construct a competitive block | Transactions and bundles | Execution payload |
These roles can overlap in practice. A Solver may use routing algorithms similar to those of an aggregator, maintain inventory like a market maker, and account for MEV when designing an execution strategy.
The defining feature is therefore not a specific algorithm. It is the relationship to the Intent: the Solver is responsible for finding a valid way to satisfy the user’s signed objective.
Liquidity and Solver Inventory
A Solver does not necessarily have to execute every Intent by sending the user’s assets through a sequence of public liquidity pools.
Some Solvers can use their own inventory. If a user wants to exchange ETH for USDC, a Solver holding sufficient USDC may provide the requested output directly and later rebalance its position elsewhere.
This can be economically attractive when public routing would create significant price impact or when the Solver can rebalance more efficiently than the user could trade directly.
Other solutions may combine several sources. Part of an order could be filled from Solver inventory, while the remainder is routed through one or more decentralised exchanges. The Solver evaluates the complete strategy rather than forcing the user to select each venue.
Access to capital consequently matters. Well-capitalised Solvers can potentially support larger orders, maintain inventory across multiple assets, and execute cross-chain strategies without waiting for every intermediate transfer.
This also creates a competitive issue. Sophisticated Solvers with significant capital, infrastructure, and private liquidity relationships can have advantages over smaller operators, potentially leading to concentration.
Solvers in Cross-Chain Execution
Cross-chain Intents expand the Solver’s task beyond finding the best swap route on a single blockchain.
Suppose a user owns USDC on Ethereum but wants another token on a Layer 2 network. A conventional process could require choosing a bridge, moving assets, waiting for the transfer, and then executing a swap on the destination network.
A cross-chain Solver can potentially abstract much of this process. It may already hold the required destination asset and deliver it to the user according to the Intent, then recover or rebalance its capital through the system’s settlement process.
This model can reduce the amount of infrastructure the user needs to understand. The user defines the desired destination result, while the Solver manages execution complexity.
Cross-chain Solvers must nevertheless account for additional risks. They may need capital on several networks, reliable methods for observing finality, and protection against settlement failures. Gas prices, liquidity, bridge conditions, and blockchain confirmation times can also change while an Intent is being fulfilled.
As a result, cross-chain solving is partly a liquidity-management problem. The fastest route for the user may require the Solver to provide assets before its own capital has been fully rebalanced.
How Solvers Earn Revenue
Solvers are generally economically motivated participants. They need enough revenue to cover infrastructure, gas, capital costs, execution risk, and potential losses caused by market movements.
The exact revenue model varies by protocol. A Solver might retain the difference between the user’s minimum acceptable result and the actual cost of fulfilment, earn an explicit fee, receive auction-related compensation, or profit from efficient inventory management.
For example, assume a user is willing to exchange an asset for at least 1,000 USDC. If a Solver can acquire or provide the required output at an effective cost below the amount available from the user’s input, the difference can contribute to Solver revenue, subject to the protocol’s rules and competition.
Competition can push a portion of this surplus back to users. A Solver offering only the minimum acceptable amount may lose to another participant willing to provide a better price.
This is one reason auction design matters. The protocol determines how Solver competition translates into execution quality and how economic surplus is divided between users, Solvers, liquidity providers, and other participants.
Solver Risks and Market Concentration
Intent systems reduce the need for users to manage execution directly, but they make Solver market structure an important part of protocol quality.
Running a competitive Solver can require sophisticated routing software, low-latency infrastructure, access to multiple liquidity venues, substantial capital, and reliable blockchain connectivity. Cross-chain operations add the need to maintain liquidity and infrastructure across several networks.
These requirements can favour larger professional operators. If only a handful of Solvers consistently win auctions, users may become dependent on a concentrated execution market even when the underlying blockchain is decentralised.
Information asymmetry is another issue. Solvers may have different access to private liquidity, order flow, or market information. Protocol designers therefore need to consider how Intents are distributed and whether all qualified Solvers receive a meaningful opportunity to compete.
There are also execution risks. A proposed route may become unprofitable as prices move, a transaction can fail, or a cross-chain settlement may take longer than expected. Solvers need to price these risks into their strategies while still respecting the user’s constraints.
The security model depends heavily on settlement design. Users should not have to trust a Solver merely because it claims that a route is optimal. Smart contracts and protocol rules should enforce the signed conditions and prevent a Solver from taking assets without delivering the required outcome.
Why Solvers Matter for Intent-Based Systems
Solvers are the execution engine behind many Intent-based architectures. Without them, an Intent would simply describe a desired state without providing a mechanism for discovering how to reach it.
Their value comes from specialisation. Instead of requiring every wallet user to compare liquidity pools, calculate routes, maintain assets across chains, or understand bridge infrastructure, professional participants can perform that work and compete over execution.
This creates a different division of responsibilities from conventional blockchain interaction. Users define acceptable outcomes, Solvers search for ways to fulfil them, and smart contracts enforce the conditions under which settlement can occur.
The model can improve trading execution and make complex cross-chain workflows easier to use, but its effectiveness depends on genuine competition. A diverse Solver market can turn routing expertise, liquidity, and capital efficiency into better outcomes for users. A concentrated market can instead create a new layer of intermediaries with substantial influence over execution.
For this reason, evaluating an intent-based protocol requires looking beyond the user interface. The number of active Solvers, barriers to participation, auction design, settlement guarantees, liquidity access, and distribution of order flow all influence whether the Solver model delivers the efficiency and competition it is designed to provide.