Liquid Staking Security with Lido, Stakewise and Frax

Transcript

welcome everybody to the uh defi security Summit today we have two Titans of Industry within the liquid staking world uh Eugene and Demitri who are going to talk to us about um some of the things that they've been working on so first we'll hear from Eugene Mammon uh he's a Lo Lido protocol contributor Lio is the issuer of the largest decentralized liquid staking token uh Ste Eugene I'll let you take it from here yeah hello hello everyone thank you for having me today uh I want to start a presentation shortly let me share the screen first

okay oh just a quick reminder to everyone uh we do have some time for Q&A after this and so if you could please use the Q QA box uh below uh it should be part of the zoom Web Conference to post your questions and we'll do our best to pick out the best ones and ask our panelists okay thank you uh shall we start then y let's do it okay so uh once again I'm from V uh I'd like to talk today about the aspiration for an UNM protocol uh it's the concept that leaves inside lier uh so I'm Eugen lier core protocol

contributor I've been participating in the protocol development for two years uh and participated in the largest so far uh protocol upgrade li2 uh so today I'd like to start with a short explanation uh what lium is uh what is UNM operation how we Define this concept uh then I refer back to previous uh def security Summit topic about most important security measure um moving forward I'll explain how we approach to coron M operations and uh what are the inter iterative

improvements for the protocol uh have been introduced and anticipated further uh last but not least uh there are various takeaways concerning death connect week happens quite soon so first of all what is Li on ethereum it's liquid staking protocol uh the protocol acts as a middleware connecting users who have other and not operators who are able to run validators uh participating in eum consensus uh nowadays protocol tvl uh is more than 8 million than other uh so Qui fact list is that protocol provides uh

St assets uh it's St and its version uh the protocol has uh withdrawal mechanics implemented via in protocol Q uh it's a reason for having another token honest it's an nft position represent representing you inside the cube uh the withdrawal mechanics was brought to the protocol together with SL to upgrade uh and another significant feature was brought it's taken router uh composability solution allowing uh on boarding diverse validator subsets uh last but not least um all of

the protocol upgrades uh changes parameter tws and tunings are performed uh via explicit on chain Dow voting process uh the governance token is ldo so let's start with the LI da topic briefly uh recently Li da stepped into uh new framework for goal settings and uh objectives it's called go it's guided open objective setting exercise uh basically uh it consists of goal setting framework and its cence

following one of the important parts here that the D ratified submission of hassu it's slide advisor uh who uh who also uh Pro provide a strong focus on protocol security to achieve uh to achieve light our goals uh and be uh and be uh and and be uh ethereum decentralized uh liquid stateum protocol so uh I'd like to introduce UNM operation concept it's

it's our security guiding principle uh what does it mean it means that uh UNM con of two parts uh first firstly we remove trust whenever it's possible and uh if uh uh if uh it's not possible that we are strive for remove it uh iteratively uh the second part is uh removing and avoiding any manual operations any side cars that uh requires explicit maintenance uh because otherwise it could become Tech depth and should be reevaluated Revisited in the

future uh so why why we talk here about UNM operation notfication uh because ACI ification is quite common concept here uh unfortunately ACI ification being the ultimate option isn't viable uh shortterm even midterm for the liquid staing protocols because uh underly networks Evolution I mean both execution layer and cons cons consensus layer uh still happen and uh more over there are various discussions about consensus layer changes taken mechanic

changes uh so everything is moving having so many moving Parts uh not practically viable to achieve verification so what I striving for is unman Operation uh I'd like to refer also to the previously uh disclosed and discovered in in depth uh security process uh for the LI upgrades uh and not only upgrades but uh actually all of the infrastructure St staking widgets Landing whatever uh is made by the ligher contributors uh so it is a talk by

Eugene p uh that he gave on defi security summon this year uh the key point of his speech was that the contributor team is the most important security measure uh but how come uh I mean we started with UNM operations and once again talking about people uh so the idea is quite forward uh basically people who work for the protocol and uh on the protocol mechanics strive for two uh things to happen first of all protocol trust SoCal should be uh should be short it should be shrinked

