Agent-based modelling of lending market risks. A case study: 0VIX

ETHCC 5 · July 2022 · 27:48

Daniele Pinna and Amit Chaudhary model 0VIX lending-market risk with a multi-asset, agent-based simulation. They examine price-driven liquidations and stressed volatility using historical data, presenting results within the assumptions of that model.

Speakers

Topics

From ETHCC 5, hosted by Ethereum France.

Transcript

hi all good to see you thanks for coming this is amit and daniel is also there so we're gonna present lending market risk assessment via agent-based modeling uh let me give you a very brief background like like why we are doing so what's the use case of that and uh so we so it would be a joint presentation i've divided it into two parts like i'll going at the high level and then we'll have a very deep down on what we actually were talking about so financial stability and defy like two scary words so it's a so in the beginning of a year when we started doing this actually at

polygon we thought that this is the right time we start taking it super seriously and then the debacle came like a various tobacco then we rammed up so theoretically like there is a dilemma of scalability and stability like why imagine like if you want to scale a d5 solutions uh you add up a lot more network what does it mean okay it means if if a risk can be started at one node it can propagate much more quickly and widely so that's a dilemma like you are scaling the d5 system but you're also making it okay much more risky as well

so that's a network effect working in the negative direction for the financial stability part and you know this financial stability is a public good so that's why like we at polygon are actually doing it if the protocols in the d5 started getting themselves stress tested optimized on the risk framework the whole ecosystem will benefit it's the financial stability which we are talking about and what we are working on on the risk assessment framework for d5 uh the reason there are primary three reasons of doing that like first one uh so there are three reasons so what happens like you know it keeps on shifting according to the era so right now the first reason that's a major

critique from regulator and central bankers is the first one like last year it was the last one so one of the major critique they have like it's a d5 is to become widespread its vulnerabilities might undermine financial stability no safe consumers i picked up these quotes because these are like prominent quotes by important persons without naming them of course and also we really want to make defy system protocol robust to handle uncertainty so the protocols itself need to evolve as a stable solutions so for example can risk taken by users can be concretely quantified because there exists like people users go to the protocol do

something they are sometimes educated they are not but what what about the risk can we give more information to the users and then users can take much more informed decisions so that's that's what it is the risk assessment as after and the third the most important thing i think if you're in the d5 world capital f efficiency is the like very common word over collateralization is seen everywhere in d5 and what risk management framework can do in defy you can like dynamically reduce the amount of collateralization so optimal decisions can be taken so that's what you know the

risk assessment framework is all about i'll i'll give a very brief overview what we are talking about in high level uh we decided like we i talk high level and daniel like really dipped down because apparently he has more postdocs so so so if you see in the center like is a d5 protocol it's a very complicated universe like i have that's a real graph for the d5 protocols which you see the networks like the curves unisop everything and in this in this uh d5 protocols what we are trying to build is around a resilient shell around it this risk assessment will act as a resilient shell because our risk

assessment engine can take modeled uncertainty into the account by modern uncertainty into account like some external behavior in the outer side market which is causing some potential shocks to uh the d5 protocol once we assess the protocol's risk this the the risk engine throws you some of the parameters like you can do option one two three you have to optimize this then you need we need to implement a risk and management solution uh now the owners lies are either on the dao or the protocol people or the community like it's an open-ended question but then the whole the what i'm trying to explain here is the whole cycle you assess you

stress test the protocol you implement the risk management solution you monitor and review it and you keep on doing it for certain times and then your protocol become like really robust to the market uncertainties so we we take the agent-based simulation framework but what like in and the protocol which we stress test is a wix protocol so one of the good benefit about stress testing is like you can really uh focus on this focus using the simulation be pre-launch so that's that's what the really important you can do it post launch also you can do it on any of the lending protocol uh compound of but uh self optimizing protocol even before the

launch is super important so in this in this mod in this model or the framework or us for the lending protocol there are two agents borrowers and lenders they're clearly shown like borrowers and lenders here so borrow so there are various types of borrowers the complication here is like every borrower is of a different type it leverages at a different level their amount of collateralization is different across different scenarios so like we try to model it in an agent-based simulation model uh in the center there is risk management happening so it's a framework which uh one of the one of the actually one of the main usp of this approach is agent-based model modeling which

