Voltz 🛠 Building the future of DeFi on Voltz Protocol

[Music] [Applause] um hey everyone i'm super excited to welcome you on this workshop so today we'll be talking about both protocol and how you can go about building the future of e5 on top of uh protocol so my name is archer my name is archer begin i'm the cto and co-founder at post labs um the company uh behind the creators of post protocol um if you ever have any questions uh or just wanna like have a chat feel free to thank me on discord or twitter and uh yeah uh so start so the agenda for this talk is kind of split up into a few parts um initially we will talk through the kinds of boundaries the rewards that we've prepared for the ether the microphone um then we'll briefly talk about pulse protocol and how it works and what uh how it delivers on its promise of effectively creating um capital efficient interest rates for some type of t5 then we'll dive into the developer resources that can leverage to kind of build on top of volts and gonna bring the next generation of uh divisive products into life um and then finally we'll conclude with a dev workshop where together kind of build the liquidator bots on top of those protocol and in the end i'll let you guys ask any questions you have cool so um for votes uh we have kind of brought 8 000 um dollars worth of bounties uh for the developers that choose to build on us so for the most useful application we'll be distributing four thousand dollars for the most creative application uh built on poles will be distributing 2.5 k dollars and for the um and we also have like another uh tier which is for another interesting application which is going to be 1.5 thousand dollars um so i guess what's proposed protocol um when thinking about those protocol you can effectively define it as a non-custodial market maker for interest rate swaps and you can think of it as like the dydx for interest rates if you think of dividx as a protocol where you can effectively showcase your views on directional price movements you can think of bolts as a protocol where you can showcase your views on directional interest rate movements um so um before we dive into the actual mechanics that enable volts protocol to shine i'll be good to talk briefly through like what interest rates are and kind of what they mean in accounting for traditional finance so if we think about traditional finance the amount of emotional that gets rated annually interest rate swaps is around 1.3 billion dollars which is just an immense number uh which shows effectively like how big this market is but if you ask a retail user like a typical average person they wouldn't really know and they wouldn't really tell you that they have used interest rates directly but if you want to think of like the most obvious use cases where interest results are applied you can think about mortgages you can think about fixed rate loans all of them in one way or another leverage and underlying interest rates to kind of fix the rate of return so um so how does both work and how does both kind of deliver on this promise of kind of bringing interest rate swaps to the world of d5 so you can think of volts as like a combination of three key kind of zero to one innovations modules that make up the protocol so the first one is a kind of concentrated liquidity uh virtual automated market maker which effectively uh brings a two-axis amm that lets variable takers and fixed takers exchange variable and fixed cash flows amongst themselves so you can think of a simple scenario where you you know deposit funds into ave uh get an ausdc token which has a variable rate of return you can then take it and bring it to wall's protocol and get into a fixed taker so for the fracture which effectively means you can give up the variable rate of return in return for a fixed rate that comes from variable takers um another key module that we've designed that kind of enables the creation of interest rates is the margin engine which is kind of completely separate from the vmm where the vmm is mainly used for price discovery margin engine is mainly used for cash settlements the management of underlying tokens as well as liquidations on the protocol and and the neat thing about um interest rate markets relative to um price uh kind of like like prices uh is the fact that interest rates tend to kind of exhibit a mean reverting behavior meaning that as a liquidity provider you can effectively choose a given fixed rate range which could be like between one percent and four percent and provided within that range um and because interest rates tend to be mean reverting it's it's less likely that the race kind of would get out of bounds of your range um and another kind of interesting feature of the margin engine is that it doesn't actually force you to use the underlying yield bearing tokens as collateral it actually enables you to express your views on interest rate movements by just depositing the single underlying asset as collateral and kind of trading rates on leverage and if you think about the final kind of piece of the puzzle that makes up those protocol is the kind of the on-chain rhetorical design that we came up with which effectively can be thought of as a kind of a buffer uh which continuously pulls data from on-chain activity on particles like ave compound and then uses this data to calculate historical rates of return which are then used to determine margin margin requirements on the protocol but also used to have for settlement purposes and we spend a lot of time thinking about how we could build this rhetorical and initially we were thinking of using an off-chain solution but eventually we kind of uh took inspiration from the tiwa particle design of uniswell and came up with a mechanic which lets us effectively write historical rates on chain by leveraging um the kind of the users of the protocol so every time somebody swaps or kind of means liquidity on the protocol they as a side effect of the transaction they cause a right to happen on the radar of volts which basically ends up kind of accumulating historical buffer of rates which is something that hasn't really been introduced before in d5 and if you want to think of the rate of co as a primitive in itself you can think of it as like a perfect solution for like a historical data analytics platform um and also it could be used for future generations of kind of interest rate protocols and other derivatives that wish to leverage historical rate data to come up with better march requirements and better risk measures for the future of d5 um so if we want to think about um the kind of agent on the protocol they can effectively be split into three fundamental groups so you have fixed takers you have variable takers and you have liquidity providers so if you look at the diagram on the slide you can see that um at the center you have false protocol the vm and the margin engine duo on the left you've got the fixed takers who are effectively receiving fixed rates and and giving heating up variable rates um to the protocol on the other side we get variable takers effectively uh promise fixed rates for the fixed takers so they access guarantors or fixed rates and in return they receive the variable rates and the final piece of the puzzle is the liquidity providers who are effectively agents who are comfortable entering into both fixed taker and variable take positions with both sides of the market and they're able to do that by using single kind of underlying lp so you could it could be in terms of usdc it can be in terms of um die or any other kind of alternative crypto asset and they can do that while still kind of collecting uh fees from kind of traders on the protocol so if you want to dive a bit deeper into like each agent and and like how they work and what are the main use cases uh for each kind of agent type in the protocol um we can start with fix takers like the i guess the easiest type to understand um so you can think of fixed takers as like c5 organizations such as coinbase book five etc who could effectively promise fixed rate of return to their uh customers but right now at this moment they kind of only are able to hold comparable field assets such as c usdc or ausdc and so on so what they can effectively do they can use volts in order to fix the rate of return they are receiving on the cusdc and remove this risk that stems from the uncertainty about variable rates from their kind of balance sheet when promising fixed rates to their customers and you can think of similar scenarios when thinking about fixed rate takers um that could kind of be facilitated by kind of family offices fintechs and protocol treasuries who kind of tend to be more risk-averse and on the more risk-reverse spectrum um um when thinking about a risk reward in context of rates um if we kind of then move on to the other side of the market which is the variable takers um we can think of a simple scenario where um a variable taker is a trader that who believes that the variable rates and given protocols such as compound are going to go up uh relative to the fixed rates currently offered in the market if they have that view and they would like to lever up their exposure on that view and kind of um maximize their p l uh you know if they end up being right they can they can choose to do so by depositing collateral into volts um and getting a variable taker slope uh at 10 to 15x leverage um which then means that if the realized variable rate end up ends up being 15 and the fixed rate ends up being 10 then they effectively get the delta between 10 and 5 15 which gets multiplied by the leverage factor um and then yeah in this scenario if the variable rate ends up being higher than the fixed rate um the variable takers get very high leveraged returns um and we can think of like a typical user type would love to kind of engage in such activities is like a typical d5 degen or that could even be like a team that leverages underlying votes infrastructure to enable um roles that effectively bring strategies that deploy variable taker funds by pooling very different investors um there's also another interesting application of variable taker swaps so it's actually an interesting idea imagine that you know you you hold some assets in ave and you know if you want to then like get compound rate of return right now you would have to take your funds and then bring them all over uh to chrome plan but with volts you can actually keep your assets on ave um you can go and effectively enter a a fixed taker swap uh with put away which effectively means that you give up your variable rate of return uh and in return get the fixed rate but you can then go on another interest rate stock market uh where you enter into variable rate swap in compound and as soon as like all the cash flows end up canceling each other uh you effectively get the variable to variable swap which means that you can keep your assets on ave but get a variable yet for from compound um so yeah that's kind of how the variable takers work um i guess the final category of users uh which which we have on the protocol is liquidity providers are they kind of the backbone of the protocol and when thinking about the liquidity providers we can think of agents who might have a belief that in the next 90 days the fixed rate on the protocol is going to be around 10 and that scenario they can choose to effectively deploy collateral into a custom fixed rate range and the more concentrated this range the higher kind of apy opportunities you have as a liquidity provider to generate fees based on the clutter that you deposited and and the cool thing about the design of the protocol is that because we're utilizing a two axis amm that means that as a liquidity provider you can enter into positions with both fixed takers and variable takers meaning that you can effectively uh map out the cash flows from both sides of the market and you can recycle your collateral and keep entering positions and generate you while staying market neutral relative to the underlying interest rates in the markets and the market makers in our mind could be could be sophisticated traders and can be five volt creators who are likely to engage in this type of activity um and um one interesting project that could be kind of built um as part of the hackathon is a nlp optimization vault um which effectively kind of tries to obstruct away all of the kind of complexities involved with kind of managing the the fixed rate ranges managing the margin requirements and so on while giving kind of retail investors an opportunity to positively provide liquidity on rolls um if you want to jump straight into kind of building on the protocol i recommend kind of you check out our docs as well as the discord server where you can come and ask any questions that might be of interest to you additionally you can also come to our medium or read our live paper in order to get a better idea of how the protocol works behind the scenes and then finally if you just want to ape intervals you can check out our ui and start trading so if you want to um yeah uh this is basically this is the the theoretical part of the workshop as kind of over now i guess the most exciting part uh is we'll try and kind of build something together um and for the purposes of this uh workshop uh we're gonna try and like build a liquidator board so before we kind of dive into like how to build a liquid about maybe helpful if i can understand um how they work and what what is the utility that they bring to the protocol so if you think about a scenario where a given trader um enters into a leveraged position on volts um in order for the protocol to stay safe um there needs to be a mechanic that you know liquidates positions that are kind of um risky um in a timely manner and liquidations on volts happen but in a very simple mechanic so um let's imagine there is a position which has a margin account which is below the operation margin for requirement this means that any anyone can come in and try and liquidate them um they can be liquidity providers or traders and in return for the liquidation they can get a share of the margin of the liquidated entity and that's effectively the incentive that enables um yeah which incentivizes liquidator bots to keep the system healthy and free of risk well as free as possible um cool so um if um if you think of like liquidation uh it can be fundamentally broken down into two key um phases the first phase is um what we call like a pre-processing phase is where you effectively try and pull um very different positions on the protocol they are active they can be traders it could be providers uh once that's done you can then um start kind of sorting them based on like how risky they are and then you know once you discover a position which you feel is kind of a below regulation threshold you should be able to kind of recreate the position and the challenging thing isn't actually the liquidation itself the challenging thing is to be the first who finds an opportunity to liquidate um so you can think of like the liquidators as kind of the half high frequency traders of of d5 um cool so um the purpose of this workshop is just to motivate you guys um by showing how you can build like a very simple liquid robot with a single position a singly gritty provider and a single liquidator and once we go through it would be great to see kind of how you guys can take this idea and like spin it further and yeah maybe build something a lot more smarter and less naive than what i'm going to show you now so if you want to jump into the code base you can just scan this qr code so let you guys take a few few seconds if you want to follow along and then we can jump into the workshop cool um so the link should take you to thunderball's core repository and on the volkswagen repository you can follow up and go to the liquidator build section initially we'll go through the design of a simple liquidator bot which will then follow by simulation which creates a single equity provider position and then tries to liquidate it fiercely created because the margin requirement is satisfied and then we'll manually tweak the apy in the underlying market to make the position nucleatable to show that basically the liquor pair both works so the first uh first we will refer to this liquid about smart contract uh which is a simple kind of test liquid about contract which has a few key functions the set margin engine function lets you pass in the address of the margin engine that you would like to reference and the margin engine effectively just references a given interest rate swap pool and interest rates for pools that tend to differ depending on the underlying rate oracle um depending on their kind of maturity date um and so on um once the margin engine is set then you can call the function get any liquidator reward which will pull out the proportional margin that gets allocated as an incentive for successful liquidators then moving on we have the get liquidation margin requirement function uh which takes this input the recipient will address the tick lower and the tick upper of the position so the thick lower and thick upper are effectively numbers that represent fixed rate ranges within which liquidity providers can deposit uh collateral um and and this function uh pulls out the position and um outputs the liquidation margin requirement um for a particular position and final function is just called liquid position it also takes as input the owner address the lower tick and the upper tick and then tries to call the liquidation and this will be successful if and only if the liquidation margin requirement is not satisfied um by a given uh position or liquidity provider so this is basically the design of a simple liquid about if we then want to like run a simulation and see how it functions on top of a localhost environment we can follow along and kind of open the literary book simulation file um which has a bunch of code but uh at its essence it just sets up an environment uh where it kind of deploys a margin engine a rate oracle a token uh which we can leverage for testing purposes um for our simulation it then um says the margin engine parameters uh for for the given interest rates for pool um and um if you want to learn more about what these parameters mean um feel free to check out our live paper um and dive deeper once the parameters are set uh we go on and deploy the periphery of the protocol which acts as the contract that passes the entry point intervals and once the setup is done we're ready for the actual simulation so before we start the simulation we manually uh tweak the uh reserve normalized income in in the underlying lending pool and all and all that does it effectively uh manually sets the historical apy in order for the liquidation position requirement to be met for our purposes um and then once that's done we manually set the rhetorical value to kind of to fetch the data from the underlying gallery landing pool once that's done we can check this historical api matches the one that we have set um and then we can move on and set the liquidator reward for a given margin engine in this case we'll set it to five percent meaning that um after successful liquidation a liquidator will get five percent of the margin uh of a liquidated entity uh once this is done we are free then to kind of uh deploy our uh liquidator bot smart contract on top of uh the local test network um and follow up by setting the margin engine to be the margin engine address behind the interest rates for a pool within which you want to kind of conduct liquidation um then moving on we can fetch this newly set margin engine to make sure it's the correct one and then check if the kind of the liquidation proportion reward proportion is also correctly set um once all of these checks are over we can actually start our scenario so the first thing that we do is we initiate a liquidity provider position and in order to do that we need to call the mint or burn function of the periphery which takes us input the margin engine address which has a one-to-one relationship with the interest rates hopefully on the protocol uh we reference the thick lower and thick upper which um are a one-to-one relationship with a given fixed rate upper and pictured lower we also provide a notional amount that the trader wants to kind of facilitate liquidity in and provide a margin delta which specifies how much margin you would like to provide to support your a given liquidly provided position once we've done we can then check the initial margin requirement of our liquidity provider uh which will then come up to be kind of um higher than the um lower than the actual margin account meaning that the trader is safe and we can test this by trying to call the liquid position function through our equator board and which you know we expect to be reverted with an error that says you know cannot liquidate uh which means that the position is safe and you know it's it's not risky um but what we're gonna do after that is we're gonna advance our pool by one day uh and we're gonna manually tweak the interest rate to go from all the way from three percent to seven percent um we're gonna write this value for rhetorical and once that's done uh we can then try and um you know check the liquidation mark requirement and once we check that we we can see that the location margin requirement is going to end up being higher than the margin account of our trading meaning that you know at that stake of state we able to liquidate the position um so yeah once that's done uh we can then kind of reference the current balance of the liquid about contract which we should show up zero but after a successful liquidation it should be equal to the margin account of the liquid entity multiplied by the five percent reward that we have set as part of the simulation um so let's just try and run this script and see what happens cool um so i don't know if you can see the screen let me just enlarge it a bit so if we just go step by step um the first thing that the console prints is the historical apy which is around three percent that have manually set on ave um and once we have done that we can then print the liquidation margin requirement and the initial margin requirement of our liquidity provider which had around 27 20 73 000 430 000 respectively and we know that the margin account of our liquidity provider is around 500k meaning that at this stage they are kind of safe and they cannot be liquidated but we can see that after the manual tweaking of the apy and kind of uh rolling of time into the future the historical ui is now 7.6 uh meaning that if we check the liquidation margin now it's around 692 000 which is higher than the account the margin account of the leak of the entity that we're trying to liquidate and so after schedule activation we can see that the kind of the balance of the liquid or smart contract goes all the way from zero to twenty five thousand which is exactly equal to kind of five percent of the final decay margin deposit uh that you see in the beginning of the simulation um and yeah that's effectively a very simple rundown of a uh liquidation involves protocol cool that concludes the talk and yeah if you guys have any questions feel free to ask them [Applause] um uh yeah so the historical api um potentially is calculated by um looking at the let's say you have a one year pool and you want to calculate the historical api with a six month loopback window uh we just need to check out the reserve normalized income in case of away today and the resulting rise income six months ago find the ratio between those two and as soon as you find the ratio you get the rate and since you get the rate you can then analyze it and get the api that you can reference in the margin engine so is it expected yeah yeah and that's kind of the the design uh so in order to avoid um a range of different attack vectors that could result because of like um short term uh fluctuations in interest rates uh we have create a pivot oracle which is resistant to this sort of fluctuations because it takes a much longer view on the historical rates and comes up with you know more smooth um kind of uh time series of margin requirements for traders on protocol meaning that you're protected from this sort of attack factors and scenarios thank you so the way it works is um as a liquidity provider um you as soon as you choose your upper bound and the lower bound for the for the range um you end up getting a kind of liquidity provider position account which has its own margin uh requirement and so each position on the protocol is kind of uniquely identifiable by this set of these three parameters um and the reason why we decided to kind of split it such that each position is unified identifiable bets address operating and lower tick is because it allows us to calculate margin requirements for liquidity providers by simulating uh trading activity on the protocol because you can think of liquidity providers as traders in the future uh in the sense that you know even though right now you don't have a position as a liquidity provider you are effectively saying that i'm ready to enter into position in the future and these are the rates at which i'm kind of comfortable doing that and what happens behind the scenes is we simulate this transaction in our margin engine and we come up with the margin requirement um that is the like the highest possible um requirement that you could get uh if somebody if the trader were to come and like trade your position fully and yeah that's kind of what facilitated the design decision thank you cool i guess if there's no more questions um thanks everyone for attending this workshop and i can't wait to see what you guys end up building um if you have any questions at any point during the conference or the hackathon um feel free to check out our booth and will be more than happy to help [Applause] [Music] [Applause] [Music] you