Grant Application: Community-built Rust SDK for CoW Protocol

Warning: Submitting AI slop PRs will result in your submission being immediately closed. All PRs if you wish to submit PRs must be submitted to GitHub - cowdao-grants/cow-rs · GitHub **.

Grant Title:** Community-built Rust SDK for CoW Protocol

Author:

  • GitHub: mfw78

About You:

  • Experienced in technical systems analysis, design and implementation with a strong emphasis on risk management / gap analysis.
  • Experienced technical writer in mission-critical, highly regulated, and technical industries.
  • Active Core Contributor to CoW Protocol and CoW Grants Committee Shepherd.

Grant category: Protocol Order Flow / Developer tools

Grant Description

Problem: Builders and developers come from many different technical backgrounds. Rust has become the predominant language for blockchain infrastructure, yet CoW Protocol lacks a Rust SDK. While JavaScript has cow-sdk and Python now has cow-py, there is no maintained, up-to-date Rust equivalent. A previous grant for a Rust SDK was awarded in November 2025 but has been cancelled due to non-delivery.

Solution: Following the successful community contributor model pioneered by cow-py, this grant sets aside funding within the Grants DAO to fund contributors to a CoW Protocol Rust SDK (cow-rs). Rather than funding a single developer, we open this to the herd – any contributor can submit code, and the Grants Committee will distribute funds based on assessed contribution.

Grant Goals and Impact

  • Extend CoW Protocol tooling to the widely-used Rust programming language.
  • Enable integration with Rust-based solver infrastructure, MEV tooling, and blockchain clients.
  • With WASM compilation support, enable use of the SDK in web application contexts.
  • Foster community engagement through collaborative, open development.
  • Provide a foundation for Rust-based trading bots, analytics tools, and protocol integrations.

Milestones

Phase One (Feature Parity):

Contributors commit code to the cowdao-grants/cow-rs repository and progressively work together to achieve feature parity with:

  1. @cowprotocol/cow-sdk – order creation, signing, and submission
  2. @cowprotocol/contracts – hashing utilities and contract interaction
  3. @cowprotocol/app-data – metadata encoding and CID pinning

Additionally:

  • Subgraph querying capabilities
  • Blockchain data fetching and decoding
  • WASM compilation target for web application use
  • Comprehensive unit tests, integration tests, and examples
  • Published to crates.io

Phase Two (Maintenance):

Contributors maintain the CoW Protocol Rust SDK over the course of one year from Phase 1 completion. This includes bug triage, dependency updates, feature requests, and keeping pace with upstream protocol changes.

Grant Timeline

  • Phase One: Open-ended. No fixed deadline – contributors work at their own pace. Funding is released upon the Grants Committee’s assessment that feature parity has been reached.
  • Phase Two: One year from Phase 1 completion.

Funding Request

$8,500 xDAI for Phase One. Based on the Grants Committee’s assessment (whose decision is final), funding will be divided amongst contributors to the Rust SDK proportional to their contribution.

Once the Rust SDK reaches feature parity, orders routed via the SDK will become eligible for the Volume Grants Program. Funds from the Volume Grants Program (if any) will be distributed to original developers and maintainers on a ratio basis to be solely determined by the Grants Committee.

Budget Breakdown

  • $8,500 xDAI: Development and labour costs, distributed across contributors.
  • Volume Grants Program: Ongoing sustainability mechanism post-delivery.

Gnosis Chain Address

TBD (Grants Committee multisig)

Other Information

As an active member of the CoW Grants Committee, I hereby refrain from voting / signing on this proposal so as to eliminate conflicts of interest. This grant supersedes the previously cancelled Rust SDK grant. All contributors, including the previous grantee, are welcome to participate on equal footing.

The repository will be hosted at: GitHub - cowdao-grants/cow-rs · GitHub

Terms and Conditions

By applying for this grant, I agree to be bound by the CowDAO Participation Agreement and the CowDAO Grant Terms and Conditions.

5 Likes

Grant Response: cow-rs Milestone Proposal

We already submitted an initial scaffold PR to cowdao-grants/cow-rs to establish a concrete starting point for the Rust SDK and to begin the technical conversation with working code:

https://github.com/cowdao-grants/cow-rs/pull/1