actually central bankers always dream of doing into the real economy so the smart contract has a deterministic kind of outcomes because it's a written code so we can actually precisely model it using agent-based simulation behavior and so we have come up with uh a paper it's on i think this i'll share the link so it's a multi-asset agent-based approach it's a like if you're it's a math and all is everything written down there and uh like daniel i think we'll try will uh try to explain some of the uh graphs which you can gather and see like you like it and the usefulness of the use cases of that uh the whole the whole idea is that it's like we're trying to get it in the very

general framework approach and any so that any protocol on polygon chain can really risk assess them we are moving towards uh some of the usability of that in terms of front ending or something like that yeah so if you are interested or you're like you know and you have in your network who have protocols on our d5 protocols right do connect with us like would be happy to chat about this so um thank you thank you for the nice introduction um i don't know if it's a compliment to have more postdocs personally but i'll take it from here uh so yeah so we published a paper where we explained the whole the technicals of how you stress test a landing market so at ovix uh we are a lending market um with a veto economic with our plan on

the roadmap to introduce speed to economics to uh bootstrap liquidity uh to uh to the protocol um what is the lending market i don't know if you've been living under a rock and i've never seen a lending market before so a lending market is a place where people come and they lend crypto assets and they have the possibility of borrowing crypto assets against those crypto assets and the kind of users that come onto a lending market can be very diverse so here in this example alice has a bunch of stable coins and she just wants to gather yield on her stable coin so she comes on our lending market she deposits her her stable coins and just collects yield over time bob comes around and he's a he's a matic lender okay so he has a bunch of matic tokens he lends them and uh he uses that

as collateral to borrow let's say usdc on our platform because he knows of some other uh um yield generation scheme off the lending market and that's that's what he's into um uh charlie and uh and devon come around and they're they're respectively one's a bitcoin maxi and one's in ethereum maxi so charlie comes and and basically creates a leveraged long position on bitcoin by using bitcoin as collateral to borrow stable coins which she swaps for bitcoin which reader deposits on the platform and so on and so forth and devon is playing the flipping so she's depositing ethereum borrowing bitcoin swapping it for ethereum and and basically creating a leveraged long ethereum versus bitcoin position the point is that and then on top of this you know once once the veto economics get engaged we also have veto economics boost on top this is a very

complex uh mechanism of interactions between very different users and as a landing market you have to always guarantee that everybody can be made whole that the the protocol is solvent the money is there and and most importantly no user is ever under uh collateralized so how do we do this um so the we built a simulation engine effectively that simulates the whole logic of a lending market protocol where we can generate uh users uh fictitious and not and um the uh the the the main the the main inputs that go into that go into a simulation of a landing market are those yeah there we go are basically the price histories of price data histories for for the assets on the protocol so effectively at the end of the day the

lending market is stressed by introducing uh price dynamics and see how the protocol behaves in different um like price behavior regimes you have user actions which at the moment we don't consider to keep it as simple as possible and last but not least you have the actual users users are basically defined by this kind of density plot where i'll you'll see it in a second it basically quantifies like the distribution of risk that users are willing to take and the distribution of portfolio sizes that they're willing that they're willing to to bring onto onto your platform and then and then you stress you basically stress test these users and you see which ones get liquidated and you simulate and you model the whole liquidation behavior is there is there enough liquidity to

liquidate these users and what happens in terms of slippage and you uh compute the optimize the optimal strategies for liquidators to liquidate specific assets of the users and so on and so forth and all of this depends on specific protocol parameters in a lending market the two main ones are the liquidation loan to value ratio that uh that an asset has and the liquidation incentive that the protocol assigns uh to assets and and and so by stresses in the protocol you can effectively iterate over different combinations of such protocol parameters and find some optimum that you want to that you want to hit all right so the inputs as i mentioned users users are defined by the risk profile and the amount of money that they bring on the platform shown here is um is a a a typical histogram of of users in one of our simulations we do

