Grant Application: CoW AMM Expansion

CoW Grants Program
1

Grant Application: CoW AMM Expansion

Grant Title:

CoW AMM Expansion

Author:

@bleu @yvesfracari @ribeirojose @mendesfabio

About You:

bleu collaborates with companies and DAOs as a web3 technology and user experience partner. We’re passionate about bridging the experience gap we see in blockchain and web3.

Additional Links:

Our work for CoW so far:

  • [CoW] AMM Deployer: a Safe app to deploy new CoW AMM pools from a Safe Wallet.
  • [CoW] MilkmApp : a Safe App designed for creating and managing Milkman orders within the CoW ecosystem. It empowers DAOs to sell tokens while deferring the price determination to execution time, leveraging price checkers for optimal pricing strategies.
  • [CoW] Python SDK (ongoing): we’re helping CoW put together a Python SDK to provide for developers for querying on-chain data, managing orders, and integrating with the CoW Protocol’s smart contracts.
  • [CoW] Stop-Loss (closing): a Safe app UI to allow for multisig wallets to fully manage stop-loss orders.
  • [CoW] Have I been MEV’d (ongoing): a set of bots and a dashboard integrated with ZeroMEV API to help the web3 community to be aware of MEV losses.

Grant Category:

User interface and user experience (UI/UX)

Grant Description:

Following the successful deployment of the CoW AMM Deployer Safe Application, which received positive community and committee feedback, we identified several enhancement opportunities:

  • Additional price oracles: Currently, the app relies solely on two audited price oracles (Uniswap V2 and Balancer). Some users are reporting that are missing extra price oracles (example). Additionally, a Chainlink Oracle was developed by one user that needed tokens that weren’t supported by the available options. To support a wider range of tokens and provide more reliable pricing options, we plan to integrate Chainlink, SushiSwap, Uni V3, Pyth, and Balancer Composable Stable Pools oracles.
  • Introduce New Pool Invariants: We will add the Constant Weighted Product invariant to offer users more flexibility in liquidity provision ratios.
  • User flow: Currently, users must first create a new Safe Wallet before transferring funds to begin using the CoW AMM Deployer. This isn’t the default flow to provide liquidity into pools and can cause issues for the users as reported here. This is going to be solved by integrating the new standalone version of the contracts being desenvolved by the CoW Team. Also, this will allow multiple AMM positions for the same wallet leading to an improvement of the CoW AMM Manager page to track multiple AMMs.
  • Balancing liquidity flow: As mentioned in this post and also executed here, balance the liquidity to add it on the CoW AMM isn’t so easy. The best solution is to use TWAP to do it.

Grant Goals and Impact:

Our grant aims to further enhance the CoW AMM Deployer Safe Application developed by us, focusing on specific areas for improvement. By incorporating additional price oracles, including the Chainlink Oracle, and expanding to support new oracles such as SushiSwap, Uni V3, and Balancer Composable Stable Pools, we aim to increase the range of supported pricing data. This initiative not only strengthens the infrastructure but also increases the range of tokens supported.

Additionally, we plan to optimize the user experience by introducing a Constant Weighted Product invariant, making the application independent of the Safe environment, and refactoring the flow for large amounts of tokens. These changes will simplify the process for users, making it easier and more efficient to access and use the CoW AMM. Overall, our grant is geared towards making the CoW AMM Deployer Safe Application more effective and impactful, attracting more liquidity to the CoW Protocol and protecting more users from LVR.

Milestones:

Milestone Due Date Payment
CoW AMM Oracles 3.5 weeks 7k xDAI + 7.25k COW
Weighted Product Constant 5 weeks 10k xDAI + 10.25k COW
Standalone Contract Integration 3 weeks 6k xDAI + 6.25k COW
TWAP for token balancing 3 weeks 6k xDAI + 6.25k COW

CoW AMM Oracles:

Development of the contracts and full integration with the CoW AMM Deployer APP for the following price oracles:

  • Chainlink;
  • SushiSwap (using the already Uni v2 contract and integrating with the App);
  • Uniswap V3;
  • Balancer Composable Stable Pool;
  • Pyth;
  • RedStone.

Weighted Pool Invariant

The only invariant available for the CoW AMM is the Constant Product. This means that regular users have to be exposed to a 50/50 proportion of each token. With the Constant Weighted Product contract, users would be able to provide liquidity in any proportion of each token.

This milestone also covers the integration of the new pool invariant into the CoW AMM Deployer.

One open item we’d be seeking help from CoW’s team concerns who to call for auditing. Balancer has launched a program to support the developer ecossystem with Certora, who has audited other Balacer contracts. We’d love to understand whether you’d be open to setting up a similar program to help developers get audited from the same teams who have reviewed CoW’s contracts and are thus familiar with your codebase.

