RFP: Bring Your Own Solver (BYOS)

CoW Grants Program
1

RFP: Bring Your Own Solver (BYOS)

Summary

CoW DAO seeks a grantee to build a “Bring Your Own Solver” (BYOS) solver: a bonded solver that participates in the standard CoW auction and whose proposed solutions are sourced from a permissionless set of external sub-solvers. Sub-solvers submit signed routing proposals against specific order uids, collateralized by an escrow balance held by BYOS, and BYOS retains exclusive control over on-chain settlement submission. Deliverables are a solver engine, a Trampoline contract for safe sub-solver execution, a per-chain native-token escrow contract, and a public proposal API.

Background

Becoming a fully bonded CoW solver carries communication, legal, and operational overhead that only well-resourced entities can clear today. There is demand from less professionalized participants who want to bid on individual orders without that overhead: users and UIs that want execution against a baseline they have computed themselves, external parties that want to bid on individual trades without RFQ or KYC, and liquidity sources that want their pools considered in the auction. BYOS lets all three participate by collecting permissionless sub-bids and encoding them into standard CoW auction settlements. BYOS itself is bonded, liable for any damage, earns standard rewards, and should be operable as a standalone profitable business.

High-Level Design

A sub-solver computes a route for a specific order UID and submits a signed proposal to BYOS. BYOS continuously simulates pending proposals. On a /solve request, BYOS selects from proposals that still simulate successfully and crafts a settlement that transfers sellAmount from GPv2Settlement to the Trampoline, invokes the sub-solver’s interactions inside the Trampoline, and pulls buyAmount back. The Trampoline holds no protocol balance, so a malicious sub-solver cannot exfiltrate buffers or plant persistent approvals against settlement-controlled funds. Settlement reverts atomically if the promised buy amount is not delivered.

image
image1159×438 13.6 KB

Scope

In scope: solver engine integrated with the CoW driver and autopilot, Trampoline contract, per-chain native-token escrow contract, public proposal API with EIP-712 signed submissions, reference sub-solver client, and operational runbook and monitoring. v1 targets Ethereum mainnet and Gnosis; escrow contracts must be chain-agnostic from day one. Out of scope: any BYOS-operated orderbook or order-discovery channel, pass-through of CoW rewards to sub-solvers, cross-chain escrow accounting, and the bonding capital for the BYOS solver itself.

Specification

Solver engine. Build a solver engine that bids on orders for which it holds a proposal that has passed local simulation against the reference block. When multiple proposals exist for the same order UID, the engine selects the one yielding the greatest surplus after any configured BYOS fee.

Trampoline contract. Receives sellAmount, executes arbitrary sub-solver interactions, returns buyAmount, and holds no protocol balance outside a single settlement. Native ETH wrap/unwrap must be specified explicitly. Two viable topologies: a single shared Trampoline with strict allowance hygiene, or one instance per sub-solver address. Applicants state a preference with reasoning; the final call sits with the Core Team Reviewer and grantee in M1. The Grants Council does not arbitrate technical contract topology.

Escrow contract. Per-chain, denominated in the native token of that chain. Anyone can deposit into a balance keyed by sub-solver address. Sub-solvers withdraw, subject to a cool-down period (default: 1 day; operator-configurable). BYOS holds an exclusive debit function for revert penalties and gas. All flows emit events. No cross-chain accounting in v1.

Proposal API. Public HTTP with POST /proposals (body: order_uid, interactions, valid_until, escrow_account, nonce, and an EIP-712 signature), GET /proposals/{order_uid} (metadata only, never full contents, to avoid the API becoming a leakage channel), and DELETE /proposals/{id} (cancellation by the original signer). Proposals expire at valid_until, on inclusion in a settled solution, or on the underlying order being canceled or filled by another solver. BYOS re-simulates accepted proposals continuously and silently drops those that begin reverting. EIP-712 schema, rate-limit policy, and authentication model are for the grantee to propose.

Order discovery. BYOS does not provide one. Sub-solvers obtain orderflow through the public CoW orderbook API, direct delivery from opted-in users or UIs, or routes encoded in user app data. BYOS does not operate an orderbook, push orders to sub-solvers, or surface its proposal queue.

