The Road to Venn Network Testnet

Transcript

and then we assemble an amazing program which includes the uh the the conference and the best speakers in the web three together with the Seal team together with the uh workshop on technical content so there's a lot of things going on it's an affordable event it's a marketing free there are a lot of very very good sponsors that made this possible so please make an effort to join you can join physically if you can which is great if you cannot join physically we also broadcast remotely we won't broadcast the the webinars we will uh broadcast sorry we won't broadcast the workshop but we will broadcast the

main event and we also broadcast the 101 so please stay tuned either attend and you can attend the the 101 or separately you can attend the conference or both and there are people giving free tickets you can also buy an affordable ticket please try to attend so for today it's my pleasure and honor to introduce Asaf who is a CTO of the ven Network so actually I think one of the thing that maybe not so known in this space that actually uh the one of the most interesting Concept in the defi is amm and amm actually started in the bankor team and Asaf was part of the bankot

team so that's actually a very interesting uh concept and and Asaf now together with his colleague now he is building this new security network which is called V which they are launching and hopefully they will tell us more so I look forward to listen to your presentation or St thank you very much thank you m so I will start with a presentation of the network and what is about where it came from and everything of course at the end of it you can ask more questions if something is not

completely understood and uh I will elaborate on everything uh I will start by sharing my my screen give me a moment all right then jump into the start so like mly presented ER I was in the foundation team of Bor and uh it was one of the first DBS of maybe even one of the first DBS of H Defi and uh back then in 2 we started at 20 2016 and uh we launched the SEO in

2017 and on 2018 we had a very big H hack that uh eventually still uh the hacko stole more than 10 million something like1 million at the beginning of that he was able to steal 20 million we will we were able to return ER half of that and uh to save more than $300 million that were locked inside the the amm H it was the first time the first

def ha of course we had a few more hack the biggest one was the da of course but for the def ecosystem it was the first ones of course back then we also uh started to uh to face front running H and front runnels the beginning beginning of front tunnels H so we had a lot of security issues to tackle ER and since then me and my partner started to to think more and more about how to create a resilient ER system for to secured the smart contracts that H deployed to the network and uh

eventually and we will explain why uh we came with that approach eventually we can we came with the the security network uh the most decentralized way to secure uh chains and DBS all over the ecosystem so I will start with where is the problem so of course it's not something that going to replace audits or to replace other measures that the DS are taking to secure their smart contracts but we have a specific Gap ER in the life cycle of D that it's not secured almost at all it's the phase between the

deployment and the act itself the H changing of the state on chain ER we have of course the audits that uh every smart contract developer must do before they deploy their own contract we have a of course all the unit test the fuzzing H formal verification of course and so on that they need to do also before the deploying their smart contracts then comes the deployment and we have monitoring and incident response those can't prevent most of the cases they can't prevent a hacks some of the hacks that happened in the last few years they

can prevent because the AKO just was lazy uh to send the first transaction that created the smart contract that they are going to use to hack and after that to use that smart contract to hack and send the money to uh wherever they want to H but all of that can happen in one transaction in private uh mle and just like that ER to steal uh the D money without any monitoring can prevent that so we need something that sits on chain that can prevent the change of the state inside

the blockchain so uh this is the the area where the gaps in we do it with a something that called a onent firewall we combine somehow also offchain part and also onchain part to be able to to prevent malicious transactions the onchain part H actually prevents the transaction but it add its own limitations about recognizing if a transaction of or if a specific call is malicious and so for and so so to to do that we combine the option capabilities with the onion abilities to uh block

transaction uh even if it's completely out there without any specific source that can H stop transaction from going into the nodes so when we have this onchain part now we combining the offchain part the part that recognized the transactions we realize that H there isn't any single entity that can decide what are the transaction that able to go into the blockchain and are okay to go to the blockchain and what or not because they can do a sensorship they can of course go down and then all the networks or all the dabs will go down and then we miss the purpose of the blockchain which is is 24/7 no matter