many many many many of them this is just you can think of this as one of them uh it's a density plot it shows that you know on average uh users have portfolio sizes of of ten thousand dollars and take on um uh take on like a user lt an average user ltv of roughly 0.6 this is this this kind of data is data that you can extract um from from from vermont chain data by looking at for example users on ave uses on compound and you can see at any given moment in time what is the what is what is the empirical distribution of user portfolios and use and user risk and from that we can effectively sample we can basically model that distribution and sample from that distribution and we can generate as many users that we want uh for for stress testing purposes

then the second input price dynamics price dynamics can be generated in a bunch of different ways through simulating actual geometric run in motion or by taking historical data um and randomizing your starting point for for the data uh choosing to take to take different like log returns at different moments and times and just string them together or taking direct sequences of historical returns to effectively capture any potential correlation in in price data that isn't uh obviously modelable the point is that we can generate price dynamics and price histories in a bunch of different ways uh shown here is is an ensemble of price histories with a couple of them color-coded specific ones color-coded uh just for for for visual sake all right and so so we initialize users

on our protocol right and then we can we we simulate the price of the assets on the protocol and we see who gets liquidated who doesn't get liquidated shown here for example is is like a back test on on maddox worst performing day this was uh november 26th of 2021 actually it's had a worst day since then but the paper is from it's from may so this is what we got and shown here so in blue is that is the price dynamics and the bars the the bars are effectively the liquidation events that we can simulate uh that we can simulate with our stress testing mechanism i'm not gonna go into the math but if you want read the paper and like we explain like the whole logic of how you how you optimize like the kind of the kind of non-trivial optimization um uh problem that liquidators need to

solve to choose a which user to liquidate b which collateral asset to repossess c which loan to repay d how much of that loan to repay there's a it's it's a non-trivial problem it's not rocket science but it's it's a problem that needs to be that needs to be properly handled all right oh and by the way one thing i didn't i didn't mention is when we when we when we simulate when we simulate liquidations we also simulate slippage uh on available liquidity for swaps so liquidator typically will repay a user's loan repossess their collateral and then you know there's they they basically possess the amount that they liquidated plus some some percentage that's uh that's their liquidation incentive bonus and then typically you assume that they that the the assets that they repossessed they swap out of it to basically remake their their original

token back and and um and keep and keep the profit so for this you also have to keep into account what kind of slippage they can expect to see on uh uh just in general for swapping out of that token and that goes into the whole optimization process for how a liquidator liquidates users okay and shown here is like a protocol wide like health diagrams okay on the left you have the protocol ltv loan to value ratio in the center you have in for for a set of simulations the total liquidated funds on the protocol and on the right the outstanding debt left over and it's all color coded by volatility in in in asset prices to keep as simple as possible for for presentation's sake the assets are all assumed to have the same

type of volatility except for except for st for first table coins um which is certainly not it's not exactly reality but it's it's close enough to make plots that you guys can look at very simply on on a screen um and uh so the the uh the shaded regions are 95 confidence bands intervals so we can effectively see how you know for for really really high volatility is the protocol loan to value uh the the loan to value of the effectiveness of the entire protocol goes down this is typically the result of liquidations which effectively reduce the outstanding debt and in fact you can see that on on the right also and we can monitor all these things and we we can monitor these things as a function potentially of protocol parameters to see where we want to be okay so let's optimize for protocol

parameters shown here is a graph of what we like to call the under collateralization frontier okay so we basically ask ourselves okay we run we we generate abundant an ensemble of users we we run this ensemble of users through a bunch of different realizations of price dynamics uh which are day long we don't simulate longer than a day because beyond that you can't assume that users won't ever retouch their portfolio um so this is obviously an approximation but you can think of it as a like as a worst case scenario like for 24 hours nobody touches their portfolio locations um and we ask ourselves at the end of the day what percentage of the users ends up under collateralized so just for reference and for context we're using in the price data we're using we're

