Relationship between Solver <-> Searcher <-> and builder

Let’s start with definitions:

To me a:
Solver is an entity, specific to CoW Protocol that is bonded and is trying to create transactions that can settle a CoW Protocol batch with the best prices for the user

Searcher: Takes a number of Ethereum transactions that (if executed in a specific order) will generate some profit. (a bundle)

Builder: Builds a full Ethereum block that might include “bundles” from searchers.

It should be obvious that a COW protocol settlement transaction can be very valuable to a builder/solver. It might generate back-running opportunities (although that means that solvers have failed to find the best route possible which of course should be the goal). But there is another opportunity that is more subtle: a searcher can improve the execution price for the solver by adding a DEX transaction from the public mempool “before” the COW-settlement transaction if the dex transaction trades in the opposite direction of the COW-settlement. As users get fixed prices (shielded from negative and positive slippage) surplus would accrue to the settlement contract and according to CIP-17 (symmetric slippage) ultimately to the solver. However - of course, there could be arrangements between solvers and searchers for the solver to share this extra profit with the searcher. If solvers can regularly make those extra profits it should ultimately lead to better prices for users as solver competition should keep solver profits within limits.

Now - there are different ways to structure the relationship between solver and searcher:

a) trough CoW-protocol
b) directly solver/searcher

In a) solvers would still submit their bids to CoW-protocol but CoW-protocol then sends the actual settlement transaction to a specific searcher/builder (according to rules decided by the DAO)

in b) solvers are allowed (after winning the off competition) to submit the settlement transaction on their own. Therefore it is directly possible for them to submit it via searcher/builder

The disadvantage of a) is that it requires someone (“driver”) to run a central piece of infrastructure. Also, decisions that need to go through the DAO will always be slower than decisions that competitive solvers can do independently. The potential issue with b) is that it might increase the barrier to becoming a successful solver. As it is quite possible that only those with relationships with builders will stay competitive. It is also possible that solvers and searchers/builders will simply become the same entities.

In conclusion, I am in favor of b) but I think it should be in the interest of CoW protocol to make the potential collaboration between solvers and searchers visible and connect parties to not make it an unnecessary barrier to entry for solvers (and searchers as well).


Solver/driver co-location, which allows solvers to manage their submission EOA and strategy, is currently being developed. First tests with external solvers can likely begin in March, so option b) will be possible very soon.


Couldn’t you make option a) more robust and instead of the DAO selecting a specific searcher/builder, you could auction off the right to include the juicy bundle from the solver as part of your block?

Obviously this would add another layer of complexity, but using option B) would centralize solvers more.

In general, I’m trying to figure out how this accounts into the proposal-builder separation design that Vitalik has discussed. Auctioning off the bundle is what Flashbots are doing with SUAVE:

Our goal is to move past the stage of monolithic block builders and toward a world where many searchers/builders with strong geographical distribution collaborate to build the best block together. The most important step for that is to enable the sharing of orderflow/bundles between block builders without leaking their contents.
These three components will be enabled by a specialized SUAVE Chain. The chain will be EVM-compatible and provide the scaffolding for all these components to interact with each other and decentralize over time.

So, even if there is a clear relationship between solver/builder, how does that ensure that block production does not centralize?