Grant Application: Tally Recipe for CoW Swaps

CoW Grants Program
1

Grant Title: Tally Recipe for CoW Swaps

Author:

Raf Solari of Tally. raf@tally.xyz

About You:

Tally (tally.xyz) is the leading interface for on-chain DAOs. DAOs use Tally’s frontend and API to create and pass proposals. DAOs on Tally run on the Governor smart contracts. Tally’s mission is to make it easy to use DAOs with strong, on-chain trust models.

Additional Links:

Website: https://tally.xyz

Twitter: https://twitter.com/tallyxyz

Github: Tally · GitHub

Grant Category: Integrations and protocol order flow

Grant Description:

Tally will add no-code flow to the our Create Proposal Tool that allows non-technical users to create, propose, and place CoW Protocol orders from DAO treasuries. Orders created on Tally would use the Milkman order type to increase the chance that DAO swaps have good execution.

We would add a ‘Swap’ action to the list of options in our Create Proposal Tool (pictured below).

image
image720×696 53.9 KB

We would build a custom UI for doing a swap (pictured below).

image
image720×696 53.9 KB

We would build a UI for displaying Swap Proposals on the Tally Proposal page

Grant Goals and impact:

Our primary goal is to allow DAOs to do swaps directly from their treasury, without needing to trust an intermediary or custodian. This feature would drive volume to CoW swap and help DAOs manage runway and hold the right mix of treasury assets.

Milestones:

  1. Design and user testing (1 week of work)
  2. Create a swap recipe using CoW Protocol (5 weeks of work)
  3. Show swap on the proposal page (1 week of work)
  4. Testing (1 week of work)

Grant Timeline:

8 weeks of work.
We can do some of the work in parallel, so we hope to deliver the grant in less than 8 weeks.

Funding Request:

  • 30k xDAI
  • 150k COW, linearly vesting over one year
  • Additional volume-based incentives in COW

Budget Breakdown:

The funds will be used for product design, development and testing. 40 hours of design, 30 hours of testing, 240 hours of development.

Part 1: Design and user testing - 50 hours at $150/hour: $7500.

  • Mock up the Swap action UI and the Swap creation UI, and Swap proposal UI
  • Gather feedback on the mocks from users to make sure that the interface is clear

Part 2: Swap action and swap proposal recipe development

  • Design and development of UI for entering information about the swap - 40 hours at $150/hour: $6000.

    • Dropdown to pick the asset to sell from the treasury
    • A form field to enter the amount of asset to sell.
    • Form field to pick the asset to buy
      image

  • Calls from Tally frontend to CoW APIs show asset prices and price checkers - 80 hours at $150/hour: $12000.

    • Tally will generate price estimates of assets to sell
      • Tally will shortlist price checkers from Uni v3 and Chainlink. Tally will also allow the address of a custom checker and “No checker”
      • Tally will use CoW Protocol’s API to estimate the assets received at current market conditions. Tally will show that to the user.
    • Tally will encode the calldata client-side
      • This will eventually be moved api-side to enable api users
    • Tally will call its proposal API for saving the calldata as a draft

  • Proposal simulation - 40 hours at $150/hour: $6000.

    • Tally will simulate that the proposal will create the order without errors. We will use a simulation tool such as Tenderly.

  • Order Preview - 40 hours at $150/hour: $6000.

    • Tally will estimate the price that the order would execute, if it executed now. We will do this by fetching quotes from solvers.
    • Tally will show an error if the order won’t fill at current market conditions

Part 3: Showing a swap proposal

  • Proposal UI - 40 hours at $150/hour: $6000.Once a swap proposal has been created on Tally, it goes to vote. Tally will show some information about the swap in on the proposal page to voters:

  • Assets to buy/sell and the amount

  • Simulation of the proposal

  • Estimate of the swap purchased. Plus, a disclaimer that execution will change from the current market conditions.

Part 4: Testing - 30 hours at $100/hour: $3000.

  • Tally will test the recipe on mainnet to make sure that orders execute successfully

Proposed funding schedule:

Milestone Funding
Upfront payment 15k xDAI
Completion of all 4 parts 15k xDAI and 150k COW, 1 year linear vesting
12 months after completion Performance-based reward, see below:

We propose this performance-based reward for swap volume driven to the protocol:
First $10M volume: 60k COW
Additional $50M volume: 120k COW
Additional $200M volume: 240k COW

Volume milestones must be surpassed within 12 months to be eligible for funding.

All COW tokens granted will be subject to 12 months of vesting.

Gnosis Chain Address:

(to receive the grant)

Address gno:0xfd4c2579664286ae699c5e25aeccfb5df58e8d85

Other Information:

  • We believe that CoW Protocol is the best way for DAOs to do a swap. On-chain AMM swaps are vulnerable to front running, because DAO proposals are public. To do off-chain trades, DAOs need a custodian and an intermediary, which isn’t a good trust model for them.
  • DAOs that use Tally collectively hold ~$10B of treasury assets
  • ENS successfully did a $15M CoW Swap from their treasury in February using Tally. ENS delegates hand-coded the swap proposal. We expect that making this process easier and safer will lead to more DAOs doing CoW swaps.
  • Tally has built successful recipes before. The Tally no-code transfer flow has been used to transfer $80M+ in DAO treasury assets since launch in March 2022.
  • Items that would be out of scope for now, but we could consider them in the future:
    • Delegate the order cancel role to a trusted party. We will put an example of how to create a proposal to cancel an order in our docs.
    • Support for slicing up the order using TWAP
    • Show whether the order was filled or killed in the Tally UI
    • Support for other networks besides mainnet
  • We will open source as much of the CoW swap code as possible under an MIT license, but some of the glue code will touch parts of Tally that are not yet open source. We aim to open source at least 80% of the code covered by this grant, including the “Recipe” that constructs and encodes transactions of CoW orders. Our goal here is for our work to be useful to future applications when integrating CoW Protocol.

Open source

We will also publish an architecture diagram of how the pieces fit together. Here are all the pieces that we’d build for a Recipe, and which ones we can open source:

Frontend Swap Recipe class

  • This class will be fully open-sourced.
  • This is the engine of the recipe, it is responsible for encoding user inputs into requestSwapExactTokensForTokens (including priceCheckerData) on the Milkman contract.
  • We expect this class might be reusable for other frontends that need to create swap proposals

** Client calls to Tally API to get a DAO’s available swaps **

  • This GET request will be fully open-sourced.
  • It fetches a DAO’s treasury balances.
  • It queries CoW API’s native_price endpoint with results from b to generate a list of sell tokens.
  • Returns sell and buy token lists.

React components to show available swaps

  • There isn’t a good way to open-source this component, because it’s coupled to many other things. The UI looks similar to the “select a token” component on https://swap.cow.fi/

User selects a swap pair

  • We will open-source the UI for this component.
  • Some of the glue code for this component doesn’t make sense to open-source

Client calls Tally API to get a swap quote

  • This GET request will be fully open-sourced.
  • It queries CoW API’s quote endpoint with the values on the Swap Recipe class instantiated in 1

Client populates React components with the response from the quote API

-There isn’t a good way to open-source this component. It is also coupled to many other things. The UI looks similar to the swap component on https://swap.cow.fi/, so if someone rebuild this component, they can start there.

User saves proposal

  • This will be fully open-sourced.
  • The calls to encodeForBlockchain() or encodeForAPI() on the Swap Recipe class if the user is saving a proposal or a draft, respectively.

Referral:

Some of the team members building CoW Protocol mentioned the grant program to the Tally team at ETH Denver.

Terms and conditions:

Include this line in your grant application:

By applying for this grant, I agree to be bound by the CowDAO Participation Agreement 2 and the COWDAO Grant Terms and Conditions 4, with the caveat from above:

We will open source as much of the CoW swap code as possible under an MIT license, but some of the glue code will touch parts of Tally that are not yet open source. We aim to open source at least 80% of the code covered by this grant, including the “Recipe” that constructs and encodes transactions of CoW orders. Our goal here is for our work to be useful to future applications when integrating CoW Protocol.

1 Like
2

I support this proposal. Allowing DAOs to do swaps directly from their treasury will likely increase volume through CoW.

3

Hi @rafso,
Thanks for the grant application. Using CoW for DAOs is a great use-case.

