[trustless://interop.landscape] Workshop - The Art of AMM

Transcript

agent running. >> Okay. >> Hi everyone. Can you hear me? >> Nice. Nice. I'm glad that it's not very hour crowded. So, everyone have some space. Okay. Okay. Guys, how many of you are liquidity providers in into MM? >> Oh, nice. That's like half of the Yeah, half of you. Okay, nice. So, today we will talk about AMMS.

We will see what are their like current inefficiencies and what we are proposing to do with this. So, I will start with the question what is capital efficiency? So yeah there are like a plenty of different research papers which are trying to measure capital efficiency and compare capital efficiency of different liquidity providing solutions automated market makers. So I saw is something like volumes per capital which AMM can attract.

But on the other side, some papers claim this is a fees which can you attract per capita or maybe yield or maybe some other things which they measure capital efficiency. So reading some papers I came up to conclusion that I do not understand what is capital efficiency for real. So okay I tried to find to take a look from the other side what inefficiencies we can find in existing AMM models and how we can address them. So the very first inefficiency which we tried to measure was how much of A mm capital is

being utilized for for real for trading and we found out that this numbers is amount of liquidity liquidity which was never leaving pools for 90 percentages of time during this year. This means that only five percentages of unis swap 2 liquidity was participated in actual trading and yeah for sure there are some concentrated liquidity protocols like unis swap v2 and v3 this is a little bit different it's like an average temperature in the hospital but yeah it still makes sense that this liquidity is

not working so yeah I don't know, but from my point of view, this looks like inefficiency and we will try to address it. By the way, this QR code would lead you to a dual analytics dashboard where you can verify everything. You will see SQL queries and more details uh dashboard with details about percentiles of time of this of the amounts of the capital shares of the capital being unutilized. Okay, on this slide I'm showing how existing AMM pools approach is actually working.

You may notice that for liquidity provider providing liquidity for multiple different assets is actually a fragmentation of their capital. They have to fragment their most liquid assets. It's stable tokens. is wrapped either wrapped bitcoin the most liquid ones are being fragmented among different opportunities by providing liquidity to tens of different assets that's also inefficiency from their point of view and one more point here is that this capital is being locked inside the pools what means being locked you can withdraw it any block yes but

being locked means that it's restricted in its functionality. It's defy disabled. This means that your funds in those pools are only able to be swapped, transferred to taker and from taker during swap. You can't use them for defy. You can't vote in DAO. You can't do nothing. And this is happening since 2017. And we're trying to challenge this approach to solve those three huge inefficiencies.

This idleness, this fragmentation for liquidity provider and this is huge amount of locked capital which is defy disabled. We are proposing new approach. We call it shared liquidity layer aqua 1 in aqua. It works differently for every liquidity provider. Capital stays on their wallet and AMMs are getting access to this liquidity on demand whenever it's actually needs to be swapped.

And this is also unlocking your liquidity. If you have some DeFi enabled assets, you could use them in DeFi, vote in Dow, do other things. How does it look like from AMM point of view? Whenever taker is coming to AMM for a swap, AMM is getting virtual balances from Aqua and using those balances to compute swap amounts and then AMM using Aqua to get access to maker liquidity by pulling assets from maker wallet and pushing the back. During pull and push,

virtual balances are getting updated. So, Aqua here is actually a settlement layer for transfers and also an accounting layer for virtual balances for AMMs. With unlocked liquidity, you could do much more than we even originally expected. You could vote in DAO, participate in VT tokconomics, you could leverage your liquidity with money market. I will show it on the next slide. Moreover, you could borrow liquidity on demand from money market right during the swap. But this would require some additional development from

liquidity provider side. So, how does liquidity leverage looks when you can turn your 1,000 bucks into 3,000 bucks of collateral and 2,000 bucks of depth. So, economically, it makes sense. You still own 1K. You could achieve it with different approaches. You could deposit your 1K, borrow 800 bucks, deposit this 800 bucks, borrow more. What you borrowed, you have to put as collateral again and borrow more. And then the end, you could end up to having 3K collateral and 2K depth. It's still three minus 2,

it's 1K, but you have three different stable tokens, which you could provide as a liquidity to three different pairs. through Aqua to AMMs and this means that each asset will participate in two pairs like USDT to USDC and USDT to USDS for example. This means that you will have 6K of virtual liquidity but you came with only 1K. So you got 3K leverage through unlock feature and 2x more leverage through shared liquidity feature. So those capital efficiencies coming from those two different

properties shares sharing shared and unlocked they're being compounded. So you could elevate your earnings as liquidity provider to like new hats and you don't need to have any support from Aqua point of view. you you just can open a make this leverage then open aqua and make it work as a shared liquidity. The only thing which needs to be supported here from IMM side is that it should rather push first and pull second elsewise it will not be able to exchange big amounts like you can't

withdraw pull one K from the this uh position because you will be underized it would lead to revert. So AMM should support this feature to push first and pull then. So yeah, we also support this feature in our AMM. But that's you will see this next. So what is capital efficiency after what I show it to you? I think that capital efficiency is no more a protocol metric.

It metric it's metric of liquidity provider efforts. and risk appetite. The more you work, the more you get, the more leverage you could have. So yeah, there is a thing called toxic flow and non-toxic flow in AMM space and I think that we should redefine this with a new thing which I call fair volumes and unfair volumes. I think that fair volumes is something what your protocol, your liquidity, your position, your strategy deserves from the market according to the prices it offers for

the takers. And unfair volumes are volumes which were dedicated to some protocol without considering any other opportunities. Like if your front end is sending some volumes to your smart contracts without considering other options for better price, it's basically unfair volumes. So yeah, with Aqua, no flow is toxic anymore. And the next slide, the next section of my slides are about swap VM. This is actually our approach to build modular strategies in AMMs and not only limited to AMMs which could

work on top of Aqua or without Aqua on their own. It's called VM because it's virtual machine. I always been asked for like few past days like what the virtual machine are you competing to EVM to salana VM to tone VM not really that's actually name of architecture this is basically now smart contract on solidity for EVM but this could be a protocol for any other blockchain in terms of architecture virtual machine means that it should oper operate with something called instructions.

And here it is. It operates with instructions. So you could define your trading strategy with composable instructions which could serve different business logic you wish to achieve starting from bottom. You could use different swap formulas. You could use flat fees, dynamic fees. You could have concentration if you want. You could concentrate from one side, from both sides, whatever you wish. You could also have decay spread.

Oh wow. I will be more loud or something. Okay. So, decay spread is something what we previously called money swap. Like five years ago, we invented thing which sells arbitrage opportunity as a Dutch auction. And now we're making it composable with other instructions. So you could get this arbitrage for arbit Dutch auction for arbitrage traders with concentrated liquidity all together.

Just place those instructions, select which of them you need and you will get this highly composable behavior. So yeah, but how is that possible that we made separate instructions which are not aware of each other? They're written completely separate. But how what do they do? How they are built? So the core architecture invention is actually swap registers. It's data model here. Here is it. It is. Yeah.

It's just four variables balance in and out amount in and out where in and out means direction of the assets in assets means assets which are going to maker wallet out means assets which are leaving maker wallet at this specific swap. Balances are actually virtual balances from Aqua or like real balances for something else. Meanwhile, amounts are provided by taker. They taker could provide one of the amounts. For example, if taker provide amount in this does mean that they provide amount they want to send spend and we have to compute with our instructions which amount we

going to give them. If take a provided amount out this means they specified how much they would get and our instructions have to compute how much we should charge them. So yeah next I would provide three examples of instructions of how exactly they working on this data model to achieve this composibility instruction level composibility. The very first and very obvious one is constant product amm. So it just makes sure that balances multiplication before swap is equal to balances multiplication after swap. It's obvious that balances

after swap would be balance in plus amount in and balance out minus amount out. So we can basically express amount in and amount out out of this expression. And yeah that's the only thing which this instruction compute that was simple. Okay let's go to something more complicated. Okay concentrated liquidity to concentrate liquidity the only thing we need to do actually is to shift balances. We have to add some constants computed offchain to balances.

It's like two lines of code, but you could achieve concentrated liquidity. It is as simple as that. I'm not lying almost. But there is a trick. If you would collect some fees with a flat fee instruction or dynamic fee instru instruction, this price range would increase. Yes, that's a problem. I mean, yeah, we could live with this, but some liquidity providers would prefer their strategy to maintain specific range. Okay, we have a separate instruction for this. This instruction we called XYC concentrate

grow price range and we wrote another one. We called it XYC concentrate grow liquidity. How it's different? The only difference is that after each swap it's being readjusting those deltas by invariant increase where invariant is just balances multiplication. So we just get new balances multiplied divide by all balances multiplied and readjust all deltas. So that was easy. We spent some time to came up to this but it's actually pretty simple code in solidity and yeah regarding the money swap or how

we call it spread decay I would explain you how does it work and how it's selling arbitrage opportunity within Dutch auction actually when swap happens you could see the starting points of red lines and blue lines The starting point of red line is something where balances were originally. Both lines, both axis are balances. So some swap happens and we're moving our balances to the beginning of the blue line and then swap in the opposite direction.

Does not immediately start from the red point. It's or from the blue point. It still starts from the red point from the origin. But we have like a conception of virtual balances which are just starting linearly move from red point to blue point. You will see it's like a straight line here and at some point arbitrage is happening and you could see it's like a line swap on this invariant curve and you could see that real balances are following the same curve because it's balance change during swap for virtual balances and real balances it's the same

and then virtual balances again start decaying to real balances. And again arbitrage opportunity happens. This happens multiple times until your real balances will meet virtual balances. And what why we build this? We built this five years ago and now we're imagining how we can achieve the same within instructions of this swap VM. So the only thing we have to do here is actually to make make it feel like pre when we swap in back direction we are pretending that swap previous swap never happened yet or never happened fully. So it's being

applied gradually changing balances and that's kind of >> Dutch auction which lets liquidity provider to capture most of the value. When we had running this as a money swap project five years ago, we made some measurements and we saw that arbitrage traders start to earn 10 times less but they still do their function. They do rebalance the pool. Meanwhile, liquidity providers started to earn two times more. This actually means that liquidity providers and arbitrage traders they usually earn comparable amounts of money. So yeah,

this is one of the efficient mechanism to capture value in favor of liquidity provider and in if when we try to fit it into our instruction model of swap VM is just changing balances like this increasing one of the balances and decreasing another balance to pretend previous swap not happened fully yet and it's decaying over time. So this instruction is like 20 30 lines of code but it's like structured with a library a little bit. So yeah, >> if you would consider development of own AMM,

>> you would usually want to implement some novel swap logic, some swap mechanism, some innovative idea. But to implement it, you have to deal with all those things. You have to write code for deposits withdrawals shares, accounting, everything. swap settlement itself, how exactly a transfer should happen in which direction? Is it flash swap or not? Flesh swap. But now if you would build on top of swap VM, you could try to implement your logic in a composible way and you would get instruction level composibility.

This means that you could make your logic work in a modular way with every other instruction. For sure, not every instruction is compatible with everyone else. So yeah, it's matter of programming on swap VM to build a proper strategies. Some instructions are for AMMs. Some instruction are for single directional swaps like instruction for Dutch auction or instruction for TWWAP or instruction for DCA or any other instruction. Some of them are compatible with each other, some of them are not.

So if you would be able to express your novel logic in this paradigm of this data model of input and output balances and amounts, you would be able to achieve composibility with existing models. And that's pretty awesome from my point of view. And that's it. Thank you very much. Uh, I think we have time to answer questions.

>> Any questions? >> Could you repeat the last phrase? Uh yeah, I I would explain one second. As far as I understood the question uh because I can't hear really well and I was told to not leave this perimeter.

Yeah. Uh yeah it could end up that during the swap virtual balances are fine and some swap amounts are being computed but at the end maker doesn't have this amounts on their wallets. That's what you asked. Yeah that's correct but that's matter and business of taker to not to try to dig into liquidity which is not existing. The thing is that takers are getting smarter and smarter. Now we have all those aggregators, solvers, network. So it's getting more and more complicated to perform transactions on your own especially when you interact with liquidity sources. It's pretty comparable to experience if you would

try to fill someone's limit order. It should be also filled by someone else before you. It's pretty similar. So some of your strategies could stuck with uh illi liquidity. If you don't have liquidity on your balances, they would stuck and they would not work. And if some liquidity will be dropped on your wallet, you could face immediate impermanent loss. Yeah, I would recommend liquidity providers to close their positions when they are liquid and then refill wallets. But even if they have not closed them and they faced impermanent loss, it's still not a showstopper. I mean, it's impermanent.

When or if prices would get back, you would be in the same exact situation as you always had liquidity, but you would had a little bit less fees because you were not able to trade them. So, yeah, that's the answer. So, yeah, more questions. Anyone else? >> Yes. Yeah, I would recommend to check out Aqua source code. It's actually 100

lines of code in solidity. It's easy as that. I would start from truth of source and then you could explore also documentation. You could explore our SDKs. What I personally see here is a huge opportunity to build AMMs and compete among EMMs not with TVL anymore but with their logic because you could attract liquidity by just getting shared access and getting shared access is so much easier than attracting TVL. You wouldn't believe me.

More questions. I'm able to answer every question. I think more questions. >> Yeah, we just announced it a few days ago like two days ago. It's super new and I getting now a lot of feedback for people who are into AMM space. It's not that much people actually. I would say it's like one 2,000 of engineers who are understanding this thing in like different levels of this understanding and I think this is a huge opportunity.

We would have uh bounties on the hackathon for builders to try to build anything on top of it. I mean we do not understand yet what's possible when your finance are on your wallet and which protocols they could interact to those this feature of funds being unlocked from the pools is actually very powerful and I think it's under investigated underexplored and this is a huge opportunity for everyone to try to build something on top we introduced this is a like a clean architecture distinction between layer providing shared access and between our own approach to AMM to

be the best AMM. I don't see any way for us to be the best AMM. We see that there will be hundreds or thousands of different AMMs approaching this uh market market inefficiencies differently. So yeah, I would welcome everyone to explore possibilities and build on top. This layer is permissionless for both liquidity providers and AMM builders. >> Yeah. Yeah, you can connect me via X Twitter. Yeah, I would reply. I have some slides there in the threads. So,

yeah, especially for those who came a little bit late. Yeah, we also have uh my workshop on YouTube and we have new recording I think. Okay, thank you very much guys.