Why not just Statemint needs an AMM but (likely) every parachain and we should do our best to agree on a shared interface

Tech Talk
1

Introduction

This is closely related to the AMM discussion that is happening in the Statemint Roadmap Update. I think though in general this discussion deserves a separate topic but I recommend you read this thread before diving into this lengthy essay.

I fundamentally agree that every parachain will likely have a need for doing small atomic swaps natively and I’m hoping to start a bit of a discussion on the push for a standardized AMM pallet for every parachain to use and for us as a community to agree on requirements and design for it. This is largely sharing our own research at Centrifuge which has been going on for a few months internally but also in response to Statemint’s proposal to build an AMM and a call for Statemint to build a design that works for everyone avoiding some of the mistakes we’ve made with the diverging implementations of fungible assets, asset registries and other parts of core functionality that have competing and incompatible implementations.

Standardization and Adoption are key to making Polkadot successful

I am a broken record in this but one of the things I can’t say often enough is the need for standardization. Having variations in how to LP or how to trade on AMMs across all parachains will cause huge hurdles for adoption of Polkadot. Just one example, if a market maker needs to build a completely new toolset for every new parachain native AMM to be able to provide liquidity and make markets it will be near impossible to get any kind of liquidity on these AMMs.

Now if we assume there’s a good reason for Statemint to implement an AMM, the fact that this AMM will be implemented by Parity, that it will be governed by DOT and generally treated as the most conservative AMM it’s probably logical to assume that it will both get a large amount of traction but also that for anyone else to build a competing AMM they will likely have to implement the same interface to provide a user & developer experience that isn’t too foreign to everyone that will be familiar with Statemint’s solution.

So this is our chance to discuss and reach consensus on what the AMM should do and hopefully influence not just the development of Statemint to better suit our needs but also end up with a piece of core infrastructure that can make every parachain better.

Is this not a death sentence to all DEX projects on Polkadot?

In short, I don’t think so. There are two conflicting datapoints I want to give on this point:

  1. Looking at Ethereum I think we’ve seen that a lot of users have started using DEX aggregators and are relying on these dapps to find the best price on any AMM. I have no reason to believe that this wouldn’t happen in Polkadot.
  2. Metamask Swaps charges a ~0.5% commission on top of any trade and itself uses the Uniswap and other AMMs as well as RFQ trades to fullfil these trades. This product is massively profitable for them ($Ms in revenue a month last year) even though users are guaranteed to get a worse price than if they went to 1inch or Paraswap. This shows the power of the default option.

So what is critical? That any “default” AMM implementation needs to not get a monopoly. Monopolies are extremely hard in crypto (the whole idea of open blockchains is that they are free of monopolies).

In the end though I think the benefits outweigh the costs for the overall ecosystem. Let’s not forget even though uniswap v1 initially had close to 100% market share initially alternative models like Curve (more efficient for correlated assets) and Balancer’s mutli-weight pools managed to get significant traction. These projects have been able to capitlize on these innovations. AMM focused parachains will have a future and will be able to compete.

Use cases for parachain native AMMs

Native atomic swaps for fee payment

There are many reaons why parachains will have need to swap tokens natively. These reasons already have been discussed but I believe the need to allow transaction fees to be paid in non-native tokens will lead to chains adding AMMs. Having a single gas token on Ethereum makes it somewhat tolerable; in Polkadot the fact that there are >20 tokens used to pay transaction fees makes this a much harder problem. This is not just an issue for end users but also the parachains themselves. For example to execute an EVM call on Moonbeam the Centrifuge parachain needs a way to buy Glimmer to pay for gas. Doing that with XCM on a specialized DEX chain is not practical as it would add another XCM message with complexity, cost & delays.

Slow large volume/expensive to manipulate swaps

In contrast to small atomic swaps that could be extremely helpful for arbitrary token transaction fees there’s also a need for hard to front run slower transactions that can be used by a parachain to trade without the risk of being front run. As an example, the treasury wants to contiunously buy DOT to pay for parachain slot or the opposite, the Polkadot treasury wants to buy stablecoins to pay out bounties in stablecoins we need the precise opposite of what a traditional AMM gives you (atomic swaps with immediate execution with even in relatively illiquid assets). A governance vote is inable to time the market and highly predictable so for such a transaction to be executed as market order on an AMM is problematic. It will be guaranteed to be front run.