Standalone Contract Integration:

CoW team is working on a standalone version of the contracts, which will make possible a smoothier experience for users.

This milestone will include a release of the CoW AMM Deployer for the standalone contract version. This will allow:

  • Refactoring to use standalone contracts version (1 week)
  • App refactoring to work inside and outside Safe (1 week)
  • Refactoring of the “CoW AMM Manager Page” to multiple pools. (1 week)

TWAP for token balancing

CoW AMM can be also used by DAOs (or whales) who want to invest a large amount of tokens. However, these tokens might be not on the right balance that you want to invest in the CoW AMM. With this feature, we will add an additional option so that you can balance your tokens before creating your AMM, using a programmatic order that combines the CoW AMM with TWAP.

Funding Request:

We suggest releasing milestone payments upon the approval of each milestone. All COW payment can be vested over 1 year.

Budget Breakdown:

The budget includes the hourly rates of a developer during the execution and a project manager on a need basis. It also includes the diluted maintenance costs for 1 year. The budget doesn’t cover contract audit costs.

Gnosis Chain Address (to receive the grant):

0x554866e3654E8485928334e7F91B5AfC37D18e04

Other Information:

  • All the code will be open-source from day 0. We’re open to feedback during PRs as well;
  • We’re happy to answer any questions and are open to feedback about this proposal;

Terms and Conditions:

By submitting this grant application, I acknowledge and agree to be bound by the CoW DAO Participation Agreement and the CoW Grant Terms and Conditions.

1 Like
2

We are currently in the process of already merging in the Chainlink oracle from a community contribution so this could be removed from the scope here for contract development, however it would be required for user interface integration.

We have had interest from external parties (Pool providers) that would be looking at implementing different AMM invariants. I think that at the moment funding explicit invariants may be outside the remit / potentially result in work duplication - I would caution about including this as part of the scope.

I think we would have to double-check on this one. Inherently there is no difference with regards to doing a one-sided contribution to a CoW-AMM versus staging the rebalanced funds before deposit. If @AndreaC could weigh in on whether this would be a valid inclusion of scope (or not really required), this would be great.

In general, I’m very much in favour of continuing the Grants relation with bleu given the excellent work that has been produced to date. The CoW-AMM Deployer (to be a safe app + EOA capable with the new standalone contract) is a no-brainer IMO, as well as implementing additional price oracle references.

2 Likes
3

Thank you @bleu for the application, we very much appreciate your continuous support!

I agree with @mfw78 points. Concerning the pool invariants: from the solvers’ side, each new invariant has a different formula for surplus and hence requires a specific logic on how to access the pool and maximize its surplus. I don’t think solvers have fully integrated the “50/50” logic yet, so I would be careful with proposing a different invariant. Also, we’ll probably need to choose which invariants we expects solvers to support (80/20? 70/30?) before allowing people to create these pools. For all these reasons, I would leave this issue for the future (perhaps an additional grant).

With respect to contributing liquidity to the AMM: with a TWAP, you convert your tokens before adding them to the AMM, which remains balanced; with a one-sided contribution, you add liquidity to the AMM, which then trades half of the contribution and is then balanced. So the difference is trading before contributing liquidity or after contributing liquidity, but in the end both trades are executed by solvers under the same logic. The difference is minimal.

Having said that, I think it would be valuable to have a system that simplifies streaming tokens to the AMM and build up its TVL (either one-sided contributions or two-sided contributions). Internally, we are using LlamaPay (for one sided contributions to the COW/WETH pool), but it took a few iterations to set up.

2 Likes
4

Thanks for all your comments, here are our thoughts on each topic:

  • Oracles: When quoting this milestone we already considered the Chainlink contract that was created by the community. We forgot to make it explicit.
  • Weighted Pool Invariant: Thanks @AndreaC for the solver integration challenges description, from the Balancer experience with Weighted Pools we were thinking that the 80/20 proportion would be a good choice. Think that we can separate this part of the proposal and propose later or maybe collaborate with the external parties mentioned by @mfw78 to not have a duplicated work. I can’t edit the proposal but please don’t consider this milestone for this grant. What do you guys think about it?
  • TWAP for token balancing: We were thinking of this feature for the case where a large AMM is being created with unbalanced liquidity, thinking that would be wise to balance the liquidity before adding it to the AMM with a TWAP. Are you saying that in terms of efficiency, this is very similar to a one-sided contribution, right? Also, can you explain a little more about how (and why) are you guys using LlamaPay to add liquidity? We want to include the “Add/Withdraw Liquidity” action on this refactoring (maybe we could add the “Stream Liquidity” option as well)
5

Hi @bleu ,

noted on the weighted pool invariant. With respect to adding liquidity to a CoWAMM, you are correct that a balanced contribution is recommended if you want to add a large amount of liquidity at once. Otherwise, the CoWAMM will immediately produce a large rebalancing order, which, depending on the token pair, may incur slippage.

