# ABA - Smart Contract Security and Audits - Channel: [ETHCluj Meetup](https://streameth.org/ethcluj-meetup) - Date: 2026-02-09 - Duration: 57:16 - Watch: https://streameth.org/watch/yt-01aoqMXBcD0 - YouTube: https://www.youtube.com/watch?v=01aoqMXBcD0 ## Description Explores the principles of securing decentralized systems and the audit process. Covers vulnerability patterns, risk assessment methodologies, and best practices for hardening smart contracts. Discusses the role of audits in trust minimization and protocol resilience. ## Transcript the presentation for whoever actually wants to work on the workshop, hence the work in the workshop. So if someone does plan on getting the source code and seeing the presentation while I also talk, you can just get it from here because my presentation also has solutions. So if you want this, okay? Otherwise, okay, I saw some people. Did you all all got it? Okay, so we're going to talk today now about smart contact security and smart contact audit. This workshop is also a part of the same eat uh ETM for everyone book that will be held at university inclusion if I'm not mistaken or if I didn't made such a bad job and it will not be included. A little bit about myself. I'm a smart contact security researcher over 10 years in security both web 2 and web 3 a lot of million TVL total value locked smart contacts that I've audited over 40 private or collaborative audits. I didn't I did a lot of work over the years. This is just short so you know who you're speaking. I'm Abba the blue one. You can might find me here. So they were going to talk about okay what is security as and why do we actually need it in blockchain? No one's actually had ever the need to secure a a bear because there's no incentive to attack a bear. You only need security on something that actually has an incentive to be attacked. I'm going to explain why. some common smart contact vulnerabilities. And here's some hands-on exercises. >> Ah, sorry. Hello. I can fail at using the mic. >> Hello. Sorry again. Okay. So, a bit we're going to talk about smart contact vulnerabilities, the common ones, some examples, hands-on risk assessment. where I gonna give you I'm going to try to give you a quiz uh best practices what's auditing blockchain security there is in just a state of the art going to go through it kind of quickly because I don't actually expect anyone to remember all the links or tools I'm going to mention the idea is to have a good overview okay studying the idea is what is security protecting making something more resilient why do we need in blockchain security to make stuff more resilient. What's the harm? Well, we need to think about the blockchain in terms of what can you do with it. What's different about it than other technology? One, anyone can create anything. You can say that normal block normal development has this. Yeah, anyone can create any software. But here anyone can attribute any financial value. This is different because in normal web two development no not everyone can make a bank not everyone can make a payment processor you need a lot of work a lot of uh financial audits and security here anyone can do anything that's why you also need security on this part so basically thinking about this everything is a fintech and everything being a fintech it's about the money put it basically because you can steal and anything can have a financial value. You need protection. You need to think about blockchain security as in the entire ecosystem is manufacturing cars as a surface, brokerage as a service, banks as a service, casinos as a service, every anything that you've ever had the financial value and incentive associated with it. It's how you need to think about blockchain technology. And that has the answer of why we actually need security. Now um people from web 2 when they come to web 3 they usually come with this in mind. move fast, bake things, make a good That's how you do it normally in development, but this doesn't work here because moving fast bakes things. We don't This is a different thing from normal web to development because if you actually deploy something with the bug and fix it in production, you don't have one or two angry clients. You have theft. That's why you can't do this. That's the need for a security. This is literally the only the general introduction of why we need security that I've talked about. Now, vulnerabilities the entire ecosystem is somewhat new and over time vulnerabilities and hacks appeared in the ecosystem. So, some categorization appeared on those vulnerabilities. I'll mention a few of the most common ones and their impact in the last few years. access control st there was an attempt a failed attempt that consensus had of making a standardized way of defining issues severity and vulnerabilities they tried it's not like um normal web to security when you have specific threats that have identified and meet a standard if I remember those correctly so you kind of need to define it on your own. Look how general people define it for now. Classic ones like access control stuff that should not be allowed by anyone to do is allowed by anyone to do. This actually is such this is something that people don't actually expect to still exist in the wild but still exist. I mean code that is accessible by anyone still deployed. lack of input validation as in smart context like the previous presentation showed. You can think of a smart contact as the entire API itself, the endpoint itself. This is different from web two programming because in web two you need a server, you need API nodes, someone makes a swagger file, you have a lot of layers between a user input and the actual backend logic that executes it. Even then hex and web to happen here my function is actually going to be called from a random place on the earth the function itself not an endpoint. So you also need to input to validate the input of users and not doing that is a vulnerability. There's a difference between a vulnerability and the root of the cause root of a hack. For example, inadequate price dependency. You're not doing you're not implementing onchain a good mechanism for checking price. That's the vulnerability. The hack is a price or manipulation. Sometimes you're using those intertwined. So access control is a type of vulnerability and a type of root cause. You do get the idea. Precision loss happens in smart contacts mostly EVM. There is no there are no floating points as in you don't have 0.0074. No, we have only fixed arithmetic mathematics which means that when you divide something each and every division you lose the minder. That's a precision loss. And if you don't don't actually know or do that precision loss intentionally, you can have an issue. That's a smart that those are actually really really hard to figure out and still happen today in the wild. Rentency is one of the most more interesting ones that happens that web two developers don't never they don't really think about it when they come here. From within a function you reenter the state of the same function. It's a type of recursion up until one point because you can't go and defend it because it would bake the contact. And by doing that before modifying state, you have intended unintended side effects. These are all kind of generic because I would need examples for each and every one of them and it's going to take a while. We're going to have some hands-on with one. Logical bugs are the ones where you can't really categorize them as business dependent and you just put it in this category. Someone made a game that you can arbitrary steal from someone else. That's a logic bug. Or you can dos someone still a logic bug. These are two graphs from chain light in 2023 to and 2024. How much for the one in 2023 we have how many error dehacks that happened the distribution of errors the vulnerabilities how which were the most as count so basically in 2023 almost 60 51% of all hacks were logical errors that we had still in that point access control there are errors in 2024 I have numbers as in how many millions were lost per Each vulnerability type logical errors will kind of always be over time only logical errors will probably remain because those are business dependent and the other ones when you you can categorize something you usually can fix it at one point you have standardized ways of dealing with it. When you can't categorize it because it actually depends on the business logic of the protocol that's where ingenuity and human creation happens. Now the exercise whoever of you got the presentation and wants to do the exercise there is you will get this is the repo we get and and there you have an exercise which we can do. Okay, I'll kind of try to yell. Is there is someone here who's going to try to do the exercise? If not, I can just present how it happens. But if not, I can leave let you to try a bit. There is no shame in saying that I don't actually want to do it. I know there's a workshop you have to work, but it's okay if you're not. I'm going to presume no one actually doing it and going to start explaining it, which is okay if someone actually does it. Okay. Um, put this here. So, so, so Lord. So, this is the this is the exercise and you would need to get the repo locally and you'll have the the entire description is okay. Uh we can move back to this the description a bit for some firef far away land governance wants to award his users. Some user it's it's you humans citizens. Some citizens are more are happy some citizens are not. They want to steal and it's your job to try to realize how to do that. As an auditor and insecurity, you need to think as the bad guy to break it. So this is an example of let us try to actually break it. the code if you download it and what's a bit wait a sign I'm not seeing it this here that's why I'm a bit whatever just a bit for tech the a bit of technical issues Just a second. In doing this time, you can try to do it on your own if you want. I have no idea how to do this. We're still failing at this, but we'll try. Huh? Huh? Can anyone from the staff come here? Come here a bit please. Hello. Boom. foreign. Ble. Of course. >> Have you tried turning off and on again? >> Only the laptop I need to turn off and on. I'll try with the laptop. Okay. But this Linux Duplic. >> You want to try using my laptop? >> Uh, give me a few more minutes and if not, I'll probably need to I was actually looking at that one. Good. Oh, no. No. No. Okay. >> No joke. >> Okay. Thank you for your patience. I hope you made the exercise during that time. >> Is the goal to get the attacker instead of >> what? >> Yes, the task was to have the attacker acquire 56 uh points. Okay, in case no one knows what this beauty is, it's file arhive manager. I recommend you use it. I don't use the terminal within Visual Studio Code that those I know people use it but no I'm using separate CLI tools. Okay. So this is the first task about how to make the how to have 56 coins. Basically there is a treasury and someone sets the winner with the owner you get the tier deploys its own golden tokens. the owner um the only the owner can set the winner and then at one point one of the any set winner can call and he will get the coins minted to himself. The gold coins the gold token is gold token which has a men to only the owner of it. When the gold token is deployed, the owner is set as the deployer. Remember the deployer itself, the t the tier is the deployer itself. So the tj can call this mint which will get this mint which will call this mint and the good gold token itself is the op is an optimized ERC where you have to believe me that I optimize by moving the context. The context is a part of open zeppelin context that ch works for a meta cont met transactions of message sender and message data. Wonder I removed it. Okay. Now you as what whoever failed or tries to attempt this start at this test better. Okay. Basically the winners are the hero of nothing, a slayer of words, random peasants, city guard and you have yourself the attacker. I saw the the other presentation that he had ro and addresses. You can also use make address. It's funnier like this. So basically the setup is called each user has a is set by the by the governance a set amount. Then this test actually shows that they can claim their rewards. And then the attacker style it's bank the start bank is the equivalent to use bank from the other presentation only works on more operations not just the first one. So and this here you should have add the code. Now since the idea here would be since I told you steal coins you need to look as an attacker on the treasury itself. You can see here okay how can we have code here that does someone needs to call this this has a only owner. So I as an external attack I cannot influence this claim only if I was set. If nothing was set this defaults to zero user has no winnings. Okay. How then can I do it? Okay. When you attack you need to check check every single thing that's on chain. In this case let's look at the gold token itself. The gold token itself. Let's see. Okay. It's another owner the mint. Okay, you have only the owner which was the deployer. Oh, fine. Whenever you see an optimized something, look for errors because optimization breeds errors. In this example, which if someone would have tried to look at it, I'm being passive aggressive without any reason. You would see that yes, I did remove the context from here. But there's another thing I copied this from open zeppelining but between the entire dependencies there are there can be issues that you don't realized for example the while I was optimizing I mistakenly he put the underlying m to public now this is easy if I'm showing you this but this is not easy imagine someone's looking at the contact on chain oh good Oh, good. Oh, good. But this, wait, wait. This is a lot of code. Opens up and copy. It's a single small change somewhere which you didn't realize, which is enough. Now, to actually make it like it's to make this attack, you'd need the treasury gold coins because it's a public variable. The compiler creates by default a getter. That's why it's a callable function. The gold coins here. And while this sees only the mint, we know that actually there's an underline mint there. I don't know why it moved here. Uh so and the underlying mint had who to get transferred the attacker. Let's say to who to transfer the tokens to attacker. Uh, it still should work. It's not, but it still should work because the interface is just a way of telling it locally what you have. Nothing stops me on chain to call it. But if you're right, I'll forget. I'll see the keyword ether means actually one to the power of 18. It's not actually one ether ether. It's just a way of instead of saying multiplied by 10 to the power of 18, I just say 65 ether. And let's see. And this should probably not the should probably work. Of course, I double test it checked it and at one point ah it worked. Hacker going to hack. It passed. If you look about what? Sorry. what you do with the mic. >> I cannot have the mic and so sorry about that. Look here the idea is after the prank let's say if we commented out you see the then the message would have been um attacker must have what I wrote here asserts can also have a message you can write a descriptive message what said happened so the >> if you call mint without the underscore >> if it should do >> it should it should fail because mint without the underscore which visual studio did see He did not see in the inheritance there that is that there is an underline one that is also public. Also there is the false concept that underline means private. It's just a naming convention. Nothing actually stops you from making it public or external. I could not put it because it can't be inhaled. If just the mint like this. Now I know that this seems simple but the idea is these happen like this would be the solution. Just a mint goes to here goes to the optimize where where we have it and it's public. This was a hack that happened last week when someone literally forgot to have a g gated mint and they lost only $140,000 because they minted like 20 something million. Well, no. Uh I think there there was 27 million equivalent in value but there wasn't underlying liquidity for it. The idea is people actually just forget to put a and it was again a mint in the dependency because the dependency by default didn't have one and they forgot to implement. Next one. This is going to the too easy box because it's too easy. But let's see how we have the time. Oh, we have time. So this task would be a bit more complicated. uh you have a contact like like the name suggests is a place where people deposit stuff and other people get the stuff. A career puts ether in it and a hacker going to hack dudes once to get you know there's always someone near the boxes the real life easy boxes who looks at them that dude wants to take stuff and this and in this case you would also need to find the to see how we can exploit this. This would require this is a bit more complicated if you you can have see there the two easy box. No, this is the two easy box. Oh, sorry. This is spam. Very simple contact. Someone deposits. anyone can deposit and then you get you withdraw. You make sure that you actually have something to withdraw and only the contacts that have been deposited can deposit. This function sends you back your eat sets it to zero. We're done and you can just get the contact to see how much. This is the two easy box. >> Yes, this is the classical case of you have some gazillion dollars. You have the courier puts to random Joe's do this Marcy attacker and we have the attacker. In this example, you only get one eat and with one that that one eat you need to get the the the entire balance of the two easy box. This has an irrelevance at one point but for now I'll leave it like this. Hackers going to hack. How we going to do this now? because I don't want really want to code in public. I'll just copy the solution. Yes, of course I have it locally. Someone told said how the of course I have it here. Yes, you're going to see exactly how I've taught it because it's easier this way and I'm no shame. Okay, someone told said orienty if you remember orienty is coming back within the same function. How do you spot these types of issues with orientency? Okay, anyone can call it this helps because you have a controllable attacker initiated entpoint. You have the side effect in in security on blockchain. There's the cause effect interaction pattern which which says first you must no cause check in >> checks yes checks interactions and um first of all you need to always do the updates of the balance before doing the interactions. In this case the interaction is when you're calling this function. What why does that matter? the this function of calling another address can trigger a hook a call back. This is this can only happen if you have a smart contact that uh calls this function. So let me give you an example of an attacker. This is the one that magically appeared. So the this function receive external is a classical function defined by solidity and the compiler and logic itself. When if a contact became if a contact is intended to receive native eat it must is it must have this one or a payable fallback. What does this happen? That means when the anyone sends E to this one, this contact will check if the the the two easy box. It could have checked if the caller itself had this balance and it'll call withdraw again. AC nothing stops me from doing this in a loop. Think about it from how would you actually implemented this if you had the time back. Okay, with the with the we create the contact. Remember the attacker has only one eat. This has was somewhat relevant because in a homework manner I would give you a harder version. We start the attack by starting the attack itself. So first of all deposit in the contact by depositing one eat we have the first requirements that we need to have an initial balance. Now the attack starting the attacker attack come here attack initiates withdraw we go to the withdraw withdraw have do we have a balance yes school calling it with we call this call means transfer eat to the caller then the attacker will get is his eat now if the box still has more one still has eat we call it again see the logic we come here again. Now the update the effect has not been applied because we we are still here in the first orient entance. This is the second reentence. We're going to reach this call and enter it again and come here and enter it again and come here and enter it again. At at the end in each of those calls, you'll just reach this one which sets it to zero. The first one will set it to zero. the other 10,000 will also set it to zero and it will not revert. For example, if I would have done here, if I would have put an amount and you would have done an amount and I would have deducted the amount, then you couldn't have done this orienty because it would be an underflow at one point here. Just by setting it to zero, I allow this case. I'll I'll show you again in um okay this is just to show that the hackers and the hack works I'm going to put a few more V's v is for ver verbose in foundry and you can see that you cannot actually see this shows how many execution and there are a lot and if we go in this example this is a uh view attack you initiate the attack which initiates creates a withdraw the door calls it and it calls again and again and again and again. These are classical redency issues. This is the classicalest example and simplest possible and it had an hack. I mean in 201 not 15 2016 there was a large hack about this because at that point no one knew about these issues. >> How long does the call keep happening? >> The exactly a good good point. The call keeps happening like the way I made the code and depending on how many times I need to call it to block the this to to stop it. So if there is a balance in the two easy box the malicious code calls it again and it only steals one eat on each call. So to answer your question needs to find out how many eats already there. So like 10 20 uh 30 41 times >> assuming >> actually yes >> what >> assuming you have enough gas >> uh for 20 whatever for 42 actually with your own is you have enough gas. Now if you want to complicate your life let's say there will be 10 thou 100,000 eat in this one. I'll I'll just show you that this this naive approach doesn't actually work if you have I should have that amount. It shouldn't actually work because uh maybe there's not but this one would be too complicated to implement. Wait, there's a gazillion dollar for the Korea. Whatever. Put more. At one point there's too much recursiveness. Probably this failed because of this. Okay. Too much can fail to send not enough gas because you there's a limit to how much gas you can actually put in the transaction. Therefore, you cannot have at many point uh homework if you ever want to do this. How would you modify the code to do it like so? I can give you a hint now because probably no one's going to actually do this. You need to think about this one in a duplication manner. Let's say there is balance. First deposit then call redraw again. Then my eat becomes two eat because I'm again depositing the one that I already deposited becomes two. Then again becomes four. Two to the power of and then you stop and have another logic. If you do need to increment again that point this simple single function cross uh orientancy becomes a more cross contact orienty. There are several types of orienty. We have the classical in the same function. You have the cross function orienties where you go to multiple functions within the same contact. You have cross contact orienty where one contact depends on the other and the logic you go enter in different contexts. You have crosschain orientency and there isn't even an odd deviation of read only view orienty where you modify the state which is used by a view function from a different protocol which basically is used for oracle manipulation. That's the most common case sometime modifying the underlying amounts while a different protocol still use the view with the older one and you have an hack. You can complicate the hell out of it. That's why they still exist. There's still issues with the entity. No one's claiming to fix it. Basically, you can't bash away with putting a modifier, but you can't really block all of them without knowing. This is a very classical and good case. You'll see it tendency is like the best known case of issues in the heat. Okay. Now, risk assessment the I'm telling you now the ecosystem is still young. There isn't a standardized way of defining issues. So we have like the risk is associated with an issue issue and we associate by severity. If an issue is highly severe then it it's high high risk of happening something bad. This is a general way of enough people are using this one so I can sent it here. Severity and risk assessment is how likely for something to happen versus the impact it has and define it by you low, medium, high. Now some give you some examples. The damage uh these are an example the does the issue itself has a high impact as in loss of a lot of funds like millions. Yes, this is a high impact. But if the likelihood of happen is very low like one in 10 years it's not that risky. It's still an issue but then you would make itself as an high impact low likelihood medium. It depends. It's it depends. It kind of depends. Now people are not actually in agreements with what is likelihood, what its impact because likelihood means how often do you need to call it to happen or if you actually need to call it to happen do you need to call it once a is it is it if I call it once per year and it has a 100% rate of reproducing the same as me calling it 100 times a year but one in 100 actually it produces there's a nuance there and it's not that standardized. Now, what is standardized is what you need to do about them. Critical highs must fix them. Medians should fix them. Lows can. This is actually good wording. Can fix them. And the other ones informational like my favorite ones I just put them there and typos and stuff people ignore. Now, quiz for you. Do it. This is actually a quiz. I'm going to have questions. Uh, how would you rate severity on some stuff? Um, when you all have it, I'll need to actually start the quiz. Do you have it? >> Okay. I see three participants. This is the first time I'm using this, so I probably have issues. Oh, six participants. Seven. You You are all in. Okay. Lol. You have 45 seconds per question. Go. L. Do you want the music? Oh, I can actually see the I'm leaving the elevator music. Damn, someone said zero zero. Nice. Continue, dude. You finished. Nice. Oh, you're the one who just passed okay on everyone to fail intentionally. >> Oh, okay. You actually thought about it. Okay. >> I assessed differently. >> I I agree. That's the idea. Everyone assess differently. I'm just giving you one subjective way of interpreting it. >> The 15 question 15 questions. So, we're then going to discuss them in the presentation, but I wanted to give you an idea of what we'll discuss. So, two people finished all of them, I guess. Bobby, you can overtake Alex. Whoever Alex is the VC. Hope you have enough funding. It's cute. Okay, two more people. Bastios and VC. Come on, VC. You're getting close. Okay, just one BC. Okay, let me see if I can eliminate the test dude. I sure want to remove Yes, because you didn't say anything. I'm sorry. Tests are not allowed. Bobby. Alex. Who's Alex? Belian. Ah, Alex. Who's Bobby? >> Yeah, we Bobby boy. And uh VC. >> This is my >> Okay. Now I'm going to give you an explanation subjectively why what what are the actual answers according to what methodology I chose because again it sort of depends. I first of all I wanted to have the questions one by one to not give hints about the other questions. So you need to decide a user loses $50. There isn't actually enough information about that one or how what does $50 means for us for an individual. So, you can't really tell on that one. Now, a user uses $50 out of the word uses out of a $500. Well, that's like 10%. That's kind of a lot. There isn't may someone may not agree there isn't a justifiable way of losing that much amount on an input of a fun smart contact. It's it's too much. You cannot say it's a rounding error at 10%. Now 50% out of $50 out of five million I put it as depends why because there is a case which regardless of amounts you will lose it all the other ones per year per day will just follow this because I asked impact not severity the per year per day depends when you want to say the severity of issue I just wanted the impact but you would probably thought that's the idea when we as an auditor I need to separate the likelihood of it happening with its impact and then choose the severity but it's a bias human bias to actually think in both likelihood and impact and say that the impact is actually a severity it's a bit tricky so basically you ignore those with time they're the same like user loses 50 per year it's still the same in my idea as not enough information again this is not exactly exactly a standardization but we need to do choose lose one at one point. Now we have these here I changed the question suffers a theft and suffers a rounding error of the same cases. Now either way when someone steals from you that's a high severity. There's some protocols or some platforms do have like some cases but theft usually is high sever high impact. >> That could be critical. >> That's that's the severity. If the likelihood is mine talking strictly about impact >> impact not severity is critical if likelihood is also high. No, could be critical detail. depends >> uh depends on I know I know I have you an example as the off one at immuni who has that one but generally no general auditors have separated this I'll give you as an I have has an example so all theft should is at least high okay someone use a critical now rounding error of 50% of $50 depends because depends on the amount a rounding error of 50 from the 500 ones you have a 10% rounding error that's a lot that's too much high rounding error 50 after five five million it's like 0.001%. That's a low because it's expected. It's actually very good if you have only $50 rounding on this one. That's why impact depends at least at least it depends on the uh amount on the amount relative to the input amount and how the amount is lost. That's two fundamental ways that it does impact generally speaking. Now there are some examples like a contest platform Sherlock defines significant loss if you have 1% of amount or more than telling dollars there's an absolute one fair. They are like immunifi who says that if any amount is lost that's a critical they even they bypass likelihood then they bypass impact and just say it as severity >> amount of user funds >> of user funds fair not of protocol funds there's a difference here the idea is someone needs some use have their own way of determining severities others have a more standardized in between private audits usually that table. It's the best we got so far. Okay, I'm going to speedun the next ones because the idea is just to present this was the only part of actually interactive the security ones limit user interactions. If a user is not intended to call the functions, don't let him call that functions. Never. If there is no incentive for him to call them, it means that you not made the function for limit limit as maximum as much logic offchain. You have a lot on the contact requires a sorted list. Don't sort it on chain. Sort it off chain. Send it onchain. Verify it sorted. Easy to do. Uh always validate user input. Even if you allow user, verify, verify. Every single thing he puts there must be verified. Uh each and every rounding error, each and every division, you need to define if it's against or the user or the protocol. It must be against someone. You need to define it. It's a this is tedious. This is very tedious. Devs don't do that. uh multiple decimal tokens you'll have you need to define each decimal look at each variable what each decimals is I'm giving just all in the presentation and the book you can read all about them these are a lot I mean if I would go on all checklists would be hundreds and tens of different things you need to check out basically be even subtractions as you have a subtraction check because they can underflow try to do subtractions additions this is an example if you're comparing a duration with the start just move it around so you don't do a subtraction because it may underflow actually had cases issues like this always reuse library code the save versions if you have a dependency you must know it like you must know your lava everything it does because depend it's a different between li code integration and a dependency unis swap is a dependency you have dependency you call a different context open zeppanine is a library you get it locally it's audited that it's okay for now. Format your code. You formatted code is always okay. As simple as possible. Low level co code size simple. Think as an attacker. Find what's relevant. Bake it. Testing should should be 100% coverage should have first testing should have um formal verification. And these are fancy words 99% of protocols don't use but I'm telling you should obs uh obscurity security by obscurity meaning not validating the contact or like Solana ones I'm happy because no one sees my open source code it's not it okay maybe it delays by a day u check all your sanity if you're too intestant get all the checklist in existence and check them yourself audit onchain and offchain smart contact auditing finding bugs you can only show that bugs exist you cannot show that there aren't any more bugs mathematically form a vacation you can what does an auditor do finds issues makes PC's suggest fixes we also suggest fixes ensure everything is implemented correctly get compiles all the issues given the report to the client this is the job of a security researcher basically uh glorify test, designer, system architect and dev at points. The ideal smart contact loop for a protocol is they develop go to a solar auditor one individual go to a company more individuals go to a crowdsource security contest where people freely participate then a bug bounty and if at any point issues are found they go again. No one actually does this but this would be ideal. Generally auditing is looking at code and understanding it. This kind of still applies but it's kind of dying. Uh the best auditors still look manually. the worst still use man they are in between that has like every single tool you can imagine and versions and whatever whatever helps you uh security today educ what's what's really relevant today about security educational content like siphon updat air skills o and d there's people relevant in the ecosystem because there isn't enough information within the ecosystem for it crowdsourcing security. I used the word word uh a few sentence ago. People from around the world can randomly participate in a contest to to secure your code for a chance of winning money. The form of decentralized security, crowdsource security. We have contests. We have bug bounties. These are a few of the most famous ones. Security automation. This is where a lot of money also goes. Like how you have static analyzers. You have Slither, the best one. Magnus from Immunifier, an orchestration of several other tools. You have audit agents. Everyone's trying to automize and eliminate us auditors because we're expensive. Normal. This is life econ economy enhanced verification and tested sto uh which has formal verification open sourced. You have the econ which is a combination of fuzz testing has medusa halmosis symbolic testing a lot runtime verification from a lot of another form of verification there's a lot of things going on trying to make the need for creativity as slow as poss as least as possible again we want to eliminate humans normal conclusion security is essential because it's money security exists as long as blockchain exists if blockchain die, security will die. Fair. Uh million dollar worth stolen each year will always be a million dollars worth on each year. Um best practices will reduce chance even if you don't actually know what you're guarding against. You've just made a best practices and you saved yourself. I think I put two times that day. Okay, basically that's it. One question. And I need to go at the panel and I suggest you also come with me at the next one. So you said something for better security to use offchain computations right >> as move as much logic offchain as possible >> because I mean from my experience it's quite easy to >> statistically I disagree with you >> the newsoft >> I know I know they happen they happen they think must think about it in percentage how much percentage of the entire global web 2 infrastructure is hacked and what's the percentage of smart contacts that are hacked and the targeted and the attack area the more contact the more code you have on chain the higher chances of bugs introducing offchain like Microsoft okay you have zero days you have large entities that will target there will always be zero days there will be exploits in web two but I'm talking about logic that it's not that critical like I give you the example of sorting a list and putting it a chain state should be on chain state that's relevant and used offchain if you're offchain using just the logic to calculate and the state which is money defining is onchain you're okay >> but why did you use encryption smart contract >> there are forms of encryptions but not relev why why there isn't any a good use case of using encryption onchain because you want to read the information you want to have it. You can't you you like it's not I cannot hash a password and save it onchain because anyone can read it. I need to define stuff on chain that I for which I use the blockchain as immutable free for all to see uncontested. I have a onchain game. The scoring point is onchain. The logic in which you calculate it may be on chain but you can put offchain something like the list must be sorted uh >> basically the heavy computation >> as most as much heavy computation as possible put it offchain but core logic the one that you yes can be hacked in web two and in web three should be just the core one should be onchain minimal as possible >> like for verification. Yeah, for being verified that nothing actually bad happened. Okay, >> thank you. >> Okay, thank you.