and uh the contributors team should be uh uh should should be uh uh removed from the circle at first and then uh the distance should be uh should gets longer and longer so that's it uh returning back to cor and M operation uh I would say that uh we we can we can group all of the protocol flows and mechanics into two separate groups first of all it's primitive flows like accounting deposits withdrawals and more composite

flows the whole governance topic valid dator set formation and maintenance uh so the gist of it that uh for UNM operation be we should start with primitive Parts uh and make it uh as in mind as possible so let's dive into it uh for for the accounting uh the state of art of the protocol that U protocol uh balances uh keeps uh keep updated by the Oracle committee the Oracle committee brings consensus layer data together with execution layer data for finalizing

withdrawals uh it's quite a complicated piece of uh data delivery but still uh since uh EAP 4788 is around the corner with the upcoming then hard for uh now it's possible at least uh in short term to deliver consensus layer data about validators balances uh however considering current EET validator set um size I mean more than 1 million indexes were allocated to R uh it's it's not practically feasible to prove uh every valid dat

State uh and in contrast it could be done with data compression where ZK field comes to play So currently we are looking for the case solution uh it it has been granted by the Lego uh part of the Dow uh so the idea is quite simple we make we we're going to make the process iterative not replacing the Oracle um in a single shot but instead uh make it make it gradually um incorporate the K Tech as a safety net layer

firstly uh and uh even further we uh participate in not only is one Z solution but uh it's three uh competitive Z Solutions we bonded by Lego and uh to connect them together we introduced multipro architecture uh it's basically kind of multi uh so when or when the Oracle provides data about validat balances the data should be uh in consensus between at least two of the

participants uh second point about un operations uh is withdrawals uh like I said protocol implements them however state of the art that um they are semi-automated it means that uh the da voted on policy uh exit requests are issued uh through Oracle uh technically it's meeting events and not operators monitor for these events and voluntary exit validators if they are affected uh and moreover if they uh haven't exited

timely they got penalized uh overall it works but still uh the there is room for improvement uh I mean uh suppose triggerable exits were implemented a smart contract would be able to um exit validators exit late validators uh in in a in a non-voluntary way but rather um defined by the smart contract uh and extra triggerable exits could pave the way for permissionless valid dator sets uh and uh make uh UNM operation even more robust and uh self

sustainable so that's why it's uh it's an important topic I suppose for for making withdrawals uh truly UNM and uh sustainable in long term uh but uh there is an interesting um fact that uh When developing withdrawals uh we stumbled upon various security considerations that uh not only new mechanics are presented with uh chaella heart Fork but also the protocol was hugely reamped and uh to overcome all of

the uh concerns and uh maybe paranoid paranoid activity we also found a solution here uh it's quite it's quite simple thing uh it's self deprecation mechanics uh that able to POS with drawals uh it's uh like one time panic button uh having only limited impact both by duration and by um involvement in into the core

protocol uh and once again why it's good and why still UNM uh gate seals have uh cell duplication mechanics uh that prevents peral control over the protocol uh so it's it's a kind of isolation solution for things that still can be considered for emergency but should be left uh UNM uh long term uh okay and uh last but not least uh there is there is an example of U

deposit operation um so previously deposits were permissionless in Li but once uh front running vulnerability was uh reported uh deposits are performed by Guardian committee uh Guardian committee basically signs uh block uh State rout of the uh deposit contract uh and a single honest actor of the committee can uh both deposits if FR tring detected uh so it's an example when we had we previously had purely unman

solution but uh due to vulnerability uh decided to uh solve it uh with uh committee and uh uh like uh midterm solution yeah uh if I speak about all of the iterative improvements that have been made uh for the protocol they are all presented in our scort card it's a self assessment measurement uh where all of the security topics are presented I believe not only security but actually it's about

decentralization but uh uh if we speak about decentralization we just can't avoid speaking about security uh and my takeaways here basically like like it pronounced in the beginning uh follow Li down def connect uh there are plenty of activities I I'd highlight the following uh it's a speech by Eugene P plan in the future of leer uh it's a part of staken summit November 10th uh gate seal tecture will be discussed further and there will be also the KE Oracle panel describing the ZK solution