Safety

Sub-solvers never receive submission keys and never call settle directly; BYOS retains exclusive control over solution submission, mirroring how non co-located solvers operate under the CoW DAO bond today. The Trampoline pattern confines sub-solver interactions to a context that holds no protocol funds, so buffer exfiltration and approval backdoors against settlement-controlled balances are not possible. The escrow contract handles revert-spam: proposals are only eligible when escrow covers the worst-case penalty and gas, failed settlements debit the escrow, and undercollateralized sub-solvers are filtered out. The public endpoint requires per-source rate limits, optionally backed by an escrow-balance threshold. BYOS must introduce no new orderflow leakage beyond what already exists in the public CoW orderbook.

Economics

BYOS participates in the standard CoW reward mechanism under its own bonded solver address and retains 100% of rewards earned. A configurable fee on winning solutions (percentage of volume or surplus) defaults to 0 in v1; proposals whose surplus does not cover the fee are rejected at acceptance. Pass-through of rewards to sub-solvers is out of scope for v1. BYOS should be profitable enough to fund its own maintenance beyond M3.

Milestones

  • M1: Design and contracts. Final design document covering Trampoline topology, proposal schema, escrow interface, and fee mechanism, with the topology decision agreed with the Reviewer. Implemented Trampoline and Escrow contracts with a full test suite covering reverting sub-solver scenarios, allowance hygiene, and escrow accounting. Audit-ready package.

  • M2: Solver engine and API. BYOS engine integrated with the CoW driver and autopilot on staging. Public proposal API is live with at least one reference sub-solver client. End-to-end staging test with a real sub-solver settling testnet orders.

  • M3: Audit and mainnet. Security audit completed and findings remediated. Bonded solver onboarded on Ethereum mainnet. At least one external sub-solver is onboarded and settling live orders. Operational runbook and monitoring in place.

Payment split to be proposed by applicants with justification.

Acceptance

All deliverables landed in the agreed repositories, contracts pass audit with no unresolved high or critical findings, the engine wins and settles at least 10 live mainnet orders sourced from external sub-solvers, median /solve latency within the protocol’s solver SLO, all code under an OSI-approved open-source license compatible with the rest of the CoW stack.

Evaluation

Applications will be evaluated on demonstrated solver, contract, or DEX infrastructure work; understanding of CoW solver competition, settlement, bonding, and orderflow privacy; architecture quality (Trampoline topology, escrow design, API safety); audit track record with a named partner where applicable; operational readiness to run a bonded solver in production; clarity of milestones and acceptance evidence; timeline; and cost.

Selection Process

The Grants DAO committee is selected in coordination with the CoW core team. Two roles run the engagement:

  • Steward (Grants Committee member): coordination, administration, milestone tracking, payment.

  • Reviewer (Core Team member): technical and strategic evaluation, contract design sign-off, integration approval.

Open design decisions called out above (Trampoline topology, EIP-712 schema, rate-limit policy, auth model) are resolved between the grantee and the Reviewer. The Steward facilitates but does not arbitrate technical content. The committee may close or extend the timeline, request clarifications, select none of the proposals, or negotiate scope and budget.

How to Apply

Submit a proposal as a reply to this thread or as a separate forum post in the CoW Grants Program category using the standard Grant Application Template. Cover team background and relevant solver/contract/infrastructure experience, proposed approach including stance on Trampoline topology, milestones with payment split, budget breakdown, and references. Deadline: June 26, 2026. Questions via Discord or forum reply.

Terms

Applicants are bound by the CoW DAO Grant Agreement Terms and the Participation Agreement. Payments in stablecoins (USDC, DAI, or USDS) on Ethereum mainnet, 30 days after milestone completion. Deliverables open source under an approved license.

2

Really interesting idea, agree that this will make much easier to integrate a new DEX or similar. Just one thing that we want to double confirm: is also expect the approved grantee to run the BYOS operations after the grant delivery (using the solver rewards to fund maintenance), right?

