Bounty for CoW AMM / solvers integration

Introduction

The CoW AMM design was launched a few months ago by the CoW DAO as an alternative AMM design that mitigates many of the problems known in the existing and widely used AMMs today.

To initiate the launch, a simple framework was set up that is generating programmatically CoW AMM orders every few minutes for the existing CoW AMMs based on some oracle prices; this is what we call Phase 1. However, to take full advantage of the power and potential of CoW AMMs, a more flexible and dynamic way to accessing their liquidity is needed. Specifically, solvers should be allowed to trade with the CoW AMM in any batch auction they want to and with amounts determined by them; this is what we call Phase 2.

The core backend team has addressed this by setting up the infrastructure so that solvers can indeed fully control the ways the trade with a CoW AMM. The weekly release on May 21, 2024, thus, will initiate Phase 2 of CoW AMM, turning it into a full-fledged function maximizing AMM.

To incentivize solvers to integrate CoW AMMs as soon as possible in this Phase 2, we propose to set up a bounty of total value 10k DAI, split into three prizes (5k, 3k and 2k DAI) and financed by our grant program.

We now provide some details around CoW AMMs and then proceed to define the terms and rules associated with the proposed bounty.

Function maximizing AMM

In Phase 1 of CoW AMMs, an oracle was used to add orders for those AMMs to the orderbook. While this is relatively close to the description of CoW AMM in this paper, it does restrict the solvers in executing the intent of Cow AMMs. Phase 2 of the project is meant to unleash the full potential of CoW AMMs and turn them into a fully functioning function maximizing AMM.

In phase 2, Instead of adding individual orders to the order book on behalf of a CoW AMM, solvers can freely propose trades for those AMMs. Those trades are of very similar form as normal user trades as they require to specify traded amounts and a fee. Unlike regular orders, solvers can choose which of the two tokens is the buy and which is the sell token.

There is a hard restriction enforced on the smart contract of not violating the constant product invariant of CoW AMMs. Providing better executions to a CoW AMM is rewarded similarly to how it is rewarded for user orders, via surplus which enters ranking and rewards.

The surplus for a CoW AMM is computed conceptually differently compared to user orders. A CoW AMM for tokens A and B with reserves X and Y, respectively, and buying x of token A for y of token B will have a surplus of

x - y X / Y - x y / Y,

naturally expressed in token A. This is just the change in the constant product invariant,

(X + x) (Y - y) - X Y,

rescaled by Y. When batching a trade for a CoW AMM together with users orders, the surplus of the CoW AMM is added together with the surplus of user orders, as usual.

CoW AMMs do pay network fees as normal user orders do and settle at uniform clearing prices and uniform directional prices. CoW AMMs can be used in CoWs with other orders or traded with external liquidity, but there can ever be at most one order for the same CoW AMM in a batch.

Implementation via JIT orders

Some details can be found in the documentation.

  • CoW AMM orders are included in the solutions as JitOrders.
  • If AMM should buy x for y, the JitOrder needs to be a fill-or-kill sell order with sell amount y and limit buy amount y * X / Y + x * y / Y. Then, the usual surplus for that order corresponds to the nonlinear surplus defined above. The reference driver does not check for correctly set limit amounts. Deviating from the limit amounts defined above amounts to lying about the surplus of your solution.
  • Generate a suitable signature and the order uid as described in the documentation.
  • Appropriate pre- and post-interactions need to be included in the new preInteractions and postInteractions field of the solution. This is described in the linked documentation as well.

For every distinct CoW AMM there can be at most a single order for it in a batch. This also applies to the CoW AMM orders that are already included in the orderbook: if a JIT order is used in a batch, then the order in the orderbook must be ignored.

Bounty specifications

  • Settle 20 orders for CoW AMMs satisfying the following properties:

    • The order is created as a JIT order.
    • The order must receive more surplus than executing the automatically generated order.
  • The first three solvers satisfying the above are rewarded a bounty.

    • 5k DAI for the first solver.
    • 3k DAI for the second solver.
    • 2k DAI for the third solver.

Authors: @harisang , @AndreaC , @felixhenneke

5 Likes

Generally, I’m in favour of incentivising solvers to integrate natively CoW AMMs. For the purpose of this grant though, I think there needs to be more specific definition as to which CoW AMMs qualify, and I would advocate that only CoW AMMs that are deployed using the CoW AMM standalone contract should qualify for this. This both ensures that there is the most gas optimal solution available for those who use CoW AMMs (making them grossly more competitive) and provides incentive for legacy CoW AMMs to be migrated to the new standalone contract.

Furthermore, the integration of the standalone CoW AMM contract is simpler from a solver’s perspective, given that there is only a pre-interaction required (there is no more post-interaction requirement in order to reset the committed swap).

3 Likes

In light of the proposed Balancer DAO / CoW DAO collaboration (see here) and @mfw78 comment, we propose to modify the bounty specification in the following way:

A total reward pool of $10K DAI will be distributed among up to 3 solvers who successfully settle at least 30 Balancer CoW AMM JIT Orders before 2024-08-31 23:59 UTC. Of these 30 orders, a minimum of 15 must be CoWs between a user order and a Balancer CoW AMM, and a minimum of 5 must be rebalancing trades in which the CoW AMM trades against external liquidity.

If only one solver meets the criteria, they will receive $10K DAI. If two solvers meet the criteria, the first solver will receive $6.7K, and the second solver will receive $3.3K. If three solvers meet the criteria, the prize pool will be split $5k/$3K/$2K.

For ranking solvers:

  1. COWs receive 3 pts
  2. Rebalancing trades receive 2 pts

Only in the event of a tie:

  1. Highest number of COWs settled against CoW AMMs wins; then
  2. The first to settle a COW wins
5 Likes

Thanks for the proposal, thanks also to mfw78 for the great comments. I’m in support this proposal with the modification. This incentive to solvers to integrate CoW AMMs will definitely help accelerate their adoption.

4 Likes

I echo @Chim9 and @mfw78’s comments. Happy to see a modified proposal go to snapshot for voting.

2 Likes

Given there was no clear objections to the first version of the grant/bounty, which unfortunately did not reach quorum. I decided to repost a slightly updated version of it.

https://snapshot.org/#/cowgrants.eth/proposal/0xc94ba1724c48ecbb2e656f19057c68b8bf138ae2bc6a693493d85312ca405462

1 Like

Hi all. Just wanted to give an update that the proposal was approved, and two solvers claimed the bounty!

  • Furucombo ranked first, with a prize of 6.7k DAI
  • Fractal ranked second, with a price of 3.3k DAI

We used this query that looked at a few weeks of data and reveals a clear ranking among the two solvers. All solver teams are aware of the metrics we used, and there are no objections to the result.

The corresponding rewards addresses of the two solvers for Mainnet can be found here

  • Furucombo: 0x0587d465fcd4a8212b66b96d99b41a8c16d4bd9b
  • Fractal: 0xd4676b4de3a982a429a8dbe90d4a7e7cfb4769a5
2 Likes