Next-Gen DeFi Protocols with Aave and Balancer

Transcript

hello everybody and welcome to the defi security Summit monthly webinar uh we have actually one important announcement as you as some of you seen we have selected the venue for defi security submit this year the event will H will have will be hold held before uh uh Devcon in Bangkok in November and we actually going to start selling tickets soon and the second announcement is today we actually have one of the or two of the leading uh defi protocols have balancer and we have

actually the top developers there they will present the new development coming for defi this year and we have Tom ganor with a leite security researcher at who going to moderate the disc so Tom take it from there thank you mly um okay hi everyone I'm Tom um I will moderating this uh webinar H we have first we have ailio from a that show that will show us um a new approach to how determine the interest rate of go H technical issues and solutions to those issues so take it away

Amilia amazing uh thank you to and thank you everyone thank you mully and Sor for the invite always nice to be uh participating in defi security Summit related activities uh for those who don't know me my name is Emilio I am currently VP of engineering at avara aabs and um I have been involved since the beginning of the development of the protocol I have been participating and leading the development of all the three versions of the other protocol uh there is a a lot of always a

lot of work around around it recently the AV has introduced also a decentralized stable coin named go and the go is integrated with the a protocol so it kind of acts like um CDP stable coins where usually users can access the uh a market and borrow borrow natively uh go against um all the basket of collaterals that the other protocol supports but in reality Go is is way more flexible than that is not just a

CDP based stable coin but it's also so it also has the capability to natively allocate um allowances of of the stable coin to eventually other protocol or other products develop developed within the a ecosystem that can basically uh extend the capabilities of the stable coin to be minted in a variety of different ways you can think for example of it would be possible for example in the future to have a we call them facility ators so there can be natively allocated facilitators decided by the avow that can allow meeting go in a in different

uh ways for example you can imagine that in the future the a might explore a way of uh generating go that is similar for example to what atina does so like delta neutral strategies or that goal can be extended to uh support uh real world assets so that it can be collateralized by real world assets and so on and so forth there are a variety of ways that the go design uh can extend the usability of go uh one of the major challenges that we have been facing uh in the current uh in the usage of go with the current ways that go

supported So within the other protocol is to is to maintain a strong and reliable pag uh there are maintaining a a a stable coin pag is a multi um multi I would say multifaced uh aspect because it it's kind of involves a lot of different um complexities that need to be handled at the same time uh one of these are certainly deter appropriately determine how the interest rates for borrowing go are calculated depending on the on the state of the

pack I will uh share my screen now so that we can I can use like the help of some slides that I prepared uh let's do it okay I guess you guys can see the screen can you confirm in the chat if you the screen is visible okay perfect so amazing so let's go let's go straight into it okay I now I shared full screen can can you still see it okay

perfect amazing okay let's go forward so um with these slides I will uh present a a new approach that we are designing for the go stable coins for the for determining the right interest rates uh to maintain maintain a healthy uh Peg and to and still manage to propel the growth unvisible okay just yeah just give me one second I think I need I need to share not this the yeah I will share the whole screen just give me one second because I share the window but you I

think it doesn't work when I then I go full screen okay now you should be able to see my screen and now you should be able to see yeah now it's okay now it's okay great yeah sorry I I just shared the window but then it doesn't work when you go full screen ignore please like this telegram icon that for some reason appeared here doesn't want to go away I need to run some commments to reset the the the window manager but anyway so uh let's go back like a notch so what's a stable coin as I mentioned before it's a kind of a digital assets that tracks the value of an underlying real world assets so we are mostly used to think of stable

coins as um cryptocurrencies that are pegged to the dollar because they are the most uh widely used within the crypto space but in reality we can Define stable coin as anything that tracks the price of an underlying asset uh which basically um brings a whole lot of challenges in terms of generation uh Redemption and stability mechanism so we can uh separate I usually separate the stable coins in three main categories at least those are the categories that we have been uh seeing uh explored in the last

couple of years so we can mention certainly over collateralized stable coins so this is the approach that currently go users but again it's not strictly strictly uh restrict to that particular design can be expanded with other designs to explore different ways of of generation so in over ciz stable coins usually the stable coins are generated against a volatile collateral ER at a fixed price so in in the crypto space like decentralized stable coins use uh other crypto as collateral so we can Bitcoin

ethereum have a token whatever other token that is suitable to be collateral and but it can also be of course against Real World assets so for example maker uh has the um real world parts where part of the assets backing die specifically real world dollars are allocated for example in shortterm treasuries to to generate y uh centrally controlled are I think the W most widely used at the moment like we can mention T we can mention usdc uh there is in general there is a central entity that controls the generation and a redemp Redemption

mechanism against the real world asset so uh simply simply put user users go to the central entity they deposit in in the case of USD base stable coins they deposit real dollars and they get representation of the real dollars that they deposit on chain they can also go to the centrally controlled entity and this entity can also exercise Redemption by get getting back the the the minted onchain minted stable coin and returning the the dollars to the uh to the users that is actually redeeming then we have algorithmic uh

