What is solver?

A competing participant in an intent-based system that finds a way to satisfy a user's stated outcome and is paid for doing it.

Solvers search across decentralized exchanges, private inventory, and their own balance sheets, and the winning solver is usually the one offering the user the best price. Competition among them is what converts the design into better execution rather than a new middleman. Solver networks vary in openness, and a concentrated set of solvers reintroduces the trust the design set out to remove. See intent and mev.

You will meet the word on trading interfaces that ask what you want rather than which pool to route through. The user-facing promise is that you sign a desired outcome, not a route.

How it works

In the ordinary model you choose a venue and a path, sign a transaction that executes it, and accept whatever the pool holds when the transaction lands. In an intent model you sign a statement of what you will accept: sell this amount of A for at least this much B, before this deadline. That signed object is not itself a transaction and does not commit to any route.

Solvers compete to fill it. Each one searches for the cheapest way to satisfy your constraint and submits a proposed solution, usually into a batch auction. The mechanism selects the solution that pays users best, and the winning solver executes it and keeps the difference between what it found and what it promised you.

Two consequences follow. Because the batch settles together, orders on opposite sides can be matched directly against each other without touching a pool at all, which costs nothing in slippage. And because you never broadcast an executable transaction to a public mempool, the ordinary sandwich attack has nothing to target. See sandwich attack.

The dependency is real. Your outcome now rests on solvers competing honestly. A small or colluding solver set can bid just inside your stated limit and pocket the rest, which is why the openness of the solver set is the property to look at rather than the marketing around it.

Example

Illustrative. You sign an intent to sell 1 unit of A for at least 990 of B. Three solvers bid: one routes through a pool and can deliver 992, one has private inventory and can deliver 996, and one matches you against another user's opposite intent in the same batch and can deliver 999. The third wins and you receive 999. Your floor was 990, so competition moved 9 units to you rather than to whoever filled the order. With only one solver bidding, delivering 991 would have satisfied your constraint and kept the other 8.

Why it matters when you buy

Intent-based venues are one of several ways to buy on chain, and the execution question is the same one that matters on a centralized order book: how much of the quoted price do you actually receive. The liquidity pages show measured spreads and slippage on centralized venues for comparison, and the guide comparing venue types covers the wider choice.

Related terms

• intent — what a solver is filling
• mev — the value competition is meant to return
• sandwich attack — the attack this design avoids
• dex — the venues solvers route through
• slippage tolerance — the equivalent limit on a direct swap
• front running — what a public mempool exposes you to

Questions

Do I pay the solver a fee?

Usually not as a separate line. The solver is paid from the difference between what it achieved and what it promised, which means the fee is embedded in your execution price rather than itemized.

What if no solver fills my intent?

Nothing happens and the intent expires. You keep your funds and pay nothing, which differs from a failed on-chain swap where the gas is spent regardless. See gas.

Is this safer than a normal swap?

It removes public mempool exposure and can improve execution, and it adds reliance on a solver set you do not control. It is a different set of assumptions, not a strictly smaller one.