[RETRO ROUND] Improving Solver Infrastructure Onboarding

CoW Grants Program Retro Round
1

Applicant: BLEU

Program: CoW Grants – Retro Funding Round

Author:

@bleu @yvesfracari @mendesfabio @ribeirojose @jeffersonBastos

About You:

bleu collaborates with companies and DAOs as a web3 technology and user experience partner. We’re passionate about bridging the experience gap we see in blockchain and web3.

Additional Links:

We developed multiple grants with CoW Swap. The ones that are more related to this project are:

  • [CoW] Hook dApps: a set of Hook dApps integrated on the CoW Swap frontend. During this project, we developed the cow-shed module of the @cowprotocol/cow-sdk. This module was created to help developers use CoW Shed to create permissioned hooks.

  • [CoW] Python SDK: we’ve put together a Python version of the CoW TS SDKs to provide developers with que ry on-chain data, manage orders, and integrate with the CoW Protocol’s smart contracts. This gives the team a deep understanding of the CoW TS packages.

  • [CoW] Framework-agnostic SDK: this collaboration enabled the release of v7 of the CoW SDK. The update introduced support for both viem and ethers v6, and merged other repositories (such as app-data and parts of contracts) into the same monorepo, strengthening the developer experience. NPM release

Grant Category:

Core Infrastructure & Developer Tooling

Motivation

The CoW DAO has identified Solver Infrastructure as a key area for retro funding, highlighting the need for updated templates and documentation to lower the barrier of entry for new solver developers (reference).

From our experience setting up solvers, we observed that:

  • Documentation and templates are outdated, creating friction for newcomers.

  • The Python solver template was not functional with the current driver/autopilot.

  • Running a “hello world” solver often requires debugging mismatched schemas, outdated dependencies, and hidden CLI requirements.

  • There is no simple “happy path” workflow — instead multiple terminals, environment variables, and fragile flags must be pieced together.

These gaps make onboarding slow and discouraging. Improving this infrastructure will directly enable more community members to experiment with solvers and contribute strategies.

While we believe the most important improvements are in the Python template (as it is the most outdated one), we are open to addressing issues in other components of the solver ecosystem if necessary.

Proposed Work

We propose to improve solver infrastructure and onboarding through the following preliminary scope. This plan may evolve based on community feedback and as we better understand the needs of solver developers.

We have already started: the solver-template-py has been updated to the new schema, and we are now finalizing the Python Baseline implementation.

  • Update Solver Template

    • Align solver-template-py with the current autopilot/driver schema.

    • Ensure it works out-of-the-box with the services repo.

  • Create Python Baseline

    • Port the existing Rust Baseline concepts into Python.

    • Provide a non-competitive but illustrative solver that developers can use as a reference and benchmark.

  • Examples & Tests

    • Add ready-to-run examples and test payloads aligned with the driver.

    • Include smoke tests and step-by-step instructions to validate setup.

  • Documentation Refresh

    • Update guides with correct shadow URLs, driver flags, and network configuration.

    • Add a troubleshooting section with common errors.

    • Provide clear guidance for running Baseline (Python) + Autopilot + Driver locally.

  • Tooling & Scripts

    • Add Makefile or equivalent scripts to simplify setup and execution.

Milestones

Milestone Description Deliverable
M1 Update solver-template-py to current schema Functional /solve endpoint compatible with driver
M2 Create Python Baseline Reference solver with examples and liquidity stubs (adapted from Rust)
M3 Add Examples & Tests Ready-to-run payloads, smoke tests, instructions
M4 Add Tooling & Scripts Makefile or scripts to run solver + driver + autopilot
M5 Documentation Refresh Consolidated onboarding docs and troubleshooting guide

Expected Impact

  • Faster onboarding: New solver developers can reach “hello world” with fewer blockers.

  • Broader participation: Python-based Baseline lowers the barrier for developers unfamiliar with Rust.

  • Stronger ecosystem: Updated docs and tooling make CoW’s solver infrastructure more resilient and accessible.

  • Increased solver diversity: More solvers means more competition and better outcomes for traders and the protocol.

Timeline

  • September 2025: Finalizing baseline design and updating solver-template-py.

  • October–November 2025: Build Python Baseline, add examples/tests, update docs.

  • December 2025: Evaluation of deliverables and impact by the DAO.

Discussion & References:

4 Likes
2

Hi Bleu team,
Thanks kindly for your retro round submission. For guidance:

  1. It is estimated that smoothing the ability for new solvers to setup / write a new solver may provide some benefit, though at the moment CoW Protocol leads the pack in terms of number of solvers, and the auction performance appears to be relatively robust. Having said this, there is some impact, though it is likely to be low and not necessarily easily measurable.
  2. An idea that we were discussing amongst the committee members is easing the ability for liquidity providers (RFQ, DEX, insert-protocol-type here) into the mix for solvers to be able to access their liquidity would be very handy. As evidenced from products, such as CoW AMM, getting solvers to integrate proves quite painful/difficult. Therefore having some liquidity abstraction / mechanism to bolt in would be good. By achieving large coverage across liquidity sources, the job of the solver comes down more to the math / algorithms as opposed to the task of acquiring routes.

Just some ideas for how to increase impact :grinning_face:

mfw.

1 Like
3

Hey @mfw,

Thanks for the detailed feedback!

We discussed this internally and honestly, we’re struggling to see how this would differentiate from what Tycho has already built. Their product seems pretty solid and already addresses a lot of what you’re describing — might just need the right CoW integration layer to get there.
Given that, we’re not going to pursue this direction right now.

That said, we’re always open to discussing solver onboarding and liquidity improvements, so feel free to reach out if something else comes up!

1 Like