what H so we need something more robust more decentralized because of the respon responsibility that it has so we created a decentralized network of a lot of uh security operators that check the validity of the transaction not in terms of the mathematical mathematical proof of the transaction like every node and every validator or the ethereum network does but more of the security side of the transaction if it's stealing money from the specific protocol that decide that he wants the protection or if the user wants to use it to protect him from

fishing and scammers so we combine all of that H security operators together we have the transaction and I will explain how it works in a moment H all of them voting for the transaction if it's good or bad and uh according to the voting power H we decide if the transaction can go through or not uh we have few middle wordss to to connect and implement this mechanism the first one is of course like we said the on F and the other one is to connect it to a sequencer on the nodes level Etc and of course on wallets so this is

the the middle rest that we have H we have a lot of security operators that work with us of course Sora and each one of them has its own unique methods that it adds to the network ER we have S with formal verifications we have other audit companies like Sigma Prime spit H Block Chain security Etc fand of course and each one of them adds their own unique mechanism to decide if the transaction is okay this way we have like with every security system we have layers and layers and layers of security that each one of them can H cover uh specific

caras and uh this way when we have all these layers we can cover most of the areas of the exploits that are in we have in the smart contracts and not only in smart contracts uh I I will explain more later and we of course have a lot uh of uh protocols that already uh going to use that and this is how the flow of the transaction is going to be in the case of orang and f that connected to the uh security network so the user send with the SDK we have an SDK that everyone can use and let's say for this spefic specific example the D can just

Implement inside the client uh the web uh the web client or if a user wants to use that H from a server it can just use it's a very simple SDK that what it does it's something like that they also send the transaction data to the security network the security network is going to send it to all the security operators and very very quick to decide if the transaction is legitimate or not then the result with a payload goes to the user the user sign all of that together and send it to the blockchain then it goes to the protocol the protocol has a a firewall that checks

each and every one uh every call to the smart contracts of the protocol when it has H when it uh the payload H approve each one of the internal calls when some of the internal SC is not approved then the transaction is reverted completely then the state is not going to change and uh we actually prevented uh the hack from happening uh we have two ways to to connect to to the network we have of course the general Network that all of the operators combined together H protecting the dats H and we have subnets subnets

are for for example if a operator has specific uh mechanism that he wants to to apply and specific protocols want to use that then they can sign to the register to that subnet we also have a specific subnet that protects h on something very specific like uh let's say and I'm just foring fing something to the air fishing uh only these operators protect fishing then users can register to that subnet or protocol wants to to use specific mechanism for amms for

landing then they can subscribe to specific subnets that do so H the fees in this uh Network can be also be subsidized by by the H Network itself or by the uh protocol but it can be also all out to the user so the user will pay a small fee that will pay for this specific security uh protection and this way the protocol or the chain doesn't need to pay anything it will be part of the of the transaction fee H that's the explanation about the the technical side of things how it

works I will dive a little bit deeper about use cases and how specific works but if you have any questions feel free to ER to ask them so I will stop for a little bit to see if there is questions and then I will uh show some use cases and some questions from the web I don't know if you see how do we screen transaction that don't go through the dab how do we screen transaction that goes don't go through the DAP do you mean transaction that are not let's say

the DB is protected but the transaction it doesn't send to the DB uh or it's going to send for another contract to the DB what exactly is the question because this is two scenarios I think this the it says that uh smart contact smart contact interactions okay so if we have even one internal call to the protocol it will need to go for the validation process so if it won't go for the validation process it will be reverted h on chain because this in internal call will still need the the approval H so this way it will block also transaction that doesn't go

for the the validation process so of course the valid the validation link is open and everyone can use the SDK and so on so everyone can use it if even if it's not for the web application thank you okay so I will show some more uh diagrams maybe to show how it works H one moment another thing before I'm jump to the more technical side we are now on the test net ER launching the test net ER of this