Of course, if you start with only one token, you still have the problem of converting half of your holdings to the other token before adding them to the AMM. You could use a TWAP, and add liquidity to the AMM after each execution of the TWAP, which is equivalent to creating a balanced stream toward the AMM. But then, if you are streaming liquidity to the CoWAMM, you can also do one-sided contributions, which seem easier to set up. Alternatively, you can add liquidity to the AMM after you complete the TWAP, which is also a useful feature to have.

For our own COW/ETH pool, we first seeded the AMM with a few large balanced contributions, and then we set up a one-sided stream using LlamaPay.

For your grant: I was just pointing out that, from our experience, token streaming may be a useful feature, and having something that makes it easy to do would be quite valuable.

6

I think something that could be added to this would be a “migrate legacy CoWAMM” so that users that had deployed previous CoWAMMs are presented with an option that allows them to migrate from their previous CoWAMM to a standalone contract CoWAMM. This gives them a “no-brainer” upgrade as it’s more gas efficient, and allows the backend to programmatically determine whether or not the CoWAMM is a canonical CoWAMM, and therefore entitled to be protocol fee exempt :+1:

7

Thanks you both for the comments! I will think about how to develop the add liquidity stream feature into the app. (if you have ideas about how to do it, let me know). Also, the “migrate legacy CoWAMM” action is a great addition that we can include as well. In the next days, I will post an updated version of the milestones.

2 Likes
8

Just to make sure we’re on the same page. Do you think that we should include the TWAP and the one-sided stream features or just the one-sided stream?

9

I think it would be great if you could include both TWAP and one-sided streaming in your proposal. Of course, the grant committee may ask you to drop one of the two based on financial considerations. But I would nonetheless include both.

1 Like
10

We can’t edit the proposal anymore, so I have pasted below the updated version of the proposed Milestones. Please, let us know your thoughts on this new scope.

Milestones:

Milestone Due Date Payment
CoW AMM Oracles 3.5 weeks 7.25k xDAI + 7.25k COW
Standalone Contract Integration 4 weeks 8.5k xDAI + 8.5k COW
TWAP for token balancing 4 weeks 8.25k xDAI + 8.25k COW

CoW AMM Oracles:

Development of the contracts and full integration with the CoW AMM Deployer APP for the following price oracles:

  • Chainlink (using the already developed community Chainlink oracle);
  • SushiSwap (using the already Uni v2 contract and integrating with the App);
  • Uniswap V3;
  • Balancer Composable Stable Pool;
  • Pyth;
  • Redstone.

Standalone Contract Integration:

CoW team is working on a standalone version of the contracts, which will make possible a smoother experience for users.

This milestone will include a release of the CoW AMM Deployer for the standalone contract version. This will allow:

  • Refactoring to use standalone contracts version, including “Migrate legacy CoWAMM” button to enable users to migrate (2 weeks)
  • App refactoring to work inside and outside Safe (1 week)
  • Refactoring of the “CoW AMM Manager Page” to multiple pools. (1 week)

Token balancing

CoW AMM can be also used by DAOs (or whales) who want to invest a large amount of tokens. However, these tokens might be not on the right balance that you want to invest in the CoW AMM. To do it, there are two options, you can do a TWAP to balance the tokens or stream the tokens directly to the AMM and let it rebalance. @AndreaC reported that it has a similar performance. The descriptions of both methods are:

  • TWAP: Since it uses the Composable CoW framework, it will be available just for Safe Wallets. Here a TWAP will be created with the AMM contract as the receiver. The TWAP will add liquidity to the AMM already balanced (2 weeks).
  • Llama Pay: A single side stream will be set to slowly add liquidity to the AMM using LlamaPay contracts and bots. LlamaPay relies on a deposit logic in which the user has to deposit native tokens on the LlamaPay Bot contract (2 weeks).

This method will be available for AMM creation and add more liquidity to an existing AMM. Thresholds will be defined to identify big and unbalanced deposits to suggest the token balancing feature.

We are thinking of using the TWAP feature for Safe Wallets and Llama Pay for regular wallets.

3 Likes
11

My perspective is that milestones 1 and 2 are important just for keeping a decent UX and level of service to the existing users of CoW AMM.
Milestone 3 is a “nice to have”, so I’d keep it for future iterations based on the actual usage and feedback we get from users.

If this is acceptable, I’d be in favor of moving to snapshot for voting

3 Likes
12

All right! I will be moving the milestone 1 and 2 to snapshot , I agree that both milestones are core additions that are being requested by the community.

However, I think the third one is really important to attract more big liquidity providers / DAOs, so I would keep this milestone in mind for future interactions.

13

Moved to snapshot voting: Snapshot