Our team at Centrifuge has researched a few approaches of how to address this:

  • Instead of using an AMM you could use a dutch auction: If I want to make a trade I start an auction: I want to sell 1000 DOT for $100’000 and I will lower my price by 0.01% every block. At any point in time users could trade against the current offer. This solves front running provided you set the initial price right but if the price goes down too much during the auction time your trade might never get fulfilled.

  • RFQ/Auctions: you could make it an auction (MakerDAO uses auctions to sell bad debt. The problem with these auctions are that they are very capital inefficient. Every person bidding on the auction locks up capital for the duration they are leading auction without a guaranteed return. You could also make something very simple: add a price oracle and just make an order book based exchange and put a limit order at oracle price. The obvious downside here is that you are now required to trust oracles.

  • TWAMM (Time Weighted Automated Market Maker): a paper written by a few folks by Paradigm is in our opinion the most elegant solution. It’s an extension of the well known constant product (uniswap-v2 style) AMM that adds an additional functionality: users can add orders that are split up in infinitely small chunks and traded every block. AMMs don’t work well because a large order cause massive slippage and can easily be front run and there is no capital at risk when sandwiching a transaction within a single block. By splitting the order over hundreds of blocks into small chunks means slippage on the AMM is minimal and it increases the cost of price manipulation enormously: instead of atomically manipulating the price within a block you have to artificially manipulate the price across hundreds of blocks and any other trader could exploit you inflating the price by trading against you. This solution is very elegant because slow automated processes (e.g. the governance controlled treasury) effectively can just dollar cost average over long periods of time. This means even large orders can be done in relatively illiquid markets.

All of these approaches are not atomic (i.e. can’t be executed in a single block). This second category of use cases (expensive to manipulate non-frontrunnable swaps) are an interesting use case with a very specific need that is not well served by other DEXs yet needed by a passive trader like a treasury or a blockchain more generally. We believe implementing a TWAMM model is the best way for slow/passive processes (like governance) to swap tokens.

So I want to end this with two questions to other parachains:

  1. What other functionality or aspects have other parachain teams looked at when evaluationg integrating a native DEX?
  2. Where does standardization help and where is not not necessary?
9 Likes
2

One point I would like to raise is that AMM is not the only way to solve the multi token fee payment issue.

For example, Statemint already support using minimal balance as an indicator to calculate how much fee should be charged. Basically, using an oracle for token price.

On Acala, whereas we do have DEX and the first chain supporting multi token for fee payment using DEX. We are not using DEX to handle fee payment any more on happy path. Instead, we created a special fee pool that only holds small amount of token (5 ACA) and all the fee related swap are processed by this pool without involving Acala Swap. This is mainly for performance optimization that it doesn’t make sense to perform potentially compute intensive operation (because likely multiple swap are required for assets that do not have direct pair with ACA) for every transaction. A fee pool implementation uses a static price (that’s updated when the pool is drained with rate from DEX) can make the work simpler. This means the rate in fee swap may not necessary match to the Acala Swap price but it is largely a non-issue for such small amount of funds.

This logic can be easily implemented on any parachain, just replace the Swap integration with some XCM code to perform the swap on the remote chain.

1 Like
3

I think the goal of statemine is to minimize governance but adding a fee pool that needs to be created and integrating a DEX it should trade against on a third party chain will be quite the overhead here. Either Statemint can limit to using one DEX which is also questionable or then DOT holders will have to pick the right trading venue for each token. How will DOT holders decide if the Acala, HydraDX or Parallel DEX should be used to do the swap?

1 Like
4

The simple solution is to use an open execution model for the swap. e.g. auction.

If the fee pool want’s able to perform a swap, it can just make an auction and allow the highest bidder to take the asset. Arbitrage bot will happily take the order and counter trade it on other dex/cex.

In fact, this will work better the more parachains using this. This means more trades for arbitrage bots to take and therefore incentive more people to create/run those arbitrage bots.

5

Unfortunately this would still require someone to take price risk across more than one block which I think is not a desired property if you don’t want a parachain to take any risk but still accept third party tokens for fees.

6

I think that’s fine.

It is the arbitrager taking the risk but they should be good at that. The risk is minimal if counter trade happens on CEX. The risk is more on DEX but they will just self-decide what premium they would like to take to cover the risk. This means parachain will need to pay a bit more expensive fee on the trades. The amount should be relatively small and why shouldn’t parachain paying some fees for this service?

Also in the end, it is user paying tx with alternative pays the fee. This means user may need to pay say 20% more when transacting using non native token. But the tx fee should be low enough to the point 20% more isn’t going to be significant anyway. On the case when parachain capacity is near the limit and 20% become significant, then people can just pay tx fee with native token to avoid tx fee (and reduce tx computation by bypassing the swap logic).

7

Don’t the fee pools that you are proposing essentially are a tiny liquidity pool with a fixed price? If you already do that why don’t you just implement an actual AMM then? I think the difference is so small that it’s almost easier to just do that.

1 Like
8
  1. Less computation overhead (i.e. less weight and less tx fee). The swap logic could be invoked for every tx and it is something we want to optimize for.
  2. Less liquidity requirement. A tx fee pool only need like $5 of liquidity and it can be provided 100% by the onchain treasury so no need of external LP and no need to manage LP at all.
9

My post could be relevant here as well, although I think the DEX we have in mind is quite different from what is currently applied in defi.
A DEX on Encointer to boost onboarding and inclusivity of the entire web3 space may

1 Like