which un famously well known because of the uh spectacular crash of uh of the of last year of Luna uh where uh there is no collateral essentially neither real world or or or volatile but the the mechanisms of redemption generation and stability are all three algorithmic controller to try and match uh supply and demand so uh I will focus on the describing like the the features that I want to uh I want to I want to show I will focus on

over collateralized stable coins and specifically on and their meaning through they reach stability so I usually separate the mechanisms that allow a stable coin to maintain the bag in soft Peg mechanisms art Peg mechanisms so uh soft pag mechanisms are for example uh one of those could be like generation and Redemption at a fixed price which is what happens on the other protocol when go are generated and and redeemed so when users generates uh go essentially the Oracle price of go is set at $1 so the generation happens always at $1 um

whatever the price on on the secondary Market is and the same is true for liquidation and repayment so when a user repays one go it will always be valed $1 um despite the price that the the the go table Co has on the secondary Market uh maker for example or liquid work exactly the same uh variable borrower rates in this list we can have die go and CB USD so like the the protocols try to adjust the borrow rates that borrowers are paying to try uh and and stabilize uh the the stable coin in the market so the idea

behind it is basically uh when there is a lot of demand and a lot of incentives to mint the stable coin and to sell the stable coin in the market what what happens is that usually borrow rates go up uh to compensate for the additional pressure of the Peg and eventually uh rebalance the Arbitrage opportunity so that borrowers are not that incentivized in in generating the stable coin anymore uh there is a difference between D go and and C vsd for example because D and go actually use uh a governance controlled rates where where uh the governance uh decides whether or not like the the interest rates the borrowers are

currently paying are correct where CRV USD used a an onchain controller that automatically uh adjust adjust the borrow rate very quickly it kind of resembles more the way the behavior of other stable coins on a rather than the behavior of uh interest rates set by governance like in the case of go so you can imagine the stable the rates that are set for go are usually uh less volatile because like governance uh timings are usually longer while in the case of C CRV USD is more is closer to an actually fully variable rate where race can actually vary uh per

block uh so I you have um lower reaction time in the case of governance controller rates but more predictability compared to a fully variable interest rate model uh lately it's interesting to mention lately there are some new interesting approaches for example liquid V2 uh will actually have user set interest rates so uh users will be allowed to set their own interest rates and they have like their interest rate will actually affect uh the directly their Redemption risk the Redemption mechanism is in a hardbag mechanism that

I will describe afterwards but um the the interesting part is that there will be no separate entity to actually set the the the user borrow rates but the users will be able to set their own borrow rates to better assess their own risk reward or to delegate the capability uh to set their own interest rate to um a third party entity uh so that's that's more or less covers current state of the market for borrow rates and uh also there are Redemption and gener generation fees these are PE peculiar to LUSD because like the the

liquidity uh mechanism is uh quite different compared to that of die and go where there is a a redemp the current version at least uh there is there are no interest rates but there are uh generation fee or or origination fee better when when a borrower originates his position and there are also Redemption fees in case like uh Redemption are activated so what are these redemptions uh we go to the rpeg mechanism part the Redemption are essentially um uh the forced uh redeem of users positions against the stable

coin whenever the pressure of the peg increases so as soon as there uh there is an increased pressure on the peg for the stable coin the system will automatically start redeeming uh the less uh collateralized positions for the stable coin in an attempt to reduce the supply and uh bring the peg to a more stable uh level so uh let's go forward and let's talk about stable coin borrow rates more in detail so as I mentioned before D for example as governance controlled borrow rates where CRV USD here we go in detail how how they work so for example D which

which is a pure uh CDP platform uh CDP means collateralized depth position like they have a very flexible uh system where different vaults with different risk profiles also have this different interest rates so whenever the maker governance usually updates the rates like you can see a screenshot of a proposal of the maker governance to change some of the risk and configuration and borrow rates they have the capability to adjust the uh risk and the interest rates of the borrower are paying per kind of so every collateral will get its own

personalized risk and its own personalized interest rates while in the the case of crvd we have an automated mechanism the formula that is described here essentially uh calculates uh what the interest rate at a certain block should be the usual they use they use certain uh parameters of the system to determine uh the the value of the of the borrow rate uh I for example I can highlight here the the P keeper depth the total depth which is the total debit of the system and the fraction of uh pank keeper that is targeted when uh the

uh in in in the up to stabilize the peg so the peg keepers are a system that the crb USD implemented to uh extend the capability of um adjusting the peg so it the peg Keepers specifically act when the the the stable coin goes above bag so it's worth more than $1 buying injecting liquidity liquidity in the bag keeper module and by by evaluating how much liquidity there is the B keeper module essentially the CRV borrow rate module that reminds what the borrow rate should be uh so both of them have some pros and some cons I kind of