uh for uh delivering validated balances data uh and quite recent topic for Lia uh I mean not not maybe recent but uh quite burant topic it's dual governance and community staken so so please keep in touch and follow for more uh follow for more activities and uh I I suppose uh I I I suppose uh you might find uh many more interesting information here that's all from my side than

you thank you Eugene um we're going to save questions till the end we'll have a a dedicated question and answer session uh but next up we have Dimitri tumac uh who is the founder of stake wise uh stake wise is a smart contract based solution to help us your stake ether and compound their rewards over time uh Demetri I'll let you take the floor uh thank you and hi everyone um yeah I'll I'll just share my screen in a moment can you see my screen yes

awesome um yeah uh let me introduce to to statewise if you haven't heard of it before um Stak wise is a liquid staking protocol uh uh we've been live since early 2021 um as of now we have 100K e staked and plus 25 million in liquidity um currently we are running on statewise V2 um so initially we started as a single node operator uh liquid staking protocol in V2 we upgraded to multiple node operators so that anyone can apply to become U operator in statewise protocol and now we are in a

process of transitioning to the new version which is statewise V free uh where anyone can run uh validated can become can run their like own uh liquid staking uh business or um they can run validators for others as well so in today's talk I will uh give you a bit more insights on how stake wise V free Works what components it has and what technical difficulties we had to solve to achieve uh decentralized uh U protocol that we have in VRE um

so our V free protocol is based on two layers one layer is layers is called bolt and another layer is called liquid staking protocol liquid staking token OSU so volts are um are smart contracts that contain all the functionality required for taking ether like accepting deposits from from the users registering valid processing the exit Q um and many many other things that you need when you uh run your staking operations on chain so and uh vaults can be deployed through the factories uh factories we

have like as of now four different factories that can deploy different flavors of vaults uh I'll tell a bit about that later um but also um like when you deploy the vaults you have different parameters you can choose and you can either provide uh you can run staking um for others you can do stating for others or you can also run your validators for yourself and have access to the liquid staking as well so another layer is called OSF uh and this is the token that you commit out of any Vault of course there is a slashing risk that uh you face when you uh um when you um

yeah when you just run when you mint the OSF token so o is minted not one to one but there is a um there is a it's over collateralized so basically uh you can't mint like for every e stake you can't mint like one one but you meant with a certain percent um it's very similar to uh how uh d Works where you have vaults uh where you can like lock your assets and you can mean die on top of it with certain colorization ratio and in our case it's it's quite similar here um but instead of locking like different assets you can only lock

ether that is then staked and and then you can mint OSF on top of it uh with a certain uh colorization ratio and then you can use OSF uh further in defi uh toti U um like other opportunities for your stake um so as of like use cases here um like bolts can be there are different flavors of bolts that's thanks to our uh architecture that we achieved on our smart contracts where we can we have like multiple modules and they can be combined in in different uh types of vaults um so this way we are able to deploy private vaults

uh vaults with like erc20 token so if you want to have your own uh St staking derivative you can deploy that Vault uh through the factory um and also you can have both you can have like a private and erc20 Vault so in that case uh you're running let's say uh institutional staking where uh you want to kyc people who can stick into your Vault and on the other side we have let's say a token that you can use um outside to integrate and that's like fully per in a permissionless manner it's like anyone can deploy the Vault through the factory and and select the features that they

want to have in their vault so yeah and some more examples from here is that um you can you can that's with like stake wise V free you can create a vault you can stake there yourself and M to if on top of it so you can run Bas for yourself uh and at the same time have a liquid token that you can utilize in Defi and uh if you don't want to like run yourself or if you don't want to create a vault you you can buy from the market and it has uh slashing protection because it's not minted with one to one with ether uh but actually it's backed by over collateralized mechanism here

that we use to make sure that we can protect from slashings um so yeah this is like um the the OSF itself uh it acur the value as well uh it's an average of apy of all the volts so every volt runs with its own API and and Os has like run like has an average of all the volts here and the rewards are accured every second and by staking and staking you can uh utilize like the secondary Market to um to Mint uh to actually get o and utilize it further um so a bit about like the