simulating one minute ticks so effectively any liquidation takes what will by default take place with a 30 block lag okay uh this is on polygon right 30 block black on polygon so during that those 30 blocks a user that is already liable for liquidations their health can get a lot worse during those 30 blocks depending on what price does depending on how bad how much worse their health gets you could get into a situation where that user becomes under collateralized big no no you don't want this so if you want to avoid this it's important to find where this happens and that's what we call the under colorization frontier shown here on the y-axis you have the liquidation ltv for for a specific asset on our portfolio on our platform

and on the x-axis you have the liquidation incentive that we assign to that asset so these are about two critical parameters uh in a landing market and we can effectively like grid this entire plot and basically sample um pairs of liquidation centers and liquidation ltv run a simulation with uh with price dynamics with different volatilities and we can see where this under colorization starts happening with a probability higher than one percent the solid line you see here is the theoretical prediction that we discussed in the paper for where you are guaranteed to create under collateralized users so it was really nice for us to see that the simulated data and and and and um the the the theory kind of matched up on here but why stop and me and the theory is basically this you basically you

never want your liquidate your liquidation loan to value ratio at plus your liquidation incentive always should be less than one the reality should be significantly less than one you never want to get close to this liquidation front this uh under collateralization frontier uh but why stop at one percent let's make this more refined if we're given enough computational power you can do way more simulations you can resolve way smaller um uh uh tail effects in in the stress testing so let's check the probability of generating 0.1 percent under correlations under collateralized users right so again you have the the solid line is the theoretical line but now you see that the under collateralization frontier like moves further to the left of it and if you were to keep going again given enough computational power you could think of of generating for any uh probability of

under collateralization you could basically foliate this entire plot and then it's a matter of choosing what kind of risk am i willing to take is 0.1 percent good enough 0.01 good enough just in general we stopped for the paper we stopped at 0.1 percent but we talked about this like yellow region as being an area where you'd want to choose your values depending on uh on the assets that you have on on your protocol and this is this is how you stress that's the protocol this is how you it this you do not want to have too high of a liquidation ltv value why because then to remain safe you need to have a really low liquidation incentive and if your acid is and if you have a really low liquidation incentive that means the moment that acid starts getting toxic liquidators aren't really incentivized

to liquidate that toxic asset again you're going to be in a situation where you create under collateralized users but why stop at the protocol level let's go to the individual user level so shown here i apologize if it's too small but um we picked we picked two random users um uh this is actually from avid these are two random ava users that we picked and this is to show one very important point that we'd like to stress right now lending markets focus their entire risk uh presentation around health factors who here have seen has knows what i'm talking about who's here has used uh d5 lending protocols and knows what a health factor is fantastic it's color coded green orange red you want to stay out of the red you don't want the number to get too close to one it's scary when it gets close to one right but the point

is that that number is kind of stupid it's a i mean it's not stupid but it's a naive number it's effectively a proxy of the loan to value ratio of your portfolio but just because i have a higher loan to valuation in my portfolio than someone else doesn't mean that i am a riskier user than that user shown here is a typical example of that so we have um in green and red we have two users uh that that with a with different starting loan to value ratios so red has a lower loan to value ratio so in terms of health scores has a higher healthier health score than um than the green user and this is simi this this is uh their ltv simulated their ltv and outstanding debt simulated over time um during the covet crash so using the data from the code crash right what we start seeing is

that um the green user which you can imagine is uh is probably uh um short crypto uh is uh is does does relatively well whereas uh whereas the the the red user actually gets liquidated and we can see this in the cumulative liquidated funds we can see in the outstanding debt of the user and so on and so forth but we can go more in detail we can look at these two users and and simulate their the the actual distribution of their loan to value ratios as a function of different price volatilities of their assets i don't know if you can see them they're written really small but basically all these plots are from uh lowest uh to highest volatility we simulate from zero from sorry from three all the way up to fifty percent hourly volatility and then we can affect with this data we

can extract a quantity which we think is much more useful for users and for user risk dashboards which is the probability of that user getting liquidated as a function of market volatility and that's what you see here again red and green are color coded like the users earlier and what you see is the probability of these users getting liquidated as a function of uh of market volatility and here's where you see green user who remember had a higher loan to value ratio lower healthcore actually has a lower overall probability of getting liquidated on uh on a lending protocol and we think that yes health scores have gotten us to where we are right now but it's important to to really raise the bar on what it means to to assess the risk of users not just at the use individual user level but at the general

