# Panel - Web3Sec: Navigating Security Challenges

- Channel: [ETHCluj Meetup](https://streameth.org/ethcluj-meetup)
- Date: 2025-11-09
- Duration: 1:11:42
- Watch: https://streameth.org/watch/yt-T6G5GwhMB-Y
- YouTube: https://www.youtube.com/watch?v=T6G5GwhMB-Y

## Description

In this panel ABA, m4rio.eth, Noah Jelich, Sebastian Banescu and Vlad Toie cover topics such as common security misconceptions, essential security tools and practices, staying updated on vulnerabilities post-Pectra upgrade, and the effectiveness of audits and competitions. 
They also delve into emerging systemic risks beyond smart contract bugs, including MEV on Layer 2s and architectural shifts.

## Transcript

So now Sebastian returns to moderate a panel of web free security expecting myths busted tool shared and systematic risk dissection. Hello, I am uh Mario security researcher uh and I've been in security for a long time doing web three for about five, six, seven, I don't know years. Currently I'm do I'm a LSR at Contina and I work with a lot of uh Rust EVM uh web two uh and so on and so forth. Thank you. >> Hi everyone, I'm Vlad. I uh do EVM security at Zelik uh and uh before I've been working as a pentester and a web security researcher. >> Hi, I'm Noah. So we're all security researchers. So, hi. I'm Noah and I play Mando Cello. Everything else is the same for everyone. Believe me, I have my own mic. Hi, I'm Aba. I'm Alen, also known as ABBA in the industry. Um, sec independent security researcher combined like 10 years both web two and web three security. I'm in it for the fun. >> Awesome. Now, we can have some fun. Like I was nervous during my previous talk, but now I'm gonna I'm gonna put some pressure on these guys. No, I'm just kidding. Like they already have the questions. So guys, what's the biggest security misconception that developers have on when building Ethereum DAPs and particularly which are the misconceptions that are not on every checklist? Well, uh for those who were at my talk, the biggest misconception is actually that the web two part doesn't uh matter so much and they all focus on the web three because especially on the smart contracts because they are somehow immutable. But if you look uh past uh few years, most of like the biggest uh hacks happen due to web two vulnerabilities. So yeah, I think that's I think that I unfortunately I have to repeat it all all over all over when I speak about security, but unfortunately still like the biggest attack vector. So yeah, that's one thing I want to mention. So we see a recurring pattern usually in uh very inexperienced developers. Um, and it's a concept that I would just summarize to developers expect their application to be used in a very specific order because they do the routing from their web app to their web to their u to their contracts. And so they don't expect that the application can be used outside their defined routes within the front end. Uh, and you can observe that because sometimes they're like, "Oh, wait, but who's going to call it?" like who's going to call the function in a different way that we thought of it to be possible. Uh and you do find a lot of bugs that are like that and generally when you do find a sim a bug like that you're like oh these guys are like beginners. There's there's an obvious mistake here. Uh and I think that a lot of especially new developers um consider that hey uh the you know the the chain works as a backend. It doesn't work as a back end. It works as a you know stateless machine. It doesn't have I mean it it is you know machine that has state but it doesn't work like always through the same routes as you know your usual backend would and I think that's a a very common misconception. >> Yeah definitely it's not a state machine in the way that you know a game engine state machine would be with defined decision trees. It's it's very loose. Um okay. Uh yeah, for me I'm going to say uh thinking that you find bugs with bug bounties, white hat hackers and uh audits and not at your design step which you didn't have uh like in general I see a lot of just faulty faulty faulty configurations and just from the get- go and uh I think my worst one was a particular audit where we managed to find over 150 issues before they made us stop. And I I've had a lot of audits for very bad projects where I feel like I killed the project because they couldn't get past the audit stage. Then they fire their dev team, then they go back to the drawing board. And the thing is they're already like a few hundredk deep especially with the expensive audit and they have nothing because they made the mistake of not having a security engineer who could have told them this is uh at the design step uh which would have saved them a ton of money and hurt their ego a little bit. So yeah, >> thank you. Um, going back to the original question, what web two misconceptions do developers have when coming in web 3? What I'm going to say is a bit including all of them. There's a misconception that if you are a very very good web to developer, someone that had 10 years in Java, AVS, serverless, whatever, then they have the very wrong misconception that they will actually be good web three devs. They will not be. Then if you just take a good web 2 dev and put him at webt, he will fail because he fails to understand the entire ecosystem is unique in its way of operating as a financial layer as issues. They don't even imagine explaining orient explaining blockchain reorgs to a normal dev. They they don't even have the knowledge to understand that. It's not an on a checklist because basically it's generic. >> No, those are those are really good points. I think like definitely you guys skip the checklists. Um for the second question, we're going to switch it up. Vlad is going to go first. Noah um and and we're going to end with Mario. What security tooling, practical security tooling or even like processes, methodologies um should developers integrate into their process in order to be you know secure from the beginning or or or have less than 150 findings per audit. What do you guys recommend? >> So I'll probably give the boring answer here. Um but I think after a few years of doing EVM especially I think that if you just have basic testing 100% coverage both positive and negative test cases you will probably get rid of most of the bugs that you know a decent amount of auditors would have found. Um and if you you know if you say okay test coverage whatever you can start to think of like invariant testing defining your very specific contract level or uh codebase level or architecture level uh invariance and testing based on that. Uh but I honestly don't wouldn't recommend looking into crazy tools because you probably won't even know how to use them if you don't even have a testing suite in the first place. Um, and most probably you will benefit the most from just investing a lot of time in developing your testing suit and making sure it's uh covering all the possible cases that you can come up with and potentially um ask security researchers questions about what type of invarian you should define and stuff like that. So just focusing on a testing suite would probably eradicate most of the bugs uh in my opinion. >> Yeah. Yeah, that's that's very good. And it's also a very nice homework or something that you can delegate to more junior team members and of course review by the more senior guys in case they're writing shoddy tests. Also, it's it it really is a massive improvement like for for me just seeing test coverage was always uh a massive boon. Another thing that you can do is if you want to save money is use mutation testing. There's a really nice tool written by um an Italian researcher lady and uh it it really helps you find if your tests are even good because you can find very flaky tests. Um >> tell us tell us who uh I forgot the name. I cannot >> Is it Is it Sumo from Moreno? >> Yeah, >> Sumo. Okay. >> Yeah, but I couldn't remember the name. Sorry. Uh like the the person name. Uh okay. Uh so something else that would be good to to add to a flow. Yeah. I I'm still on the same thing from the last question. Honestly, you need a security engineer in your design step. Please, please, you really need that. It's so cheap. We will talk to you for free. You just need to buy us two drinks and we will tell you how much you suck. And that's value. and it's very cheap value or go to a security event or something and just buy someone drinks and just leave your ego aside. It's going to provide so much value. Also, do know what you're building. Like, I mean, there's going to be a lot of people at this event and any room that are going to just be trying to follow a hype cycle, but you need to know what you're doing. If you don't, maybe find something else because I I I love the great open ethos of everyone can build on blockchain, but would you trust everyone, including that neighbor of yours that keeps their yard very, very messy, to run a bank? Because it's the equivalent of connecting a bank to a touring machine. And that's considered ill advised. You know if you've not heard of stored procedures you should maybe not be working on banking software and most of this is banking software in a way. So yeah have a skill you know minimum for for doing financial applications but I cannot save you. You can feel the pain is in highs. Um my idea is similar somewhat similar with what with everyone with just with what everyone said or just I want to add this one usually you see tests what I would really want to see from the start which people kind of don't really add is invariance and fuzz tests protocols think of first as like complicated define invariance they do sometimes make a lot of normal tests they have a even 100% coverage But they don't touch the first test because it sounds fancy. It's literally something that they should add. That's my opinion. They should add those as soon as possible. Make a test and a first test. If you just wait until the entire protocol is done, you will no not that helpful. >> Do you have any specific fuzzing tools that you would suggest? >> Even found is enough. I mean, they don't actually need to complicate. Okay. They can use recon, medusa, kidna, but those are fancy words. founding. It's literally just you're already using it. Make it as easy as possible. Use what's easiest for you. Just created. >> Awesome. Do you want to add something? >> Yeah. >> Uh I think I have a controversial answer. Uh use LLMs. I mean LLM like AI. Man, I had a client like in December like yeah uh 2024 awful code awful lots of criticals whatever and then he came back after 3 months and I was surprised how did you hire a new team or what happened and he said no I started to ask everything I I've I've done and I basically that helped me write better code and unfortunately it's true uh AI is becoming more and more intelligent ent and start using it in your like day-to-day flow. Not trust it, but at least it's a you know it's like a colleague like a peer reviewer right now for you and that should be the first step in everything that you program right now because at least AI can just tell you hey you forgot are you sure you want to make this function uh open to everyone because you withdraw some funds from it. Are you sure? And at least you you think about it like hm wait should I make it? Oh, wait. No. And that's it. That's a critical that it got out of your way, right? Yeah. So, start using LMS, but the smart way. Unfortunately, there will be guys who will just put a prompt into the LLM and then deploy the code, but there will always be some more for us, fortunately. Uh but yeah, I mean >> about the LLMs, but uh I've I mean I of course I use LLMs for for coding assistant in a similar way. Um but again, when we're talking about stuff where you don't know enough necessarily. I've had a lot of experiences when I'm trying to talk to an LLM and I find myself arguing with a stupid toddler and I know I'm right and here it is trying to hallucinate its logic into being you know whatever it hooked on to. So like watch out it will hallucinate. It will gaslight you. It is an emotionally manipulative prick. You know, last my last good conversation was about an hour of talking how to prove some integral and like it was just skipping a step and I spent such a long time just convincing that it's wrong that I was going crazy in my own head, you know. So, watch out. Watch out. Do not trust them. Do not trust the faceless monster. While I agree with that, I you also have to think that uh if you look like a year ago, charge JP versus a year now, I mean the difference is huge, right? So yeah, I mean don't trust everything they say. Uh but at least you know use them for like basic stuff. They will uh derail a lot from what they should do. But if you have a bit of critical mind and you question everything it responds to you, you will see that uh it will you will get better and better and better over time and they will get anyhow better and better better every time. I mean it's amazing how what they do on web too. If you ever try to like do some pen testing with it's quite uh nice. Yeah, this this bring back brings back the memory from the Eve Bucharest panel where we talked about vibe coding, right? Um I guess like there's there's a point I think both of you both of you guys are right. If your devs are below claud level, then use claude. If they're above above claude level, then don't use it or Yeah. basically or use it but but >> they >> but don't trust everything they say. Right. It's a toddler. >> It's a toddler. LLMs are a toddler. Claude is a toddler. If everyone any if anyone was wondering how old Claude is, it's a toddler. All right. So, let's go to the next question, which is I guess also for, you know, anyone in the audience who's an end user. Um, I mean, like the the answers are going to be useful for everyone. Um, we just saw this uh, Pectra upgrade in May and it brought a lot of risks with it. So, you know, many end users were totally unaware of EIP7702. Uh, if they didn't go to any crypto conference or they didn't watch any talks about it, it took them by surprise. They were they just got a message, hey, here's an airdrop. they signed it and their wallet got drained. So like just like that, how can both developers and end users keep up with all of these new risks that emerge when you have like an upgrade like Pekra or any other upgrades in the future? What should they follow in terms of resources? I know uh Noah just mentioned just hire like just talk to a security engineer, right? But but security engineers are not on all the you know like in in all the bars. So um you know if you guys have any resources that you could point or or any you know best practices that users developers can do and maybe even like how auditors should play a role in this whole thing and let let's start with Noah this time. So this is really a question of security awareness trainings and briefings for the general populace and that cannot ever come from a small circle of security engineers with limited reach. It has to come through mainstream tooling. So I I think this is a thing where MetaMask for example being the top wallet should be pushing more education, pushing more protections for user or maybe limiting feature supports and keeping them behind lock doors and behind check uh check marks to make sure that users will not use advanced features in stupid ways like uh you know pseudo exists right on Linux and I think it should be the same level of severity for anything more advanced. Um like my talk yesterday was in a way a security briefing. It was trying to get people paranoid and conscious about the topic. But this is limited. It's a it's a limited approach. You cannot actually make a lasting impact. And there was a a lady at my talk a few weeks ago and we talked about the recent emerging threats including for example deep fakes. And then she got hacked and she got hacked because somebody used a deep fake to social engineer her. So you know it's nothing's a guarantee and thus I think that from the institutional level from that point we need to assume that users are toddlers stupid. They don't know what they're doing. they they like simplicity and we should focus on the thing that's more or less completely ignored in a in a system designed by engineers under the fallacy that you know oh I I can use Linux and I I know how to configure you know permissions in Linux and I know how to set up rate zero on my disk. So the other person surely knows at least how to install an operating system and not that they are struggling to turn on the microwave, right? Um so I think we need to think how dumb. Let's let's not offend them. Let's not call them dumb. This is actually stupid. We need empathy here. They're just not thinking about that. I would love to just run around in the grass and not touch a computer ever. I think many people here would. And then I would have to know nothing about Linux and nothing about any technical topic and I would breathe in the trees and be happy, right? And I think it should be the same approach. Assume that we have these happy people that just want to do stuff and ignore computers because computers are a necessary evil to them and that's real. And uh and let's just try to keep them safe by limiting what they can do by keeping features that may be dangerous locked behind certain barriers within let's say mainstream wallet architecture pseudo for crypto. >> Okay. Um coming back a bit to the question was specific how would user and this get a better feel of tests that appeared with pecta and seb mentioned 7701 IP that's the one that mentions that uh normal wallet addresses can now have code so you an externally owned account now can can have code this is this is the big difference but I do need to answer this question like they did because I don't feel that there is the way you can have how would normal people get any information about any security that not just pecta not just AIP7701 or whatever random digit they assigned. So I would say they need to follow newsletters and content tailored for the masses. And the follow-up question that you asked how auditors do can help simple just make content every audit content is gold mark for marketing purposes as an auditor you show that you know stuff people read it you make a good for the environment and ecosystem and yourself and there are resources like blocked who just collects random ths information articles and spread them concrete action subscribe to block dead read whatever is there and it's still better than 90%. Follow Crypto Twitter, follow random security companies, get a list. It's enough at least for starters. I mean, um there's no easy way to to teach anyone like the upgrades and so on and so forth. Um I think my colleagues I had like very good points. Uh if you're in this space, it moves so fast. You have to I mean to I mean you you you are terminally online and you have to be thank thankfully uh we also get like some nice decisions sometimes at the core level for example EF was not released in this spectra thankfully that was a big mess as well so trying to I mean it's always a challenge you want to evolve technologically but you also want to not introduce new stuff that are dangerous and the balance uh it's uh I mean it's tough to to see where is that balance. So yeah I mean other than just documenting yourself as colleagues also said they're writing a lot of content for those who like to write content uh it's also nice but yeah I don't I don't think there is like a nice solution other than just staying up to date. Yeah, my colleagues made the made some very good points, but you know, I would add that u I think coming from let's you know, if we think about it from the retails perspective, uh most retail users use some kind of wallet, right? uh and so I think it's it could be also the wallet transposability as well as the protocols that u you know want to leverage those like extra features of spectra uh to actually define some whitel lists or some mechanisms that uh would not allow any user to essentially perform remote code execution on their entire wallet or like you know essentially have as you said pseudo privileges on their wallet with by just like the click of a button. Obviously, the the mechanism itself allows for a lot of innovation as Mario also Mario also said, but you just you need to think about it. There's no backups. What do you do in case you know you get like a you know you you you get you know a fishing link and you click you click a random link and then now your wallet is wiped out. Um your entire balance is wiped out, right? MetaMask could, you know, come up with solutions here. And I think I think we will see eventually uh the the wallet uh providers being more involved u in terms of um in terms of taking more decisive action and kind of like protecting the users and the users will have to agree to a certain kind of protection because otherwise maybe if if you're a ledger user and you're signing all your transactions by yourself or whatever you take the risks but otherwise I think most users don't want their wallet don't want the possibility of their wallet being wiped out uh as a nonzero risk essentially. Um and yeah, >> so we're all doomed. Um I guess like I was expecting everyone to answer, you should follow my blog or my podcast or uh you should watch my video on YouTube about how I present stuff. Just follow click click and subscribe. Uh but no, everyone was like, "Oh no, we're doomed. We're doomed." I I wanted to I want I was I was thinking maybe someone is going to say, "Oh, you know what? The wallet should basically um whenever there's an upgrade and people don't know about it, the wallet should say, "Oh, wait. You haven't used this upgrade yet. So, you need to take a mandatory uh security awareness training before we allow to to we allow you to do the next transaction. And if you don't pass, you don't get to do any transactions." No, that's that's ridiculous. But I wanted to throw that fun one in. So, for the next question, it's a bit more spicy. Um, I hope no one in the room takes offense or no one was involved or whatever, but uh there was this recent I wanted to talk about it because it's a it's a recent thing that happened on crypto Twitter. There was this debacle with um I don't know if I should name the name of the of the of the company, but you guys know it. >> I will. >> Okay, you will. Uh but basically there was this debacle with uh an audit contest, right? And apparently the company who was who paid for the audit contest wasn't aware of all the rules of that audit contest and when it came to uh to the time to to pay all the security researchers who put the effort into finding bugs, they were like iffy and it took a while. I don't even know how resolved it is at this point, but it took a while until like the project formulated an answer. It was a bit of back and forth and you know I think those kind of things we see them you know not that often but I wonder like with these conditional pots happening with contests nowadays are are are researchers going to be I don't want to I don't want to use a swear word but would will they be you know sort of like um >> unloved >> unloved yeah um with with the with the and and are there sufficient you know, super talented researchers looking at these conditional pot contests or, you know, like I loved the idea of contest when it there were no conditional pods and now it's a bit different. So, I was wondering what your take is on that. Let's start with Aba. >> There are two questions here and I'll it's going to be a lot of talking but I like talking. The first one was regarding the debacle. It was between a protocol called Spectre Finance and the bug bounty platform called Immunifi. It's not secret information. It's on Twitter. I mean like I don't if it were I would say that I would not say it. Basically it they had the issue was the pro there's a such thing called conditional pot contest and full pot contest. Basically, at the start of a contest where anyone can participate and secure the protocol, they say, "I'm going to give you $40,000 if any issue is found." But there's also a differentiate the conditional part. I'll give you $10,000 if low severity is fined. 15 is medium severity and find issues is found severe the issue, the more money is allocated. Okay, these are part of the second question and they uh are more frequent. In this case, the company that uh started the contest uh Spectre said that they misunderstood the protocol contact and description and they thought it was a conditional uh part contest while the hosting platform clearly stated that it wasn't. And I'm saying clearly stated because I literally researched it. We had the questions beforehand and you have specifically mentioned hey any issue found full pot. Now why would they do this? I was thinking about from a point of incentives probably money. The idea is they didn't want to pay in my personal opinion I don't think they actually wanted to pay the full amount because it's I read the description of the contents and it's like the second literally the second line of the entire page says if any issue is in found you will pay full amount and they had like three weeks they declared three weeks we we looked at the description sign the contact no issues found now there was a back and forth some panic some discussions and the very respectable security contest that held the that held this contest said okay we're not dedicating more time to it dealt with pay they have defined what happened immunifi is going to pay and the spectre finance basically got a free audit now that I don't think they did a good thing but coming back to your question why did they did it I think they did it for the money coming back to the conditional pot versus the full pot. Both are tools that will exist now and forever. The conditional pot has a marketing effect that is used up to one mill. It's like you can like we're using now in marketing. You win $10 million up to somewhere at the bottom. That's a good marketing 10 million but actually win like five. It does help and I think they will stay. And one thing that I want to add is that conditional pots are very good for large blockchain contests. If you look at statistics and the distribution of money and how many people actually got it, if you have a blockchain protocol like I don't know the ethereum itself or whatever stacks blockchain whatever if they have conditional parts they usually are reached and paid. Those are good ROI. Do them. The other ones are not necessarily that good IOI but whatever they will exist their marketing gimmit they also help in their way each to their own yeah oh uh this is a drama everyone likes drama of course I mean come on security researchers are paid a lot so condition it's unsustainable to pay us that much money uh over all the projects if VCs and everyone does not allocate a budget for security. Uh it's impossible for a new startup which most of the these products are startups right to have a very like full security if VCs don't and they don't raise money for the security itself. I'm not saying uh we don't deserve those money. We we do because sometimes we uh go our TVL's worth of billions and we have to be paid very well so we don't screw up. Uh but unfortunately uh conditional pots uh it's a tool that should be used by any uh like big protocol that has a lot of money to pay as well of course because first it's a it can be used as a incentive for the developers you have no critical in your code you get a bonus uh and where do I get you uh that bonus from well from the competition results because I did not pay the 1 million or 2 millions or whatever uh critical. Second uh the good security searchers when they have like a high payout they look a lot on the code uh and they start looking at the code more thoroughly and so on and so forth. If I have a competition that pays 50k versus a competition that I may have like 10% or like 5% uh chance to win or a million, I will for sure look at the one a million one because why? Because I mean I have the funds to not to live like two three months whatever uh and not earn anything and have the chance to win a million versus just win 10% or whatever of out of 50k. So yeah, I mean conditional pots uh I don't have any uh I mean anything against it. It's a good tool uh and uh should be used because it drives more incentives. Um and if you look a bit uh I mean I know there's a lot of drama saying uh okay people doing statistics so how much you paid if you didn't do conditional B whatever and the researchers will get paid more but well again it's unsustainable for all the for the all the protocols and you can see especially in the bare market like the competitions like uh the payouts for the competitions are like super low you know And it's impossible for uh for some protocols to pay uh for high security um at least they may have a high chance to not pay that uh that amount. That's a chance. Um so to obviously we are all here security researchers and uh we got to be honest it's simply an incentive game. Um, if there's a, as you said, a 50k conditional pool and there's a 60k or even 40k non-conditional pool, which one would you choose? Because after all, you are spending a lot of time on the code and maybe you're not finding anything, but the time is still spent. That doesn't mean you didn't work. So, you should still technically be paid. Um, and I think the conditional, you know, from from an incentive point of view, the conditional pots are broken. um largely because as I said you're still spending time. So um for researchers that value their time in terms of hey I have a few options. Which one do I go right? I have to I don't have 40 hours in a day. I have to spend some time maybe you know earn my living. Uh which which one do I choose? Do I choose one that maybe pays me even though I'm paying a lot of I'm paying with my time uh to actually find something or do I try to spend the the same amount of time somewhere else where I'm most probably be guaranteed to be paid if I do find something. Uh so it depends on it depends on the perspective of each security researchers and I think depending on your current status if you're working somewhere or if you're doing you know freelancing or if you're doing bug bounty depends your on your mindset as as you said depending on having a disposable income for a few months. Uh but I do think it's a it's you know the incentives are broken for conditional spot specifically because you're still spending time and time is value and in terms of security research even if you do a contest where nobody found anything that says something about your code. You don't have to be you know you don't have to be uh very I don't know how to say it but you don't have to be like very um specific and say like oh yeah you didn't find anything you don't get paid. Well, maybe it's a good thing they didn't find anything. Maybe your code is very good. Um, and I think that's also one of the strange expectations that some uh protocols have when you're doing audits, right? They're like, "Oh, you didn't find anything." Well, yeah, your code is good, right? Like that's what you expect. Your code has to be good. You want to deploy. That's that's a good sometimes it's a good sign. Sometimes it's not. Maybe you miss something. But uh generally let assuming that the code is fine and you also didn't find anything, auditors still spend time on it. They have to be paid. They're not slaves. They don't work for air. Um so yeah, I think it's it's simply an incentive game. Depends on how you play it. I agree fully. Uh okay. I just like to take the time to play devil's advocate for a minute here for Spectra. not not to make enemies, just to just to add a little bit of more clarity to wrap it up. So, okay, it's a bare market. Uh it's better to not spend money than to spend money, right? And if you can get out of paying the full price of 40k for two medium issues that were found during the bug bounty, uh that's a net positive for a company. That's maybe a few months of development time that you can put in, right? Um and in this case it seems like there was also some confusion and misunderstanding to to keep it clear because the there was a conditional pod for 40k for issues found. But I looked at the actual website and on that you see the conditional 40k is split into four different categories. 25% it's visually presented into low, medium, high and critical. And their rationale was that since only two medium issues were found that the split of the 40k should be applied only for the two medium issues. So there should be 10k distributed for the medium issues which spectra suggested be raised to 15k since none of the other categories had any issues found. So it you know it feels like it is not uh no black and white situation because there were really only two medium issues found and for two medium issues like the 15k of the pot which was a significant percentage were nice. It was just not made clear whether in case the other issue categories were not found whether any of this would be mixed into other parts of the pot. Right. >> Literally it the second line you that you're mentioning is a bit down like it's like saying in a contract if amendment one says full but the added amendment is >> the little the second it open the side the second line >> sorry >> I did it was what they were mentioning but it's like a bit you need to scroll down and like the second line when you literally open the contest page says if any valid issues and finding full pot is given I initially I thought like that and I read I was agreeing with spec ctor but dude the literally second line says if any then full pot and that distribution is for the SR themselves I and it's the second line I mean >> so you're of the you're of the opinion that in this case the severity level distribution should be merged so in case there were like let's say medium and critical issues found then the other two pots should be distributed between those >> for the for the researchers that found them. Yes. >> Okay. >> That was the point. Not for the protocol itself. It had like >> not your don't get me wrong there's there that specttocol is okay. I get that what they existing for a while good protocol probably for it to be used. But you had a contact they have an agreement first. It's like you have a contract with has seven amendments and the sixth amendments modifies the second. Does that mean that >> Wait, did they publish the actual contract with him unified? >> No. And they of course they can't. You can't publish a legal document. >> No, they can't. It's a legal document. >> It's not It's a legal document, but it's not a secret. >> It is. Have you ever seen the public documents the context between Open Zeppelin and any other competition like each paragraph exactly everything? No, of course. I've seen plenty of documents like that. >> I know officially no one's actually sharing them. You can't share them. >> Okay. Okay. >> Interesting. >> Okay. But okay. The idea is that it's subjective. I uh just wanted to add something like you know that this conditional if I may say P thing is not actually I mean it first started on bounties I if you look at bounty like you have I think layer zero was the first time who like we have 10 million bounties like the biggest bounty on imunifi uh but you look at all the conditions that that happens it's like 0.00 0000001% to get that 10 million. It's it's a marketing scheme, but there is also um incentive uh because I spoke with a lot of researchers saying that no, I'm looking at uh at um at this uh even though I may not find the 10 million, but I may find something that pays me a good chunk of of that 10 million. You know what I mean? So yeah, it's a it's somehow a marketing scheme, but um u it pays off for both researchers and also for protocol. If you look at how much money some of these like conditional bot competitions paid, I mean it's a lot like story paid a million, Ethereum foundation paid a million. Uh so there are like lots of money I mean to be paid off. >> Yes indeed. I I was I was wondering who's going to mention like these these conditional pod audit competitions are like live bug bounties basically in the end. Yeah. Um >> find >> cool. So this this got a bit spicy as expected. Um let's move on to the last uh question I had on my roster and then we can answer the one from the audience. Um so you know we we as auditors we typically look at smart contracts but I wanted to focus the last question to something beyond smart contract bugs. Um do you guys see any systemic risk in the ecosystem that is coming up either already exists like for instance centralized sequencers on all these L2s or anything else um I mean like some people consider even me on L2s something like a risk but that's you know like debatable um or even like the the risk v proposal right some people consider those kind of architectural shifts like a huge risk. may might not be, but how do you know we as auditors start thinking about you know mitigating those risks? And again, this links to the the I think the third question which had to do with how do users like how do they even like keep you know their awareness of these risks when they come up? >> Stuff I don't have. So I think there's a bunch of directions and multiple attack vectors that are pretty scary. Uh obviously there's the interface uh aspect of how you interact with with anything that's onchain, right? Whether that's a phone app, web app, you know, everything can be it's essentially an attack vector and is vulnerable. We see that with a lot of like compromised uh front ends u you know even fishing attacks and stuff like that. So which is like on the website on the web uh part of things but there's also the systemic risks associated with like the execution layer uh the fact that like 56% or 60% of the clients are basically GU and like the rest of the 30% is like I forgot what and then you know essentially if there's a bug in G She's like most of the execution clients are and like what happens then? Um, you know that I think that's a good question and it's pretty scary. Maybe if we had a more decentralized kind of like client approach where okay maximum share of a specific client could be 10% of the resources within the within a specific chain. Okay, that would be fine. Uh but you know I think there's a lot of centralization risks uh and simply very deep systemic risk that we still have to deal with right luckily there's uh uh I think there's the um rust version of basically ref yeah which is gaining some traction hopefully will you know gain enough traction not to replace g because then in that case it would like that would be 60% of standard g but maybe like you know drain a little bit of G's uh you know market share I mean it was bad a year or two years ago like it was G was like the there's no nothing else than just get mostly but now it improved like a lot I mean we have the client diversity it's a way way way better than um it was before and I think we are working towards that it's hard to move completely from get but uh we have a lot of client diversity now um And uh we are working towards that. Regarding the question like I mean there is a lot of L2s and I mean new chains that appear every time and it's hard for you as a user to interact with all of them to understand them. Um there will always be decentralizations uh on all of these new chains. Um blast was for a long time just a multi guarding five billions. uh and um you have to stick with I know uh what I mean you have to see your appetite for risk and uh then go from there. There's nothing else you you are not you are you don't like to risk a lot stay on it or stay on Bitcoin if you are like that old uh if not then uh just go and risk on L2s and so on and so forth. Okay. Uh so yeah to to shift away from the general like assuming that there is an inherent risk profile in code just because it's newer I I wouldn't necessarily agree. I mean yes there's when something is completely new sure but there are a lot of good teams who are putting good development effort and you know even a small team with very very senior engineers can build very very strong products and I've had the joy of auditing some of those where where I saw really really good quality really good workflows and where I felt stupid because I was auditing code for three months and couldn't find anything really severe you know um and Uh yeah, coming back to that I I think we should look towards like I I I really like some recent conversations I've had and I would love to have some in general more about fundamentals of analyzing blockchain. So not not talking about you know this is so great this is just you know sort of going back to TPS sort of going back to functionality of blockchain sort of going back to consensus because Bitcoin is Bitcoin Bitcoin has changed a little bit but Bitcoin has more or less stayed fundamentally the same over the last who knows how many years right and it's probably going to stay the same and Ethereum is also not really changing. It is more or less abandoned a lot of its major change road maps and it's staying the same. Instead of that, we have fragmentation through L2s and stuff like that. And I'm thinking more about fundamental analysis because there are more newer projects that are implementing interesting structures like okay DAGs for example like we're mostly not even talking about those although they do have interesting implications for security for consensus for stuff like that or gas. Why would we even have gas? It's just a concept that has stayed in everyone's minds. But recently we can see verifiable transaction ordering as a solution which provides some better options at the end of the day in terms of throughput etc or a possibility for a non-fragmented scalable blockchain because at the end of the day today we have just a lot of fragmentation. >> Uh your your comment about gas reminded me of a joke. I'm trying to liven up the room a bit. These guys are really pessimistic. Um, so why does Tesla not use Ethereum? >> Because they don't want to pay for gas. That's a that's my dad joke for today. Uh, Abba. Hey. Um, I'll keep my answer short, but before giving it, I want to have a bit of explanation. Two of my colleagues were talking about GU and Ret as a presumption. Those are the Go implementation and the rest of implementation of the node software that actually runs and validates Ethereum. The core underlining issue there that they mentioned was if an issue happens with the major client the network goes down. I just wanted to mention what actually get an eyes. Now my coming back to the question systemic risk besides the entire technical debacle and issues that can appear what I've been seeing as a possible I don't know if you can call it systemic risk but I'm fearing that retail will never actually come that adoption retail now adoption is financial is institutions are but not retail and crypto will exist blockchain technology will exist Once I'm thinking it as a risk as in you're losing the ability to actually retain normal users that's my we haven't managed it now and we won't man I'm not seeing it more layers how everyone make wants to make their own abstraction layer there's even an abstraction chain and over it another chain and we have evvm and you have another and another and another it's like that joke of having 10 ez and one someone wants to make the one for all makes the 11th. So that's my fear. >> Oh, you want to add something? No, >> I just want to say that. >> Uh maybe we don't need the return to come. Why do you need like >> that's a discussion for >> why does my mother needs to when she transfers money for example, why does she needs to know she's using blockchain? Maybe at the bank behind the scenes is using blockchain for transfer the mind. But why does my mother need as a retailer to know how to I mean I'm I'm speaking in the future not right now. I mean right >> but it's really not whether she knows that she's using blockchain. It is whether she is using blockchain and the fear is that they will not even use it. >> Yeah. But maybe I I think we uh you are speaking like a geek exactly like I I was like a few years back when I was thinking like no everyone should use it because oh how it it's the new thing. >> No dude I don't I'm a security researcher. I go back to the cave. you think you think like a you know like a like a person of technology you know what I mean versus uh people who actually they don't care about a lot of this stuff and maybe we should somehow push push towards mass adoption but without the retailer actually needing to learn what they use in some sort if it makes sense you know what I mean like knowing about the technology they just know that maybe it's more safer and we as a tech uh let's say evangelists we like to push that and make that a mass adoption somehow not uh by forcing them to come into our world. >> So >> yeah, we need to wrap up. Um we're almost >> um yeah, basically um thanks a lot to everyone here. We have one question I think or multiple questions from the audience. Oh man, >> I'm starting to be very happy that this was the last thing of the day because this one could have gone on for hours still and I know everybody wants dinner and sleep at one point. So we have a lot of questions. Let's start with the oldest one that actually came in almost 45 minutes ago now. Uh do you do pro bono audits for projects that find that you find valuable but cannot afford the bill? If you can buy me a drink and get me drunk, I will promo audit for you on the spot. I've done it before. >> I think Alex will love to get you drunk. >> I've also done that before in project. I think then I liked. Of course, I think we're all passionate about, you know, security and systems in general and thinking through a system and especially if there's something you like, some audits just go by like, you know, very fast because you just enjoy what you're doing. Think, you know, I would do it. >> It's all about the right project, right? >> Uh that's how I started in web three. I doing proono because I wanted to invest in products and I didn't want to get wrecked. So, I basically I did proono work so I know what to invest to. So, yeah. >> Yes. The answer is yes. >> So you have it. They would love to work for a beer. So the next one up is 38 minutes ago. Just to make sure that we go down the timeline. How much do LM make you more productive at what percentage? Let's start with ABA over here. >> It makes me more productive by providing clients to me because they're using LSM. The more VIP code, the better. Personally, I'm using it as limited as possible because I find it that it limits my abstractization abilities. I'm not using it for the report generation and I'm not using it for making descriptions. I'm actually thinking about it and all my juniors, I'm bashing them and whipping them to not use it. Seniors can use it because they have the ability to generate, but I'm not allowing anyone under me to do it. So don't 20%. I I wouldn't say I rely on it. It makes me not be a cool programmer that uses a ton of uh shortcuts, which I was doing before. Uh so it saves my carpel tunnel syndrome a little bit, which I have in both hands, right? Seniority marks. Uh, my favorite use of all time though was for report generation because sometimes I would just have a little rant and say that this client is so stupid. They're dumb They should fire themselves, kill themselves. Just just ranting all of that to an LLM and then being like, "And now write the nicest message possible." And it was emotional work. Metaphorically speaking, I have totally never said on a client call that someone is an idiot. I think there's a a ranging amount of uh opportunities where to use the LLM in a auditing process. Um but you know most probably I I personally use it for stuff that has to do with coding something really quick maybe a P maybe testing maybe testing suit. Um so as long as you have let's say let's you know make it abstract as possible. As long as you have a item that you have a couple examples of how the result you envision should look like, you might be able to automate, you know, automate that specific item through LLMs if especially if you're doing security research and uh yeah, auditing in general. >> I use LLM a lot. Uh I replace Google with Chad GPT search and perplexity. I've uh my terminal has an AI agent in it. Now I don't write bash and try to debug bash. I just let the AI agent to solve my bash mean errors for me. Um I like the LLM to correct my English because I have no time to write uh correct English for the report generation. uh but I keep LLM out of my uh critical thinking uh uh and uh yeah basically other critical work I keep LM out of it. >> Awesome. Uh should I answer as well? >> Uh please go ahead as short as possible. >> As short as possible I I you typically check the the rankings of LLMs and I use the one that is at the top >> because they change every month I guess. So basically depending on which one is more popular with the masses. >> No, not popular. They have like this rating that shows you which one is more intelligent. >> Well, there's still highly sophisticated algorithms. So yeah. So the next one up is we're almost down to 40 minutes ago. Actually, this is 39. Can Ethereum still claim to be secure the centralite if it's a layer 2 ecosystem grows in ways we cannot easily measure? standardize or secure collectivity. Let's start with you, Sebastian, on this one. This one is not even on the screen so far down, is it? >> You want you want to take it first or you want >> Go ahead, Sebastian. >> Yeah. So I think Ethereum as an L1 um let me just look at the question again but Ethereum as an L1 to me seems you know one of the most decentralized L1s out there because of the numbers of validators involved and so on. Of course you have node operators that are running thousands of nodes. uh but you know I think you need a level of centralization if you want to be able to you know reach mass adoption which requires some kind of regulation financial regulation you need centralization in some places uh it's I mean besides bit Bitcoin Ethereum is the second uh the most decentralized network out there Um it will always be decentralized. Uh there will always be L2 that are centralized. Uh and as I said previously, it's all about your risk like how risk averse you are. So yeah, there will always be uh I mean Ethereum will always be decentralized, but if you go to an L2 that is somehow centralized, you have to take the risks. Uh there is I I do not think it's it affects Ethereum as core. Uh it's just how you I mean how you like the risk. For example, the big the big the big guys out there, they don't go on L2s because they have a lot of money, you know, they stay on it. Uh but most of the users, they uh chase the the highest yields, which usually means an L2 that decentralized. It's all about the risks and how you manage your uh your uh your risks. I do agree with you guys uh with regards to the fact that uh obviously some L2s have a lot of advantages with the you know the the drawbacks that they're more centralized um but obviously as long as the the L2 that you're you know you may be using or you want to use um has specific features that are you know crazy in terms of uh you know maybe throughput or the cost the low cost or whatever like accessibility in terms of crosschain messaging and whatnot. Uh, and you you understand the risks as you as you as you said as well. Um, you should just choose whatever you think is uh is is safer and that's probably not necessarily where most liquidity is, but that's probably where, you know, you do have maybe you do a little bit of research on the team and you see that, hey, they're doing a complicated thing. uh they've done audits, you know, they've done contests and whatnot and uh they have a good posture in terms of uh their actual code uh and their actual security. Um even if it's, you know, even if they're more centralized than other protocols and have less liquidity in general. >> Um I think I'm going to give a very particular answer, but I'm just going to say one thing. Um I don't think decentralization is a key measure. I think decentralization is a means to an end and the means the end is censorship resistance. So just keep that in mind when looking at how we're measuring stuff because these L2s are very heterogeneous. They are very very different architectures. So in a way it is a form of sensor resistance. It is good that the L2 ecosystem is growing in bad ways or weird ways. But you know, okay, so I'm just going to answer the question. Yes, the simple the idea is I don't even get why you're putting it one to each other. ATM is ATM, L2 is L2. The L the L2 can be as centralized as possible. In TM is still decentralized. So the answer is yes. still claim the L2 ecosystem can be as opaque complicated as possible. Yes, because Ethereum is decentralized. If it's L2s are it's irrelevant. Water is wet even if you are on an island. >> We can keep on the conversation without many questions to go through. I like that you said yes and then went into a deep conversation about it. Anyways, love it. So, um we're gonna start off with you on the next question, Avi. I hope that's all right. What are your recommendations of securing the EVM crypto asset? The gold standard used to be Gnonosis safe, but they got wrecked like many others in the space. What do you use? >> Still use the best ones in the market. I mean the what do I use personally as someone in the field a lot of knowledge. I don't even have an anti virus because I'm paranoid on everything. I'm I should have not say that locally, but whatever the idea is what I use common not common sense security sense. What can people use still use them? And they had one in a million chance. What's your best option? Are you going to read the entire whatever? Are you going to decompile your own source code? Are you going to reverse your a normal user? Use whatever basic tools you can use and you will have one in a million hack. But remember that one in a million was a centralized exchange for a gazillion dollars. You are not the target. Just use them. I believe we all agree on this one and can go to next. >> Thank god because we still have two left. We're going to jump one because we already been over LLM. So we don't want to go into that. You you got just going to keep showing about it. So, how many researchers consider AI that can't be written in solid solidity? >> I mean, I I I do Rust. >> Do you want to explain it more? What do you mean? >> Oh, you're a you're a live human. Hello. >> Hi. >> So, there there's Solidity that compiles to AI and there's AI that you can write that can't be written in Solidity. >> Like bite code. >> Like like bite code. >> Oh, I I I've I analyze bite code. >> So sometimes when you're doing like inputs and you're you're doing variations, this maybe this is covered in fuzzing commonly, but >> I I I've had a task, let's say last week where I was literally analyzing bite code, just reading straight absolutely bite code. So if you have something in particular, I'd actually love to look at it. >> Are you auditing this as an input? Is that a But are you checking normal contracts using Abby as an input? >> Oh, not not necessarily. No, mostly focus on the code auditing. When I do bite code, it's when I need to. It's slower. A lot slower. >> You got your answer? Yes. >> I got one answer. >> Well, we still have the other one coming up. Don't worry. >> No, no. I mean, there's other people. >> Yeah. >> Just a quick answer. The question is very oddly formulated. The ABI is just the interface itself. Whatever the interface can be declared, what's onchain that matters. The entire bite code on chain regardless of the interface is the one you're actually using. And if the question is how you can just analyze a raw manually written like in Huff or whatever exotic language bite code you can I personally just decompiled it and looked at it and see the bite code. There are Heimdal and other good decompilers. the API itself it's regardless you can create an invalid API that doesn't compile and there isn't any contact that matches to it it's irrelevant what actually exists matters and if you can't map it to an API irrelevant you have the contact there you have the code you can see it >> no I don't do >> yeah it's I think it's a very specific kind of uh kind of research area >> you understand the mental model behind the the question like what do you exactly mean by >> so I'll use buffer overflow as an example if you're only using the logic of the memory addresses that's present inside CC code then you'll never find a buffer overflow however you can send AI you know you can send bite code to execute that wasn't valid solidity so you would never find the parallel you know or the equivalent of a buffer overflow. If you're only auditing solidity and you're not auditing what how inputs are handled and checked and type safe and you're just relying upon the inputs being valid. So it's it's kind of a fuzzing question, right? It's I mean it's not uh there isn't much you can do here to be honest in the in the crypto here because uh the the type safe checking and there is a particular thing you can do attack you can do if the interface allows you but other than that I don't think you can you can actually exploit it too much in uh from my point of Do you have a particular piece of code? >> We can make it. >> Let's talk later. >> So my understanding in is that you basically want to do some kind of dynamic testing and you're asking if auditors typically do like a lot of fuzzing and dynamic >> any kind of like something beyond solidity because there's things you can do not in solidity. >> Yeah. Uh yeah I think like everyone does that everyone does I mean typically you know companies do dynamic testing like fuzzing or something in that direction. Yeah, >> we throw code at B byte code sometimes and see how how it responds because you just you know if you look uh down down there you just just throw a call to the blockchain and see what it responds to right and you you can analyze based on that and do some fuzzing based on that uh bite code if I may say. So yeah you do that we do that but it only if client request because usually we audit the code before it's deployed for example and that's nothing I mean you cannot do anything because uh there is still long wait till it reaches uh let's say the deployed code you know what I mean uh we are hired most of the time to analyze solidity uh there is uh there are projects who let us analyze I don't know u all types of like uh uh maybe implementations of I know low-level code and so on and so forth. But no, not not something if I only if I go like exploratory and I want to just crack things out on chain. I I do that. >> I can almost hear like this is going to go on for hours. So I feel like this is a conversation over dinner. You should ask them all out. >> It might be they said they said they'll give a free order for a beer. So the last one also from from Victor over here. Has anyone audited CK circuit as attack vector? >> How do you mean >> what do you mean by >> sorry? So there's ZK uh circuits that have valid inputs but not every input is valid but can still be proven. There's a series of papers on this. There's like six papers on breaking ZK circuits. I'm just wondering has anybody here audited this the actual ZK circuits or is it just >> so I was part of the hack and Binance proof of reserves audit and some other similar like ZK audits. There are some interesting bugs mostly in the cryptographic area but you know you need specific code to to find those bugs. So we'll talk later. Okay. I think that's a good thing because everybody's getting hungry, everybody's getting anxious. Like this conversation can go on for hours. I can hear they won't let up. So, I do want to say thank you for an amazing panel. Before I throw the mic, please everybody give a hand to the amazing panel. [Applause] And now, let's get a beer. Let's go. [Music]