uh Network H it's going to be to have a few phases ER and I will explain how it works we have a few h a few things that we do in the test net uh the first thing that uh that we do we deployed uh The Operators with the with the mechanism that we built in inside the operator of course they can add their own logic and so on and we check the last year and a half something like that uh of the hacks that happen in ethereum of course we will do more uh later we will add more hacks ER more than the

last uh year and a half and it will be we will add the recent tax every time and every time and we check that with the operators and what we do there we actually H run it like it's a production ER and live on the main net each one of the transactions also the the N the regular transaction are going to be also H Shi to the operators and uh we check a few things in this test net we check the false negatives we check the false positives we check the latency and so on and so on all of that together

and going to be part of the specific part of the test net we also have a test net for daps daps can add the F to the smart contract and to see the flow and to use of course the SDK and other thing and to to check out the flows work with their protocols they will feel much more comfortable after they're doing that in the testet to go uh live H with the protection this is two phases that we have H they work in parel they're already live we we already started to H work on that and to to launch that so we're

actually going to announce that today and we also have another phase that is going to Fork the main net and to to add the the protocols with the F also to that fork and each transaction that goes in the main it will go to that fork and at first it will also show how the uh that protocol works with the p with the firewall but after that of course the operators can just connect to that fork and to show the results for each one of the transactions that goes into that uh test net of the protocol this way we can show on real time the world transaction

that goes into the main net what is forse positives what is with the false negatives Etc H we also have a lot of other options in the firewall of course the protocol can decide ER the onent power is very flexible very modular so they can decide for example if they want only transaction that goes for the smart for smart contracts and then to the protocol to go for the PowerAll and all the others EA for example that goes directly for their web app will go without the firewall this can sometime reduce some of the gas fees and so on and they can

add even more and more more Logics that they want to to add to the network for example if someone is with dra from a let's say above uh $1,000 then they will need to go for the F and so on and so it's very modular everyone can add any logic that they want so we we have all of that ER in the test net everyone can add their own logic they can test the F the functionality and other thing they can see the results in the we will publish all of that H the results of the test net and I will say that we aim to uh in the test net we aim for below uh 1% and

we have much much much below 1% of false positives false positives means that a transaction is flagged as malicious but it's not H we aim to less than 10% of false negatives and we have of course much less than that false negatives me mean that ER the transaction is malicious but we didn't recognize that ER and we have I will go over the the all the variants of the the variety of exploits that we have so this is the second thing and of course the third thing is the

performance H how much time it's going to take to for all the operators together to vote and to get conclusion ER and uh we aim for uh something like 200 milliseconds and again we are lower than that ER so this is the main criteria for the uh test net when we test The Operators and for the DBS we check the functionality everyone to check that of course we have a I will go over that in a moment we have an incentiv layer for that H everyone that uh implement the F wall uh we are open to feedbacks and everything we prepare a very nice tools that make it very very

very uh simple to implement the firewall and to use that in the web application um any questions until now not anymore sounds clear let's see thanks oh question there's another question all uh are all operators running the same logic correct so they should all vote the same way absent any conclus collusion so it's not completely right any operator can use their own mechanism they can use the mechanism that we

provide with the with the operator ER so they can use that so at first we we test it in the with the operators that what is the force negative and force positives of that logic but they can change the logic they can add their own logic Etc it can be more accurate it can be less accurate depends on the operator I believe that most of the time it will cover more and more and more re and it will become more and more accurate ER so it can be different ER different Logics thank you I will show a small

demonstration ER small diagram uh of how it works one moment sharing my screen okay this is It's er eli5 er of the how it works this is a regular user sending is transaction data it will go to the network it will get an answer and then it can send it to the blockchain and the AO will try to send it of course the vote will be not to