In reviewing the grant application, from my perspective, I would like to see clarification on:

  1. The GrantsDAO terms and conditions stipulate the requirement for open sourcing of all intellectual property that is funded by grants. I note that there is a disclaimer that “80%” will be open sourced. From my perspective, this needs to be explicitly outlined from the start so that we know exactly what will, and will not be open sourced.
  2. Can you please clarify the “API calls to show asset prices and price checkers”? Nominally, would Tally be rolling their own Quote API endpoint on the basis of this grant?
  3. How will order cancellations be handled?
  4. Our current funding arrangements have run on a 50% up-front, and 50% on delivery. I’m concerned with the breakdown in funding arrangements. From reading the “parts” of the grant, it seems that while admittedly the bulk of the work (and therefore funding requirements) would be in Parts 1+2, if Part 3 isn’t deployed - would this still be usable (note, in terms of usable for this, I’d think that it makes sense that an order should be able to be created and previewed / voted on by participants in a DAO - this is afterall the bread and butter of Tally). For this reason, I would like to see either a stronger argument as to why the funding should differ from 50% / 50%, or to see the grant application amended to reflect this.

Overall, I’m glad to see Tally engaging, and hope that this is one step among the many on Tally’s path to becoming a fully open source, publicly funded, public good for a health governance ecosystem in our fledgling blockchain world.

2 Likes
4

Thanks for your questions. I updated the original post to address them. I’ll add more color below:

Good point. I added an Open Source Section to explicitly outline which parts are not open source. Generally, these parts are glue code or tightly-coupled react components that it doesn’t make sense to reuse elsewhere.

We aren’t rolling our own quote API. The API calls would go to CoW’s quote API.

This scope doesn’t include a no-code way to create an order cancelation. If a DAO needs to cancel an order, they can construct a cancel transaction by hand using Tally’s “Custom Action” proposal flow or from e.g. a Hardhat script.

Long-term, we think it makes sense to pick a trusted third party to handle cancelation as part of the initial proposal. We were thinking that it makes the most sense to tackle that in a separate project if needed, but we’re open to other opinons.

Good point. I broke things out to be transparent about budget. I’ve updated the milestones to be 50% upfront and 50% on delivery, to keep things simple.

Let us know if you have any more questions.

Thanks,
Raf

5

Thanks for the detailed response @rafso.

As part of this, in the repository, I think it should be a requirement for an architectural diagram so open source coders can understand the architecture, and what is and is not open source, so as to have a complete picture of the system, and any assumptions therein.

If this is the case, for accompanying documentation, I’d suggest that an example / walk through of how to do this should be done for the initial release.

Is it your intention to use the CoW SDK for integration (please kindly excuse the seemingly obvious question). A new CoW SDK has been released and we would very much like to work closely with grantees to get feedback on the SDK to better improve it. We will setup a discord channel where devs have access to CoW Devs / Grants Team directly.

Apart from the minor nits above (which mostly center around documentation requirements that I think should be included), I indicate my conditional support of this grant application.

6

Happy to add that!

Good idea. We’ll add that, too.

The sdk doesn’t help with our use case, unfortunately. The sdk assumes a web3 provider, but Governor doesn’t have a web3 provider. Instead, we have to construct a transaction and pass it to the Governor contract to execute later, if the proposal passes.

Also, we plan to create Milkman orders. As I understand it, those aren’t supported by the sdk yet.

1 Like
7

I support this proposal, it’s good to see that the proposal have being updated following the mfw78 great questions/comments.

8

It should help with the quoting use case, but certainly not with order submission due to the Web3 Provider issues you mention.

Nonetheless, it looks like there is reasonable temperature for this to move to voting by the grants committee.

@rafso Can you please create a snapshot vote on the cowgrants.eth snapspace?

2 Likes
9

Proposal is live!

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

10

This proposal should be resubmitted so it can be ratified on Snapshot. Please note, the Grants Committee did reach consensus internally, unfortunately, some of us we’re on leave during the vote.

2 Likes
11

Additionally, @rafso would you mind removing the previous snapshot vote that failed to reach consensus, just to keep our snapspace clean. It’s anticipated the lack of consensus for the snapshot was due to signers being away for holidays.

3 Likes
12

Thanks. I reposted the proposal here: Snapshot

2 Likes