[Retro Round] Hummingbot Gateway Connector for CoW SDK

CoW Grants Program Retro Round
1

Author: Tantodefi.eth & Bhavya Gor
Date: January 12, 2026
Category: Developer Tooling
Funding Requested: 10,000 xDAI + 20,000 vested COW tokens
Gnosis Chain Address: 0x9B2FB7a8d227cDaA8002f80e8c8A99a19Bb1b969
GitHub: Tantodefi | Bhavya Gor
Contact: tantodefi.eth@proton.me | bhavyagor12@gmail.com

About You

We are Tantodefi.eth and Bhavya Gor, experienced developers specializing in blockchain integrations, API development, and trading systems. We’ve contributed to open-source DeFi projects, including smart contracts, algorithmic trading tools, and developer resources for platforms like BUIDLGuidl’s Scaffold-ETH. Our expertise lies in creating accessible tools for DeFi ecosystems, with a focus on standardized APIs for algorithmic trading. This is our second proposal for Cow DAO and it is heavily related to expanding access to the anti-MEV features of cow swap’s batch auction features enabled by the cow-sdk. Our first proposal was for a CCXT connector library (a popular trading library that standardizes the APIs of numerous CEXs and DEXs helping algorithmic developers and automated traders buid their strategy once and deploy/trade everywhere).

Project Overview

This proposal seeks funding from CoW DAO’s retroactive funding round to develop a Hummingbot Gateway connector for the CoW SDK, enabling seamless integration of CoW Protocol’s intent-based trading into the widely used Hummingbot framework. This will allow algorithmic traders to leverage CoW’s MEV-protected executions through a unified API, reducing integration barriers and driving protocol adoption. The project builds on prior efforts, such as the community-built Python SDK[1], to enhance developer accessibility and ecosystem growth.
For full details, including feasibility, implementation, and impact metrics, see below.

Team

  • Tantodefi.eth (Fullstack Developer): Blockchain engineer with expertise in DeFi integrations and algorithmic trading. Contributed to exchange adapters and participated in BUIDLGuidl hackathons. GitHub: tantodefi, X: @tantodefi.
  • Bhavya Gor (Fullstack Developer): Full-stack developer focused on API wrappers and Web3 testing. Built TypeScript/Python SDKs and DeFi tools at BUIDLGuidl. Winner of numerous web3 hackathons. GitHub: bhavyagor12, X: @bhavya_gor.

Project Details

Motivation and Rationale

The CoW Protocol’s intent-based architecture, powered by the CoW SDK[2], offers superior executions with MEV protection and gas efficiency. However, algorithmic traders using Hummingbot—the leading open-source bot framework with over 50,000 downloads—face integration hurdles. This connector will map CoW SDK functions (e.g., quoting, order management) to Hummingbot Gateway’s API, enabling plug-and-play usage for trading bots and strategies.
Key Benefits:

  • Ease of Integration: Add CoW as a Hummingbot Gateway “Router” connector with methods like quote and trade.
  • Increased Usage: Enable algo traders to route orders to CoW, boosting TVL and solver activity.
  • Differentiation: Custom quote comparators highlight CoW’s advantages (e.g., 1-5% execution savings) over DEXs like Uniswap.
  • Ecosystem Growth: Open-source Hummingbot contribution[3] attracts builders for AI agents and automated trading.

Feasibility

CoW’s batch auction model differs from order-book systems, but Hummingbot Gateway supports partial implementations for DEX routers. We assessed:

  • Compatibility: Map async quoting/orders via polling, inspired by DEX connectors (e.g., Uniswap).
  • Async Handling: SDK-based polling with configurable intervals.
  • Rate Limiting: Mirror SDK logic (10-20 quotes/min) to prevent IP blocks.
  • Missing Features: Disable order books/tickers; synthesize symbols from metadata.
  • Enhancements: Add compareQuoteWithOtherExchanges for multi-venue benchmarking.
    This ensures 70-80% Hummingbot Gateway coverage, focusing on trading, similar to prior integrations[1:1].

Implementation

We will implement a TypeScript “Router” connector for Hummingbot Gateway (repository: GitHub - hummingbot/gateway: Middleware that standardizes DEX API endpoints on different blockchain networks), leveraging the official CoW TypeScript SDK[2:1]. The SDK will be initialized with the user’s chain ID and signer (via wallet integration in Hummingbot), enabling high-level access to CoW Protocol features while handling rate limiting and polling for asynchronous batch auction settlements.

The connector will map core CoW SDK methods to Hummingbot Gateway’s required router interface (primarily /quote-swap and /execute-swap endpoints, plus supporting methods like order status polling):

