Future of Smart Contract Security: Neither Smart Nor Secure?

Transcript

All right, welcome back. Hope you guys had a good lunch and uh we'll try our best to keep uh you from falling asleep. So, uh we'll start with a quick round of introductions. Um I'm Rajie. I'm a security researcher and the founder of Securium. And we'll go around the panelists. We have a fantastic set of panelists here. >> Hi, I'm Seth. My name I'm the CEO of Churra. joined just 4 months ago. New to the space but learning quite a lot and pleasure to be here.

>> Hey, I'm Hari. I'm one of the founders and CEO of uh Spear Argentina. I've been in the space for a while building uh the solidity language at the Ethereum Foundation before this and we run a security company now. >> Hey everyone, my name is Medi, co-founder and director of Sigma Prime. Uh we're a blockchain security and research firm, also Ethereum core developers. Uh I also have the pleasure to serve as a steward uh of the trillion dollar security initiative for the Ethereum Foundation. >> Hi, my name is Benjamin Samuels. I'm the director of engineering at Trail of Bits. Uh I've been in the security space coming up on 10 years and uh Trail Bits, we're really heavy on tooling development, developing new techniques for finding bugs and building more secure software.

>> Hi everyone, I'm Alice. I am a protocol engineer at Uniswap. been there about 4 and a half years now uh building various fun protocols um so I'm hoping to bring a slightly different perspective >> critical perspective so as you can imagine you know the security community is can be a bit of a bit of an echo chamber uh we all seem to be agreeing and not disagreeing much so we really uh we're just talking and we want Alice to keep keep us all honest here Right. So cool. Uh so let's let's get started. I mean there are a whole bunch of uh I think burning questions the community has and a lot of it has been discussed

as well. But to start off with some level setting just want to go around the panelists and uh essentially give your thoughts on what does smart contract security mean to you because you know when I talk to people I see it means slightly different to you know depending on who you are what you're doing. So anyone can start and others can chime in. >> Sure. Uh from my point of view I feel like it's the smart contract behaving as it was designed to behave. I think you can you can design a smart contract and build it and it might behave in a different way and maybe the funds are still secure but if it's not behaving 100% as you designed every function should behave

exactly how you designed it to that to me is security. And that's an interesting thing from the point of view of audits of you might have you need the auditors to fully understand what the what the intention was with the smart contract to be able to actually tell you whether whether there's a bug. Even if the funds are all secure, a bug is actually it not behaving as it was intended to. >> Uh smart contract security to me is uh about building high assurance software. This is something you see in aerospace.

This is something you see in medicine. Uh we've built high assurance software before. We just need to take those lessons and bring them to the smart contract security space and it's like for a long time academics would de develop these techniques for verifying code but it would only work for very small programs. That would always be the caveat. They've got these cool techniques for verifying programs but only these very small ones. And uh we finally have some very small programs that require uh extreme verification and I find that really exciting.

>> Um I think a lot of people associate smart contract security with smart contract audits. Um I'd like to think that we we can do better. Uh the way I try to think about it is um secure ideation, secure design, secure development, um security assessments obviously, but also continuous monitoring and secure um I guess incident response as well. Um so I think it's important to recognize that uh we have to address the entire stack and not just uh look at security as a as a checkpoint when it comes to smart contracts.

To me, I want to really like simplify this because I think smart contract security can be very broad. And I like to think about smart contracts as a way to program money. And security in that context is to make sure that this programmable money does not lead to a programmable disaster. And 95% of the work that we all have to do is to make sure that the users of these protocols are not losing money and a lot of things can be traced back into this one idea. Even even like centralization risk, it can be traced back to like a potential for users to lose money even though it's much broader than that. I

think that's one thing to capture that really um gets to the point. I would tend to agree with Alice. I think smart contract security is about making sure that the contract does what was intended and doesn't do what is not intended. And usually it's as simple as that. >> Cool. Yeah. U interesting variations, but I think they're all aligned. So uh don't hear much of a disagreement uh yet. So uh we thought we'll do this a bit differently. Instead of sort of asking questions, uh what what I plan to do for the rest of this panel is to really pose uh some statements, some slightly you know edgy, provocative just to keep it interesting and uh then have