pass that and it will be blocked on the blockchain H it works pretty much the same as estimate gas so every transaction that goes to the network goes first to estimation of the gas and then the user can send it it works pretty much the same estim we call it security estimation so we go to the network to estimate the security if it's okay or not and if it's okay of course you get the payload you just sign the transaction and send it to the blockchain and I will go over another thing ER the life cycle of the transaction what I mentioned now maybe in a sequence diagram just for it to be a little bit more clear

okay so exactly like I just said ER the user send the transaction this is how it works onchain this is the onchain firewall part H when the transaction goes to the daap the D as a when he implements the the firewall it has something that called F consumer ER it's just something that the contact is is inherent and uh iner it and it's add and modifiers to the functions that uh the protocol wants to protect so it checks pre-execution and post execution H it checks if the transaction specific

call to this function is approved if it's not approved of course it will reverted if it's okay okay then it go to the Post execution and checks if there is something else in the on F that the that want to add H for the checks it can check it too and if it all okay then the the transaction will go for exactly as me uh meant and uh I will share H another thing about the governance of uh this protection it's very important for most of the protocols who own the F who own the the security we own

the if they can turn it off turn it on and so on so that's also a second okay so this one for example explains the the ownership over each one of the parts that we have in the firewall if something is not completely understood then feel free to ask and we have all of the explanations in the documentation I'm trying to ER to do it as simple as possible and to H cover all of that in uh 10 minutes something

like that just uh to be able to explain all of that so the consumer are actually the the smart contract the protocol ER smart contracts ER so the F admin is of course ER the protocol H admin it can be ER the governance it can be even the multisig of the protocol it can be everything that the protocol wish to be the owner of the security of the protocol and we wish to we wish the D to to take the the firewall admin to be a different entity or a different multisig or a

different EA it can be also EA a different ER owner than the general owners owner of the protocol but uh the protocol on the of course the consumers then we have the firewall itself the protocol weed deployed the firewall so it's going to be a a firewall that no one will own that it's going to be just a router in some kind ER of uh of the checks H so there will be no owner to that uh router but we can also deploy F that we are the owners depends on the protocol what you decide it it can be

the owner of the F whatever decide we can deploy it for him and he can deploy by himself and of course the policies the policy admin will be also the the protocol oner so it can be the same as the F admin so basically the fal admin can be the owner of all of all of the three or the policy admin and the and the consumers so this is for the governance of the security and of course the checks that happen the offchain will be a decentralized to all the security operators so the protocol can decide to choose a subnet to decide which the

which are the operators that are going to check his transactions H but you can also go to the uh van General Network and then everyone will check his transactions and it can't decide who are the ones that are going to uh to check the transaction of course each one of the operators taking a amount ER in the in the network and of course there was lashing and rewarding according to the to the performance of the topor ER and I see that there is there's a question there's another question if

there is is there incentive for an operator to invest an R&D to improve their detection logic above and beyond what you provide them what are the yeah so I actually touched that a little bit in a ER what I said in the last minute H so the operator if he is rewards according to the to its uh performance so we provide with a very good logic but we believe that when everyone is uh joined to the network then they can be much more accurate it can create much more Logics that H cover all kinds of uh exploits together and so

on so when they are more they get more rewards this is one thing another thing is the subnets so if they have their own logic then protocol can register to their own subnets then they can create a different pricing they can create for example if if a a a security check for the regular transaction in the general then will cause something like a a zero 4.1 or 0.1 Cent for example then on the subnet it can be anything that the operators decides to so it can be if

it's very very H heavy lifting uh logic and it can be $1 for example for transactions for so for example if that subnet is for admin calls or for uh change in the configuration of the uh smart contacts and so on and the protocol register to that subnet then it this transaction will happen a little bit less but this specific operator will get much more ER fee for each transaction so that depends on the market we just provide the infrastructure and then everyone can add their own ER logic ER and uh the customer base also to that H