mentioned the pros uh before uh of the governance controlled versus algorithmically controlled the pr is that like usually governance controls give more predictability to the users so because there is there are um certain uh inter time interval needed for governance to enact their its own decisions this means that interest rates cannot CH change more quickly and also you know in advance to what the interest rates will change to but like it require it gives brings a lot of governance overload that you will need to actually model continuously the stable coin you

will need to have participation people voting the proposal to actually be enacted and it's also very hard to estimate properly uh the variable on the other hand like they act in a completely autonomous way so there there is no entity setting the rates but they offer no predictability because like the the the Peg and the therefore uh this state of the system therefore the interest rates can change per block so ideally what we are trying to model with go is a stable um borrow rate module that works algorithmically but also offer some kind of degrees of predictability so no interest rate

set per block so you cannot end up in a situation where you are paying at this block 3% and the next block you are paying 25 for example but rather have a mechanism that is algorithmically controlled but change the rate of change of the interest rate so if their interest rates need to go up they will start going up per block but with a certain speed not directly to the Target value and the same when they go down so when they go down interest rate will start going down progressively and not going directly down to the uh um to the to the value that is uh optimal that is determined uh this I think will offer

the best tradeoff between reaction times so it's not as fast as a re true variable interest rate model but it's not as uh but is also more predic predictable than a truly uh variable interest model so uh we explored a variety of um possibilities here to be able to implement this uh variable uh borrow rate model and algorithmically controlled the first model that we evaluated was using a PID controller uh so what's P controller is is very commonly used in industrial application to control aspects of a

certain systems of sample temperature or the speed of your car using the cruise control uh this look equation here looks particularly complicated it's actually not uh it's um basically um composed by three different terms the first term that is the proportional the second term that is the integral and the third term that is the derivative each term control different aspects of the variability of the system so we have a proportional uh term that acts proportionally to the current error that the system is experiencing so you can think for example from the Del the current error as the Delta from the peg that the system is experiencing then

there is the integral part that basically uh acts on the historical all the error so if historically the asset for example has been underpacked there is a component of the of the system that gets balanced by the integral component and then there is a derivative component basically determines uh contribution to the final uh control value that is determined by the the the D the derivative of of the error which means basically estimates how quickly the error is changing in the in in the basically uh within a short time frame from the from the current time

so um again what do we want automat but predict but predictable rates ER acceptable degree of latency so not as long as the governance but ER quick enough to be able to react to changing Market condition and we want this because we want a certain degree of predictability which will basically offer an alternative to more traditional stable coins that can be borrowed on AB with pure variable pure variable interest rates so uh the first iteration using PID didn't quite uh behave the way that we were expecting to uh because the

uh this model is too simple to actually model such a complex system like a stable coin uh Peg as this is because we can as as you can see in the equation we can only uh consider the the basically different aspects of the error from the peg but we cannot evaluate why the actual behavior of the peg has been like this like there are a lot of different variables that contribute the to the behavior of the peg so for example stable coin could go up in price because there is uh short-term surge of demand because I don't know a new

protocol has launched a I don't know farming campaign with using your stable coin then suddenly uh your stable coin goes uh in a demand frenzy but it's not necessarily a long-term Market behavior that is driving the the the the begging but it's a kind of a shortterm event and is hard to for example uh model something like this with such a simple approach so uh we kind of evaluated I can suggest also uh the there was a very interesting paper um published by the mor Moro team on the on on the topic uh in in a couple of days ago which is very

very interesting I'm suggesting like to to give a read if you are uh interest to on on this particular topic especially the part uh there is a the modeling of um like full-fledged uh theoretical interest optimal uh interest rate strategy which for obvious obvious reasons is uh hard to replicate on chain because it uses dynamic programming and it's very uh comput computational intensive we found another way uh which is a different approach of control theory which is called fil logic so um I'm getting close to the time I will try

to be quick and trying to explain what fzy logic is um so it's kind of a novel application control theory on the blockchain because as far as I'm as I know no other systems are using it at the moment uh it's interesting because it's very computationally inexpensive and it allows to model a system following uh human kind of human understandable reasoning so uh it's pretty easy if you look at a a system like a stable coin is pretty easy to identify certain conditions for which your borrow uh interest your interest rates should react in a certain way and they are pretty easy to translate in natural

human language but they are very complicated to model mathematically the fzy logic kind of fits perfectly in this particular use case because like it allows to represent a degree of Truth between a range of zero and one so it's an extension of the classical Boolean logic where something is either true or false uh but but like the um essentially what this allows to model are degree of Truth where temperatures for example as we fill them are not super uh cold or not super warm like there there might be a degree in

the middle same behavior can be um evaluate for the uh certain behavior of an aspect of of of stable coin so that's what we why we decide to use this particular system so I will go very quickly here but this would take probably a few hours of of discussion so the whole system is basic is based on a set of rules where you said you define rules that are actually human readable one example of rule is if the distance from the peg is very high and negative then the rate of acceleration of the interest rate should be high because uh if the peg of the stable coin is going down very fast then

