Grant Application: TWAP Orders

CoW Grants Program Funded Grants
,
1

TWAP Orders

Grant Title: Time-Weighted Average Price (TWAP) Orders

Author:

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.
  • Actively independently developing with emerging decentralised technologies, including Swarm and Waku.

Additional Links:

Grant category: Protocol Order Flow / Developer tools

Grant Description:

Problem: Currently DEX aggregators / AMM marketplaces only provide market and limit order types. Conversely, on a TradFi exchange, more advanced order types are available, providing utility to traders.

Solution: By making use of EIP-1271 smart contract orders, implement more advanced order types, with this grant specifically targetting TWAP (Time-weighted average price) orders.

Grant Goals and impact:

  • Increase CoW protocol utility through DeFi-market unique order types (e.g dollar-cost averaging by use of TWAP orders).
  • Increase concentration of orders by timing, leading to increased likelihood of CoWs.

Milestones:

Basic TWAP:

Basic TWAP logic would be implemented as multiple fixed size orders, with constant time spacing, enforcing a user-specified floor / ceiling price (sell / buy) as appropriate. Deliverables include:

  1. Implement a user-upgradeable proxy contract with TWAP logic. This would allow users to upgrade their deployed proxy’s implementation contract, yielding gas savings on token approvals, and contract deployments.
  2. Implement a factory contract for user’s to deploy contracts from (1).
  3. Comprehensive test suite for contracts.
  4. Example script for submitting TWAP orders off-chain to Cow protocol.
  5. Documentation for integrators / developers.

Grant Timeline:

Complete by end of January 2023.

Note: The above timelines do not make for allowances / timing associated with audit completion.

Funding Request:

$10,000. Half paid up-front ($5,000), with the remainder paid upon satisfactory completion of code as determined by the member(s) of the CoW team.

Budget Breakdown:

  • $10k: development / labor cost.

This budget does not include any costs associated with audit by a 3rd party. It is expected that CoW would undertake the necessary steps / cost for audit. Any cost overruns associated with meeting the standards of an external audit (additional testing / code fixes) would be paid out of the development cost.

Gnosis Chain Address (to receive the grant):

0x070E0a700E36D303a0Ce3fe37976dD70974D7883

Other Information: As an active member of the CowDAO Grants Committee, I hereby refrain from voting / signing on this proposal so as to eliminate conflicts of interest. In determining the timelines associated with this Grant, I have taken into consideration workloads due to my position as a Committee member, 3rd party work, and allowed appropriate buffer to ensure the Grant Committee’s continuance.

Referral: N/A

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

3 Likes
2

The TWAP advanced order will provide utility to traders and add further value to the CoW Protocol. I am signalling my support for this proposal.

3

Great proposal, I’m supporting it!

4

Great proposal @mfw78 !
I think that this first example of ERC1271 based smart order is of great value to CoW Protocol and its users. Adding unique and differentiating functionality while increasing the chances for CoW within TWAP orders.

As we already have another grant approved aimed to eventually work on this use case, (golang client) I’d love to see some thought around the interface between those grants.
Are there any TWAP related functions that would be useful to expose in the CoW Protocol SDK?

I would like to propose approval of the first phase outlined above (ASAP), with a soft commitment to approve the second phase upon satisfactory completion of phase one :handshake:

(In addition, would love to get more details about the need and functionality that keeper bots will add to advanced TWAP orders)

5

Hi all,
Thanks for the positive feedback.

From my understanding, currently the golang client is a utility / wrapper for Cow’s API, and serves as a basis from which golang developers can integrate with the Cow services backend (such as auction batch retrieval, price quoting etc). For Phase 1 of this proposal, I wouldn’t foresee any specific functionality to expose (as all the orders would be submitted to the Cow backend API by the TWAP order, and these would then be visible to users of the golang client by polling for the batch auctions).