deployments uh of of the vaults um so um there are like multiple factories that uh deploy the proxy contract for for the vault and uh uh the Vault itself uh is upgradeable uh and and there is like uh dual mechanism for upgrading the the vaults I'll tell a bit about later on that um but here um when you deploy the vaults there is um you actually like deploy the proxy and connected to the implementation contract that was previously already deployed uh and is uh in chain so there are multiple modules that

we have um there is uh like Vault admin this is the module that is responsible for um like like making sure uh storing the admin of the Vault the admin can update the parameters like for example setting um who who going to have the possibility to Whit list the addresses or add update the deposit data required for um risting validators and and some other parameters as well uh Vault enter exit module is responsible for accepting the deposits from the users um and also like it has the functionality for withdrawing the funds from the vault as

well the O token is the one that allows vaults to me o um so it has all the functionality for checking whether uh the amount of os if you want to Mint um is not larger than the amount of e that you have St so um it checks um it's it's yeah similar to let's say if you lock e on on D Vault and mint D so when minting die it make sure that um you you have enough e locked so volto token module is responsible for for that volti mutes are just like the module which has some mutable values stored in they used

across the other volt modules Vol validators is responsible for storing um the data required for Reg validators so for example if you created a vault you allocated validator keys to it then uh when spinning up the validator that module makes sures that actually the validator that is registered right now was previously wi listed uh by the Admin of the Vault so basically someone else cannot register the validator for your Vault volage staking is encapsulates the functionality specifically for E staking so we also run like a nosis chain for example and later if we bring v3e to nosis chain we will be able to have like

G module that then can be used uh in conjunction with other modules to um provide staking here um so then B fee are responsible for the fee me module responsible for me uh required functionality we have like a smoothing pool as well and we also have like you can also collect M bewards only for your vault which we call like on M escrow um so they're based on your decisions during the creation of the Vault uh the different functionality is used um if you want to have your own volt token you can uh that volt token um uh can be used here and also like the

volt version is for making sure that um upgrades uh are done correctly so there is like a do uh uh dual governance um upgrades that we allow to do for the vault I'll tell a bit about later and VA white white list in case you want to White list like users who can State and and VA state is basically the module that contains the exit Q functionality so whenever user enters the exit Q waits for the asset to be unstake and withdraws that module does that and it also is responsible for minting sh shes uh burning shares in ERC for 626

fashion so that's like the basic modules and and by having them we can combine let's say if we add the world token module it allows us to have like here C20 um in our vault if we have like Whit list it allows us to have uh like Whit list users who can stti and also like in the future we will add more more modules and we will allow we will try to create like more different flavors of vaults so that all the different groups of uh users like d solo stakers um institutional stakers can can actually benefit from uh creating a vault for the factory and and running the staking operations for

themselves uh one of the key part for us was to make sure that we can exit the validators uh when when they get registered um so that's the that's the difficult part uh before the on chain uh exits submissions will be enabled um so for now what we do is that we have a oracles um th that um that is on that is responsible for submitting the consensus rewards bringing them from uh consensus to execution but also they are responsible for collecting the exit signatures of The Operators before the validators get registered and that's

actually the tricky part here because you have to in order to Pro in order to create the exit signature for your validator you must know the validator index before and um we can't kind of allow to register the validator then uh expect operator to provide the exit signature for us so in our case we collect exit signature before the validators are registered and and this way uh every time any user wants to exit specific Vault uh oracles Dow will publish their shares of exit signatures making sure the validator for that specific Vault will exit and user will be able to collect uh Stak assets from from that Vault and the way we do

that is that we pre-calculate the index based on the events from the beacon chain contract and uh we know exactly when there is like a deposit rout what index is uh what index corresponds to specific deposit route and um this way like oracles sign when they verify like this is the current deposit route of the beacon chain contract and this is the validator that gets registered it going to get this index so they they pre-signed the message um to they signed the message allowing the operator to register the validator and then contract verifies that enough Oracle signatures

were collected and allows the operator to register the validator and this way um like operator runs the validators for for the vault and oracles are responsible in case let's say operator doesn't want to do that themself uh oracles will monitor the assets that want to exit from staking um and then decrypt the um exit like shares of exit message and uh publish that to make sure validator exit from staking um so yeah that's one of the important parts for us to to make sure that like exits are controlled by by the