you would probably react in a way where the interest rates are rising very quickly so uh this rule that is human readable can actually be translated in in a computer readable rule with a with a set that defines level of Truth for this particular Rule and then the rule can be applied to Value actual crisp they are called crisp value red from the system uh to determine the the control value that is applied to um to react on the system so this case the borrow rates uh there are a variety of V variables that we can use the interesting part is that this can be

expanded indefinitely with minimal to no gas addition because like the the the rules are very very cheap to evaluate so we can use distance from the P the P historical from the and rate of acceleration so for these three are ready cover everything that is uh described in the in the PID controller but then we can use for example Additionally the balances of the GSM which is the uh go stability module that basically allows to uh increase the stability of go using uh actual um stable coins like usdc or t uh the state of the secondary market so you can we

can you can evaluate with system and have uh participation in the calculation of the error what's the state of the secondary market for example on a set of selected decentralized exchanges and so on and so forth uh so what will happen is that like the pro the system will Define a set of onchain rules and again the rules can be expanded indefinitely and then we can read these uh values from oracles or directly from the system uh and that provide the service so for example the GSM and apply the rules to the value to determine the correction that needs

to be done to the interest rates to to improve the state of the p uh it can be expanded in a variety of ways you can Define the the the sets that Define the degrees of truth in a variety of shapes you can use the def deification method in a variety of um different approaches so it's very flexible because it allows uh seamless expansion of the model and also uh seamless customization of of the way that the rules are interpret interpreted so next steps are going to be uh building model in Python this

actually was done already and because this uh this presentation was already uh it's been quite a bit like I I have been presenting it there will be a governance proposal and discussion to uh to also showcase how the system would have behaved in the past ER there will be comparison against the PID version of the control that we implemented before and then onchain proposal and and execution so to to finalize stability is a very complex topic uh there are um there will be automated mechanism that actually bring faster reaction times to allow for a better stability

mechanisms and but even even faster reaction times and better stability mechanism cannot like be developed separately from uh creating new use cases for the stable coin and focus on uh on growth which is actually as important uh if not more important than than stability mechanism so that's pretty much it from me I don't know if there are questions first of all thank you very much Amia um so it seems like there are a few questions maybe we can do it like in a minute

someone let me show it want to discuss here in length uh later so of course um can talk with they can talk to later see yeah also we have another question regarding to how do you estimate the likelihood of the code to detect yeah okay so like for Integrations like the a is yeah the integration of for Integrations the Avid is the best um is the best place to look like for for collaborations or Integrations go can be integrated is

permissionless is just stable coin so can be integrated in a variety of ways if there needs to be governance participation I would say that the the a governance governance. a.com is the best place uh to start and how do you estimate the like like you don't really estimate the likelihood to of of the asset to the bag uh you kind of evaluate uh what's the state of the system now and then you react accordingly uh so so that's that's more how this kind of system work even the governance controlled ones work like that it's it's really hard to predict if and when the stable Co will wield the

back it's basically the only way is to um estimate what's the best reaction to bring the asset back to Peg I think it's pretty natural all stable coins have experiened and will experience the peg at some point because there is no way to hardly um tie the price of the asset in the secondary Market to to the stability mechanism the only thing that you can do is basically react accordingly and as quickly as possible yeah we can't fight with the market of course yes exactly great thank you very much Amelia was very

interesting um and thank you yeah thank you and now we have Juan from balancer to show us um the new version of balancer comp to the previous one ju the floor is yours thank you very much Tom uh thank you everyone from for having me here um and yeah so today this uh talk is going to be quite Technical and it's going to be basically a speedrun of what we are building for balancer V3 uh so yeah I'm Juani uh I'm been working for balancer for about two years

now and well I'm leading the smart contract team so yep uh let's get to it brace yourself and fasten your SE bels because this is going to be a bit intense uh so yeah let's get to it so in the agenda we have uh first uh quick overview of what balancer V3 is uh to explain it properly I have to take a step back uh and explain a bit how vichu Works how the architecture Works in vichu and some of the pain points that we realized About It by building and operating it throughout the years uh and then I can jump to V3 and actually explain what the differences are with respect to V2 and what the improvements are so let's get to it first what is

balancer B3 uh it's a decentralized exchange uh it's going to work with fible liquidity positions uh meaning that when you add liquidity to a pool you will get an near C20 in return that represents your position in that pool uh it has a single bolt meaning that all the tokens for every pool in balance3 will stay in a single contract that holds and manages all that liquidity uh and it's also uh kind of optimized in to some degree to hold yield bearing token second of all uh it's a defi platform uh and this is also something that we are like building very strongly towards uh and it's basically uh not only a DEX but

also a platform uh we would like other builders to come on top of balancer and build their Custom Pools and hooks that might have like interesting trading curves or strategies uh and the idea is to facilitate that as much as possible and finally balancer is also an ecosystem in the sense that besides smart contracts we also have Integrations with our protocols we have an SDK team we have a front end all of that to interact more easily with the contracts so yeah it's not only about smart contracts this talk is going to be mostly about smart contracts because it's my speciality but yeah balancer is more uh than that so let's take a step back and take a look at what Vu looks like uh I'll

