Thread by @GuthL

1/n We just publish the new extension of dAMM on which I have been working for some time with @Brechtpd from Loopring. I believe it could be a groundbreaking design in the upcoming multi L2s.
A quick thread 🧵:

https://twitter.com/StarkWareLtd/status/1420716961990860807

@Brechtpd 2/n For those who follow @StarkWareLtd work, we publish a few months back the first version of dAMM: an L2 AMM design where the restrictions are enforced on L1, simplifying greatly the AMM design of a constrained system like StarkEx.

3/n Not only it provides a simpler design, but it also provides additional advantages like the ability to lend the pool asset using an Asset Manager as proposed by BalancerV2.

4/n With this new version, we wanted to explore a shared AMM between multiple L2s. Since dAMM operates on each L2 without locking liquidity there, we felt that some nice design space was available to us.

5/n We quickly realized that the hard part of sharing an AMM between L2s is the concurrency risk that this AMM carries if multiple users can trade on it at the same time.
The concurrency risk would make it impossible for each L2 to know if it can settle safely.

6/n One way to prevent it would be to have a centralized entity providing quotes on behalf of the AMM on each L2 at the same time. In such an approach, the combination of L2s behaves as a single L2 from the perspective of the AMM: a single swap, split according to each L2 needs

7/n One problem with this approach is that we must guarantee the execution of the whole swap to maintain self custodian. This also means that all L2s would have to settle their state in the same operation. This approach is sound but would be problematic to implement.

8/n We then realize that we could pivot this idea on its head. What if, instead of having a single state-managed offchain and maintained on all L2 at the same time, we have an AMM that has multiple states on the same liquidity pool.

9/n This is where the asynchronous dAMM comes from. Under this condition, each L2 can satisfy the trades it committed to as long as the L1 contract holds enough liquidity.

10/n Due to arbitrage, all states should always go back to an equilibrium ratio. So what are the consequences of this design? The main consequence is that LPs are now in the worst-case subject to n times the IL they would have suffered under a regular UniswapV2 AMM.

11/n In markets where IL is limited (Curve), this risk is massively constrained making dAMM extremely efficient.

12/n For other markets, we must implement IL mitigation techniques. The main idea on this is the Health Factor that we codesigned with Loopring. This minimal version will guarantee that the dAMM liquidity ratio does not fall lower than 80% than any L2 dAMM state.

13/n The notion of the Health Factor (HF) will evolve with the additional features and capacities that L2s become more expressive and powerful. Under this expressivity, funds could trustless flow between L1 <> L2s, enforcing tighten HF constraints.

14/n The last bit I went to discuss: enabling L1 <> L2 simultaneous trading. dAMM with a small modification can support L1 trading. L1 trading comes with an additional difficulty which is that the HF cannot be really mitigated out of the box.

15/n Regardless, LPs can choose to take more risks on themselves and be exposed also to L1 trading. Assuming some incentivization, I really believe that this method will enable L2s to source additional liquidity in their markets.

16/n Lack of liquidity has been one of the most important growth factors in the adoption of L2 DEXs. I hope dAMM will enable the market to push for their adoption.
TLDR: dAMM cool, more apes in the reservoir!