Our idea is to continue from that baseline with the milestones listed below, following the same general approach as the scaffold we already delivered: small, concrete contributions aligned with the grant scope, progressively building out the SDK in the open.

Team

CoBuilders

We are a blockchain-native R&D and engineering studio focused on developer tooling, protocol engineering, smart contracts, and DeFi infrastructure.

We have built developer tooling, backend systems, and integrations across multiple blockchain ecosystems. For CoW Protocol, we implemented a local block explorer integration that enabled transaction inspection in ephemeral development environments.

We have worked with leading organizations: at OpenZeppelin, we delivered an R&D report that influenced the Defender Relayer roadmap. Within the Arbitrum ecosystem, we built the Stylus Cache Manager and are currently developing additional developer tooling, including a Stylus Hardhat plugin, while also collaborating with the Hardhat team on ongoing development efforts.

For Worldcoin, we built a production mini app used by real users. For ZetaChain, we developed a proof of concept and supporting materials around cross-chain interactions.

We have also supported teams working on advanced developer tooling, helping solve technical challenges in evolving frameworks.

Phase One Scope

Our proposed Phase One is meant to cover the scope described in the Grant Application:

  • feature parity with @cowprotocol/cow-sdk for the main order creation, signing, and submission path

  • the hashing utilities and contract interaction required to support those flows

  • metadata encoding and CID-related app-data support

  • subgraph querying plus chain data fetching and decoding

  • WASM support

  • tests, examples, and release readiness through crates.io

For implementation, we would align this work with the current CoW SDK monorepo surface that covers these capabilities today, in particular:

  • @cowprotocol/cow-sdk

  • @cowprotocol/sdk-contracts-ts

  • @cowprotocol/sdk-app-data

  • @cowprotocol/sdk-subgraph

Phase One Milestones

Below is how we would continue the work as concrete milestones, starting from the scaffold already in the repository.

Milestone Scope
M0 Initial scaffold PR submitted
M1 Core foundations + Order Book parity
M2 Signing + Contracts parity
M3 Core order creation, signing, and submission flows
M4 App-data + Metadata capabilities
M5 Subgraph querying + Chain data decoding
M6 WASM + release readiness

M0 — Initial scaffold PR submitted

The current PR establishes the first project structure, the initial SDK surface, the basic quote/sign/submit flows, tests, examples, CI, and the devcontainer setup. We see it as a baseline contribution, not as completion of parity.

https://github.com/cowdao-grants/cow-rs/pull/1

M1 — Core foundations + Order Book parity

Stabilize the crate structure and public API, finish the main order book client surface, and align config, environment, and supported chains with the expected CoW SDK usage model.

This milestone is mainly about getting the low-level SDK base into good shape: typed config, errors, chain support, request/response modeling, and the main orderbook capabilities needed to quote, submit, query, and cancel orders through a solid Rust client.

M2 — Signing + Contracts parity

Implement the signing and hashing utilities required for order creation and cancellation, as well as the core contract interaction and encoding/decoding helpers needed by the SDK flows.

This is the protocol-heavy milestone. It covers EIP-712 order signing, order UID generation, cancellation signing, and the contract-side helpers needed so the rest of the SDK is not forced to reimplement hashing, encoding, and settlement-related logic in multiple places.

M3 — Core order creation, signing, and submission flows

Implement the higher-level flows required to support quote-to-order workflows and the main order-posting path expected in a practical Rust SDK.

The goal here is to move from low-level primitives to a usable SDK surface. Instead of forcing integrators to manually stitch together the quote, order preparation, signing, and posting, cow-rs should expose the main order creation and submission workflow directly.

M4 — App-data + Metadata capabilities

Implement metadata document generation and validation, app-data encoding, CID conversion, IPFS fetch support, and CID-related functionality required by the grant scope.

This milestone focuses on making order metadata a first-class part of the Rust SDK. It should be possible to build and validate app-data documents, derive the values needed by CoW orders, and resolve metadata back from appDataHex or CID when needed.

M5 — Subgraph querying + Chain data decoding

Add subgraph querying support, plus blockchain data fetching and protocol decoding helpers for trade, order, and settlement-related data.