first uh try to speak about like the architecture in bichu uh and bichu looks something like this you basically have two main components which are the vault which holds all the tokens and pools which hold uh basically uh say how tokens have shall be traded so for example you have weighted pools stale pools all of those have different trading curves uh and basically uh have the pricing mechanism that establish how much tokens how to go out for a given amount in for example so sorry so how does work basically the Vault uh both holds the tokens and also it's like a an API for external users so users can call the

Vault and say okay I want to join a pool basically adding liquidity I want to swap token a for token b in a given pool or I want to exit my position basically removing liquidity from a pool so users interact directly with the Vault the VA basically talk with the pools so that they know what to do uh the pool tells the Vault how to do the accounting it's essential what's the result of a given operation The Vault saves the accounting and settles the the balances so for example if I'm trading token a for token B uh the Vault will tell you okay give me x amount of token a I will give you back y amount of token B uh so first thing here that uh is worth mentioning is that the vaol is both uh a user facing contract but also

the one that is immutable and holds the the tokens uh and that is a big deal I will expand that a bit later and the second thing is that token accounting is a bit uh separated from BPT accounting BPT is basically the lp tokens that represent the liquidity positions in the pools and this is because the pools hold uh the state of the their supply uh on its own so basically the account for the accounting for the tokens happens in the bolt and the accounting for BPT or the lp tokens happens at each pool this means that the Vault basically doesn't know about uh what what a BPT is so for example when uh someone wants to join a

pool and add liquidity basically the Vault sends the command to the pool and the pool is in charge of actually minting or burning tokens in case of adding liquidity it will mint BPT tokens in case of an exit or removing liquidity it will burn BPD tokens and there are a number of problems uh that arise from having this split between token accounting and BPT accounting so some uh pros and cons of this uh design so we have token accounting split from pool logic which is cool uh that means that you can have a vault that hosts a token but different pool types that you can build on top of the pool on top of the Vault and then use them

accordingly the second thing is that you have efficient batch swaps so for example if you want to trade token a for token F and they are not in the same pool you can basically do many Hops uh between all the pools that you need uh and you won't need to be transferring tokens back and forth uh the user and the Vault and this is because essentially all the tokens are already in the vault so basically if you uh manage the accounting properly you can just do one transfer for a token in and get your token out um there's also one thing that I haven't mentioned that much but basically you can also have a relayer that is basically uh another layer uh of to extend basically the user facing API uh and that you can basically do more

complex operations so for example if you want to I know add liquidity and then stake that liquidity in a gauge you can do that uh or you can add more complex functionality that is outside of the Vault and you can also like iterate on that and improve it over time um and the other good thing uh that is also a challenge is that the bolt API is flexible and kind of future proof um this has to be this way because we wanted different pool types that we didn't know about when we first starting building the Vault uh so we needed the Vault the API to be flexible but on the other hand uh being flexible is sa at odds with an immutable contract that you cannot upgrade at any time so basically

that adds complexity uh and if you do something that is not optimal you have to live with it for as long as the platform is alive which is basically forever uh so yeah there's a challenge between being flexible and having an immutable contract the B has to be immutable because it holds the tokens uh and otherwise it wouldn't give the LPS any Assurance at all so there's no way around it so the question is how do we keep like uh something that is flexible but yet immutable um the second thing is that well uh pool tokens separated from LP tokens or bpts uh keeping those accounting separated is a bit complicated because essentially if the Vault doesn't know about BPT there's no

way to query uh what the result of an operation will be when you add or remove liquidity directly we can do that in vichu but it's like very cumbersome uh and basically what we want from queries is okay if I add liquidity or remove liquidity what will be the result of this operation and when I mean like getting the result beforehand I don't mean like running a full simulation but rather just doing a static call that says okay this is the result uh and that's it so that's a very desirable trait of a system and it's something that inbu is a bit challenging to get um also I said that the volt API is very flexible but it's also a bit complex uh for uh adding and removing liquidity in particular you always have

to rely on encoding uh data in a bytes array and decoding that in the pool and that is a bit cumbersome and again there's no way around it because it's already built in the vault so yeah we have to live with it I said that the relayer is cool because it adds uh like another layer of flexibility but the problem is that it's even harder to query what's going to happen when we interact with the relayer and the last thing is that um besides the basic architecture there are a lot of like helper functions that are distributed uh so for example uh pause and recovery mode those are two very interesting things POS is basically being able to like shut down a pool so that it doesn't allow trading anymore recovery mode is

what allows users to essentially exit uh in case there's a problem uh you can enable recovery mode and you basically provide a separate path that basically always works and doesn't have any external costs so even if a pool logic is broken you can enable recovery mode and allow users to exit their liquidity positions and that is fundamental to give users uh good assurances uh token scaling uh basically pools need to do token scaling so if you have for example usdc that has doesn't have 18 decimals you might need to do the token scaling at the pool level um and also well liquid liity operations I will dig on that a bit later uh but essentially there are many ways to add