3

Hello @bleu, yes, that’s right. We’d love to see proposers include their thoughts on how they plan to manage and sustain operations in their applications.

4

Grant Application - BYOS Meta-Solver: Permissionless Sub-Solver Aggregation for CoW Protocol

Author(s)

Applicant: Chainza
Main contact: Vladyslav Myronenko (email: vlad@chainza(dot)io); Ivan Nazarov (email: ivan.n@chainza(dot)io)
GitHub: chainza.io · GitHub

Payment address (Ethereum mainnet only): 0xcde50306C1c5365134836Fc51e916fC83a7f2E97

Experiences and Qualifications

We are a Web3 engineering team with direct experience building production backend systems, DEX aggregation infrastructure, on-chain routing integrations, smart-contract integrations, and latency-sensitive blockchain services.

Our relevant experience includes:

  • hands-on production experience with Delta, the intent-based trading protocol by Velora, including intent execution flows, routing integration, and production backend infrastructure;

  • DEX aggregation and routing infrastructure across AMM-style liquidity sources;

  • EVM protocol integrations, including Solidity contracts and TypeScript/Rust/Go backend services;

  • production blockchain infrastructure with RPC, indexing, simulation, monitoring, and incident-response requirements;

  • smart-contract interaction design where safety, execution correctness, and gas-awareness are first-class concerns;

  • operating Web3 backend systems that need high uptime, deterministic behavior, and fast iteration cycles.

We are applying for the BYOS RFP because it fits our team’s strongest area: building the infrastructure layer between external routing intelligence and safe, production-grade settlement execution.

The goal is not to build a toy relay. The goal is to build a bonded BYOS solver that can safely receive proposals from permissionless external sub-solvers, normalize and simulate those proposals, select the best executable candidate per order, and participate in CoW’s standard solver competition without introducing new orderflow leakage, approval risk, or griefing surfaces.

Grant Description

Summary

We propose to build and operate a BYOS Meta-Solver for CoW Protocol.

The solver will participate in the standard CoW auction flow as a bonded solver while sourcing candidate routes from a permissionless set of external sub-solvers. External sub-solvers will submit signed proposals for specific CoW order UIDs. BYOS will validate, collateral-check, continuously simulate, score, and convert accepted proposals into CoW-compatible settlement solutions.

Our implementation will include:

  1. a solver engine integrated with the CoW driver/autopilot flow;

  2. a Trampoline execution layer for isolated sub-solver interactions;

  3. a per-chain native-token escrow contract;

  4. a public proposal API with EIP-712 signed submissions;

  5. a reference sub-solver client;

  6. observability, runbooks, alerting, and production operations;

  7. audit-ready and open-source code;

  8. Ethereum mainnet and Gnosis v1 deployment.

We will also continue operating the BYOS solver after grant completion. Our operating model assumes that BYOS keeps standard solver rewards and uses those rewards, plus an optional configurable BYOS fee after v1 if needed, to sustain infrastructure, monitoring, sub-solver support, maintenance, and future chain expansion.

Why this matters for CoW Protocol

CoW Protocol already has a strong solver competition, but participation as a full bonded solver has a high operational, legal, and capital barrier. Many parties can produce useful routing information for individual orders, but cannot justify becoming full solvers.

BYOS reduces that barrier without weakening CoW’s core safety model.

It creates a path for:

  • smaller searchers and routing teams to bid on individual orders;

  • liquidity sources to make their routes visible to CoW execution;

  • wallets, UIs, and advanced users to bring computed execution paths;

  • CoW to increase execution diversity without directly onboarding every small participant as a bonded solver.

The key design requirement is that this must not become a loose “submit arbitrary calldata and pray” system. BYOS must remain accountable as the bonded solver, retain settlement control, and isolate sub-solver interactions so external parties cannot access protocol buffers, user funds, submission keys, or private proposal queues.

Our proposal is built around that requirement.

Proposed Approach

Architecture Overview

The system will have five main layers:

  1. Proposal Gateway

  2. Proposal Validation and Escrow Filtering

  3. Simulation and Scoring Engine

  4. BYOS Solver Engine

  5. Trampoline + Escrow Contracts