infrastructure and this way yes there is incentive for each operator to build more and more uh accurate and relevant logic thank you and um a little bit more about what kind of logic that we provide just to add to that question H what are the logic that we provide and what can be even more than that so we provide a regular generic generic it's it's a very good we think that it's supposed to be every D needs to use that generic logic H somehow H so we provide generic

logic that mean to uh prevent uh price manipulation and reeny attacks and uh ER bugs in the code and so on and so on and so on but we can't H protect all of the exploits of course we we trying to protect when we have the prevention mechanism most of the ACT can be H detected of course H when we do it afterwards uh but we can detect each ha ER binary if it was or wasn't a hack so it's achievable H and we believe that with

more and more operators that combine more and more Logics we can cover 99.9% of the hacks for examples like I said admin calls and change of configuration in smart contracts there's a few operators that this is their ER specialty they they have this H profession to do that to detect if this is a okay or not H we have even H when we have admin calls that's using multi and so on then some of the operators are very uh they have very special abilities for that they can decide if specific

admin call is okay or not and I mean specific transaction form a multisig or proposal or uh this kind of transactions and we have some operators that are most uh professional with the the user the end user transactions to check if the transaction ER is is going through a fishing campaign H some scamming and so on H so we have some portal that has that uh special abilities too oh I see another question this one this one is a long one

[Music] related to the heck you explain yeah it's interesting yeah yeah okay so we have we have two questions over there three questions the first question is H about uh comparison between a van and another uh Network I will go over that in a moment the second questions it's about Banker uh something like I believe almost H almost eight years ago I will

answer that also and the third questions was also something about bankor ER and I will answer that also so let's start with the first question about the comparision between our our Network to other networks so h every we now have a few security networks that are launching in the near future and some of them launch a few specific things in the recent months H each one of them has something a little bit different ER from the other ER specific about uh this one I need to to check because I don't want to to give

answer that it's uh not correct with their approach H so I need to check uh more deeply what they did H but I know of the others so I can answer what is our main difference from the others the first one is that we have already a lot of audit companies that combine together to give their own unique H View ER of security and uh this is very different from the others and uh we have also the onchain part that combines the offchain part with it h so first of all is this and very differences in the use cases and so

on ER we are very we built a very generic uh infrastructure that can be very customized to each use case so if a protocol want to use it in very specific way it can add the specific blocks and then it very very direct to to its his use case and we have also the ability for every protocol to just join in very quickly and uh and uh boost up that jump to that implementation very quickly H so this is for the first question we have the

second question about bankor the question is is uh we were able to return some of the stolen funds uh back then H the question if it was for the centralized ability in benor back then ER yes the the money that we were able to return was from that ability I will explain in a moment and uh after that I will answer the other question so I will explain what was the hack in general uh so this smart contracts were okay there isn't any bag in the smart contract but H someone was able to take advantage of

one of the private keys and we know it from the recent tax when private Keys compromised then basically ER most of the cases the money is gone very quickly so back then someone had the the ability to use that and he started to move funds from the pools that we had back then ER and to move that it was the pools in Bor worked in a way that we had the token of the protocol in one side and BNT On The Other Side ER so when he was able to take the funds from the pools he he was he take the token of the protocol with

the BNT we were able to burn the B&T and we had also other um abilities to stop the malicious attack with the gas we had the mechanism to to see the gas price and by that to uh approve the transaction or not we have a lot of other mechanism to do that so we were able to burn the the BNT that he took and return it to the pools H so yes it was a centralized approach back then it was meant to be for the short term and then to remove the disability after that so the hack happened before we we remove that

and we use that to return some of the money and to close the the vulnerability very quick and just to transfer ownership and stop the ability to remove funds and so on and so on H and for the h third question if it was a good idea to do it in a centralized nature the the mechanism in Bor okay so back then and the the continuation of the question was if it was a a lack of confidence in the smart contract security so of course there was

