Solvers are participants or software components in some intent-based systems that construct candidate ways to fulfill users’ signed transaction conditions. Depending on the protocol, a solver may find a route through liquidity, match orders, or assemble a proposed settlement. The term does not describe one universal architecture or guarantee the best possible result.
From User Intent to Candidate Settlement
A user first expresses a desired outcome through transaction intents, such as which assets to trade and the conditions an execution must satisfy. In CoW Protocol, for example, orders are grouped into batches and solvers compete to propose settlements. The settlement contract checks the signed order constraints before execution.
A solver’s proposal is only one candidate. It can use different sources of liquidity or combine compatible orders, depending on the protocol and the order. An auction or selection process then determines which eligible solution is used. Other intent systems may define their own admission, scoring, timing, and settlement rules.
How Solvers Differ from Other Roles
A solver is not automatically the same thing as a searcher extracting MEV, a block builder, a sequencer, or a relayer. A protocol may separate these jobs or combine them. Its documentation should explain who receives intents, who proposes settlements, how proposals are compared, and which contract enforces the user’s conditions.
In CoW Protocol, solver competition is part of an order flow auction: its documentation describes scoring and rules for valid solutions. That is a concrete example, not a definition that applies to every system using the word “solver.”
Limits and Risks
A solver can only optimize within the information, liquidity, deadlines, and rules available to it. A selected proposal does not prove that it is globally optimal across every market or time horizon. A signed limit or other constraint can bound an execution, but it does not ensure that an order will fill.
Users should check which solvers are allowed to participate, how selection works, what order data is exposed, and how settlement is verified. Permissioning, limited competition, failed or delayed execution, liquidity differences, and protocol-specific MEV exposure can all matter. CoW Protocol documents its own protections and competition rules; those claims should not be generalized to every solver system.
Related Terms
See Also
- What Is MEV — And Why Every Ethereum Transaction Is a Game
- Does Ethereum TPS Include Layer 2 Transactions?
- Are Layer 2 Networks Actually Decentralized?
Sources
- CoW Protocol Documentation: Intents — describes signed trading constraints and how solvers compete to construct valid settlement solutions.
- CoW Protocol Documentation: Solver Competition Rules — details protocol-specific eligibility, scoring, winner selection, and settlement constraints.
- CoW Protocol Documentation: Arbitrating Auctions — distinguishes solver engines from the driver that prepares and submits candidate settlements.