liquidity to a pool and in V2 each pool has to basically Implement all those ways uh and what I mean with all of this is that there are many things that are common to pools that that a common functionality that every pool will need and in Vu every pool has to implement its own logic to provide uh that functionality uh so we were thinking that maybe some of that can be moved to the B so that there's a base layer that handles all of that and pool developers can only focus on what's important which is basically new invariants uh new training strategies or things that are not basically piping and pluming uh so that's our question for B3 is like how do we keep the good while improving the the rest so now let's jump into B3

architecture before like like hitting you with another diagram uh let's go again with with the list like okay let's keep the good and say what can we add uh so first of all uh we want to split the user facing API from the immutable bolt uh and this means that we will need another layer that we can basically upgrade if we want and can be more flexible and reach and like even do more complex operations but that doesn't have to be in the vault so it's going to be a sort of free layer but it's going to be more integrated into the ecosystem in B3 the second thing is that well we should split settlement from accounting and that means that uh for example when you do an operation of a swap uh I don't

want the Vault to start sending me tokens back and forth because that complicates uh the queries so for example if I can split the settlement time from the accounting time that will help me in the queries because I can just like run a function that only does the accounting without settlement and with that I can get a result of what's going to happen when I do the actual operation uh when I inan settlement I basically mean sending tokens back and forth so for example if I want to swap token a for token B I can tell the Vault okay uh what's the amount of token a that I need to send you and what's the amount of token B that you need to send me and if I can do that first and only then when I know the result do the actual settlement then I can do the

queries basically for free um the other things that keeping the token token accounting and BPT accounting together all in the vaol will also help help us to do the queries uh for liquidity operations so that means that if all the accounting is in the vaol I can know what will happen when I and remove liquidity which is also very cool um and finally what I just I was just talking about about solving the development the developer experience issues at the base layer so basically all the things that are common to every pool we should move them to theol as well so that pool developers can focus only on what's important so now let's try to look at uh what B3 looks like from a workflow

standpoint uh so the the workflow with something like this the user sends a request to something that is the user facing API it's not going to be the vault in this case uh that contract is going to open a tab at the vault in the sense that telling the Vault okay start registering all the things that I'm going to do it can be a swap it could be a adding liquidity removing liquidity or a combination of those uh that's fine because the Vault will register every operation uh and at some point when I'm done I have to settle if the user facing API is able to settle correctly meaning basically paying the depths to the VA and taking the to the right amount of tokens out of

the Vault according to the operations that have been done then we can finish everything is is correct but if it's not settled we just revert as if nothing has happened uh so this design is uh the idea is to provide much more flexibility uh we can like add much more complex operations in the middle uh and if something is not paid for at the end which just revert so I won't dig that much but the B3 architecture looks something like this what I want you to take out from this is that now we both we will still have the volt and the pool but we also have the router which is the user facing interface the router can be replaced uh it doesn't matter because it just operates with the bolt uh and it can do

like a like with combining simpler bolt Primitives it can do like more complex stuff and everything should still be queriable uh and the other difference is that again token accounting and BPT accounting will all leave at the Vault so that's how we can query uh liquidity operations again uh those are the two things that I want to take out from this call we will have this router bolt and pool architecture uh all the accounting will live in the vault and the workflow is always like okay let's open a tab start registering all that we do uh no matter what the combination of operations is it's it's going to be fine because the Vault registers everything uh and only after I'm done I can settle if everything settle I can finish if not

everything revers one note about this is that all these uh opening the tab and registering all the operations uh now we have transing storage for this which is a storage that only lives within a transaction and that is a great fit for this design because we can essentially store everything in transit storage that doesn't go away within the transaction and that's exactly what we need for this design to happen so a summary of the trades that I have described so far uh we can settle at the end that means that the the whole design is queriable uh simpler bolt in the sense that we don't need to maintain uh very complex API because the router will do that um and basically the bolt has to

be safe in terms of like reverting and settle transactions keeping pool balance is isolated same as Inu meaning that if there's a bad pool that does math wrong okay that's fine but it shouldn't drain the rest of the Vault and then maybe pull some of the responsibility of uh like the common layer of the pools uh back into the bolt so that every bolt has the same treatment again the router and the external API is upgradeable which is great uh that means that you can potentially come up with something else better for example if you need a router that's that uh adds liquidity and then Stakes you can just build it and it will work uh and finally another uh not so

minor issue is that uh this design also supports re-entrancy as you are always like keeping the track of like what's going on you can basically do swap within swaps or like adding liquidity before a swap or like start doing weird combinations or more complex operations uh that include like even modifying the pool balances within an operation so for example if you want to swap but for example add liquidity to the pool before you swap you can do it or if you want to remove liquidity before after you swap or whatever you can also do it so what are the DX improvements this is also very important uh as I was

