Liquidity Tree Protocols With Pachira | Ian Moore - Pachira / SYS Labs

[Music] calls with pachera uh we're going to talk about the introduction next we're going to cover Preamble then we're going to talk about the problem we are solving and that problem is going to be solved using liquidity trees and then we're going to cover the simulation results followed by the summary so who am I um I'm Ian Moore um dii Pi core developer which is a defi analytics um python package that we I just released or we just released um I am the liquidity tree co-inventor and I share that title with another individual and he goes by an alias his name is coyote Doge other than his personality and his intellectual acumen that's all I can tell you about him so it's me and this guy um I'm a c CIS Labs researcher and then I've been a CIS coin Foundation adviser for the last three years uh prior to that I was uh senior lead data scientist for six years uh I was also an adjunct lecturer at the University of Toronto bio statistics division for four years and on top of that I was a statistician for another five but I held the adjunct uh uh status only facty position while I was a statistician so the objectives first we'll cover the Preamble we're going to talk about what is capital efficiency um and we're going to talk about constant liquidity market makers or um concentrated liquidity market makers we'll Define our problem which we call the stagnant liquidity problem it's a novel problem that we're defining to bring us into liquidity trees and then we're going to talk about our simulation results so what is capital efficiency Capital efficiency is basically the total revenue that you realized from your system divided by the total lock value so a l example would be say you have a liquidity pool that has $100,000 of capital in it on a given day you may have2 to 5,000 that move uh that uh collects a uh a swap fee of 3% so that two to5 uh, is earning Revenue but the question is what about that other 95 to 98,000 that's just sitting there idle so that's what's formally known as lazy liquidity and then the example I outlined that's what we call Poor Capital efficiency so this is this Unis swap V2 so on the left here we have the um liquidity frequency distribution of Unis swap V1 and V2 which is effectively just a a uniform distribution um the active liquidity that's being traded here is between PA and PB and um lazy liqu is is the uh liquidity that lies outside that band that's not being traded so what uni swap V3 did is they virtually added they virtually extended the the liquidity within that system and then we what what results this bell-shaped curve looks like a normal distribution or or uh just a bell-shaped type distribution uh is is denoted by this frequency distribution curve which is the fact um an estimate for the optimal curve so there are many concentrated liquidity market makers out there right now so the the the famous one that we all should know of is uh Unis swap B3 and there have been many copycat Forks that have taken their code and forked it and extend and and implemented on their platforms namely pancak squap Sushi swap quick squap AP swap um then there's been others that not quite uni swap V3 but uh some slight modifications such as kyber elastic Trader Joe V2 Orca and radium so we talked about lazy liquidity next we're going to talk about a term that we have invented which leads us into our protocol the liid tree which we call call stagnant liquidity so if we let lfp be our optimal liquidity frequency divis distribution then our constant liquidity Market maker would be defined as L hat which is because it's ACH it's it's trying to achieve to concentrate the all the liquidity within the price band but it will never ever do that there will always be liquidity that lies outside that price band so you have the total liquidity so we call that liquidity outside the price R stagnant liquidity it's a new term that we've defined which is effectively the total liquidity subtracted from and we what we do is we subtract the liquidity within the optimized um within the uh the price ban of our optimized liquidity um frequency distribution denoted as elh hat here in the in this integral so here's a we bring this diagram up so effectively within the PA to PB we have our active liquidity and that curve there is our frequency distribution or our estimate of our optimal liquidity frequency distribution and anything outside that St liquidity so the question is how do you get at that so there are many many as I covered many con uh concentrated liquidity market makers that are trying to achieve this so no matter what what one does to address this lazy liquidity issue we'll always have a certain amount of stag liquidity left over so how do we going to get at that liquidity so the problem is given our estimate of our optimized Market maker liquidity frequency demission um elh hat how do we increase the trading volume we call this problem the stagnant liquidity problem it's the solution which everyone so focused on they're just focused on single LPS how do we get concentrate that liquidity within that price band but we're doing we're we're we're opening up the ideas we're saying now we're not working with individual LPS working with networks of LPS which we call liquidity trees so these two ideas concentrated liquidity market makers and liquidity trees are not mutually exclusive to one another they complement each other which we'll talk about and we at CIS Labs believe this will be the next Epoch of defi much like how the liquidity um uh the Unis swap VT was the first Epoch of def5 we believe this will be the next so like I said yeah you can Implement both liquidity trees and clmm together so let's look at the price curve of Unis swap V2 versus V3 this green curve here represents V2 and with Unis swap V2 V3 what we're doing is we pushing out their life the the curve and effectively deepening the order book virtually so we're virtually deepening the market okay so but before we talk about liquidity trees we need to cover another problem which we call the CPT or Conant product trading indexing problem which is effectively take a little bit of um liquidity in our pool let's say we have a th000 LP tokens and we have 10 tokens 10 LP tokens we want to know well how much is that worth in one asset or the other if we have an eth die pool how much is that worth in eth or how much is that worth in ethereum we call that index liquidity denoted by this iy or IAC X for an XY a dual consant product trading pool X versus y so given that what we do is we take this index liquidity which is effectively fully collateralized debt we place that on the market so what that in fact uh creates is a derivative Market which we're calling a child Pool the original Market which we extracted our collateralized lytically is what we call parent so now we have a parent a child this repr since the single the simplest form of an what we call an amm net which we call a simple tree so geometrically the two can coexist together as we can see here we have Unis swap V2 we take our collateralized liquidity put it on the market as I ex it quickly gets bought up and now we have another Market the good way of looking at it is for Unis swap V2 or V V2 to V3 were virtually deepening the market with liquidity trees we're virtually increasing the breadth of the market so breadth versus depth okay so what effectively we're doing is like a like I I like to think of it as like a grand unified theory of defi so how does this work so on the top here we have our a box uh height is y length is X so X versus y x x y is our liquidity we do some trading because of the 3% swap V over time the Box will grow and that's denoted by this blue strip on the out outside edge here with this simple tree we have the same effect happening we have the green box we have some trading trading it grows but then we take our collateralized liquidity and our child the child also grows it too produces additional Revenue so what we've in fact done is increase the market efficiency via another route using liquidity trees so in short we've leveraged some of the green got red made some extra purple if we were to um reference this this uh simple uh diagram here so let's extend this idea we talked about the simple Tre so for um a dual AET constant product trading pool X and Y the maximum number of child pools if we have our parent x uh pool and then our children the maximum number that we can create is five iix y y iixx iix i y iyx and iy Y this is what we call a full tree so mathematically speaking liquidity trees can be represented as computational graphs where the nodes are denoted as Dex operations and the arcs are denoted as index liquidity flowing from the parent to the children so we can take that idea and we can of the full tree and what we've done is we've broken it into these sub trees the left tree the right tree the Double Tree equivalent tree posing tree they all have slightly nuanced differences between each other and how they respond according through our simulations but for the sake of this conversation we're just going to talk about the left tree so here you have um our parent and this this uh uh graph here is what we call left tree XY iix Y and iixx that's that's what we Define as a left tree and we have our Unis swap V2 pool here denoted by the green and our two derivative markets denoted on SE separate planes so the question is can we if we were to implement a protocol the question someone might ask is do we go with liquidity trees or constant liquidity Market maker no you can Implement liquidity trees and constant liquidity market makers together in one nend dimensional Le ukian space in this case it's R3 so in fact we're extending the the idea the theory into multiple Dimensions because we've been thinking and talking about just R2 right now we're expanding our thinking so here we have the simulated what we've done is we taken that idea we simulated it there's a few mathematical things we had to do to put this simulator together we're not going to talk about it in this this talk um so these top two images are the simulations for um the child one of the child which is die i e or I eth I die and I eth eth as you can see here it's highly volatile not as volatile as a top chart and the bottom chart is the revenue that we harvested off the tree the green the green represents the revenue pulled from the parent the red and the pink represent the revenue that we pulled from the two derivative children without them we would see less Revenue so we've effectively as I said before increase the Market's efficiency using this concept of dimensionality so we tabulated the results here um in the Top Line we have the revenue of our parent which and for the sake of this simulation we use real data starting from on eth die or ethusd C January uh Jan January 2018 all the way to the end of 2023 and we see that we see a return of 19.4% when we implement the tree it jumps to 26.3% which is revenue Bo boost of 35. 61% now if we look at it as sub as the individual pools this first um uh column we see a revenue from the parent as 19.4% and and then 80.

5% from one child and 3.64% and that's because anytime you make any kind of changes on the parent the activity in the children are more exacerbated we see that consistently over and over and over again in our simulations and and that's one of the interesting features that liquidity trees do that and in this simulation we only use 7 and a half% of index liquidity so in summary we've defined the stagnant liquidity problem we've addressed that problem using liquidity trees which is a new defi primitive which we believe is the next Epoch of defi uh utilizes fully catered liquidity and be represented as undirected graphs or algebraically an RN which I which we talked about and the simulations which we've shown support our reasoning we're going to take all that we're implement it into the petera token launch we've taken this new primitive and we've connected it to a governance system to make a trustless immutable decentralized exchange traded fund that's effectively uh one thing that you can do with liquidity trees you can do all this is what we're calling an amm net so we've all heard of um Nets in used for ai ai so this is the same kind of thinking we're we're thinking the the the way is we're calling them amm Nets that's it thanks