Grant Title:
CoW BYOS — Bring Your Own Solver
Author:
@bleu @jean-neiverth @jeffersonBastos @yvesfracari @mendesfabio
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. We have completed 12+ grants for CoW Protocol, building core infrastructure and developer tooling across the CoW ecosystem.
Additional Links:
Our work for CoW Protocol includes:
-
[CoW] Offline Development Mode: Self-contained offline environment for CoW Protocol backend engineers. Deep integration with autopilot, driver, baseline solver, and the full CoW settlement stack. Deployed core and periphery contracts (GPv2Settlement, CoWShed, ComposableCoW, HooksTrampoline) on a local chain with deterministic CREATE2 addressing.
-
[CoW] Framework-agnostic SDK: Refactored the CoW SDK into a modular monorepo supporting multiple EVM adapters (ethers v5/v6, viem, wagmi). Deep work inside the CoW SDK internals: order signing, order book, subgraph, composable orders, CoW Shed, bridging, and trading modules.
-
[CoW] Programmatic Orders API: Indexing infrastructure for all programmatic order types — Composable CoW (TWAP, Stop Loss, Perpetual Swap, Good After Time, Trade Above Threshold), flash loan orders, and CoWShed ownership mapping.
-
[CoW] Hook dApps: Suite of hook dApps integrated on the CoW Swap frontend, including the
cow-shedmodule of@cowprotocol/cow-sdk. Developed with direct experience in the CoW Shed contract (a per-user, signature-gated, CREATE2 proxy — the same pattern we adopt for the BYOS Trampoline). -
Silo Finance: For the past year, bleu has been responsible for Silo Finance’s lending protocol backend services and infrastructure. Includes developing, improving, and maintaining a liquidation bot, incentives program, indexers and a public API.
Grant Category:
Core Infrastructure & Solver Development
Grant Description:
CoW DAO’s BYOS RFP describes a bonded solver that opens CoW’s auction to permissionless sub-solvers (participants who compute routes for individual orders and submit signed proposals without bearing the full overhead of becoming a bonded solver). We propose to build the complete BYOS system across all three RFP milestones: a solver engine, Trampoline contract, Escrow contract, public Proposal API, audit remediation, and gnosis + mainnet deployment with live sub-solver onboarding.
Proposed solution
The architecture research and an initial PoC (BYOS crate, sub-solver crate) are already complete. The PoC covers the proposal API skeleton, EIP-712 schema, Trampoline calldata encoding, and a working sub-solver client. This prior work reduces M1 execution risk: the contract interfaces and engine structure are grounded in working code, not only design documents.
The sections below describe our initial set of design decisions. These are subject to change based on reviewer feedback and findings from the testing round. The guiding goal is to ensure a safe, straightforward path for sub-solvers to submit proposals and have them executed.
Trampoline topology: one instance per sub-solver
We will adopt one Trampoline instance per sub-solver address. With a shared Trampoline, residual state (approvals + balance) from one sub-solver’s settlement may become an attack surface for every other sub-solver. Secure shared operation would require enumerating and resetting all touched approvals after every settlement, a guarantee that depends on complete enumeration of every exotic token interaction (rebasing, non-standard approve, Permit2, ERC-777 operator grants) now and forever.
The zero-balance post-condition (sweep any remainder back to GPv2Settlement) is enforced regardless of topology. Per-instance isolation ensures that the un-sweepable residual (simulation != on-chain due to MEV, state changes) can only be drained by the sub-solver who created it.
Additionally, per-instance Trampoline addresses in settlement calldata prove which sub-solver’s route ran, enabling clean attribution for escrow debits without reliance on BYOS’s private records.
Escrow contract
Per-chain, native-token, immutable contract with owner/operator role separation. This minimizes the blast radius of key compromise: if the operator key leaks, debited funds go to the owner (not the attacker), and the owner can replace the compromised operator immediately.
- Owner (secure wallet / multisig): sets operator, configures cooldown, withdraws accumulated debits. All debited funds flow to the owner.
- Operator (EOA in the BYOS service): debits sub-solvers, freezes/unfreezes. Cannot withdraw funds or change configuration.
- Blanket debit authority: depositing grants BYOS standing debit authority up to the sub-solver’s balance. Simpler and lower gas than per-proposal signature verification.
- Withdrawal with configurable cooldown. Freeze blocks
executeWithdrawal()only; it is a withdrawal gate for Track B investigations. - Immutable: no proxy, no admin upgrade key. The code sub-solvers deposit into won’t change.
API & execution authority
Auth. Gated routes require an EIP-712 signature over the request payload, recovered to the caller’s address. The recovered signer is the identity, no separate account field. This is why read/cancel of a sub-solver’s own data is gated (prevents a competitor from listing or cancelling someone else’s proposals), while the per-id status lookup is public.
| Route | Auth | Description | Returns |
|---|---|---|---|
POST /proposals |
gated | Submit a proposal. Body: full interactions array + EIP-712 sig over {orderUidHash, sellAmount, buyAmount, interactionsHash, validUntil, nonce}. |
proposal id |
GET /proposal/{id} |
public | Status of a single proposal. | {id, solver, validUntil, status} |
GET /proposals/{subsolver_address} |
gated | List caller’s active proposals. | [{id, solver, validUntil, status}] |
DELETE /proposal/{id} |
gated | Cancel. | 204 |
interactionsHash = keccak256(abi.encode(interactions))binds the signature to the exact interactions. BYOS simulates/scores the fullinteractionsat ingestion; only the hash enters the signed commitment.
The reasoning behind these choices is:
GET /proposal/{id}receives aproposal_id, not anorder_uid. A sub-solver cares about its own proposal’s status, and receiving every other sub-solver’s proposals for the same order would be noisy and a potential information leak.GET /proposals/{subsolver_address}(gated) returns all active proposals for a given sub-solver. This is the natural query for a sub-solver syncing the status of everything it has posted, without needing to enumerate order UIDs.
Signature-gated Trampoline execution: The sub-solver’s EIP-712 signature commits to the amounts and the interactionsHash. At settlement, the Trampoline verifies keccak256(abi.encode(interactions)) == interactionsHash before executing. This prevents BYOS from fabricating faults: substituting different interactions, triggering a revert, then debiting the sub-solver under Track A. The signed data is in the calldata, recoverable from the tx, making Track A escrow debits indisputable by any third party.
Two-layer rate limiting: IP-based coarse filter (DDoS protection) + signer-based fine limit scaled by escrow balance tier. Sub-solvers below minimum escrow are rejected entirely.
Solver engine
A thin scoring layer serving the /solve hot path entirely from an in-memory cache:
- Pre-ranking:
score = surplus + fee - gasmirrors the driver’s scoring. Returns the single highest-scoring proposal per order UID. - Singleton settlement per sub-solver: We recommend one sub-solver per settlement tx for the initial release. Singleton settlement gives clean attribution for Track A debits and Track B passthrough, simpler escrow accounting (one debit per reverted tx, no partial-revert apportionment), and a smaller audit surface for the Trampoline contract. Same-sub-solver batching (multiple orders from one sub-solver in a single tx) is worth evaluating for capital efficiency, and we plan to study the trade-offs during M1, but we do not want batching complexity to delay or weaken the first BYOS release.
- Each solution’s interactions wrapped in a single
Trampoline_S.execute(signature, interactions)call. The driver sees one interaction per order. - Continuous re-simulation every 3–5 blocks. Permanent drop on revert.
- Self-contained chain monitoring for settlement outcomes (matches settlements to proposals via Trampoline CREATE2 address, triggers Track A escrow debits on revert).
No simulation, no RPC calls, no database queries on the /solve hot path. All expensive work happens at ingestion or during periodic re-simulation.
Settlement value flow
GPv2Settlementpulls user’ssellAmountvia vault relayer.- Intra-interaction:
sellToken.transfer(Trampoline_S, sellAmount)pushes trade capital (not buffers) into the instance. - Intra-interaction:
Trampoline_S.execute(signature, route, buyToken, buyAmount)verifies the sub-solver’s EIP-712 signature, runs the sub-solver’s interactions, then the immutable trampoline code transfers exactlybuyAmountback toGPv2Settlement. GPv2Settlementpays the user from its (now replenished) balance.
The trade is self-funding: if the route produces less than buyAmount, the transfer reverts, the settlement reverts atomically, and BYOS’s buffer is never net-drained by a sub-solver.
Escrow lifecycle & slashing
The escrow and slashing design reproduces CoW Protocol’s existing penalty framework for bonded solvers (Track A for automated, on-chain-verifiable penalties, and Track B for arbitrated fairness violations) and adapts it for the BYOS-to-sub-solver relationship. The core principle is the same: solvers who cause harm bear the cost. However, BYOS introduces scenarios that don’t exist in the standard solver model. For example, a single sub-solver’s bad behavior (e.g., consistently reverting settlements) can trigger a temporary ban on the BYOS solver itself, affecting all other sub-solvers who depend on it. These cascading effects require additional mechanisms, such as proportional escrow debits and sub-solver-level rate limiting, to ensure that one participant’s misconduct doesn’t degrade the system for everyone.
Track A (revert/gas penalties): BYOS-unilateral, immediate. Debits gas + c_l from escrow. Everything on-chain-verifiable: tx receipt, gas cost, Trampoline CREATE2 address proves attribution. 72h dispute window with narrow grounds.
Track B (EBBO/fairness): CoW core team as arbiter. BYOS freezes the sub-solver’s escrow, relays evidence, and gives a 36h challenge window. This mirrors CoW’s own penalty process and ensures BYOS cannot fabricate Track B claims.
Potential driver-side improvements
The current design assumes BYOS operates with an unmodified CoW driver, which is fully feasible. If eventually the bonded solver is able to run its own forked driver, several improvements become feasible:
- Driver already knows whether settlements landed or reverted. Integrating this information in BYOS would eliminate its chain watcher entirely.
- Driver could expose its scoring inputs, or accept a ranked list and encode from the top down until one passes, eliminating the scoring divergence risk.
- If the driver carried a sub-solver tag on proposals, it could merge multiple orders from the same sub-solver into one settlement while keeping different sub-solvers separate, recovering batching efficiency without breaking attribution.
- BYOS re-simulates proposals every 3–5 blocks independently from the driver’s own re-simulation pass. The driver could expose its simulation RPC infrastructure or accept a proposal pool interface, reducing duplicate RPC load.
Observability
Two layers of metrics, exposed via a standard metrics endpoint (Prometheus-compatible):
- API metrics: request success/error ratio, response duration (p50/p95/p99), requests per second, broken down by endpoint and status code.
- Operational metrics: orders settled per day, settlement failure ratio (reverted vs. landed), active sub-solver count, distribution of settled orders per sub-solver, escrow debit frequency, and proposal ingestion-to-settlement latency.
Where solutions live
We propose to develop all Rust components (BYOS API, solver engine, and sub-solver) against cowprotocol/services for dependency reuse, and Solidity components (Trampoline and Escrow contracts) in a new cowprotocol repository, using Foundry and keeping the same standards as cowprotocol/contracts repo.
Sub-solver strategy
The grant includes a baseline reference sub-solver, similar to the example solvers in the cowprotocol/services repo. Its purpose is to exercise the full BYOS flow (proposal submission, Trampoline execution, escrow debit) during integration testing, not to be a production sub-solver.
Future production sub-solvers for specific protocols (COW AMMs, Balancer V3, Ryze Protocol, and others) are outside the grant scope. They are, however, exactly why bleu has a long-term incentive to keep BYOS useful and operated after launch: each integration is a project opportunity that only exists if BYOS works well and has active sub-solvers. That alignment (BYOS must be reliable for bleu’s own future work to have value) is a stronger maintenance guarantee than a grant obligation.
Grant Goals and Impact:
- Permissionless access to CoW solver competition. BYOS lets users, UIs, and external liquidity sources bid on individual orders without the communication, legal, and operational overhead of becoming a fully bonded solver.
- New liquidity sources in the auction. Sub-solvers route through any DEX or protocol, bringing liquidity that current bonded solvers may not cover.
- Self-sustaining system. BYOS participates in the standard CoW reward mechanism, retains 100% of rewards, and should be profitable enough to fund its own operation and maintenance, with no ongoing grant funding needed.
- Open-source infrastructure. All code under an OSI-approved license, enabling the community to audit, fork, and extend the sub-solver model.
Milestones:
| Milestone | Duration | Payment |
|---|---|---|
| M1: Contracts & Design | 6 weeks | 18,000 USDC |
| M2: Solver Engine, API & Staging | 5 weeks | 15,000 USDC |
| M3: Audit Remediation, Gnosis Deployment & Mainnet | 3 weeks | 9,000 USDC |
M1: Contracts & Design (6 weeks, 18,000 USDC)
Deliverables:
- Final design document covering Trampoline topology, proposal schema, escrow interface, fee mechanism, and slashing/attribution policy.
- Initial BYOS app with: proposals API, EIP-712 schema, solve endpoint handler, Trampoline calldata encoding, proposal scoring, order amount matching, working Escrow operator for Track A and Track B.
- Implemented Trampoline contract: per-sub-solver CREATE2 instances, factory deployer, signature-gated
execute, zero-balance sweep, native ETH wrap/unwrap. - Implemented Escrow contract: owner/operator roles, blanket debit, all-or-nothing withdrawal with cooldown, freeze semantics, permissionless debit sweep.
- Full test suite covering: reverting sub-solver scenarios, allowance hygiene, escrow accounting, withdrawal/freeze edge cases, Trampoline isolation, signature verification, and EIP-712 domain separation.
- Audit-ready package. The security audit is expected to begin immediately after M1 completion, running in parallel with M2 development.
Development approach (build-test-finalize):
| Step | Task | Duration |
|---|---|---|
| 0 | Architecture research, initial PoC, and proposal elaboration (already done, charged only if grant is accepted) | 1 week |
| 1 | Initial Escrow and Trampoline contracts | 1 week |
| 2 | Baseline sub-solver: reference implementation for integration testing (not a production sub-solver) | 1 week |
| 3 | Initial BYOS engine with sub-solver API (working end-to-end) | 1 week |
| 4 | Offline-mode test round: threat-model-driven e2e tests (see below) | 1 week |
| 5 | Final Escrow and Trampoline contract incorporating test findings | 1 week |
Offline-mode testing strategy. We developed and maintain CoW Protocol’s Offline Development Mode, a self-contained local environment running autopilot, driver, settlement contracts, and a baseline solver. We will use it to run e2e tests covering:
- Happy paths: proposal submission, acceptance, settlement, escrow accounting for successful trades.
- Malicious sub-solver behavior: proposals that attempt approval backdoors, reentrancy, balance manipulation, or Trampoline state pollution across settlements.
- Malformed orders: invalid EIP-712 signatures, mismatched
interactionsHash, expiredvalidUntil, orders exceeding escrow balance. - Non-profitable orders: proposals that pass gatekeeping but produce less than
buyAmount, triggering atomic revert and verifying no buffer drain. - Track A scenarios: reverted settlements followed by escrow debit, attribution verification via Trampoline CREATE2 address, dispute window mechanics.
- Track B scenarios: simulated EBBO violations, escrow freeze, nested challenge window, and resolution flow.
- Lifecycle edge cases: proposal cancellation during settlement encoding, order filled by another solver between simulation cycles, concurrent proposals from the same sub-solver on the same order.
Findings from this round directly feed the final contract and engine implementations in steps 5–6.
M2: Solver Engine, API & Staging (5 weeks, 15,000 USDC)
Deliverables:
- Final BYOS app with: complete orders validation (hook presence + EBBO checks), rate limiting, continuous simulation, complete settlement watcher, fee mechanism, reserve tracking for Track B cases.
- BYOS solver engine integrated with the CoW driver and autopilot on staging.
- Public Proposal API live with all specified features.
- At least one sub-solver client settling orders on staging.
- End-to-end staging test demonstrating the full sub-solver flow: proposal submission, acceptance, settlement, and escrow debit on revert.
- Deployment documentation and operational runbook.
Development approach:
| Step | Task | Duration |
|---|---|---|
| 6 | Final BYOS engine implementation incorporating M1 findings | 3 weeks |
| 7 | Infra setup + deployment to staging + documentation | 2 weeks |
M3: Audit Remediation, Gnosis Deployment & Mainnet (3 weeks, 9,000 USDC)
Deliverables:
- Security audit findings remediated.
- Contracts deployed and BYOS solver operational on Gnosis Chain before mainnet migration.
- Bonded solver onboarded on Ethereum mainnet.
- At least one external sub-solver onboarded and settling live mainnet orders.
- Operational runbook and monitoring in place.
Development approach:
| Step | Task | Duration |
|---|---|---|
| 8 | Audit findings remediation | 1 week |
| 9 | Gnosis Chain deployment and operational validation | 1 week |
| 10 | Mainnet migration and sub-solver onboarding | 1 week |
Funding Request:
We propose that milestone payments be released upon each milestone’s approval.
Total: 42,000 USDC or other stablecoin.
No COW token vesting is requested for maintenance. BYOS participates in CoW’s standard reward mechanism and should be profitable enough to fund its own operation and maintenance beyond grant completion, consistent with the RFP’s economics model.
Budget Breakdown:
The total cost (42,000 USDC) is calculated at a flat rate of 3,000 USDC per week (M1: 6 weeks = 18,000; M2: 5 weeks = 15,000; M3: 3 weeks = 9,000). The payment schedule is shown below:
- M1: 18,000 USDC. Retroactive compensation for architecture research and PoC, Solidity contract development (Trampoline factory + instances, Escrow), comprehensive test suite, Smart Contract & Backend Engineering work, iterative testing cycle in offline-mode, reference sub-solver baseline, minimal engine for integration testing, design documentation.
- M2: 15,000 USDC. Rust solver engine development (CoW driver/autopilot integration), public API development, staging deployment infrastructure, operational documentation.
- M3: 9,000 USDC. Audit findings remediation, Gnosis Chain deployment and validation, mainnet migration, sub-solver onboarding on mainnet, monitoring and operational runbook.
The budget covers development time across Solidity and Rust engineers, Smart Contract engineer for pre-audit contract validation, and infrastructure costs for staging and mainnet deployment.
Gnosis Chain Address (to receive the grant):
0x5D40015034DA6cD75411c54dd826135f725c2498
Other Information:
- We will work closely with the Core Team Reviewer on open design decisions: Trampoline topology confirmation, EIP-712 schema finalization, rate-limit policy, and any driver-side integration needs.
- The 14 weeks of development time above represent active engineering effort. However, the project includes expected idle periods (waiting for audit results, stabilization time between Gnosis deployment and mainnet migration, etc.) during which we will not bill development hours. The overall project timeline will be longer, as it may include idle periods.
- The security audit itself is expected to be coordinated with CoW DAO (audit cost is not included in this grant).
- We’re happy to answer any questions and iterate on this proposal based on feedback.
Terms and Conditions:
By submitting this grant application, we acknowledge and agree to be bound by the CoW DAO Participation Agreement and the CoW Grant Terms and Conditions.