Key SDK methods and mappings:

  • Quoting: Use TradingSdk.getQuote(parameters) or OrderBookApi.getQuote(quoteRequest) – Computes a simulated execution price based on intent parameters (sellToken, buyToken, amount, kind: ‘sell’/‘buy’, receiver, etc.). Maps directly to Hummingbot’s quote endpoint, returning expected output, price impact, and gas estimate.
  • Order Creation / Trade Execution: Use TradingSdk.postSwapOrderFromQuote() (high-level) or OrderBookApi.sendOrder() after OrderSigningUtils.signOrder() – Submits a signed intent/order for batch auction execution. Maps to Hummingbot’s trade/execute-swap endpoint, handling slippage via validTo deadline and returning the order UID.
  • Order Status: Use OrderBookApi.getOrder(orderId) – Polls for order details (pending, filled, cancelled, expired). Implemented via polling loop in the connector for asynchronous status updates.
  • Cancel Order: Use OrderBookApi.sendSignedOrderCancellations() after OrderSigningUtils.signOrderCancellations() – Submits signed cancellation for pending orders.
  • Fetch Trades: Use OrderBookApi.getTrades({ orderId }) – Retrieves execution details for settled orders.
  • Markets/Tokens: Supported tokens will be fetched via the CoW API endpoint /tokens (or cached from SDK metadata), synthesizing market pairs for Hummingbot’s market loading.

Limitations Assessment:
CoW Protocol’s intent-based model (users submit preferences as signed messages, delegated to solvers for execution in batch auctions) introduces key differences from traditional exchanges:

  • No Real-Time Market Data: Batch auctions (every ~30-60 seconds on mainnet) mean no order books, tickers, or OHLCV data. Solvers optimize post-submission using off-chain liquidity, leading to delayed executions and variable final prices.
  • Asynchronous Execution: Orders are intents, not immediate; status requires polling (e.g., every 10-30 seconds via getOrder) as no websockets exist.
  • Order Types: Primarily limit-style intents; market orders simulated via quotes with tight deadlines. No advanced types like stop-loss natively (can be emulated via custom bots).
  • Partial Fills: Supported but not default; MEV protection is built-in, reducing front-running risks.
  • Dependencies: Requires user wallet signer for order signing; balances fetched via on-chain calls, not SDK.

Optimal Integration into Hummingbot Gateway Router Adapter:

  • Core Focus: Implement mandatory router endpoints (quote-swap for getQuote, execute-swap for postOrder/postSwapOrderFromQuote) with polling for status/trades.
  • Disabled Features: Configure unsupported router features (e.g., real-time order books, websockets) as false.
  • Custom Extensions: Add optional comparator to benchmark CoW quotes against other Gateway routers; include example polling-based risk management script.
  • Polling and Rate Handling: Built-in configurable polling with SDK-aware rate limits.
    This approach leverages the SDK’s high-level abstractions for simpler, more maintainable code while fully supporting Hummingbot’s router schema for intent-based trading.

Milestones

The project spans 5 weeks (January 12 - February 16, 2026):

Milestone Description Timeline Deliverable Verification
1: Research and Setup Analyze SDK/Hummingbot Gateway; review DEX connectors; prototype class. Jan 12 - Jan 18 (Week 1) Feasibility doc, prototype. GitHub commit.
2: Core Implementation Build order lifecycle, polling, rate limiting. Jan 19 - Feb 01 (Weeks 2-3) Functional connector, basic tests. 80% test coverage.
3: Advanced Features and Testing Add comparator/bot; tests/docs. Feb 02 - Feb 08 (Week 4) Beta version, docs. 90%+ test coverage; draft README.
4: Submission and Review Submit PR to Hummingbot Gateway; iterate. Feb 09 - Feb 16 (Week 5) Merged PR, usage guide. Hummingbot merge; metrics report.

Budget

Total: 10,000 xDAI + 20,000 vested COW (12-month vesting).

Category Amount (xDAI) Justification
Development 8,000 xDai 40 hours @ $200/hr (research, coding).
Testing/Documentation 1,000 xDai Testing and docs.
Community Engagement 1,000 xDai Feedback, PR reviews, features.
Vested COW Tokens 20,000 vCow Long-term alignment + 1 year maintenance of gateway router
Prefer xDAI for liquidity.

Impact and Metrics

  • Quantitative: Hummingbot downloads (GitHub); CoW tx uplift (unique tags); comparator savings (1-5%). Target: 10-20% algo volume growth in 6 months.
  • Qualitative: Forum feedback; GitHub stars/forks; developer contributions.
  • Verification: Open-source GitHub; on-chain analytics.
    This builds on grants[1:2], expanding CoW’s algo trading reach.

Additional Notes

We welcome community feedback to refine this proposal. The project leverages insights from the Python SDK grant[1:3] for robust integration practices.

CoW DAO Grant Agreement

By submitting this proposal, we agree to adhere to the terms outlined in the CoW DAO Grant Agreement. We commit to transparency, timely delivery of milestones, and open-source contributions to maximize value for the CoW ecosystem.

  1. Community-built Python SDK Grant ↩︎ ↩︎ ↩︎ ↩︎

  2. CoW SDK GitHub ↩︎ ↩︎

  3. Hummingbot Gateway Contributing
    Previous Proposal: HackMD
    We look forward to your feedback and to moo-ve forward with our second proposal! ↩︎

2