High-level flow:

  1. A sub-solver discovers a CoW order through allowed external channels: public CoW orderbook, direct opted-in user delivery, UI integration, or app-data encoded route intent.

  2. The sub-solver computes a route for a specific order_uid.

  3. The sub-solver submits a signed proposal to BYOS through POST /proposals.

  4. BYOS validates the signature, nonce, expiry, order status, proposal shape, and escrow eligibility.

  5. BYOS simulates the proposal against current chain state and stores only the data needed for ranking and execution.

  6. BYOS continuously re-simulates accepted proposals and silently drops proposals that begin reverting or become undercollateralized.

  7. On /solve, BYOS selects eligible proposals for orders in the auction, ranks them by surplus after fees and risk adjustments, and returns CoW-compatible solution candidates to the driver.

  8. The CoW driver postprocesses, simulates, scores, and submits the winning settlement if BYOS wins.

  9. If settlement fails due to sub-solver route behavior, BYOS debits the relevant sub-solver escrow according to the agreed penalty policy.

Design Principle

BYOS should generalize sub-solver routes, not blindly forward them.

We will implement a canonical internal proposal representation that normalizes different sub-solver outputs into a common format:

  • chain ID;

  • order UID;

  • proposal ID;

  • sub-solver signer;

  • escrow account;

  • nonce;

  • validity timestamp;

  • raw interactions;

  • explicit native ETH wrap/unwrap requirements;

  • simulated buy amount;

  • simulated gas;

  • touched tokens/pools/contracts;

  • last simulated block;

  • failure class if simulation fails;

  • estimated user surplus;

  • BYOS fee impact;

  • risk haircut;

  • escrow reserve requirement.

This lets the engine compare heterogeneous sub-solver proposals consistently, while still keeping v1 scoped and auditable.

Solver Engine

The solver engine will implement the standard interface expected by the CoW driver.

On every /solve request, the engine will:

  1. map auction orders to active proposal candidates by order_uid;

  2. filter out expired, stale, undercollateralized, canceled, or reverting proposals;

  3. compute a net score per candidate based on simulated surplus, effective gas cost, configurable BYOS fee, and route risk;

  4. select the highest-value proposal per order where only one order can be safely settled;

  5. produce CoW-compatible solution candidates;

  6. emit multiple candidates where useful, allowing the driver to simulate and pick the best one.

The initial implementation will support three candidate generation modes:

1. Singleton Mode

One external proposal settles one CoW order.

This is the safest and simplest mode, and it will be used as the fallback path for all supported orders.

2. Same-Pair Compatible Bundles

Where multiple orders trade the same directed token pair and compatible clearing prices can be maintained, BYOS may compose proposals into a single solution candidate.

This mode will only be enabled when the engine can preserve CoW’s uniform directional clearing price requirements.

3. Disjoint Candidate Bundles

Where proposals are independent and safe to combine, BYOS may return multiple disjoint solution candidates and rely on the CoW driver’s existing postprocessing, simulation, and disjoint-solution merging logic.

We do not propose a full arbitrary combinatorial optimizer in v1. That would add complexity and audit risk before the basic BYOS mechanism has proven itself in production. The v1 design prioritizes safe execution, correct scoring, and production reliability.

Trampoline Topology

Our preferred topology is:

one deterministic Trampoline instance per sub-solver address, deployed through a shared factory.

We believe this is the right v1 design.

A single shared Trampoline is simpler operationally, but it creates a larger blast radius and makes allowance hygiene, attribution, and forensic analysis harder. Per-sub-solver Trampolines give us:

  • stronger isolation between sub-solvers;

  • cleaner attribution for failures;

  • simpler approval hygiene;

  • clearer accounting;

  • easier monitoring;

  • easier audit reasoning;

  • lower blast radius if a malicious or buggy route is submitted.

