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:
- 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.
- 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:
- What other functionality or aspects have other parachain teams looked at when evaluationg integrating a native DEX?
- Where does standardization help and where is not not necessary?