protocol another interesting part that I was mentioning before is the Dual governance um so one thing what we have right now in B2 is that Dow decides what to upgrade to um so in that case like if we want to do want to release a new version we um do the Dow voting and in case it's positive the onchain transaction is submitted and the contracts are upgraded to the new version but in in the new protocol we want to make sure that uh both the Dow and the Vault creaters or maybe it's if it's a dow behind who standing behind the vault have like have to agree on every upgrade of the contract making

them immutable was like not an option for us because ethereum constantly evolves and there are like new things added or changed so uh the vaults have to adapt to the changes of the ethereum so we want to make sure that we will constantly improve and let's say uh uh comply with the changes on on ethereum side so the way it works is that D um um registered registers and you implementation for a specific um volts type uh in the volts registry uh then U like in vaults version module there is a check um that the the upgrade

function is called by the uh by the Admin of the Vault and the implementation contract is white listed in the vault registry so this way like d adds to the Vault registry and the one who can upgrade is the admin of the Vault and um and then uh and then yeah so um The Vault upgrades it also has some additional checks that the volt type is the same so you can't say upgrade from usc2 volts to non usc2 volt and also um make sure that um like the you can't you are not downgrading to the previous version so it's always like the version is increasing and that's thanks

to like the ueps uh contracts where you have uh authorized upgrade function inside the implementation uh contract where you can actually Define the way the upgrades can work uh so this functionality will utilized for for the governance of of the Vault um so yeah I think that's that's like some of the uh important parts that we had to solve for uh V free um um there are also like some some other things that uh we can probably uh chat about later but I

think that's pretty much for me for now um thank you for listening and I'm happy for any questions you have great um maybe we can we'll start with a few um specific questions for the speakers and then uh we have a few more you know broad topics uh we can discuss um so I'll just start with uh there's someone here I think they're asking Dimitri will staking rewards in OS eth be restak automatically uh yes so like the the staking rewards are compounded there so yeah there a stake there the withdrawals

are automatically happening into the vaults and then the vaults once there is like 32 e accumulated they will be restak again into the new validator uh for Eugene I think there's a question here about unmanned operations specifically is there an expectation to create some type of a monitoring about um you onchain actions in order to build profiles uh for validators well uh I I suppose it's not an operational concept but design concept that I presented so uh actually I I I

believe it's it's not needed at this stage maybe yeah great so um I think I forgot to introduce myself uh I'm Drake Evans and I am a core contributor at the fra uh protocol and and we also um are in the process of sort of decentralizing our liquid staking token fra SE um I think as it stands today all liquid staking derivatives have a few points of centralization which um we touched on specifically uh getting information from the beacon chain to uh the execution layer and also Dimitri talked about this as well you know this idea of taking hold of the validator exit messages

which are required to boot um bad validators and and eject uh there are a few eips in process to address some of these specific concerns um however there are some people who make the argument that a truly decentralized validator set and permissionless Anonymous validators actually pose maybe some threat to the health of the network uh my understanding of the arguments are essentially along the lines of it reduces the cost of uh an attack on the network um and I'd be curious to hear you know if we are working towards this sort of anonymous permissionless decentralized validator set um do do you think those concerns are valid or or

what are your thoughts I'm not sure who wants to take it first but I think would' love to hear from both of you okay if it can be first and then uh I I I would start that permission validation is a fruitful topic yeah uh because uh Lia is committed to the process of improving uh decentralization of data set uh currently uh it's not uh it's not about uh by current state of that but uh emerging DVT technology also helpful here uh and that's why we are piloting

DVT project simple DVT project called uh firstly test oneski and then to mayet with a limited share of course so uh my opinion here my own opinion I would say that uh everything new and everything like emerging into eum wor uh not only like uh pure black and white color but maybe careful evaluation and uh gradual process moving from test Nets and

having uh like training wheels yeah you know that term maybe from L2 uh papers that presented by vitalic so that's it from my side yeah um yeah I think like in general like the architecture where you have U let's say um have one place where you aggregate ether and then let's say it gets distributed to um Anonymous validators um that's I would say like maybe risky because then you really there is no any