The Trampoline will:

  • receive the user’s sell token amount from settlement for one execution context;

  • execute the approved arbitrary interactions submitted by the sub-solver;

  • return the required buy token amount back to settlement;

  • hold no persistent protocol balance;

  • avoid persistent token approvals wherever possible;

  • explicitly handle native ETH wrap/unwrap logic;

  • revert atomically if the promised buy amount is not returned;

  • emit events sufficient for debugging and incident analysis.

The final topology decision will be locked with the Core Team Reviewer during M1, as requested by the RFP.

Escrow Contract

We will implement one native-token escrow contract per chain.

The escrow contract will:

  • accept deposits from anyone into a balance keyed by sub-solver address;

  • support withdrawals by sub-solvers subject to a cooldown period;

  • default the cooldown to one day, operator-configurable within the agreed bounds;

  • expose an exclusive debit function callable only by the BYOS operator for revert penalties and gas;

  • emit events for deposits, withdrawal requests, withdrawals, debits, and operator configuration changes;

  • avoid cross-chain accounting in v1;

  • be chain-agnostic from day one.

The off-chain BYOS engine will use escrow state for eligibility and rate-limiting.

A proposal will only be eligible if the sub-solver’s escrow balance covers the worst-case gas and penalty reserve. If escrow is insufficient, the proposal remains rejected or inactive until the balance is restored.

This gives the public API permissionless access while making spam and griefing economically expensive.

Proposal API

We will implement the RFP-required public HTTP API.

POST /proposals

Submits a signed sub-solver proposal.

Required fields:

  • order_uid

  • interactions

  • valid_until

  • escrow_account

  • nonce

  • signature

We will propose an EIP-712 schema during M1. The schema will bind proposals to:

  • chain ID;

  • BYOS verifying domain;

  • order UID;

  • interaction hash;

  • validity timestamp;

  • escrow account;

  • nonce;

  • sub-solver signer.

We will also support optional non-authoritative metadata fields:

  • expected buy amount;

  • gas hint;

  • route type;

  • native ETH handling hint;

  • route expiry hint.

These optional fields will never be trusted without simulation.

GET /proposals/{order_uid}

Returns metadata only.

It will never expose full proposal contents, calldata, route data, interactions, private ranking information, or proposal queue details.

The goal is to make the endpoint useful for submitters without turning BYOS into an orderflow or route-leakage channel.

DELETE /proposals/{id}

Allows the original signer to cancel a proposal.

Cancellations will be authenticated by signer ownership and proposal nonce. Canceled proposals are immediately removed from eligibility.

Rate Limiting and Authentication

The API will remain public and permissionless, but not free to abuse.

We propose three layers:

  1. standard IP and source-based rate limits;

  2. signer-based rate limits;

  3. escrow-backed rate-limit tiers.

Higher escrow balances can unlock higher submission limits. Undercollateralized submitters will be filtered out before simulation to protect infrastructure.

This keeps BYOS permissionless while aligning API usage with economic responsibility.

Order Discovery

BYOS will not operate an orderbook or order-discovery channel.

Sub-solvers must obtain orderflow through allowed channels:

  • public CoW orderbook API;

  • direct delivery from opted-in users or UIs;

  • app-data encoded routes;

  • their own independent order monitoring.

BYOS will not push orders to sub-solvers, expose active queues, or create a new orderflow distribution channel.

Fees and Economics

BYOS will participate under its own bonded solver address and retain standard solver rewards.

We will implement a configurable BYOS fee mechanism, defaulting to zero in v1, as requested by the RFP.

The fee can be configured as:

  • percentage of surplus; or

  • percentage of volume; or

  • disabled entirely.

In v1, the fee defaults to zero. Proposals whose surplus does not cover the configured fee will be rejected at acceptance or filtered before solving.

Reward pass-through to sub-solvers is out of scope for v1.

Longer term, the business can sustain operations through:

  • standard solver rewards;

  • optional BYOS fee after v1;

  • increased external sub-solver participation;

  • chain expansion after Ethereum mainnet and Gnosis are stable.

Safety and Security

Key Threats