the panelists chime in with uh you know for against give their views and maybe we'll have one panelist sort of uh kick it off and then others can chime in either in agreement and disagreement. And we want to see a bit of disagreement as well you know uh at least between the protocol and the auditors. So there are hopefully enough uh statements that can get this uh ex you know interesting. So the first one I mean this I think has been talked about a bit um and we I mean it really um felt the security community at least and all the protocols felt this quite a bit. This is about the balancer exploit right. So the point is balancer exploit

could have been prevented anyone can [laughter] you know I'll jump in the I would say the answer to that is in specific sure you could take any specific vulnerability and argue it could have been prevented in general no there's absolutely nothing that I have seen in my time in this space that could prevent every possible smart contract hack and that's a flaw in the way we build, but also in the flaw in the way the blockchain itself is architected. And that's fine. It's the world we live in. But it's not by any means a solved problem. It's in fact a terribly solved problem. And it limits the entire industry because you can't truly say I can guarantee that my interaction with

any particular contract is going to be safe. And when I talk to our customers about how they want to grow their businesses, at the end of the day, you cannot get to large amounts of institutional investors and people beyond the world of crypto, if there's even a tiny chance that all of their money is going to be stolen. >> From my point of view, I don't want to give a simple yes or no answer um because that's not fair to everyone in involved in that incident. The reality is that balancer v2 was built at a time where these kind of rounding issues were not part of the threat model. Um you know if you look at the history of like programming you can see that rounding issues exist in other industries as well. There are fail rocket launches

because like rounding errors um uh added up to lead to like rockets uh deviating from the path. So these are very similar issues um as in a lot of other industries. It's just that in that era of security or writing software these kind of bugs were not part of the third model like the builders were not thinking about it the people uh reviewing uh the software were not really thinking about it and I would say after the kyber swap exploit I think that's when people started really paying attention to these type of rounding issues and I would say balance of v2 in a modernday context potentially this bug could have prevented but at that time

it's very unfortunate. it wasn't part of anyone's uh mind and when I was part of solidarity uh around this time I would talk to a lot of builders and I would literally ask the question like hey what do you think about rounding issues and almost all the answers I got was I don't care about it um and I come from a uh before before building solidarity I used to build linear algebra solvers and this is something that you have to worry about because if you run the same computation hundreds of thousands of time these floatingoint errors like add up and that leads to very edgy behavior.

Uh but this just wasn't part of uh this wasn't top of mind for anyone uh in that era. >> Um I think hindsight is cheap. Um I think we um have to find better ways to incentivize researchers to look at protocols that have been live for a long time. Um, and the unfortunate incident was a grim reminder that um, if a protocol hasn't been popped in four years, it doesn't mean it's going to it's not going to get popped tomorrow. Um, how do we come up with a incentive structure to make sure that people keep looking at things? Uh, even if they've, you know, attracted a lot of TVL and have been used by a bunch of users. And

it's not an easy answer. I don't think we've been trying to come up with one over the past few weeks. Um, it's it's really tricky. really really tricky. Um yeah, so with with hindsight you can always say something is preventable. Uh I think what's really unique about balancer and that balancer hack is we were cognizant that there were rounding issues existing in protocols back then. uh we hadn't really seen any big hacks from it and if you even go and look at the reports there might be like a couple of rounding issues in there but they weren't necessarily exploitable back then but as time has gone on the industry like that the attackers have gotten

better the code is more complex and now we know with hindsight you know this is actually a really really serious issue and you see that show up in balancers engineering today so like if you look at V3 they're very very specific about what gets rounded and where it gets rounded Uh, so it's really a problem of how do you discover your unknown unknowns because back then we knew there was a rounding issue here, but we didn't necessarily think that they would ever become something that people would use to exploit. It was just something like maybe you could get one way, but then you lose your money on the gas. And I think as the industry matures, more of these unknown unknowns are going to be revealed as we get a better idea of how to build smart contracts. And like the