reputational part that takes place here because like you really are giving out ether to let's say um unknown validators but in case there is reputational fact maybe some validators or operators they are Anonymous but due to the good overall performance for like many years and maybe proving the underlying uh taking architecture that they have let's say maybe they use DVT or some other way of making sure there's like no slashing and U and yeah maybe like some other things in that case I think it could be fine that the operator himself stays

like Anonymous but then there is actual reputation that speaks for them themselves because in the past um past years we've seen like many not many but some of the reputable operators getting slashed or like losing the withdrawal keys so that could happen and uh maybe some of the anonymous validators will run pretty well if not better than some of the reputable ones thanks I think um another thing that people talk about to a certain extent is the network effects of um validating and I think the or I'll I'll maybe more broadly say the economies of scale and

the idea that uh maybe a decentralized validator set is actually very hard to achieve in a competitive environment because there are massive uh economies of scale to to to running validators uh these end up kind of in data centers and I guess when we think about the security risk of that uh how do you guys think this plays out and and are there ways to address this I'll let Demitri go first since we went with Eugene first last time yeah uh well I I think like probably having a uh like whether that's responsibility or the protocol to make sure they're not

growing like too large or not that's uh that could be one thing like for example if you like take like your liquid staking protocol and think like okay if all the validators in know in that protocol going to get slashed uh what will be like whether we will be able to cope with the damage or whether there will be like a way of not harming the underlying um Network so like in in in our case in V3 we have have caps that you can set as a vault when you create a vault you can say like I'm not accepting more than x amount of e and also we set as a dow a cap on how much OSF can be minted in

total and this way like also because we are over collateralized we need to make sure that um the LTV that's uh we have is always uh corresponds to the current Network situation so if we see that there is a lot of like slashings happening or like the network becomes unstable we will uh we will um decrease the LTV so that it will motivate people to burn OS to make sure they not get like liquidated um if they won't do that so this way we will try to reduce the amount of steak that the prodal has so that uh so that we always stay like

right under the risk here um so yeah I think it's it's uh kind of um like it really depends on the protocol how how they Sol that but of course like growing large is always considered in like in in networks to be harmful for the network yeah it's for me I quite agree on all all all of the mechanics I mean having cups and uh limits to prevent situation being out of control uh however for withdrawals in particular

for uh there is a concept of bod uh was introduced basically it uh allows to uh not pose but uh make withdraw process more lengthy uh when uh M slash happen because uh it's uh it's a visible first move advantage to run out of protocol if uh uh if like slashing happen and you expect that the token Market condition would be worse so uh that's why yeah being hard means being extra cautious and uh have variety of safety nets

yeah yeah I think that's actually an interesting point um there have been some discussions about changing the mechanics of the queue in order to prevent I think essentially Lido's dominance um would be curious to hear your guys thoughts on whether that's uh I think I think I've heard people argue it's actually more harmful potentially uh some have have argued it's you know less less harmful to the security of the ethereum network would be curious to hear uh your guys thoughts on that on this proposal I'm not sure if it going to work actually because uh because probably like okay if there is one protocol that

is uh suppressed in in size uh then there could be like some other protocol that will grow like later and then you have to like swap from like decreasing the size of one protocol to decreasing the size of another protocol so I think like we had similar situation with uh consensus clients where like prism client grew like too large uh most of the validators were running on them and it was actually uh so yeah like the I think right now the situation is much better where the like not not on the execution layer but on the consensus layer where um clients are almost like equally

used so um I think maybe like something similar can be achieved with the other let let's say protocols like liquid stating protocols where where there is like more granular distributed stake to let's say not having like multiple protocols holding like all all of the stake yeah it's it's a hard question actually because like I'm here talking about uh uh by the share and the uh like have maybe some

bias I mean it's okay it's okay but still if possible uh so for self-limiting I agree that uh it's it's a thing that could work for a particular protocol but it's not scalable thing and uh no one can guarantee by consensus rules or what whatever else that uh the next player would would play that game at all yeah uh and that's why actually before voting on self-limiting proposal there there was quite lengthy discussion uh where uh actually it's one of the most uh diverse topics on Li