The biggest issue that I foresee with TWAP orders in general is that by placing them in a public order book, this leaks information to the market, presenting opportunity for the market to move against tranches of the TWAP order. In order to minimise this impact, I can think of a couple of approaches:

  1. TWAP orders are held privately (off of the Cowswap public API), and only submitted on a just-in-time basis. This would primarily be the value proposition for a keeper bot, such that the bot is then able to introduce some time randomness / variable order sizes, without leaking this information well in advance (this assumes a self-soverign bot).
  2. In order to increase the risk to those wanting to front-run a tranche of TWAP orders, the Cowswap Protocol could be modified to include some form of trusted randomness. This could be done by the solvers on a commit / reveal basis, or using external randomness providers, such as Chainlink VRF (though Chainlink VRF isn’t available yet on Gnosis Chain). TWAP orders could then be broken down into epochs, with the randomness forming jitter / noise as to when the TWAP trades in that epoch become executable.

Use of bots for (1) would be the solution requiring the least modification of the existing Cowswap protocol and wouldn’t place additional trust assumptions on the Cowswap protocol.

6

Thanks for explaining!

I think that this kind of front running that you want to avoid will usually be done programmatically, in which case orders can be decoded from the TWAP contracts and even posting orders “just in time”, makes them public in the CoW Swap order book for enough time to front run them.

so although I agree front running (non-atomic) is a general concern, I think it should be evaluated based on evidence of actual activity and be addressed on the Protocol level if anything.

to add to this, I assume keeper bots will add additional complexity and cost overhead.

Based on the above I’m not sure there’s justification for implementing it.

But there are definitely other improvements that should be considered once the basic implementation is done!

As I mentioned, I propose to approve phase 1 and consider the details of phase 2 later on as we gather more insights.

7

Sure, the above points are salient. It certainly was / is the intention to structure it in a multi-phase approach so insights can be integrated / built upon.

I’m OK with Phase 1 approval, and defer to the Committee with respect to any voting / approval process to be undertaken per CowDAO / GrantsDAO processes.

8

Can you please amend the OP saying that phase two is provided for information purposes and will be revised and approved separately? :pray:

Then I think you can proceed to be the first to use the new transparent grant approval flow using cowgrants.eth snapshot space :partying_face:

9

For the sake of clarity and to avoid ambiguous language, I have narrowed the scope of the grant to basic TWAP orders. It is envisioned that insights gained from this Grants Proposal will inform a future grant to expand functionality. For reference, expanded functionality in the original grant proposal included:

Phase two (advanced features):

  1. Advanced implementation, of which the contract from phase (1) is capable of upgrading to. This implementation would use a Merkle-tree root hash to store an arbitrary amount of orders (including different assets, order sizes, validity times, and prices), optionally storing tokens in GPv2RelayerVault for gas efficiency.
  2. Expand test suite and documentation for advanced implementation.
  3. Write a keeper bot, written in rust, that supports day of week, size, and price modifiers, reducing the duration that pricing information is available in the public market.
  4. Package keeper bot in docker container for ease of deployment in cloud environments.

Grants Committee Snapshot

Given that overall, the feedback for this seems to be positive, I have created a snapshot proposal that you may review and cast your votes accordingly.

URL: https://snapshot.org/#/cowgrants.eth/proposal/0xe8e214a79b2682d9949b0314768ea128e39859144ad904a34df6396a48f06066

NOTE: Above snapshot recreated due to lack of quorum. Seems most are on holidays!

1 Like
10

To all those that are following, the grant proposal was passed with quorum, work commenced and has now been completed. The repository for the work is available at GitHub - rndlabs/cowswap-twap-orders: 🐄🐮 Time-weighted average price orders for CoW Protocol.

2 Likes
11

Hi,
Work on this Grant Application is complete. Audits have been passed and the contract has been deployed on Ethereum Mainnet, Gnosis Chain, and Goerli at address 0x87b52ed635df746ca29651581b4d87517aaa9a9f.

The repository contains source code for:

  1. Deployed contracts.
  2. A command-line utility to interact with a Safe with the configured TWAP fallback handler, to create and cancel TWAPs.
  3. A tenderly web3 actions watchtower to relay the orders autonomously to the CoW API.

In addition, the README.md contains extensive documentation as to the architecture and method of use.

For the purposes of this grant, I consider all milestones / mandate to be satisfied.

2 Likes