The main threats are:

  • malicious sub-solver calldata;

  • route reverts and gas griefing;

  • buffer exfiltration;

  • persistent approvals;

  • proposal replay;

  • orderflow leakage;

  • invalid clearing prices;

  • stale simulation results;

  • denial-of-service against the proposal API;

  • incorrect escrow debits;

  • operational failure by BYOS as a bonded solver.

Mitigations

Trampoline Isolation

Per-sub-solver Trampolines prevent one sub-solver’s interactions from contaminating another’s execution context.

Each Trampoline should hold no long-lived protocol balance and should avoid persistent approvals wherever possible.

Continuous Simulation

Accepted proposals will be re-simulated continuously. Proposals that begin reverting are silently dropped from the active set.

Simulation will be refreshed on:

  • new blocks;

  • touched pool state changes;

  • material gas changes;

  • proposal expiry approaching;

  • order cancellation/fill events;

  • previous simulation becoming stale.

Escrow-Backed Eligibility

Every active proposal must be collateralized.

If the escrow balance is insufficient to cover worst-case gas and penalty exposure, the proposal becomes ineligible.

EIP-712 Signing and Replay Protection

Proposal signatures will be domain-separated and chain-bound. Nonces prevent replay. The proposal hash includes the interaction hash, order UID, validity timestamp, and escrow account.

Metadata-Only Reads

GET /proposals/{order_uid} will not reveal route data, calldata, interactions, or private scoring data.

Conservative Batching

The v1 composer will avoid unsafe cross-order batching. Same-pair bundling will only be used when clearing-price compatibility is clear. Otherwise, proposals remain singleton or disjoint candidates.

Driver-First Integration

We will use the standard CoW driver path wherever possible in v1, so the driver continues to perform postprocessing, simulation, scoring, and settlement submission checks.

Operational Controls

BYOS will support:

  • proposal intake pause;

  • sub-solver suspension;

  • rate-limit tightening;

  • chain-level emergency disable;

  • dashboard-driven monitoring;

  • runbooks for revert spikes, latency spikes, RPC degradation, and escrow anomalies.

Milestone-Based Grant

This is a milestone-based grant.

Expected length: 18 weeks after grant approval and reviewer assignment.

Commencement: upon successful approval and reviewer/steward assignment.

Finalization: within 18 weeks of commencement, unless audit scheduling requires a mutually agreed extension.

Milestones

Milestone Title Due Date Funding Request
M1 Design, Trampoline, Escrow Contracts Week 6 $19,200
M2 Solver Engine, Proposal API, Staging Integration Week 13 $22,400
M3 Audit, Remediation, Mainnet Launch, Operations Week 18 $26,000
Total $67,600

Payments requested in USDC, DAI, or USDS on Ethereum mainnet, according to the RFP payment terms.

Milestone 1: Design and Contracts

Timeline: Weeks 1–6
Funding: $19,200

Deliverables

  • Final technical design document.

  • Trampoline topology decision agreed with Reviewer.

  • EIP-712 proposal schema draft.

  • Escrow contract interface.

  • Fee mechanism design.

  • Trampoline factory.

  • Per-sub-solver Trampoline implementation.

  • Per-chain native-token escrow contract.

  • Unit tests.

  • Fuzz/invariant tests for:

    • reverting sub-solver interactions;
    • allowance hygiene;
    • escrow accounting;
    • withdrawal cooldown;
    • authorized debits;
    • no persistent protocol balances;
    • native ETH wrap/unwrap paths.

  • Audit-ready smart-contract package.

Acceptance Evidence

  • Reviewer-approved design document.

  • Contract repositories published or shared in agreed repositories.

  • Test report.

  • Gas benchmark report.

  • Audit scope document prepared.

Milestone 2: Solver Engine and Proposal API

Timeline: Weeks 7–13
Funding: $22,400