Research Forum that had happened I I mean so many participants from various parties stakeholders and participants um well the risk is true I mean the risk of having uh the protocol with too large um ethereum participation uh for for us currently uh the mitigation pass is to have D dual governance implemented uh dual governance in our case means uh St V mechanics when uh light the propos when light The Proposal of L holders can be objected by stf

holders uh so we suppose that it could cope it could help to cope this problem uh however like uh it's an experimental thing yeah so let's see speaking of experimental things um someone from the audience has asked um about the ZK proofs to reduce storage costs uh Eugene and they're asking has it already been used anywhere in the code bases or is this still in the early stages uh yeah for us it's Sol stages we have test Nets with ZK data for oracles uh

but like at the very beginning of 2024 we expect to have first M setups maybe I think that's a nice segue um into kind of another topic maybe a little bit more low level you know one of the reasons that people have have talked about self-limiting is um is a governance thing right which is like the governance maybe have but there's another topic which is the sort of smart contract security risk and um you know and and just like you might have Diversified consensus clients in case there's a bug in one um you should have you know multiple smart contract

implementations and I guess you know would love to hear the thoughts uh from each of you about how smart contract security uh and testing plays a role in uh each of the organizations and and in in an effort to reduce the risk there is above bug Eugene do you want to go first uh well for smart smart contract security risk mitigation um I I suppose that the most important part is design uh I mean uh uh 80% of spec always is about cor cases and about about expecting

unexpected things uh more over we believe in advanced security measurements like formal verification uh that's why we um gone through it with light do uh and uh it was quite helpful um well I I suppose that it could be a new security standard for the smart contracts to have like second lay of security by formal modification actually yeah uh in our case I think like also design is one of the key Parts uh we

like we need to like every time we design a new feature like uh like yeah different parts for example the exit Q for V3 was pretty difficult one as well uh but every time we design something it's always you have to think about like not let let say the normal cases but the actual let's say some tricky or unusual cases uh uh that can happen like someone like with flash loans for example or some something else that could be could be used um so we test a lot uh we run like different kind of testing uh on our contracts and um

and also we like of course like Audits and and uh security contests uh this is something we do a lot and also the yeah the test net we we've been I think since February with v fre testnet we've been like re recreating them multiple times uh like finding something uh fixing creating a new test net and it was like constant process of fine-tuning all the uh Corner cases and and problems that that arise from from just like running um running uh the protocol makes

sense um we've talked about a few different types of risk one that we haven't talked about is maybe jurisdictional uh resiliency you know with any bleeding edge technology which I think uh liquid staking is is certainly part of can sometimes uh come under the crosshairs of regulators or you know governments how do you guys think about jurisdictional resiliency within you know your your respective protocols Demetri I think we can start with you yeah that that's a good question uh and it's I think it's like one of the uh questions that is really there is no certain answer on it uh for now like

there is really uh so many different opinions but uh the actual kind of solution how to uh like protect yourself protect your protocol from from that is is not that clear but in our case we uh we have like the we provide a smart contracts layer so we have like uh our our model is somehow similar to let's say Unis swap model where anyone can create a pool and provide liquidity for their tokens in our case you can um and and let's say create a vault for running validators staking and also you don't need to have to Mint liquid staking on

top that also is quite um quite helpful for many protocols or for many let's say uh institutional clients where one of the most like regulatory part comes not from doing staking but actually from minting the liquid token and and trading it so this is usually the the difficult part so and also by like providing the features that allow uh different entities to based on their regulatory requirements to select the set of features they want from the Vault that's something that we wanted to do if you are completely fine with like having your own liquid token anyone can stti

there um and like utilizing defi that's fine you can create a like specific VA for that but if you are more in a strict side where you have to run privately White list the ones who can stake and not have a token that's also possible so we try to balance between because we don't think there is like one solution for everyone but there are like different solutions that uh based on your requirements you can choose and and and run with yeah I I also agree on that because uh speaking about protocol uh the protocol is software thing uh that can do variety of things and uh

basically to fulfill your particular needs I mean whether you want the token that behaves like that or uh whether it should be bable or uh maybe you you want to have uh validators uh that U selected by the particular principle like the Vols do uh all all of these um actually are features and uh having having an opportunity to select them and to um pick up everything you need and otherwise leave something you are not comfortable is is a Way Forward yeah I

agree on that