Centrifuge TWAMM grant application

[wischli]

Project Abstract

This application aims to implement a Substrate pallet that seamlessly acts as an opt-in extension for the frame pallet-asset-conversion. The latter serves as a representation of the upcoming Uniswap-v2 style Decentralized Exchange (DEX), integrated within the Asset Hub. This application can be beneficial to any other Substrate chain seeking a straightforward local chain DEX.

Regrettably, the prolonged exchange of large volumes on such DEXes is susceptible to being front-run or subjected to sandwich attacks. We believe that the optimal solution to this predicament is the Time Weighted Automated Market Maker (TWAMM).

Our proposed framework can be incorporated across a variety of Substrate chains, inclusive of the relay chain, aiming to streamline the operations of a simplified Uniswap V2 decentralized exchange. This model effectively mitigates the challenges associated with executing sizeable orders, even within comparatively illiquid markets. It is especially compatible with gradual automated procedures, such as governance-controlled treasury operations, thereby enabling the proficient implementation of a dollar-cost averaging strategy over extended periods. Our recent collaboration on the development of a Multi Asset Treasury has highlighted the necessity of having a non-attackable long-term tokenswap mechanism like TWAMM. Within this context, we have engaged in discussions with the System Parachain team, particularly Joe, who has expressed support for the inclusion of our proposed TWAMM extension onto the Asset Hub

Grant level

• Level 1: Up to $10,000, 2 approvals
• Level 2: Up to $30,000, 3 approvals
• Level 3: Unlimited, 5 approvals (for >$100k: Web3 Foundation Council approval)

Application Checklist

• The application template has been copied and aptly renamed (project_name.md).
• I have read the application guidelines.
• Payment details have been provided (bank details via email or BTC, Ethereum (USDC/DAI) or Polkadot/Kusama (USDT) address in the application).
• The software delivered for this grant will be released under an open-source license specified in the application.
• The initial PR contains only one commit (squash and force-push if needed).
• The grant will only be announced once the first milestone has been accepted (see the announcement guidelines).
• I prefer the discussion of this application to take place in a private Element/Matrix channel. My username is: @_______:matrix.org (change the homeserver if you use a different one)

[CLAassistant]

All committers have signed the CLA.

[semuelle]

Hi @wischli. Thanks for the application, and sorry for the long wait. It looks good to me, so I will share your proposal with the rest of the committee. Thanks for the DCA write-up. I just have some general questions:

• Based on the numbers, you are requesting ~33k USD per person-month, which is about 2.5 the usual rate we see. Is that the actual rate or are the FTEs off?
• Could you summarise the differences between your treasury proposal and this application? I see you left out frontend and audit, but there is still a big difference. Is this due to the pallet_twamm deliverable being a POC?

[Noc2]

Thanks a lot for the application. But I agree with what @semuelle said. We usually pay a lot less for the development of pallets. Especially since the grants program primarily supports the development of a PoC or something similar and not production-ready software. If you want to deploy this on the asset hub, including audits, etc., you need to involve the community at some stage anyway, so it might make sense to immediately apply another time for treasury funding using open gov and potentially a reduced price.

[wischli]

@Noc2 @semuelle We are grateful for the time you've taken to explore our application. Your engagement is genuinely valued!

Your constructive feedback regarding our pricing structure has not gone unnoticed. Following your insightful comments, we've undertaken measures to decrease our fundamental hourly rates, while also making minor modifications to the project scope. This strategic move embodies our pledge to uphold a transparent and client-centric business ethos. Our intent is that this modified proposal aligns more closely with your financial parameters and anticipates your requirements. We are steadfast in our dedication to provide the uppermost tier of professional services, ensuring the most efficient use of grant resources.

Could you summarise the differences between your treasury proposal and this application? I see you left out frontend and audit, but there is still a big difference. Is this due to the pallet_twamm deliverable being a POC?

Following careful consideration and refinement, we have determined it appropriate to present a proposal aligning closely with Milestone 1 of the DOT Treasury proposal, which initially requested funding amounting to $190,000. It is important to emphasize that the DOT proposal also included retroactive funding for the development of the pallet-rewards. However, this component does not form part of the current application as it has been already developed.

Furthermore, in order to remain within budgetary constraints, we have chosen to adopt a more optimistic estimation that does not exceed the originally requested $100,000 (now $75,000) for this grant application.

We usually pay a lot less for the development of pallets. Especially since the grants program primarily supports the development of a PoC or something similar and not production-ready software. If you want to deploy this on the asset hub, including audits, etc., you need to involve the community at some stage anyway, so it might make sense to immediately apply another time for treasury funding using open gov and potentially a reduced price.

We think merely building a PoC would not have the result of actually building something usable for Polkadot. Our intention is to make this widely available to parachains to allow them as well as the Polkadot treasury directly to diversify their holdings safely without the risk of front running or any centralized trust. As such we want to make sure this pallet is well understood and easy to use.

[takahser]

@wischli FYI I'm taking this over for @semuelle since he's currently out of office. Please allow for some time to study and digest your proposal and above conversation, I'm going to get back to you soon.

[Noc2]