Deliverables

  • Public proposal API:

    • POST /proposals
    • GET /proposals/{order_uid}
    • DELETE /proposals/{id}

  • EIP-712 verification.

  • Nonce and replay protection.

  • Escrow-backed proposal eligibility.

  • Metadata-only proposal reads.

  • Rate-limiting implementation.

  • Continuous simulation scheduler.

  • Proposal scoring and selection engine.

  • BYOS solver engine integrated with CoW driver/autopilot staging flow.

  • Reference sub-solver client.

  • Staging environment.

  • Basic dashboards:

    • proposal intake;
    • simulation success/failure;
    • /solve latency;
    • active proposals;
    • escrow balances;
    • settlement outcomes.

  • End-to-end staging test with at least one real external sub-solver.

Acceptance Evidence

  • Staging deployment live.

  • Reference sub-solver can submit signed proposals.

  • Engine can return valid CoW-compatible solutions through the driver flow.

  • End-to-end test settlement completed in staging/test environment.

  • Initial runbook delivered.

Milestone 3: Audit, Mainnet, and Operations

Timeline: Weeks 14–18
Funding: $26,000

Deliverables

  • External security audit completed.

  • High and critical findings remediated.

  • Final deployment scripts.

  • Mainnet and Gnosis deployment.

  • Bonded solver onboarding completed.

  • At least one external sub-solver onboarded.

  • Production monitoring.

  • Production runbook.

  • Incident response checklist.

  • Post-launch support plan.

  • Open-source release under an OSI-approved license compatible with the CoW stack.

Acceptance Evidence

  • No unresolved high or critical audit findings.

  • BYOS solver live as a bonded solver on Ethereum mainnet.

  • At least 10 live mainnet orders settled from external sub-solver proposals.

  • Median /solve latency within CoW Protocol’s solver SLO.

  • Operational dashboards live.

  • Final documentation delivered.

Budget Breakdown

Category Amount
Technical design & architecture $6,400
Smart-contract engineering $12,800
Solver/backend engineering $19,200
Proposal API & reference client $6,400
Testing, staging, benchmarking $6,400
DevOps, monitoring, runbooks $3,200
Audit support / remediation $3,200
Smart Contract Audit $10,000
Total $67,600

The audit budget is reserved for an external audit partner approved together with the Reviewer. We will finalize the audit partner during M1, ideally by week 2, to avoid scheduling risk.

Operations and Sustainability

We understand that the selected grantee is expected to continue operating BYOS after grant delivery.

Our plan is to operate BYOS as a standalone solver business after M3.

Post-grant operations will include:

  • maintaining the bonded solver infrastructure;

  • monitoring solver performance and settlement failures;

  • supporting external sub-solvers;

  • maintaining the proposal API;

  • tuning scoring/rate-limit policies;

  • handling chain upgrades and CoW driver/API changes;

  • keeping dashboards and alerts operational;

  • performing regular security reviews;

  • publishing updates for major changes.

In v1, BYOS keeps standard solver rewards and the configurable BYOS fee defaults to zero.

After v1, if operating costs exceed solver rewards, we may propose enabling a small BYOS fee on winning external proposals. Any fee change would be transparent, configurable, and documented.

Testing Plan

Testing will cover:

Contract Tests

  • Trampoline execution success path.

  • Trampoline revert path.

  • No persistent balances after execution.

  • No unsafe persistent approvals.

  • Native ETH wrap/unwrap behavior.

  • Escrow deposits.

  • Escrow withdrawal cooldown.

  • Exclusive debit authorization.

  • Event completeness.

  • Malicious interaction attempts.

Solver Engine Tests

  • Proposal parsing.

  • EIP-712 validation.

  • Nonce replay protection.

  • Proposal expiry.

  • Order cancellation/fill invalidation.

  • Escrow eligibility.

  • Proposal re-simulation.

  • Scoring and ranking.

  • Same-order proposal replacement.

  • Multiple proposals for same order UID.

  • Driver-compatible solution output.

Integration Tests

  • Local CoW driver integration.

  • Staging autopilot/driver flow.

  • Forked mainnet route simulation.

  • Forked Gnosis route simulation.

  • Full settlement transaction simulation.

  • Reference sub-solver end-to-end flow.

Performance Tests

  • /solve median latency.

  • /solve p95 latency.

  • proposal intake throughput;

  • simulation queue throughput;

  • stale proposal eviction time;

  • RPC degradation behavior;

  • driver timeout behavior.