saying before basically want to push all the things that uh in which you are done by the pools directed to the bolt so essentially token SC scaling uh is pushed to the bolt uh I will skip the second one protocol fees this that's also something that was partly handled by pools uh in B2 that's al already handled by the vault in B3 post window uh that's also something that PS needed to do in B2 now the B can do it and the same for recovery mode which means that whenever you build in B3 a pool you get all the well the protocol FS handled but also you get the post window and the recovery mode essentially for free and that means that as a pool developer

you don't need to care about like a way a mechanism to actually post the pool in case something goes wrong you you get that uh already for free and you also get like a escape hatch in case something goes wrong again you can enable recovery mode to allow uh users to exit their positions in a way that is meant to fail basically never um the second item is a bit more complicated uh and this is related to like how you add or remove liquidity from a pool so in many basic um amms you basically have to add liquidity proportionally and remove liquidity proportionally for two token pools that's maybe not that bad because

you can basically like I know if I only have one of the tokens of the pool I can swap half of it and then add proportionally but then if you have for example four token pools it starts becoming more annoying so that's what unbalanced add and removes basically so there might be for example a four token pool you you want to add liquidity to that pool but you only have one token then you can do an unbalanced at liquidity with only that token uh that is a bit of a complex problem because essentially uh it's more or less of a swap plus and adding liquidity all in the same operation it has price impact of course uh but it can be sold and it's something that we put some thought on uh and we found a way

that is a bit better uh with respect to VU so this is a small chart that summarizes like ways of adding and removing liquidity so for example imagine that you you want to add liquidity again you have only one token uh and you want to specify like okay I have I know 10 E I want to add it to this pool and I I just want to add 10 E I don't care if the pool has four tokens or whatever so that's basically an unbalanced single token exact in at liquidity because I want to like add an exact amount in and I only have one

token um same for remove liquidity I usually have like I don't know 10 BPT I want to exit all the position or half the position so I give it like I don't know five BPT to the to the system to burn and I get my liquidity out uh or I give all of it and I get all the liquidity out uh so this is more or less the the add and remove liquidity types that make sense so in the case of unbalanced liquidity uh both exact in and exact out for single token makes sense um and balance multi token and liquidity also makes sense maybe there's a four token pool you have three tokens or two tokens and you want to add both of them you can also do that and of

course proportional for remove liquidity it's more or less the same the only one that doesn't make much sense is uh un balance multi token liquidity you usually when you want to exit liquidity you either want a proportional exit that doesn't pay any fees or you want to just exit in a single token and both you need exact in and exact out and I will get to that very soon uh but essentially uh it allows you to control uh either the amount that you are adding in case of the adding liquidity the tokens that you are adding or the amount of BPD that you get out and vice versa for removing liquidity this is important for bat swaps when you have composable pools and I will get to that really

soon so the problem is that in B you could do all of this but the problem is that the pools needed to uh basically know how to do this and have a method that solved okay if I want to add liquidity and balance single token given in or exact in okay I need to have a function that explicitly does that same for given out so each type had its own implementation this was okay and it works in balancer V but the problem is that if you are building on that uh you might not want to do all of that because basically uh you can just by having add in liquidity proportional the pool will still work it's just that it won't be like so user friendly so we found out that some integrators that built on

balance V2 really didn't care about all of this and only Built with proportional joints and exits so in balance3 the idea is that uh the DX for building a pool should be much easier and instead of providing like one explicit method uh for each of those add and remove liquidity types we can just do with with that with two functions one is that is called Compu invariant and computer balance the details of this are like a bit intricate but essentially the the point is that every pool with tangible liquidity should have a sort of invariant if you expose the way to calculate it and you also expose a sort of inverse invariant which is your

balance the volt resolves all of that for you so essentially by implementing these two functions you get all of the add and remove liquidity types that are relevant for balance3 of course on top of that you need to implement a swap function that is optimized uh because that's basically the key of a pool and finally another important thing of building pools on balance3 is that we also have this pool life cycle uh and as I as I said before you can do actions like before swapping or after swapping uh or before adding liquidity after adding liquidity and same for removing liquidity uh and the actions that you can do in those instances are basically unbounded because you can as I said before if

you're swapping you can add liquidity to the pool before you're swapping or you can add liquidity to another pool or basically you can do whatever you can also go to another protocol do some Arbitrage or go to a and close a position and then come back it's like the idea is to make this as flexible as possible to provide opportunities for Builders uh and finally a practical example of putting all of this together let's say that you have a p the first pool p a with d uscc and usct in some form of G bearing tokens so basically this is a sort of booster pool where the assets are actually lent to have uh an earning yield then you have a second

pool pool B which is the BPT of pool a paired against R State te uh and then you have a pull C of rap State D against Bal for example a weighted pull that is 8020 the second pool is very interesting because it's essentially like a yield bearing pool that has all the most used uh stable coins it could be also go for example uh and that's earning yield at a and it's pair against a a yield bearing version of e uh so you have all of that in a single pool which essentially gives LPS uh lots of sources of revenue not just swap fees but also yield fees coming