end goal should be that all of these hacks are categorically preventable. Otherwise, there's no point of building smart contracts. I'm not sure I have much more to add. You guys have covered a lot. Um yeah I I l I agree with Hari a lot that nowadays audits I I've seen it time and time again in audits that there's a lot of a mathematical focus to for example in unis swap v4 all of our audits had a huge mathematical focus multiple things came up about discussions of rounding and if you have a constant in the code you have to choose which way you've rounded it slightly but that being said uh what Seth said like that that was one

issue and yes, balancer unfortunately got hacked for that but there's there's so many protocols out there and if it wasn't going to be this issue with balancer it's going to be a different issue with another protocol and so I do think it's important for us to learn from these these individual hacks but also try to think of broader solutions than just the individual solutions for each hack that happens. >> Makes sense. Great points. So maybe uh for the next one right for the next point we'll start the other way around. U so this is I believe the biggest crypto exploit you're talking about by bit here. So the point is by bit like exploits will happen again.

>> Yeah. I think unfortunately in the space maybe we're improving but we're still a long way from where we need to be. Everyone throws so much money at smart contract audits and competitions and bug bounties. And I'm sure you've all seen UniS swap has a million of all of those, but uh that's not the only part of the stack that needs to be secured. The entire stack needs to be secure. And it's unfortunate that I would say there is still not enough focus on making sure that the rest of the stack is secure, the private keys, the interfaces, everything. um how many companies are actually getting their interfaces audited, how many companies are getting their npm deploy scripts audited, um all

of that. And I think that again it's something that we can improve and we can try and prevent them. But I think for now we are a long way from where we should be probably. >> Uh yeah, I agree with that as well. um private is going to happen again and a big reason why it happened in the first place again is because there's this expectation with smart contract protocols that you get audited any of the users that's the first thing they ask has this been audited has this been audited uh but they don't necessarily ask the same questions at their exchange they don't ask about the key pro you know that how they store their keys what is your life cycle management like a user doesn't even know what questions to ask that's why when they ask protocols they're like have you been audited

And uh the truth is there needs to be a little bit more on the uh operational side. I I think that smart contracts could have had it much worse off security-wise if there wasn't this really big culture of we have to get an audit and then we have to publish a report. Because if you look at like web application security or web 2 security, it's very very uncommon for any client to publish a report. that's that's really only a blockchain thing and it's really only a smart contract thing. And I think a lot of organizations that are managing cryptocurrency have been able to like kind of slide under the radar and not have as mature security as they should because there isn't this expectation that they publish their

audit reports or that they even get audited in the first place. Yeah, if you know me, you probably know that I've been saying for years now that we should be focusing on the entire stack. As Alice uh just pointed out, um I do think that the bybit incident or a similar incident will happen again. Um I still find it ludicrous that we're all using the same UI to manage our multiigs. Um, and I've tried myself to use the eternal safe UI. So, there's a fork of the safe UI that you can theoretically run locally uh with your own nodes. Um, and that thing is buggy

as hell. Uh, spend a whole day uh trying to fix JavaScript errors. Um so when it comes to supply chain attacks um if we don't provide better ways for customers, users, institutions to interact with uh these multisigs, it's just bound to happen again. Um these these supply chain attacks are very difficult to detect. Um and they're usually carried out by very sophisticated threat actors. Um so you know what uh these people have said just before me um is very very important. I'd like to think that the industry has unfortunately thanks to the bybit hack uh slowly started to realize this. So we're starting to get a lot of

these requests from our customers. Um people are realizing that they have to secure their entire stack, their UI, their nodes, their RPCs as well as their smart contracts. Uh but there's still a very very long way to go. So the answer to the question will bible like hacks continue I think it's yes and for two simple reasons. One the complexity of software is going up by a lot every single week every single month. Um, number two, the amount of money at risk on chain is going up because the amount of money is going up and there are really malicious threat actors sometimes sponsored by governments that will find a way to get

into the systems. So, I personally do not think these hacks are preventable just because when you have a complex system and when you have actors that are incentivized by the government, this is uh not easy to prevent. There's like a lot of different ways to get into systems and potentially the real preventable ways to like you know use uh like have countries figure this out where you know there are real threat actors here like how do we you know how does certain governments figure out how to minimize uh these whether with trade or whether with threats or with war so that that is that is the way to minimize these I don't