Thanks a lot for the updates, and sorry for the delay here. I'm happy to go ahead with it and share it with the rest of the team. Apart from this, a reminder to sign the latest version of our terms and conditions above.

[keeganquigley]

Thanks for the price adjustments @wischli quite the lengthy forum post, but I don't have any questions at this point. Based on your reputation and thorough research, LGTM.

[takahser]

@wischli I'm quoting from your comment:

We think merely building a PoC would not have the result of actually building something usable for Polkadot. Our intention is to make this widely available to parachains to allow them as well as the Polkadot treasury directly to diversify their holdings safely without the risk of front running or any centralized trust. As such we want to make sure this pallet is well understood and easy to use.

However, in your proposal you wrote:

| 1. | pallet_twamm PoC | Config using pallet-conversion-rate as implementor of BasicAmm trait, Structs, Storage as above. |

Could you remove the PoC from that deliverable?

Also, while I agree with the overall sentiment that a TWAMM pallet would be very useful I think you're not the first team to approach a TWAMM implementation. For example, FraxFinance has already delivered theirs >1y ago and I also found this TWAMM reference implementation. For translating one of these existing implementations that consist of a couple of functions to Rust/Substrate I think the price point of 75k is not justified. But at the same time I must admit that I don't know a lot about _TWAMM_s, so if I'm missing something here feel free to correct me. :)

[semuelle]

@wischli, are you planning to address the suggestion @takahser made, or should we review as is?

[wischli]

@wischli I'm quoting from your comment:

We think merely building a PoC would not have the result of actually building something usable for Polkadot. Our intention is to make this widely available to parachains to allow them as well as the Polkadot treasury directly to diversify their holdings safely without the risk of front running or any centralized trust. As such we want to make sure this pallet is well understood and easy to use.

However, in your proposal you wrote:

| 1. | pallet_twamm PoC | Config using pallet-conversion-rate as implementor of BasicAmm trait, Structs, Storage as above. |

Could you remove the PoC from that deliverable?

Also, while I agree with the overall sentiment that a TWAMM pallet would be very useful I think you're not the first team to approach a TWAMM implementation. For example, FraxFinance has already delivered theirs >1y ago and I also found this TWAMM reference implementation. For translating one of these existing implementations that consist of a couple of functions to Rust/Substrate I think the price point of 75k is not justified. But at the same time I must admit that I don't know a lot about _TWAMM_s, so if I'm missing something here feel free to correct me. :)

Sorry for getting back late, I was away until yesterday. Thanks for spotting the PoC - I've taken it out of the application.

On the topic of cost and timing, I just wanted to note that our plan for 7.5 weeks of work with 1.5 full-time team members is what we think will let us deliver a qualitative pallet that's not just a repeat of the same old solidity TWAMM code. We're considering all the tasks involved which includes some retroactive work as well - researching TWAMM and comparing with HydraDX's DCA, writing a detailed spec, setting up the pallet the Substrate way, really getting into the nitty-gritty of the Substrate pallet-asset-conversion implementation (which might include submitting some small PRs), and of course, the necessary documentation. We feel the timeline we've set is totally fair. We thought we were all set with the money stuff, so let's talk if there are any lingering questions.

[wischli]

@wischli thanks for your answer.

We're considering all the tasks involved which includes some retroactive work as well - researching TWAMM and comparing with HydraDX's DCA, writing a detailed spec, setting up the pallet the Substrate way, really getting into the nitty-gritty of the Substrate pallet-asset-conversion implementation (which might include submitting some small PRs), and of course, the necessary documentation

If you're not merely translating the existing TWAMM implementation 1:1 but instead improve it (also, but not limited to Substrate-specific adjustments) it'd be interesting to have that covered as well. Maybe you could add a deliverable for an article where you outline the improvements you came up with, when you compare your "TWAMM 2.0" spec & implementation to the original one. In that case I'd be willing to approve as well.

Thank you for presenting the proposal for a comparison article. Your suggestion is indeed well-founded! I have now incorporated it into the list of deliverables. I hope this will address everyone's concerns and preferences. I really appreciate everyone for their valuable input and time dedicated to this matter!

[github-actions]

Congratulations and welcome to the Web3 Foundation Grants Program! Please refer to our Milestone Delivery repository for instructions on how to submit milestones and invoices, our FAQ for frequently asked questions and the support section of our README for more ways to find answers to your questions.

Before you start, take a moment to read through our announcement guidelines for all communications related to the grant or make them known to the right person in your organisation. In particular, please don't announce the grant publicly before at least the first milestone of your project has been approved. At that point or shortly before, you can get in touch with us at [email protected] and we'll be happy to collaborate on an announcement about the work you’re doing.

Lastly, please remember to let us know in case you run into any delays or deviate from the deliverables in your application. You can either leave a comment here or directly request to amend your application via PR. We wish you luck with your project! 🚀

[taqtiqa-mark]

I think this project is a valuable contribution.

Adding it to pallet-asset-conversion may improve the state of play.
Or it may not:

I wonder if the approvers (@Noc2, @takahser, @semuelle, @SBalaguer, @keeganquigley ), might consider asking for the hype to be dialed down in the delivered documentation.