from a and from Lio in this case so if you want to swap for example die for Bal uh the swap path would be something like this you have to add liquidity first essentially G die uh for pool a that's adding liquidity and getting the BPT for pool a the second step is swapping that BPT of pool a for R State te and the third step is swapping r stick D for B uh and all of these which is a a fairly complex swap which has adding liquidity in the middle can all be queried and executed uh in one transaction no matter whether it's like exact meaning that I specify the amount of D or exact out if I specify the amount of b um so yeah as

you can see the design is very flexible uh and all of this is given as long as the pool developers Implement those three function uh and you can then uh extend it with your imagination uh you can pair like do different sorts of composability or different trade paths uh but the idea is that you can always query what the result will be and you can always execute that in a single transaction with minimal transfers because in this case you should only transfer die at the beginning and get P at the end so uh I think that was it uh I hope you enjoyed it it's it's a bit intense uh but yeah it's a speedrun of what we are building for Baler 3 uh yeah now

open to questions first of all thank you very much joh it was very interesting h of course um and if there there is a question from the audience feel free to ask WR in the chat H so we can ask um in the meanwhile um I have a question and regarding the you said before in the example you had the yield bearing tokens there like you had the A and you had also s and everything and my question is um like the the the middle pool the second pool

that you had there is it you said that you can get a multiple sources of of income but the user doesn't have like it doesn't get a compounded amount of of yield right they get like a partially divided yield from each and then it's proportion like it's more um Diversified income right correct exactly correct so when you LP the second pool you essentially own a piece of rap stick te and a piece of the pool that has uh tokens lent to a uh so yeah it's it's not that it's compounded but it's Diversified by just lping one single pool yes so practically when I have BPT

of of the second pool the one with rep st e and and the BPT from the first pool I effectively have 20% I some percentage of a die some percentage of of rep e rep st e and and and and all of that and then if for example I don't know for some reason the Lio that it has less yield we still have the yield from a and some proportion correct that is correct I see we have a question let me just show it on screen and then you can read it so wait yeah so what was the main security consideration um if there is one that you that you kept in your in mind while

coding one3 smart contracts okay that's a tricky one uh I would say that we try to strive for Simplicity uh and you have to take that with a grain of salt because uh at this year we are not in 2017 or 18 anymore uh it's not that you can like build uniu and be successful because that's already been done uh so we try to make things as simple as possible and particularly when when it comes to invariants or things that uh are very critical uh such as mantaining like uh pool balances separated or like ensuring that everything settled at the end um those pieces of code should be like very easy to reason about uh so that makes them

easier to test uh and there basically that improves your chances of that being correct if those mechanisms are complex to reason about and harder to test then that makes it much harder for it to be successful so yeah we always try to like I said that we push a lot of complexity into the Vault but we really thought what is Justified and what's not uh in the sense that if it's a 10x Improvement for the system as a whole then we can push it in the bolt uh but if not U it's out of way so that it's not part of the immutable contract that is very like the centerpiece of it all yes so so the complex stuff are out the simple stuff

are in the vault and the rest is is super simp exactly yeah exactly so basically like separating the API for example is one step in that direction because like if you have simpler Primitives in the vault it's easier to reason about them then you can mix them up but if every primitive does its job properly then you won't mess up I mean you you're just like combining things that work all together can you give an example um I see there is another question where is V3 uh coming out uh soon uh I mean yeah we've been building it for several months now we are a bit delayed because we are still uh tweaking some things uh but yeah hopefully in the next few

months um great and I have another question regarding you said that you try to make everything as simple as you can and is there something that is too complicated to have in that if it was simple you put in or too complicate for now at least well for example I mean bat swaps I mean that uh that example that I just said of like trading token a for token F and they are not in the same pool uh and doing all that swap path that potentially has adding liquidity and removing liquidity in the middle that's super complex in Balance actually that is part of the Vault uh and the The Vault has to uh need some help from the pools to decide whenever there's uh

adding or removing liquidity uh so that part is like super complex and we basically took that out from the Vault so now basically if you want a bat swap the router will do that for you by combining simpler operations at the bolt uh that's one example um and if the is wrong then the The Vault would just revert everything and then we don't care exactly exactly uh another example is wrapping and unwrapping NY be uh again in balancer Vu The Vault wrapped and unwrapped na be that turned out to be a problem um so now the vault only handles rc20 tokens and the rter is uh the one that has to wrap and unw wrap in that in case there's native with involved in the

operation yeah that that makes sense I wouldn't expect the Vault to do such operations if you can just Outsource them yeah if there is any more questions feel free to ask um but I think um and that's that's it thank you very much Joan was very interesting thanks to you also to a million from before and um I think that is everything thank you everyone from uh from Jo us and um have a good evening or good morning depending on where you are thank you very much pleasure thank you thank you everyone