think there is a security solution to prevent these kind of hacks. Um, as long as the software complexity and money at risk is going up going last, I would definitely say it will happen again. And I would say that if you look at the analogy to other industries, you know, there was a time when nobody knew what a ransomware gang was. And now it's a very viable business for people who find that to be a great way to make a living. And so by bid was maybe government sponsored, but the gang activity has yet to come and it will come and they will find ways no matter what you do to get around it. And so it's always that game of escalation. The more money there is, the more it's good business for someone to try to take it and it will absolutely happen again. All

that you can do is try to get of it ahead of it now. And I think that that's probably something that the industry could would be wise to start thinking about. Yeah. So it looks like the answer is a unanimous yes that it will happen again. I mean note that these are not you know we don't nobody here really or in this conference wants this to happen. We hate making predictions but unfortunately the state of affairs is such that you know a lot of these things happen. For context, the previous DSS we had a similar panel where the question was, will we see a billion dollar hack in 2025 and we have had at least one that we

know of. Right. So, >> all right. So, if you don't mind, >> I think it's worth reminding everyone that the vast majority of the hacks that happened over the past 24 months have nothing to do with smart contract bugs. >> Yeah. Exactly. Yeah. So um so yeah I mean it's it's a full stack so a lot of you'll see a lot of uh repeating themes uh which is really what security is about. Um so maybe switching gears right um there's this notion that security matters I mean we all here it we think it matters we know it matters uh but then you go around in the different events at dev connect and then there are questions like well we are trying to

decentralize everything but do users really care right does it really matter I mean are we doing the right thing or is it just all about you know yolo fomo and any other acronym Right. So I I guess the next question maybe uh goes to Alice is uh not a question but a statement. Protocol users really care about security. >> Maybe in the context of unis swap. Sorry. >> I would say yes. I think not all of them necessarily are are consciously caring. Like when you open your phone and you're using an app, are you are you consciously caring if whether there's a bug in that app?

You're using your like maybe a lot of us are security-minded. So maybe in this room there's a disproportionate number of people who yes are thinking about those things, but the dream with when you're building an app is that people aren't thinking about the the scary things that could happen in the background. So maybe they're not actively thinking that they care about security, but would they care if the protocol got hacked and their money was at risk? Yeah, I think I think there's a 100% answer that yes. So maybe some people actively care and some people don't know that they care, but subconsciously they obviously don't want to lose their money. Um, >> yeah.

>> Anyone else? I want to add one thing where we are seeing in crypto today there's a lot of large entities that are putting capital in and some of those large entities are regulator players often with fiducial responsibility where if they lose this money you know they will they could potentially go to jail and these people definitely care about things like that they they care about protocols being secure they look into details I'm very surprised sometimes they read like an entire audit report even though they may not have a technical background around before they deploy a large amount of capital into uh D5 or crypto. So I I do think a big like from a capital point of view the bigger you get the more you care. Uh maybe if

you have small amount of money if you want to be a detent maybe they don't care. >> I would say the only people who don't care are the people who don't understand what's going to happen. Once you know that you could lose all your money they care. >> Makes sense. Yeah. I mean great point. So maybe the D5 DENTs don't care. They're just yoloing if small amounts of money. Retail may or may not care, but they definitely will care once, you know, things go wrong. But once, you know, as and when we have more institutional players come in, more regulated entities and people who are putting in big chunks of capital, right?

They absolutely will care about everything that can go wrong before it goes wrong, right? Cool. Uh so the next one is um maybe Ben you can uh take this AI powered audit tooling will be table stakes I mean we we I think we've seen a whole bunch of AI related stuff within DSS within dev connect um but in I mean it's going to be table stakes is it going to be a differentiator what are your thoughts >> so yes it's going to be table stakes uh I think ultimately what AI Id driven auditing and AI driven development are going to do is they're going to drive the incremental cost of developing

software not to zero but close to zero. And what that means for the security industry is that there's probably going to be a lot more contracts out there. However, uh the cost of you being able you auditing a contract also is going to have to converge to zero as well. Um it it it it's going to be very very ubiquitous. It's going to be everywhere. there's also going to be ways to use it incorrectly and uh I'm really looking forward to seeing how things develop over the next year. Can >> can I add I I want to say that it's going to be more than table stakes. It's going to define the next era of security but at the same time I think all of you