This milestone is about read-side capabilities. In addition to order creation flows, cow-rs should also help backend services, bots, and analytics tooling query indexed protocol data and interpret relevant on-chain CoW data without rebuilding that decoding layer from scratch.

M6 — WASM + release readiness

Make the SDK usable from wasm32, complete the minimum test, example, and documentation coverage needed for release confidence, and publish cow-rs to crates.io.

This milestone is intentionally focused on hardening and release, not on adding a new product surface. The goal is to leave the project in a state where it is functional, documented, distributable, and adoptable.

Notes on Maintenance and Open Source Support

The repository is open source, and we are happy to remain available for reasonable follow-up questions and issue discussion in the normal course of open development.

However, we cannot commit to a formal 12-month maintenance obligation without an explicit maintenance budget and scope being defined separately.

Out of Scope but Interesting for Future Steps

The current proposal is intentionally focused on the Rust SDK path described above. Beyond that, there are several areas in the current CoW SDK ecosystem that could be valuable future work for cow-rs:

  • Composable/programmatic orders: conditional orders, multiplexer logic, and flows such as TWAP, DCA, or stop-loss-style strategies.

  • Bridging flows: multi-provider bridge quotes, best-route selection, and cross-chain swap-related helpers.

  • Cow Shed / smart account support: account abstraction-oriented helpers and smart account transaction flows.

  • Flash-loan-assisted flows: more advanced collateral swap and flash-loan-driven interactions.

  • Weiroll integration: transaction planning and execution helpers for more advanced composed strategies.

  • Provider adapter ecosystem: a broader Rust equivalent of the JS adapter story for different signer/provider backends and richer wallet integration patterns.

  • Expanded analytics/indexing utilities: richer reporting, protocol dashboards, and more specialized subgraph/on-chain analysis helpers beyond the initial read-side milestone.

These are all reasonable directions for a mature Rust SDK, but we consider them follow-on work after the main SDK path is delivered and validated.

@mfw78 Thanks for the feedback on our PR.

We’ve followed up there with a few clarifying questions to better understand the expected direction and contribution model, so we can move forward in the right way.

Looking forward to your comments.

Thanks.

CoBuilders Team

Please note that this is a Grant Application, which is whereby the grants committee / myself are proposing a grant that would distribute funds to a collective / multiple developers who contribute.

A similar grant was done for cow-py, which you can see essentially had a lead contributor (@bleu), and then another main contributor (@8baller). Unlike the previous Rust SDK grant, we will not entertain the grant allocation going to a single entity, there’s a lot of initial scaffolding and we’d rather see things unfold organically (you will see that cow-py was much more qualitative in design).

Sharing a concrete cow-rs implementation branch for review:

This branch is not presented as “done”, but as a reviewable Rust SDK foundation aligned with the current CoW Protocol TypeScript surfaces.

Current scope in the branch:

  • multi-crate SDK layout (core, contracts, signing, app-data, orderbook, trading, subgraph, sdk)
  • quote, sign, submit, cancel, allowance, and approval flows
  • app-data and CID support
  • read-only subgraph support
  • native and WASM examples
  • committed parity fixtures and pinned upstream source references for reviewable parity work

Approach:

  • keep the root SDK thin
  • keep trading flows in a dedicated crate
  • keep parity tied to pinned upstream sources and committed fixture contracts
  • keep normal builds and tests independent from live upstream checkouts

The goal is to contribute a solid, maintainable Rust base that can be reviewed and extended in the open.

If helpful, I would especially appreciate guidance on:

  • whether the current subgraph surface is the right Phase One boundary
  • any preferred coding style or documentation conventions for the repository

See the warning in the top message. Notably, it is evident from the submission that this is not implemented with Rust idiomacy, and therefore the submission will NOT be accepted.

For all readers of this thread: DO NOT SUBMIT CODE PULLS HERE. THESE MUST BE SUBMITTED, IF YOU WISH TO SUBMIT, AGAINST THE GITHUB REPOSITORY NOMINATED IN THE TOP MESSAGE.

AI SLOP WILL NOT BE TOLERATED AND YOUR SUBMISSION WILL BE IMMEDIATELY CLOSED AS AI SPAM. IT IS AN EXPECTATION THAT THE SDK BE PRODUCED IN A MAINTAINABLE MANNER.

1 Like