Hey I saw your post referencing this connector in the Hummingbot Discord, so I wanted to post some info about how Hummingbot works here. Hummingbot is an open source project managed by Hummingbot Foundation, and we have a governance-based process for adding exchange connectors. The process strives to ensure long-term maintenance of the connector along with increasing usage by the community. Given how good AI is these days, writing the initial code and getting unit test to pass is the easy part about maintaining a connector. The harder part is keeping up with API updates from both exchange and Hummingbot, especially since this DEX router standard is brand-new and may need changes in the next releases. In addition, there’s the need to create/maintain documentation that explains how users should configure the CowSwap specific params, creating guides for new users, and ensuring that the connector works with all Hummingbot strategies that utilize it. Will you be doing that work?

2 Likes
3

Hey @fengtality

Thank you for replying here as well as to the proposal I made in Hummingbot Discord re: this connector here

Assuming that this is a desirable addition for both protocols then I would plan to be doing whatever work is required to maintain the CoW/hummingbot connector for the next year - including and not limited to:

  • maintain the connector due to breaking API changes in either cow-sdk or the hummingbot ‘DEX router’ type schema in the Gateway repo
  • create/maintain documentation that explains how users should configure the CowSwap specific params
  • creating guides for new users
  • ensuring that the connector works with all Hummingbot strategies that utilize it

‘By all Hummingbot strategies that utilize it’ are you referring to the example strategis listed here Examples - Hummingbot - would they be required to be adapted or re-written to show how to use with the new CoW connector? If so yes i agree to do this work.

I’m happy to follow along the PR for pumpswap feat: add PumpAmm by kyoshoku · Pull Request #575 · hummingbot/gateway · GitHub and any related upcoming PRs related to the required documentation and example strategies for adding/maintaining a new connector.

Tagging some CoW grants people to get their thoughts on this @Sov @mfw78

for reference i also created this issue in hummingbot/gateway repo: Feature Request: Add CoW protocol router to gateway · Issue #593 · hummingbot/gateway · GitHub

and the MVP of the connector is currently done in my fork located here:

4

For most exchange connectors, Hummingbot Foundation works directly with exchanges who fund bounties managed by the Foundation team and built by community devs. See Connector Bounties - Hummingbot for more information. This ensures that the Foundation is adequately compensated for bearing a connector’s maintenance and upkeep costs while centralizing the process for changes required, etc. How is that accounted for here?

1 Like
5

I was under the impression that this connector would be maintained by DIY Governance - with me acting as lead dev responsible for the connector (and supported by my CoW grants manager and CoW technical reviewer for this proposal)

It was my understanding that this would offset the need for the Bounty Management and the Bounty Escrow Agreement as I would be providing the same coverage, support and required maintenance/updates for the same duration (1 Year).

As for how the Hummingbot Foundation could be adequately compensated for accepting this DIY Governance and supporting the new CoW connector, I included support for the Partner Fee logic This in my mind adds CoW to the list of Fee Share Partners supporting Hummingbot Foundation and aligning incentives between the protocols longterm.

CoW swap Partner Fee revenue has grown considerably in the last few quarters per defillama and assuming a successful integration between CoW/Hummingbot I thought that increased usage of the connector = increased protocol volume = increased partner fee, hopefully could lead to be a meaningful source of revenue for the Hummingbot Foundation.

image
image1540×243 29.4 KB

6

In my opinion, I don’t think the value proposition for a HummingBot integration is well defined. The mechanism and API within CoW Protocol is not designed for high frequency trading, with some endpoints being extremely costly. Given the previous CCXT connector integration (which has stalled in upstream), and the lack of any validation for a net benefit to CoW Protocol from such a trading integration, I signal that I would not be in favour of this grant in any form without validation of other HFT and backend API changes that would facilitate such.

1 Like
7

Thanks for your opinion @mfw78

I was thinking that there would still be a benefit for the CoW connector for strategies that required end-of-day inventory rebalancing, large position adjustments, and harvesting operations.

As such I saw the integration as complementary tool to the other low-latency routers, not a replacement.

I’ll close these PRs and Issues given the overall lack of support.

8

Agreed I think we should integrate LlamaSwap instead.

9

Thanks for your time @fengtality talking through this and finding us here :slight_smile:

I really thought I was onto something here and it would have been a desirable contribution.

PS: just to satisfy my curiosity - what would make LlammaSwap a better candidate for integration than CoW? Is it the overall underlying architecture with faster settlement times? Would like to have this framing for futur ideas I might get

10

I think LlamaSwap is an AMM aggregator similar to Jupiter and other Solana DEX routers, while CowSwap is RFQ so MMs have to quote.

I’m not super familiar with the Ethereum landscape however. Currently Hummingbot just has Uniswap and Pancake routers.

1 Like
11

I see. yes maybe something like LlamasSwap or even 0x protocol even as an aggregator might be worthwhile to expand the ethereum/evm offerings…

Til next time gents :saluting_face:

[RETRO ROUND] CCXT connector lib for CoW SDK