a lack of confidence in the smart contract security it was very early it was the first am H one of the first DBS in the eum ecosystem uh one of the first iOS and so on and so on so yes there was a lack of H confidence in the security of smart contact so we wanted to create something that we can upgrade very fast and back then we didn't have any upgradable contracts that we have now ER we had we used only IM mutable contracts so also to upgrade was a very it was an event to upgrade the contact it was a MIG migrations and so on and so on

so and most of the time migrations was the very weak point I remember a lot of protocols that the migration part was the the part that opened the vulnerability to to the protocols so we avoided the migration very hard so was it a good idea or a bad idea I think that back then it was the a necessary a necessary uh approach so we will be able to upgrade and uh to get a very uh stable version and that we can then remove the

centralized approach then we didn't have too much centralized abilities but we had uh some of the core functionalities that were uh C and we remove that after that so is it was a good idea I think that yes um but [Music] uh now I don't see that most of the most of them are upgradeable by the way so it's it became some of a standard to be able to upgrade the protocol and so on they work with the governance so it's important but it

works very slow so uh this is about that eight years ago so um maybe some of the specific Parts I'm don't remember very accurate but it was like that and the last question is can the V Network prevent this yes yes yes ER and this is very very unique to this network it can prevent also privately compromised for example the one the the last for rent we can and we check that and we will maybe publish

that in the future er uh with all the data we have a few uh announcement that we need to do and part of it will be the the check that we did we did with radiant we were able to prevent that also and also the one that we had in a banker ER but uh back then the security the gap between the technology and the use cases and the technology and the security uh measures that uh we had back then were a huge were a huge gap between them so now we have more uh and with the security network and the Onan fowl we have almost H the same ability that we

have in a in the other ecosystems ER to stop malicious H attacks and not just pray that H the money won't be stolen from the D so yeah it we were able to to stop that if when were available back then [Music] um yeah I mentioned that there is a lot of protocols that are upgradable but also of course there's a lot that are immutable and also we some of the contacts that we have are going to be mutable not all of them I

believe uh when we go live but uh the main ones uh we tend to make them immutable in the test net they are immutable and on the main net they will probably also it depends on the protocol of course H and I mean the fowl the policies and so on so it depends on the protocol you can decide to use the mutable or upgradable one H so we believe my my vision is that the blockchain the nature of the blockchain supposed to be mutable ER it's supposed to show to be very

transparent with the everyone that see what it's on the blockchain and to show exactly what is the code and that no one can change it so upgradeable upgradeable contracts a little bit remove that ability of the blockchain but they are important in some of the cases for example if a contract is upgradeable and may uh maybe in the first phases it needs to be upgradeable to deploy more and more features H in a timeline that it's uh for example in web 2 you know that you have MVP and then you go with other

feature another feature another feature another feature until you are stable enough you have a beta Alpha and then beta and so on so we don't have that with immutable contracts because we then need to do a migration it's very very slow ER Improvement of the protocols so I believe that we need something in between H upgradeable at first and then to move and uh to renounce for example the ownership and then you can't upgrade the contract anymore and then basically it's immutable this is my C by the way um so this is my my thoughts about that and of course we have a few

[Music] uh protocols that are immutable and uh they are for a long time and okay oh yeah this is a very very important questions so question so we have of course everyone can turn off and can turn on again and turn off again and so on the the F entirely so yes this is the the short answer for that we also have the ability to we call it dry one H the firewall you can deploy it with the firewall not stopping the transaction that just emitting H events and to see the performance of the firewall to see

if there is a let's say a lot of transaction that you didn't want to to prevent and the firewall emitted the event that it prevented them and so on and so on so you can run it with a dry one one for example but yes you can turn it off and turn it on uh as you need it right do we have another one I don't see okay a few more abilities that uh if you look in our ripo for example you will see a few more abilities that we provided in

that repo with the we call it policies so we have the onchain we have policies one of the policies is the one that connects to the V Network this is the main one we think that this is the best option to go to go to it will connect it to [Music] the van ecosystem then you can decide which are the operators that you want to work with or to work with the default General network but in the policies you will see that we have EA only policy for example that one I mentioned before that that means that every EA can H go through uh the network and everyone