Specifically, the advice to Treasuries or others that this is a solution for, protects against, or is otherwise a set-and-forget exercise in the face of front running:

... the prolonged exchange of large volumes on such DEXes is susceptible to being front-run or subjected to sandwich attacks. We believe that the optimal solution to this predicament is the Time Weighted Automated Market Maker (TWAMM).

and

... to allow them as well as the Polkadot treasury directly to diversify their holdings safely without the risk of front running...

I don't read the Paradigm document as claiming a solution to front running. I certainly don't read any claim about optimality. Nor do they claim to eliminate the risk of front running.

To my mind, they suggest the opposite. Front running needs to be monitored and manual intervention is required, by canceling the order being front run:

If a trader places a sufficiently large long-term order, other traders may be tempted to front-run it, buying up the asset on the TWAMM's embedded AMM and elsewhere in order to sell it back to the trader later as the long-term order pushes prices up.

Because users can cancel their long-term orders at any time, we expect overly aggressive front-runners to be exploited by other traders, keeping the overall impact of information leakage in check.

If those "other traders" don't spontaneously comply with these expectations, or you don't cancel your long-term order until they showup. You've been successfully front-run.

Also, the Paradigm document is careful not to define "overly aggressive front-runners".

They stand in contrast to, I presume, acceptably aggressive front-runners.

[Noc2]

@taqtiqa-mark, I might be missing something, but can you share with me the exact lines in the grant application doc from which you took the quotes? Additionally, everyone has the right to share their opinion/beliefs as part of an application. We mostly care about the concrete open-source deliveries defined in the milestones that are actually the requirements of the contract. Furthermore, to quote the paradigm document on the topic:

If a trader places a sufficiently large long-term order, other traders may be tempted to front-run it, buying up the asset on the TWAMM's embedded AMM and elsewhere in order to sell it back to the trader later as the long-term order pushes prices up. Because users can cancel their long-term orders at any time, we expect overly aggressive front-runners to be exploited by other traders, keeping the overall impact of information leakage in check.

[taqtiqa-mark]

@taqtiqa-mark, I might be missing something,

I don't think so...

but can you share with me the exact lines in the grant application doc from which you took the quotes?

They come from the above representations, and can be found in the application:

L23:

In our opinion, the most elegant solution is TWAMM (Time Weighted Automated Market Maker.

Additionally, everyone has the right to share their opinion/beliefs as part of an application.

Agreed.

We mostly care about the concrete open-source deliveries defined in the milestones that are actually the requirements of the contract.

Yes, I just suggested possibly toning down the hype in the documentation, from anything like what I quoted. Anyone reading the code after a while, will realize that what Paradigm state still applies - you still have to monitor for front running and be ready to cancel your order when it happens at a level you are unhappy with.... the "overly" vs "acceptably" aggressive front running point I made.

Furthermore, to quote the paradigm document on the topic:

Yes, this is the same section I quoted above...

If a trader places a sufficiently large long-term order, other traders may be tempted to front-run it, buying up the asset on the TWAMM's embedded AMM and elsewhere in order to sell it back to the trader later as the long-term order pushes prices up. Because users can cancel their long-term orders at any time, we expect overly aggressive front-runners to be exploited by other traders, keeping the overall impact of information leakage in check.

[keeganquigley]

Hi @wischli how is the milestone coming along?

[wischli]

Hi @wischli how is the milestone coming along?

Hi @keeganquigley! Due to recent adjustments in our engineering team's capacity, we have not yet commenced work on this project. Our focus has primarily been on our core product, which we had to prioritize. We anticipate initiating work on the TWAMMs project in the coming weeks. Rest assured, I will provide updates as soon as we reach our targeted milestone. We regret any inconvenience this may have caused and appreciate your understanding.

[keeganquigley]

Thanks @wischli we understand that delays happen, but in this case, could you please file an amendment to extend the timeline in the milestones? It can be a rough estimate, doesn't have to be exact. But adding a few months should be approved relatively quickly and will allow us to update our records and budget accordingly. Thanks!

[keeganquigley]

pinging @wischli

[keeganquigley]

Hi @wischli how is progress coming on M1?

[keeganquigley]

pinging @wischli

[wischli]

Hi @wischli how is progress coming on M1?

Sorry for the late reply @keeganquigley - your message got buried during my summer vacation. Unfortunately, we haven't had the capacity to work on the first deliverable yet. It looks like we won't be able to get to it before 2025. I'm really sorry for any inconvenience this change in priorities might cause.

[keeganquigley]

Hi @wischli thanks very much for the update, it is much appreciated. A timeline adjustment like this would require an amendment, but in this case, since the starting date would be more than 6 months out, it's probably best to close the grant for now, and it can potentially be re-opened in the future when you are ready to work on it. The same amount of committee approvals would be needed to re-open it, but we would take your current situation into account. Let me know if this sounds good and we will proceed with closing it for now. Thanks!

[keeganquigley]

Hi @wischli we will go ahead and close the grant for now since the starting date is over six months out, but feel free to comment here next year if/when you want to re-open it. Thanks.