are correct to be skeptical about all those claims today. This is one of those things that you have to see to believe. uh there's nothing I can say here today or anyone can say here today that will make people believe that this is going to be uh important. Um you have to see to believe it and I've had this moment where I went down this rabbit hole and some of the things that I saw was very humbling. I think there there are many things that you imagine is not possible and suddenly they are possible and I'm hoping that more people are able to see that and once it once you see it you you start like believing it. uh everything else. Um I think people are right to be skeptical.

>> Yeah. Building on that, I I it makes sense that people are skeptical because we've had this thing where we've revisited AI like every eight months for the past couple of years. Uh like you know, looking at like the original codecs GPT3 like it was it was a very sad state of affairs. And if that was your first exposure to AI and you haven't looked at it since then, you'll probably be shocked to see what the latest models can do. But I mean, you have to come around to it. That's kind of the trick. >> If I may add to that, last year uh in Bangkok, we had a similar panel and Jocelyn uh made the prediction that a lot of uh software will be uh built by AI within like 12 months or 24 months.

And I was sitting right next to him. I was like, there's no way, man. There's absolutely no way. I don't believe that. Um, I take that back completely. Joselyn was right. I was wrong. Um, and the reason I can say that is because looking at our uh pipeline, the stuff that's coming out of our clients, some of our, you know, best clients, most mature clients is is is pretty crazy. They're pumping out code left, right, and center. And um, back to your point, uh, we now have a lot more uh, work to do. So, I think I agree with you. uh the cost to uh delivering code or building code is going down. We have to find a way to also uh basically reduce the cost of of reviewing these uh these things.

But good call Jocelyn. >> Jocelyn has usually been right. I mean the previous panel Jocelyn was the one who said that there will be u you know a billion dollar hack not due to smart contract. So yeah shout out to Joselyn. Um good. So um I I think we're covering a whole bunch of topics not necessarily in the right order but that's good. So we know I think anyone here will disagree that there will be bugs right due to AI wipe coding due to humans due to a combination there will be vulnerabilities introduced some of them will get exploited right so

thinking so as as as we said smart contract security is not just about audits right it's the entire life cycle so let's move ahead right let's talk about okay when things go wrong what do we do Right? It's about one knowing that there something has gone wrong, detection and response. Right? And we had a previous panel from Mud and others about water rooms. So that brings me to detection and response, right? So the point maybe Mahi you can take this is protocols are still not taking detection and response seriously and because of that they're scrambling for help towards initiatives such as C911.

Yeah, this is probably the least mature part of the stack I think. Uh if you look at it like from you know security design all the way to incident response through monitoring uh this is where I think we have the most work ahead of us. Um when hits the fan um it's it's it's pretty good to have battle tested um work plans and incident response plans. Um even some of our most mature clients don't have that. Um, and what tends to happen, uh, when incidents happen, thank God for the Security Alliance and, uh, Sealed 911, specifically Pascal and his team are doing God's work. Um, we raised tickets. There's been over, I think,

1,200 or,300 tickets raised uh, since its inception. Uh, they've been able to save literally over $und00 million worth of assets. Um, and these guys are, you know, volunteers. Seal is a nonprofit. Um, if you're building um, DeFi protocols, I would strongly encourage you to consider donating to the Security Alliance. Um, but you're right. Um, protocols don't really take that seriously because, uh, the thinking is, well, if I'm doing everything right, this should not happen to me. So, I'm going to invest uh, my time, my money, my effort uh, towards the left side of the development life cycle or the security life cycle. Um unfortunately I

think we should be looking at it as if um it's not about if but when things will go south. Um and you should really have proper procedures in place. Um rehearse them as well. Uh again, security alliance uh has recently launched an initiative called uh C certifications where you can you know go through your operational security um and you know essentially self-certify yourself against what we believe are the best um practices in in that space. Um Cal 911 is doing great work but I think it's very important for protocols to also own that part of the stack.