that's using a smart contract to to use the protocol will go through the checks ER basically we have the ability to to create any uh binary logic or or and any logic to to combine policies together so you can end your own logic also one of the use cases that we had some of the we had a protocol that deployed with a firewall to production and he deployed a smart contract with with uh specific vulnerability that he had and the immediately when he deployed

the smart contract he saw that there is a vulnerability no one it's a vulnerability that is going to be open in the in the future in I think a few weeks after the deployment so he just deployed a policy he added with the firewall and uh he just deployed a policy that prevent that specific vulnerability in production so it actually prevented a act that was going to be happen in the on the protocol H so that demonstrate the option to create a custom policy in the f h of course we have an SDK to

create uh the mechanism in The Operators themselves so uh the protocol can decide to run even their own operator to create their own logic and uh to deploy it and uh to use the F to use that operator for example so this is also a use case that can be imply in the in the protocol um I think that I went over all of that I talked about the test net I recommend everyone we are going to announce that H in the media we're going to H also publish a website that is

specifically targeted for that everyone that want to try that everyone that wants to use it to see how it works uh to check that H just join uh the test net and um we wish a very safe journey into creating DS in the blockchain H we wish we wish that we wish that we had that security back then but now we provide that for others and uh we believe that it will become a standard in the ecosystem if you use van or not

uh we will think we are thinking that it's going to be a standard uh onch security most of it will be H also combined with the offchain part which is decentralized security networks ER I just H want to mention that we are the first one but we also created a very flexible H and modular uh platform to do that H so every security company can join H and add more security to the ecosystem it's it's not for us it's a platform and a infrastructure for everyone ER we just ER build it it's going to be for the

community it's going to be also by the community and like I said it will in year or two so on it's going to be a standard like every D doing audit every D will have a real time security with that also great great thank you very much for the insightful presentation and congratulation again so maybe this is a bit of a Layman question the question is sounds like you are protecting from a a logical mistake you are you are protecting from perhaps like the issue of of key ffts but what are the things that you are not protecting for example

what happened if I have a front an error how will this be C so what I have you thought of all the fs which are still not covered here I I know they didn't happen in bankr perhaps but still can be interesting right the people we have seen several font and hacks this year that actually were missed right yeah so it depends on the implementation of the protocol of the DB so for example if the DB is not adding a protection for let's say if he has for example in the web app and I'm just throwing hypothetically use case or an option

that can happen in the in the real world H some H calculation error in the frontend then it will be okay let's say it adds $10 for each uh user by mistake then for this this example won't be H prevented because h i I believe that and I'm talking about our Logic for example our logic won't recognize this kind [Music] of bug ER it will look as okay and then it will uh it can arm the protocol with a lot of users getting $10 by mistake for example

H but that one also can be protected by operators that can have their own logic that can protect that because of the flexibility of the of the platform H there isn't any limit of what it can protect the limit it what the security ecosystem will come with h to protect the protocols with basically like I said H after the fact when ha happened we can uh detect each every hack so we can recognize each Act if it was malicious or not so this way it means that after the the fact we can build a logic that can detect that act so we can add it to

the security network also and it's like a block by Block it's going to be a very very robust ER wall that H I believe that eventually can like I said block every every uh h malicious transactions or every bug also but some of the new ones that never happened before and uh the protocol didn't sign specific this on that protection or I don't know something can happen and sleep for the the blocks

but every every um bug or malicious everything every transaction that can arm the protocol eventually can be blocked see thank you Nathan had there more question from the audience I don't know if naan is there we also EX L on time so thank you very much ASA for the audience and for ASA hope to see you in a week in def I

security submit and anyway or or listen remotely and thank you thank you very much thanks a lot bye by everyone thank you thank you take you