# Proposal for CoW DAO Retroactive Funding Round: Development of CCXT Connector for CoW SDK

## Applicant Information

- **Applicant Name**: [Tantodefi.eth](https://x.com/tantodefi) and [Bhavya Gor](https://x.com/bhavya_gor)
- **Contact Information**: [[e-mail]] or [[e-mail]]
- **Relevant Experience**: We are experienced developers with a background in blockchain integrations, API development, and trading systems. Our team has previously contributed to open-source projects in the DeFi space, including smart contracts and algorithmic trading tools, as well as developer tools for platforms like se2 from BUIDLGuidl.

## Summary

This proposal seeks funding from CoW DAO's retroactive funding round to develop a CCXT library connector for the CoW SDK. The connector will enable seamless integration of CoW Protocol's intent-based trading features into the widely adopted CCXT library, allowing algorithmic traders and developers to access CoW's MEV-protected executions through a unified API. By bridging CoW SDK with CCXT, we aim to lower barriers to entry for existing trading bots and strategies, driving increased protocol usage and TVL. We plan to complete the project during the retro funding build period (August-November 2025), delivering measurable impact through open-source contributions, usage metrics, and community adoption.

We request **15,000 xDAI** and **15,000 vested COW tokens**, scaled based on the project's anticipated impact in enhancing developer accessibility and protocol growth.

## Motivation

The CoW Protocol stands out in the DeFi landscape for its innovative intent-based architecture, which batches orders and leverages solvers to achieve optimal executions while protecting users from MEV (Miner Extractable Value). The CoW SDK[^1] provides developers with a robust toolkit for interacting with this protocol, including features for quoting, order signing, and submission. However, adoption among algorithmic traders remains limited due to the lack of integration with popular libraries like CCXT.

CCXT is the de facto standard for cryptocurrency exchange integrations, supporting over 100 exchanges and used by thousands of developers for building trading bots, arbitrage strategies, and market-making tools. Without a native CCXT connector, developers must build custom integrations for CoW, which is time-consuming and error-prone. This project will address this gap by creating a connector that maps CoW SDK functionalities to CCXT's unified API, enabling plug-and-play usage for existing CCXT-based systems.

## Rationale

Integrating CoW Protocol via a CCXT connector will significantly increase protocol usage by making it accessible to a broader audience of algorithmic traders. Currently, traders relying on CCXT for centralized exchanges (CEXs) or decentralized exchanges (DEXs) cannot easily incorporate CoW's superior execution without extensive rework. By providing this connector, we will enable direct comparisons between CoW quotes and those from other venues, highlighting CoW's benefits such as lower slippage, gas efficiency, and MEV protection.

Key benefits include:

- **Ease of Integration**: Developers can add CoW as an "exchange" in their CCXT setups with minimal code changes, leveraging familiar methods like `fetchTicker`, `createOrder`, and `fetchOrder`.
- **Increased Protocol Usage**: Algo traders can route orders through CoW for better pricing, potentially increasing transaction volume and solver competition.
- **Showcasing Differentiation**: Custom features, such as quote comparators, will demonstrate CoW's value empirically, encouraging adoption over traditional DEXs like Uniswap.
- **Ecosystem Growth**: As an open-source contribution to CCXT[^2], this connector will attract new builders to CoW, fostering innovation in areas like AI agents and automated trading strategies.

This aligns with CoW DAO's focus on developer tools and ecosystem expansion, as outlined in the retro funding round priorities.

## Feasibility and Viability Assessment

To ensure the project's success, we have evaluated the architectural differences between CoW Protocol and typical CCXT-supported exchanges. CoW's intent-based, batch auction model differs from traditional order book-based systems, leading to certain incompatibilities. Below, we address key questions and considerations regarding feasibility, including how we will handle missing methods and enhance the connector with value-added features.

### Key Considerations and Questions

1. **Compatibility with CCXT Interfaces**: Does CCXT's unified API support CoW's settlement methodology, which relies on asynchronous batch auctions rather than immediate executions?
- **Viability Answer**: Yes, CCXT allows for partial implementations where unsupported features are disabled or handled via polling. We reviewed other DEX connectors (e.g., Uniswap, Balancer) in CCXT, which similarly adapt to non-traditional architectures by mapping available endpoints and disabling inapplicable methods. We will map CoW SDK's async quoting and order submission, using polling to mimic synchronous behaviors where needed.

2. **Handling Asynchronous Operations and Notifications**: CoW lacks websockets for real-time updates, requiring polling for order settlements. How can this be integrated without degrading performance?
- **Viability Answer**: Polling is a standard approach in CCXT for protocols without websockets (e.g., many DEXs). We will implement efficient polling intervals based on CoW SDK's recommended practices, ensuring minimal latency. During development, we plan to use proxies to test high-frequency scenarios without risking IP blocks. The connector will respect CCXT's async handling, allowing users to configure poll rates.

3. **Rate Limiting and API Abuse Prevention**: Excessive calls to endpoints like `/quote` could lead to IP blocking via CloudFront. What measures ensure sustainable usage?
- **Viability Answer**: We will mirror the rate-limiting logic from the official CoW SDK (used in CoW Swap UI), capping requests (e.g., no more than 10-20 quotes per minute per IP). The connector will include built-in throttling and error handling for rate-limit responses, advising users to implement backoffs. This prevents spamming while supporting typical algo trading volumes.

4. **Missing Market Data Features**: CoW does not provide tick data, order books, or real-time tickers due to its batch auction model. How does this impact the connector's completeness?
- **Viability Answer**: CCXT supports disabling unsupported features via the exchange's `features` configuration (e.g., setting `fetchOrderBook: false`). We will synthesize limited market data where possible, such as deriving symbols from CoW's token metadata API and using quotes for ticker data. For viability, this partial support is common in DeFi connectors and does not hinder core trading functions like quoting and order management.

5. **Overall Integration Depth**: Given architectural differences, what is the maximum feasible integration, and how can we demonstrate CoW's advantages?
- **Viability Answer**: The connector will achieve 70-80% coverage of CCXT's core methods, focusing on trading lifecycle (quotes, orders, trades) while disabling certain market data endpoints. To highlight CoW's strengths, we will add custom extension methods not standard in CCXT, such as `compareQuoteWithOtherExchanges`, which fetches quotes from multiple CCXT-supported venues (e.g., Uniswap, Binance) and normalizes for fees, slippage, and gas to show empirical savings (e.g., 1-5% better execution). This will be implemented as an optional mixin, allowing users to benchmark CoW against other classes seamlessly.

These assessments confirm the project's viability, with mitigations ensuring robustness. We have familiarized ourselves with CoW SDK, CCXT interfaces, and existing DEX connectors to map out requirements, ensuring a technically sound implementation.

## Implementation Plan

### CCXT Integration Mapping for CoW Protocol APIs

Based on an analysis of the CoW Protocol's three APIs (Orderbook, Driver, and Solver)[^3] and the CCXT contributing guidelines, the primary API for a CCXT connector is the **Orderbook API**, as it handles user-facing operations like quoting, order placement, management, and querying trades. The Orderbook API is the main interface for traders and integrations, aligning with CCXT's unified trading methods.

The **Driver API** is primarily for internal batch auction management and solver interactions (e.g., collecting orders and coordinating settlements). It doesn't provide direct trading endpoints for users and isn't necessary for CCXT methods, as CCXT focuses on exchange-like trading interfaces rather than backend auction driving.

The **Solver API** is designed for solver engines to implement (e.g., solvers expose endpoints like `/solve` for the driver to call). It's not user-facing and is irrelevant for a CCXT connector, which targets trader operations, not solver competition or batch solving.

CoW Protocol is a non-custodial DEX aggregator using batch auctions, so some CCXT methods (e.g., `fetchOrderBook`, `fetchBalance`) can't be fully mapped due to architectural differences (no traditional order books or custodial accounts). Per the task, we skip impossible features and focus on maximal integration. Authentication uses EIP-712 signing with a private key (no API keys), similar to other DEXes in CCXT like 1inch or 0x. Markets are dynamic (any ERC20 pair on supported chains like Ethereum, Gnosis), so `fetchMarkets` can derive pairs from supported tokens.

Below is a mapping of key CCXT exchange class methods to CoW Protocol routes. All routes are relative to the base URL (e.g., `https://api.cow.fi/mainnet/api/v1` for mainnet). I've prioritized Orderbook API endpoints based on their functionality. Methods are overridden in the exchange class as per CCXT guidelines (extend the base class, implement `describe()` with exchange details, and handle signing/parsing).

| CCXT Method | CoW Protocol Route(s) | HTTP Method | Description/Mapping Details | Parameters/Body (Key Examples) | Response Handling |
|-------------|-----------------------|-------------|-----------------------------|--------------------------------|-------------------|
| `fetchMarkets` | `/tokens` | GET | Fetches list of tradable tokens to derive markets/symbols (e.g., generate pairs like `ETH/USDC`). No direct "markets" endpoint, so synthesize pairs from tokens (focus on common bases like WETH, USDC). | None required. Optional: chain-specific params if multi-chain. | Parse token list into CCXT market format (symbol, base, quote, precision, limits). |
| `fetchTicker` / `fetchTickers` | `/quote` | POST | Gets current price/quote for a symbol. Use a small hypothetical amount to simulate ticker data (bid/ask from quote). Supports multiple symbols via parallel calls. | Body: `sellToken`, `buyToken`, `kind` (sell/buy), `amount`, `userAddress` (optional for better quotes). | Extract `quote.buyAmount`, `quote.sellAmount` to compute price, bid/ask with slippage. Return CCXT ticker structure. |
| `fetchOrderBook` | N/A | N/A | Not supported (no real-time order book in batch auctions). Throw `NotSupported` error as per CCXT guidelines. | N/A | N/A |
| `fetchTrades` | `/trades` | GET | Fetches recent public trades (settled batches). | Optional: `limit`, `offset`, `minDate`, `token`. | Parse into CCXT trade format (id, timestamp, symbol, side, price, amount). |
| `fetchBalance` | N/A | N/A | Not supported (non-custodial; balances are on-chain). Throw `NotSupported`. Use external web3 for wallet balances if needed, but not via API. | N/A | N/A |
| `createOrder` | `/quote` + `/orders` | POST + POST | First get quote/fee, then sign and place order. Supports market/limit via slippage params. Type: market (use quote for execution), limit (set price bounds). | `/quote` body: same as fetchTicker. `/orders` body: `sellToken`, `buyToken`, `sellAmount`, `buyAmount`, `validTo`, `appData`, `feeAmount`, `kind`, `receiver`, `signature` (EIP-712 signed). Required: all order fields; optional: `partiallyFillable`. | Parse response UID into CCXT order format. Handle signing in method (use privateKey). |
| `cancelOrder` | `/orders/{orderUid}` | DELETE | Cancels an open order by UID. | Path: `orderUid`. Query: `signature` (signed cancellation). | Confirm success; return order status. |
| `fetchOrder` | `/orders/{orderUid}` | GET | Retrieves status of a specific order. | Path: `orderUid`. | Parse into CCXT order (id, status, filled, etc.). |
| `fetchOrders` / `fetchOpenOrders` | `/orders` | GET | Fetches all/open orders for the user. Filter by status in code. | Query: `owner` (required, user address), `limit`, `offset`. | Parse list into CCXT orders array. |
| `fetchMyTrades` | `/trades` | GET | Fetches user's executed trades. | Query: `owner` (required), `limit`, `offset`. | Parse into CCXT trades (filter by user). |
| `fetchLedger` | N/A | N/A | Not supported (no ledger API). Throw `NotSupported`. | N/A | N/A |
| `signIn` / auth | N/A (signature-based) | N/A | No login; handle EIP-712 signing per-request in private methods. Set `this.privateKey` and `this.walletAddress` in options. | N/A | N/A |

### Additional Notes

- **Base Implementation**: In your CCXT exchange class (e.g., `class cow extends Exchange {}`), override `describe()` with: `id: 'cow'`, `name: 'CoW Protocol'`, `urls: { 'api': { 'public': 'https://api.cow.fi/{chainId}/api/v1', ... } }`, `has` flags (e.g., `'fetchOrderBook': false`, `'createMarketOrder': true`), and `options: { 'chainId': 1, 'walletAddress': null }`. Implement signing using libraries like `ethers.js` (CCXT can integrate).
- **Multi-Chain Support**: CoW supports Ethereum (chainId 1), Gnosis (100), etc. Parameterize base URL with chainId.
- **Rate Limits**: CoW has limits (e.g., 10 quotes/min); implement `rateLimit` in describe().
- **Error Handling**: Map CoW errors (e.g., 400 for invalid order) to CCXT exceptions.
- **Impossible Features**: Skip custodial features (deposits, withdrawals, margin) as they're on-chain only. No websockets for real-time (batch-based).
- **Testing**: Follow CCXT guidelines—test against staging (barn.cow.fi), ensure unified parsing (e.g., amounts as strings).
- **Other Routes**: Orderbook has auxiliary routes like `/version` (for `checkVersion`), `/solver_competition/auction` (for batch info, optional for advanced fetchTrades), but not core for CCXT. Driver/Solver routes (e.g., Solver's `/solve`) are ignored as they're not trader-relevant.

This mapping enables a functional CCXT connector focused on swapping/trading via CoW's batch auctions. For full code, start from CCXT's DEX examples (e.g., 1inch) and adapt.

## Deliverables

1. **CCXT Connector Class**: A fully implemented `cow` class that supports core trading methods (quotes, order creation/cancellation/fetching, trades), with disabled features clearly flagged in the `has` config.
2. **Custom Extensions**: Quote comparator and risk management bot examples, integrated as optional modules to showcase CoW's advantages.
3. **Documentation**: Comprehensive README updates in the CCXT repo, including usage examples, limitations, integration guides for CoW SDK, and instructions for custom methods like quote comparison.
4. **Tests and CI Integration**: Unit tests covering 90%+ code coverage, ensuring reliability across supported chains, with specific tests for polling and rate limiting.
5. **Open-Source Contribution**: Merged pull request to CCXT, making the connector publicly available.

## Milestones

- **Milestone 1: Research and Setup (September 2025)**: Analyze CoW SDK and CCXT interfaces; review DEX connectors; set up development environment with proxies. (Output: Initial prototype class and feasibility doc.)
- **Milestone 2: Core Implementation (October 2025)**: Build order lifecycle methods, wallet integrations, and polling logic. (Output: Functional connector with basic tests and rate limiting.)
- **Milestone 3: Advanced Features and Testing (October 2025)**: Add quote comparator, bot example, and comprehensive testing for architectural differences. (Output: Beta version with documentation.)
- **Milestone 4: Submission and Review (November 2025)**: Submit PR to CCXT; address feedback. (Output: Merged connector and initial usage metrics.)

## Budget Breakdown

The total requested amount is 15,000 xDAI and 15,000 vested COW tokens, justified by the project's scope and anticipated impact:

- **Development Effort**: 10,000 xDAI (200 hours at $50/hour equivalent, covering research, coding, testing, and feasibility assessments).
- **Testing and Documentation**: 3,000 xDAI (60 hours, including polling and rate-limiting optimizations).
- **Community Engagement and Iteration**: 2,000 xDAI (feedback incorporation, PR reviews, and custom feature development).
- **Vested COW Tokens**: Aligned with xDAI request to incentivize long-term commitment to CoW ecosystem.

This pricing reflects the value to be delivered, including open-source code that can drive sustained protocol growth. Payments are preferred in stablecoins (xDAI) for immediate liquidity, with COW vesting over 12 months.

## Impact Measurement

- **Quantitative Metrics**: Number of CCXT downloads including the connector (tracked via npm/GitHub stats); increase in CoW Protocol transactions attributable to CCXT integrations (e.g., via unique order tags); quote comparator usage showing average savings (e.g., 1-5% better execution).
- **Qualitative Metrics**: Community feedback from CCXT and CoW forums; adoption by trading bots (e.g., GitHub forks/stars); contributions from other developers building on the connector.
- **Verification**: All code will be open-source on GitHub; metrics can be audited via on-chain data and repository analytics. We estimate a 10-20% uplift in algo-driven volume within 6 months post-merge.

This project will demonstrate clear, measurable impact by expanding CoW's reach and reinforcing its position as a leader in intent-based trading.

We welcome feedback from the CoW DAO community to refine this proposal and ensure its alignment with ecosystem goals.

[^1]: CoW SDK GitHub Repository: https://github.com/cowprotocol/cow-sdk

[^2]: CCXT Contribution Guidelines: https://github.com/ccxt/ccxt/blob/master/CONTRIBUTING.md

[^3]: CoW Protocol APIs: https://docs.cow.fi/category/apis