protocol level once they all start interacting with with each other and uh with that i go back to the framework figure that amit uh introduced you to so we can we have this we have this model that effectively um uh it's a risk assessment engine where we stress test we uh we stress test the system to optimize for specific protocol parameters that allows us to implement the risk management basically based on the simulations that we do we can monitor and review whether in real life that actually performs as expected and then you start over again because the work never stops you always got to keep going and this is important for again parameter optimization uh giving users more advanced risk dashboards to assess what risks they're actually taking on d5 platforms and last but not least also inform

dow decision making decision making at the at the dow level and uh with that i'd like to thank you so much for being here uh for being here uh if you're interested in asking questions i don't know if we have time for questions i'm not clear how exactly it works but if not you can meet me outside and we also have a bunch of ovic's swag that we'll we'll hand out for uh for questions uh you can read more uh at our paper here on the ovics.com website and you can find us on twitter and on telegram and we're very friendly lovely people thank you very much any question thank you very much very interesting presentation but have a one question

regarding the last slide so you mentioned a lot health factors but most protocols also have a second parameter the interest rate doesn't capture doesn't the interest rate already capture this next to the health factor uh no the interest rate captures uh right now actually we could have a whole other conversation interest rates and we're working on a paper on that matter precisely uh interest rates really capture uh the amount of uh actively utilized capital on your platform uh you don't want to utilize two you want to incentivize utilization but you don't want to incentivize too much utilization because then users can't withdraw their money but but at the same time i'll agree the interest rate does matter here in the sense that right now these simulations that are presented here today the users

are basically uncoupled agents we can look at individual users and assess their risk because it's a it's a one day long simulation sure there's in principle there's interest rates on top of the price dynamics but we're stressing volatility high volatilities the bips you're paying over the course of 24 hours are are neglect negligible compared to these to these price volatilities but if you want to simulate longer periods of times you where you then have to also model the behavior of users which is a whole other beast then yes then you need to model borrow interest rates because that's how users communicate information to each other about what they want and to use or not use on your platform okay thanks a lot any more question

um so yeah my question is you you mentioned that you your simulation match theory right i guess the natural question i have in mind is how well are you able to predict empirical data so what's the performance in terms of right predicting liquidations of users so so um on a 20 on a 24 hour time scale it's uh it's it's it's again it's pretty good but you don't want but pretty good has to be put in quotes because the point here is not to predict a specific event in reality the point here is to predict worst case scenarios and create worst case bounds for how reality may unfold and choosing your protocol parameters in consequence so that then you don't care what actually happens in reality you've simulated like worst case scenarios

you've quantified worst case scenarios and you're prepared for the worst case scenario this line doesn't happen in reality because nobody wants to get that close or that risky as a protocol you want to add something else yeah i think a very important point you can clearly see it theory doesn't matches right so this is the area actually where the liquidity in the market is less the slippage is too high so that's that's a deviation which occurs actually so yeah so it also depends because if market is too much volatile uh it also depends on the external market also because in the d5 we are also liquidating on dexes like uni swaps kind of thing so that's one of the constraint which also

d5 phases you hear like liquidations right those are on chain liquidation so that's why so if if if we see the binance kind of a liquidity indexes like probably it will match perfectly i hope that answered a question but yeah like this is like golden rule never get anywhere close to there you will generate problems on a landing market but luckily nobody's nobody's really there i mean you'd have to like be really playing with like super exotic tokens to to get that close but but it does it does tell you it does tell you if you're listening if you're listing a token you can't just think oh what liquidation ltv will i give it you have to you also want to choose a

liquidation incentive that is proportional to the risk that token brings to your platform and you know if your liquidation incentive is really high because you want that asset to be liquidated first if anything weird happens that already starts setting the bound to what your liquidation ltv should be and so it's like it's this two variable problem that that needs to be properly assessed all right thank you very much