I would just >> if you don't know what Seal Alliance is, by the way, you should look it up. Like just just in case anyone in this room doesn't know what it is. It's it's very important. >> Quick show of hands. Have you heard of the security alliance? >> Okay. Okay. Just want to make sure. >> We're in a pretty biased room though here. >> That's true. That's true. >> I'd say from it's interesting how how strongly you stress this because we at UniS swap have done unis swap labs have done quite a lot to try to prepare for this. We have also had the discussion of is it not if but when we put so much code out there we've we put so much effort into security probably more than we do into the actual coding of the contracts but like we we're only humans building the

contracts um and yes we have AIS and formal verification to help us secure it but um there's a lot of work to do there and we have worked with uh the it's called the seal war room we've done that we've We've done as much as we feel we can to prepare. We've simulated something happening. But I still think that if that day were to come, touchwood, it doesn't. Uh we would still want those people to jump in and help because there is nothing that can prepare you in the same way as having done it before. And us simulating it, simulating rescuing money, simulating everything down to what tweets we would

put out and when. And along the way, we got a report back from Seal saying which things we did well, which things we didn't different. We've we feel like we've prepared a lot, but the second something happened, I feel like I would be on the on the phone to SEL 911 being like, "Come help please." >> As you should, as you should. Um, but I think again like UniS swap is probably bestin-class in getting getting stuff sorted well in advance and thinking well in advance. Uh my point was just not relying exclusively on >> you want you want to feel like the people in your room are at least >> as prepared as they can be for something even if we're then going to need help along the way from people who've done it before.

>> I would just add that I think it's deceptively easy to just put a smart contract out there and hope for the best. You can just pay a little money and push a button and it's out there. But it has to be a full organizational design task to prepare for this. And there's a lot to learn from other industries. Other industries have spent a lot of time trying to figure out how to handle incidents and what to do about it. And this industry is a little bit behind. >> I I would add on onto that I think in the traditional banking world there is a lot of processes around um instant response and it's not just a nice to have for a lot of them that is a requirement. There are very strict SLAs on uptime and how you handle incidents,

how you talk about it, you know, especially for the the regulator industries and with a lot of regulated capital and players coming into the market, this is going to become more important and sort of the open secret is that almost every protocol has small incidents that happen to them. they don't often like become public but almost everyone has like small incidents that happen to them and you need to handle them and people are not quite there today but we will I think this is going to become an expectation from a lot of the new um investors a lot of the new capital allocators which they would say hey I'm going to allocate this amount of money into your protocol but

do you have SLAs's do you have liability can you take liability like things like this will emerge in the next um few few months, few years. >> Interesting. So, just doing a quick time check. Um so, maybe we'll get to some of the more tricky or uh you know, put you >> I I just thought of a tricky question. I should have told you about ahead of time, but I literally just thought of it, but this is probably going to be controversial, but kind of a question for you guys. uh everyone um do you think it's possible for there to be a future where we can develop smart contracts, not get an audit and still have a secure system you can deploy.

>> And when you say audit, you mean an external third >> an external audit. So there's no external audit. You just have your secure, you build a protocol, you build the tests, uh you do all the planning, and you deploy it with no audit. Do you think there's a future where you could do that? Maybe with AGI. >> Yes, but yes, but there has to be some infrastructural change to make that happen. I mean, in other industries, you can deploy critical code without an external auditor. In fact, the term auditor is not usually used for a guy who comes and looks at your code when you're building a large system. It's for the guy who's looking at your finances.

So, it can be done, but that's because there are layers of protection in front of every piece of code you write. here codes exposed on the blockchain and anybody can interact with it. So it's entirely different thing but if we can develop those other layers of protection then sure but there has to be some significant architectural shift for that to happen and yeah my answer was going to be I don't think it has to be a future I think that was the past I think that's still the reality in many parts of you know the spaces we just don't hear about these protocols maybe getting hacked they're just deploying without audits I mean who knows what is an audit right we can't even really agree and uh I mean And if it is a stamp of approval, then maybe you know things are happening that