Security Tests

  • fuzzed calldata;

  • malformed interactions;

  • replayed proposals;

  • expired proposals;

  • undercollateralized proposals;

  • malicious native-token flows;

  • ERC-20 approval edge cases;

  • route reverts between simulation and settlement.

Success Metrics

We will consider v1 successful when:

  • the solver is bonded and live on Ethereum mainnet;

  • contracts are audited with no unresolved high or critical findings;

  • the engine settles at least 10 live mainnet orders sourced from external sub-solvers;

  • median /solve latency is within CoW’s solver SLO;

  • at least one external sub-solver is live;

  • proposal API is public and documented;

  • runbooks and dashboards are operational;

  • all deliverables are open source under an approved license;

  • BYOS can continue operating after grant completion.

Open Design Decisions for Reviewer Alignment

We propose to resolve the following during M1 with the Core Team Reviewer:

  1. final Trampoline topology;

  2. final EIP-712 schema;

  3. rate-limit policy;

  4. authentication model;

  5. exact penalty and gas-debit policy;

  6. exact fee configuration interface;

  7. audit partner and scope;

  8. mainnet onboarding path and staging acceptance process;

  9. exact solver SLO target to benchmark against.

Our default recommendations are:

  • per-sub-solver Trampoline instances;

  • EIP-712 signed proposals with chain/domain separation and nonce replay protection;

  • escrow-backed rate-limit tiers;

  • metadata-only proposal reads;

  • configurable BYOS fee defaulting to zero;

  • no reward pass-through in v1;

  • standard CoW driver integration in v1.

Other Information

We believe the biggest risk in BYOS is not implementing the HTTP API. That part is straightforward.

The real risk is accidentally creating one of three things:

  1. a new orderflow leakage channel;

  2. a new execution surface where arbitrary sub-solver interactions can affect protocol balances;

  3. a griefing mechanism where permissionless submitters externalize revert and infrastructure costs onto BYOS.

Our architecture is designed specifically around preventing those three failure modes.

We are intentionally proposing a conservative v1:

  • safe singleton execution first;

  • compatible same-pair batching where clearing-price rules are preserved;

  • disjoint solution candidates where the driver can safely merge;

  • no BYOS-operated orderbook;

  • no v1 reward pass-through;

  • no cross-chain escrow accounting;

  • no full arbitrary combinatorial optimizer before the base system is proven.

This keeps v1 auditable, launchable, and useful.

Technical Overview Notes

We have also prepared a more detailed technical overview of the proposed BYOS architecture for reviewers who would like to inspect the implementation approach in more depth.

The overview covers the expected interaction model with CoW Protocol, the sub-solver proposal flow, Trampoline execution model, escrow mechanics, simulation flow, and key operational considerations.

This application should be treated as the primary grant proposal. The technical overview is provided as supplementary implementation context only.

CoW BYOS MetaSolver - Detailed Technical Overview

Terms and Conditions

By submitting this grant application, we acknowledge and agree to be bound by the CoW DAO Participation Agreement and the CoW DAO Grant Agreement Terms.

We are happy to coordinate with the assigned reviewer and steward once the application moves forward.

5

Hey, just to share we posted a proposal here! Open to feedbacks and discussion

6

Thanks for your applications. We will be reviewing the submissions and providing a statement by next week on the direction forward.

7

Hey everyone,

Thank you to both @chainza and @bleu for your excellent submissions.

After reviewing the applications, the committee has decided to move forward with @bleu for the BYOS grant.

@chainza, we really appreciate the time and effort you put into your design, it was a very strong application, and we hope to see you apply for future grants!

@bleu, congratulations! As the next step, please move your proposal to Snapshot for the formal vote.

8

Thanks for running a transparent process and for sharing the decision here. Congrats to @bleu, looking forward to seeing the solver take shape.

We’ll stay close to CoW’s roadmap. If there are future RFPs that fit what we build, we’d welcome the chance to apply again.

9

Thanks for the trust, everyone! We’re very happy with this opportunity. FYI snapshot link is here