it's already there. So >> damn, I was hoping someone would disagree. [laughter] It >> it's very working in security is very counterintuitive because technically I feel like our job is to make it so that our clients don't need to get audits anymore. And there's definitely like a couple clients where like I'll audit their code and like very consistently there's no findings. I can't even think of like anformational finding to nitpick about. And uh I'm very interested in seeing if we can standardize that and make it so it's something that basically anyone could do at any skill level. Um I I was hoping someone would disagree.

>> We could we could get to provably correct correct code and so on, right? So there could be things that can be done, things that you know maybe is not possible for depending on what the protocol is. So great question. So yeah, so in in the spirit of uh increasing the intensity of questions and making it spicier and maybe waking some people up. So maybe the next question is for hurry. So auditing uh has sort of evolved in the last I don't know uh at least I mean we talking about web 3 crypto here right in the last five well 10 years um it used to be private reviews and then collaborative audits independent researchers and then contests came about right u so that was few years ago contests were everything and now I don't

know how it is maybe people are uh thinking twice so the question the point is audit contests are always going to be part of the security feature. Yes, no, maybe. >> So, I I I wrote this thing a couple weeks ago where I said like competitions as we know it won't exist in 12 months. And looks like a lot of people paid attention to it. I I'm getting the same question over and over again. So what I mean by that is if you if you look at the history of security competitions they emerged at a time where it was solving very different problems and the the first problem it solved was there wasn't enough security researchers like 5 years ago there just there just wasn't

enough researchers which led to a lot of bottlenecks in customers who has to launch uh code to production and get some secure review. So that was the original intention of these security competitions like put your code out there, put some money on the line and people that find bugs get rewarded. That was as simple as that. And if you look at the data of the number of submissions and the number of valid submissions, unfortunately the number of valid submissions is like going to zero today.

Um if you look at some of the early competitions like 60% of submissions were like valid like some in you know the first few competitions today one in one in like um 100 findings are potentially valid and as a platform you have to ask yourself like what are you are you a security company or are you a company that is you know preventing spam. So I think that is the that is the question that people have to ask and this problem got got like went on steroids because of LLMs as well because a lot of the submissions people get in in any

platform and not not just like you know a single platform in in web 2 too a lot of the submissions people get are like you know AI generator slop and it's become very easy for people to generate things that sound real but is not real and you have to ask yourself there are ways to solve this. You can use you know also AI to fix the problem but then you have to ask the question are you really utilizing your tokens appropriately like do you want to spend all your tokens invalidating 99 findings when that could be like moved to finding bugs. So I think all these are driving to this future where I think this may not exist in the

current shape or form in 12 months and historically uh competition solved a very different problem and I think we have we have more we have a lot of researchers today that you know you can work with directly. Cool. Interesting points. We could go along, but uh we're running out of time. So, um in the spirit of the title of the panel, maybe in, you know, each one of you, if there's one thing that you would really want to see to make sure that the future of smart contract security is really secure and that we're being smart about it, what would that be? Just like two seconds each. For me, it would be improvements from the developers of contracts earlier on in their

development process. There's uh right from the beginning, before you even sit down and write a line of code, you need to start mapping out what attack vectors could be of the system and designing it secure before you've written a single line of code. Not relying on finding the bugs further down the line. >> Uh testing, testing, testing, testing. There needs to be much much much better ways of measuring test coverage. Percentage of line or branches covered is not adequate and is terrible. Uh if we have much much better ways of measuring test coverage, whether that's fuzzing, formal verification, whatever, uh I think we'll be in a much better position.

>> Testing, testing, testing, testing as well. Uh that's Ben Ben is totally right. uh threat modeling and one thing maybe for mature protocol consider internalizing your security function or at least at least having a dedicated security engineer who is responsible for the security posture of your protocol. >> So I I want to live in a future where people can do less and get more and I want people to be able to write code and I don't know magically have correct software and there should be more automations. Um, and that's that's uh that's what I want to see. I want people to do even less testing than they are doing today and still write safer code.

>> Maybe in contrast, I would say this is a safety critical system and it needs to be built like one. >> Cool. All great points. We're out of time. So, thanks to all the panelists and uh we'll um I don't know if we have time for uh questions. Do we? >> No. All right. Well, they're all going to be here after come grab us and ask questions if if you have any. >> Yeah. Thank you.