New Ethereum talks, every Monday. The week's conference uploads by event, in your inbox.

Loading player…

Demystifying Smart Contract Security: Facts & Fallacies | Devcon SEA

DevconTue, Oct 7, 2025, 12:00 AM

Smart contract security is of critical importance as the Ethereum ecosystem rapidly expands across different infrastructures & applications. However, there exist serious gaps and misconceptions about security as it relates to smart contract design, development, validation, tooling, offchain components, audits, bug bounties, monitoring & incident response. This panel brings together six recognized researchers within the Ethereum security ecosystem to help demystify facts from fallacies. Speaker(s): Josselin Feist, 0xRajeev, Matthias Egli, Mehdi Zerouali, Mooly Sagiv, Harikrishnan Mulackal Skill level: Intermediate Track: Security Keywords: Security, Best Practices, Hacks, Formal Verification, Auditing, Bounties, smart, contracts Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum, https://warpcast.com/devcon Learn more about devcon: https://www.devcon.org/ Learn more about ethereum: https://ethereum.org/ Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more. Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. Devcon SEA was held in Bangkok, Thailand on Nov 12 - Nov 15, 2024. Devcon is organized and presented by the Ethereum Foundation. To find out more, please visit https://ethereum.foundation/

Transcript

all right GM last day last session uh good to see you all so this is uh um hopefully this will be worth your time we will kick off with you know a quick round of introductions um I I'll I'll start so I'm I'm Rajiv I'm the founder of secum um secum started about 3 years ago with the mission to scale ethereum security and we have been doing it in a couple of ways with uh the boot camp the online boot camp uh with which we have onboarded hopefully hundreds of security researchers into the space in in a variety of ways um and also we are the trustex event which is um a dedicated event to ethereum security all layers of the stack so that's secum and I'm also a security researcher been doing security research All My Life um web three ethereum security for the last 6 to8 years um and most recently as a lead security researcher with the spearit Cantina so that's me and we'll pass it on to Harry hi I just want to add Rajiv is very humble here he said hundreds of researchers it's probably thousands um so my name is Harry I'm one of the founders and the CEO of uh speit and cantina we are an End security platform we work with uh companies like unisab coinbase optimism you name it uh I used to build the solar decomod at the the foundation before and our funding team has a lot of experience building software that where there is like tolerance to mistakes hey I'm J I'm the engineering director of the blockchain team at trof bits U we are a company where we specialize in high hand security technology from blockchain to application security or cryptography uh we spend also a lot of time building tools you might know slitter Medusa or Aina which are smart contract bug finders hello yeah I'm Matias I'm a managing partner and co-founder at train security so uh we focus on like complex audits of defi projects and um many many others uh around that uh I'm very happy also to be here this is uh with with the fellow ones uh because the ethereum ecosystem of all the time has been great on like joining people and working together um on our end we have been doing this also for quite some time together with ethereum foundation with some Buck reports you might find us there on the ethereum leaderboard hey everyone my name is Medi co-founder and director of Sigma Prime we are a blockchain security and research firm have been operating in the space since 2016 turned eight years old last week um we provide security Assessment Services to web 3 projects exclusively do a lot of smart contract Security reviews but we're also very comfortable diving deeper into the stack doing a lot of L1 and L2 security assessments that's kind of half of what we do uh we also do a bunch of research and uh one project that I'm sure um speaks to at least some of you here is Lighthouse Lighthouse is an ethereum consensus client it's currently responsible for about a third of the ethereum main net very thrilled to be here amongst these esteemed professionals and can't wait can't wait to get uh into the wi thank you I'm miv I'm academic in computer science in the area of static program analysis I contributed algorithms which are now integrated into Microsoft device driver verification I am also so co-founder of defi security Summit and Sora Sor will be 6 years old on Monday we have developed this during this time three things we have this language called CVL which is extension of solidity for formally specifying code we have used it to actually write formal specification for many of the D5 many important and also we have uh developed sophisticated static analysis that convert the program into mathematical formula all of this will be uh open source actually soon I'm really really excited to be here among distinguished colleague actually I have uh was not when I started this domain I had zero knowledge in security and and and smart contract and thank you all for teaching me I've learned a lot and I'm looking forward to learn more amazing so welcome welcome everyone um so the title of the panel as you see is really broad right it's demystifying smart contract security uh facts and fallacies so we thought we'll keep it I mean a lot of the panel discussions um get sort of repetitive in the format so we thought we'll keep this uh a bit interesting maybe a different style so what we're going to do is um I'm going to pose one statement very sort of a short statement with maybe a brief context to each of the panelists and they're going to react to it by saying okay do they believe is it's a fact or a fallacy and they're going to justify it with their opinions and then we'll have any of the other panelists um either rebut that with their opinions or agree to that right so we want to keep things interesting I mean smart contract security there are lot of these things as you see which are uh um um not black or white right so they're sort of in in the gray area so we hope to touch upon those topics but we would also like to leave a good 10 minutes in at the end of the panel for the audience it won't be more of a Q&A but we would request the audience I think to scan that QR code maybe now or at the very end and pose similar statements right which you believe as a factor fallacy and you would like the panelist to you know react to it right so we want that to happen so let's sort of level set um and see if anyone on this panel or otherwise thinks um this smart contract security is a solved problem so there are really no gaps of misconceptions and this panel is really irrelevant we shouldn't even be here does anybody think this is a fact hopefully none of us here anyone in the audience okay uh if there was you know if you think so please reach out to me and we'll uh if you can convince us we'll have you on the next panel all right so let's uh let's get into it right um so this one is har smart contract security is considered equivalent to audits today for most developers and for any users who care about it I think there is some truth to it um well well the the term audits in in traditional sense often mean like a tax AIT and maybe the term is not the correct way to look into things um the issue is that a tax audit is like completely like defined well defined whereas a smart contract you know secure review is often open-ended you don't truly know what are the bugs when you're are coming into a codebase and it's very frequent that when we order a code base or like you know review a code base we find bugs that have never been discovered before so in that sense like AUD the term can be a bit misleading but at the same time it's okay to use it like C I don't agree I think it's it's a it is one part but it's a lot of things start way before the audit uh Simplicity of the code documentation thinking about it uh of course and and and using tools and of course audit is a significant part of it but smart contract security is many things like we have seen recently even C like for example decentralization aspect everything you have to worry about when you when you have a code which is uh uh carries a lot of value you need a lot of things to make it secure and audit is is a core part of it but you want a lot of it not just audit it's sometimes you see a a customer he's going to an auditor and he said you you understand what this C does it's not what you want you want to have and we have for example team that have internal security and that's great it's a it's not instead of audit but it's a very good compon on it so you want everything yeah no do you do you believe that the protocols that you work with understand this or do they think that you know audit is everything I think it's a varies it's not like a one thing it's varies there are definitely a lot of protocol that understand and I think it depends like some protocol do see like their security as something they delegate to security provider they see like security or okay we are going to do an audit or Security review you know one week before deployment they're going to find everything and you know we are done we want security uh but I think there is a some team that see security that way so it's kind of a part of a fact that they see it that way but it's not obviously what security is about it's not binary it's not like you pass you don't pass it's everything mly mention like security is like a it's a journey it's something that is going to help you to get better overall yeah can add to that uh at this Workshop here on what did we learn from hacks and what I spent a lot of time at Defcon was interviewing projects which did not get hacked to have the opposite side of what to learn from the not hacks and there's a wide variety it is true I would agree it is a fact what you said for most projects they equal having done an audit is what makes them secure but there are those projects which honestly even we struggle to find more bucks in and uh crowd Auditors have a very hard time then to find anything right they don't get paid anything even um these projects they have really excellent security practices through the whole development cycle and they know that audit is a piece of the puzzle um so yeah there's much to learn I think also from the people who have not been hacked um so yeah I'm looking forward to another Workshop actually on the not hacked on absolutely so good um can I add something I may have misunderstood the question so I I completely agree that you know an external secure review is not enough the the best teams that that we work with they're very very security aare and they're very security conscious from day one they tried to build protocols so that even if there is a you know small mistake in one component there is a lot of defensive uh defensive like you know uh building where you know one buck in a certain component wouldn't be the end of the world so the greatest teams out there they are aware of security from day one of building and they don't just rely on an external Security review uh to secure their you know smart contract or protocols great point so we may be sort of answering there may be some repetition as it goes along but we sort of just getting warmed up by the way none of these statements that I'm making are my opinions these are sort of and they've obviously not been vetted by any U you know any of the panelists this is uh the first time they're actually hearing these things but it's a lot of these things are sort of common perceptions or misunderstandings in the space so that is that is what it is so the next one is for Joselyn and you may have touched upon this already smart contract audits are neither necessary nor sufficient I think you talked about the sufficiency part but can you talk about the necessary part does every protocol need an audit okay I I hope that we get to a point where it's not necessary like that should be our end goal as a security commun Community our end goal should be to us in a place where we are not needed to get to that is going to be you know about training about education about like tooling and and things like that chance that this end state is never going to happen like we are not going to be out of business you know by by that but that should be our end goal so it's a fallacy but will be nice to be a fact anyone else want to add to that I mean I agree to this and I can maybe like give some anecdotal example um over time the quality of engineering uh has gone up significantly if you go to rec leer board um the number of hacks from 2024 is like you know very little as compared to like other other years in 20120 and 2021 like every other week There's a hack that will get into the top 10 of Rec leaderboard and I think there's only one from 2024 and top 10 today and even if you speak with like some of the greatest bu boundi Hunters out there they share the same feeling they feel like the bugs are in code deployed in like 2020 and like 2021 know in the code that's deployed today um and I you know I talk with a lot of successful like poundy hunters and they just go one by one on like projects that are deployed in know 3 years ago and they believe that the current projects are much more mature just to answer your question I think it depends on whether the actual contract handles user funds uh not everying Le smart contract has to have tokens that have value and hold eth or or things like that um but I'd like to think that as of today if you are deploying code production code that's handling user funds you should probably seek an external security assessment um I I certainly agree with jelyn uh I think ideally in the near future we have two link that's you know a lot better for developers but there's so many fot guns in the evm maybe you know solidity itself as well uh that it's extremely easy to introduce bugs so um you know static analyzers are there fuzzers are there but uh seeking um advice from people who have been doing this for quite some time um is is certainly something I'd recommend I agree I think also the but we are actually seeing a lot of progress in the last year we are seeing at least with working with our client first of all the tool get better but also humans internal people get better and we are seeing actually internal security researchers in companies that we work with they actually do pretty decent job so basically they have something called internal aiting I don't know if it's a good term maybe it's a misleading but actually it's useful we have seen these teams are working in addition before after the auditor after deployment we have actually recently work with one protocol and actually the we together and it was actually a that but we together with the team found the compiler back just before deployment so the teams are getting more technical the teams I think not all the teams but some teams are getting more Technical and there's more education thanks to SEC and others the more this space will be educated we see also on web to some people get audited sometimes but I think the more there is the need for audit still will decrease in my my experience I know and this is external audit right yes so I think it's definitely wrong to think that an audit or a review isn't needed uh you will always need other people to challenge your code internally or externally sometimes externally is the most efficient because they have been doing this more than internally or internally they they might be too tunnel visioned on this right but you will need this and the more review you put in the better your whole project gets actually so we might get away from external reviews over time or reduce the Reliance on them but only because we got internal reviews on a state which is really good makes sense so by the way just to clarify when I say audits I mean time boxed external Security reviews of smart contracts right so to come back to to to something um that you said which is if you are handling user phones because there is also a point in time where if you are deploying something which is not going to be integrated in anything which does not have any impact which does not have any user fund your need for like external validation is lower than for something which can have an impact um so right now like everyone is deploying thei application you know mostly and so there's always like kind of like a composability or user fund or you know something like that but we could see a point in time where people are deploying things that have less impact that are not connected to other protocol for which like the security guarantee might be lower than what we need today can I add that thing if you have funds in your contracts in some way or if you are a company that manages like funds um chances are there are like Bad actors that are looking to exploit those funds already uh so people are out there who are trying to seal this funds and you need to work with the mentality that if you don't put in the work others are going to come in and steal the money that that's a reality makes sense all right so turning turning up the heat just a little bit here's a fun one for Maas audits are opaque underwhelming and overpriced this this is a loaded one so and just just a bit of the context right opaque right and and not from the context of your own companies but in general right the person ception is what we are going towards protocol gets an audit from some some team it could be a solo auditor it could be you know you have all the variants right it could be a contest it could be any of those the protocol gets deployed and we don't know if the contracts deployed were the same ones that were audited were there changes made where they upgraded so that's the opacity I'm talking about and then there's a report that's either published or not not it's private we don't know what the scope was we don't know how much effort went into it we don't know who performed the audit right there are just so many levels of transparency that may be missing right critical critically missing so that's the opacity uh opacity and then underwhelming in the sense that I don't know what the latest wck leaderboard statistic is but several of the protocols that were hacked right for Millions 100 of millions had audits right so it's so that is that is that part and then pricing right so when I so I was talking to protocols as well U and when when we talk to them they're like great we we love it can we you know do it for a lower price so that's yeah bit bit of a loaded one feel free yes thanks for that especially the price today yes so starting with the um opaque right uh fact um the um like overpriced one jumping to the end I definitely agree with the feeling if I am a founder of a defi project and you have to Shell out this amount of money which equals uh approximately for a small project your development budget you are shocked um is it um overpriced because of that no it's because the security is so Paramount and this is not something you are used to so that's a fallacy the um um reason for why it can be underwhelming um there I'd say like it's it's also a fallacy the reason is that you get a lot of value from that added security and overall the stats we have seen which there was a great talk by Peter at DSS for example on this having reduced the exposure of the ecosystem to Smart contract he significantly shows that value and this has been heavily carried by uh initiatives like secum to train and um by by a lot more audits being available today to also have the throughput right and then doubling down on the initial part this is kind of dear to my heart this opaqueness um we struggle with that ourselves when being an auditor after after another auditor and you go in and you you read reports from others right and you want to know okay what did they focus on what should we focus on did they miss something did they have some misconceptions what are their assumptions you will not find it in an audit report our audit reports today Focus heavily on issues right that's kind of the bread and butter how many criticals did you find uh we do very extensive um system overviews and and clients love it right it's really important but that is something which is still rare um it's this documentation thing right which all developers and Auditors also aren't into that much yet you you hunt for bucks you don't hunt for the best documentation um the way I do it is for example if we follow an audit after a trail of bits did it then I call right then I reach out and say like hey let's jump on a call and how did you do it and then then we get to understand better but this is probably rare and the public audit reports bring little value uh except for you can extract hey that was an issue you can learn from that issue um yeah hearing you asked the question reminded me of a conversation we had just before Devcon and I on on the opaqueness and like opacity of of the space I think there's definitely room for more transparency and perhaps for even a platform that could um um link those commits that were actually assessed by some of these firms here and what's been actually deployed on chain and I think that is a massive Gap um that and the unpublished security assessments just want to say if if a sigma Prime report is not public it means that our client did not want to publish it all our work we take great part in our work all our work by default is to be published unfortunately in practice I estimate are about 40% of our work being kept private um and there's plenty of reasons for that you can imagine um the the biggest ones I guess um but I think it's it's probably uh something that we should aim at fixing and I think there's room for a a platform that could you know kind of name and shame all these protocols that decided not to release those public reports those audio reports so I I actually disagree going good disagre are good yeah so you want to start you go ah okay so I don't think we should have all the report public like our report are not meant for public conception they are meant for engineer like they are meant for the people building the protocol making them public is nice like it's nice for transparency it's nice for like visibility but I don't think it's a necessary step for the security of the protocol themselves and it's it's not for the users it's for for users to have confidence in the potential safety of they're interacting with the reality is that user don't read the public report we can have a protocol we can say poliy they read some some user we we could we could have a a protocol we say in the executive summary this protocol should never be deploy it's trash it's not going to prevent user to use it this is a plat this is where a platform like uh the one I'm suggesting sorry could come in right where you don't have to actually dive into the technicalities perhaps we could come up with a way that we surface the important information that should be consumed by users this this is my point so I think that's probably I I will I'm I'm definitely on the minority here probably in this sator even so we our our most commitment is to our client not to the community sorry about that if you want to deal with it it's fine so if we tell something to the client and the client we we we need to be transparent but we our most commitment is to the client we are not about Bounty platform we are a company that's serving a protocol they pay us we provide service we do also tools of course but then people use the tool so we provide that we of course we like to talk to this team here I learn with you but our most commitment is to the client when we disclose the report for example we find many criticals the client does not want to publish it we negotiate with them for example we tell them to fix the code we will not publish that because it's not we are not a shaming company we're not a social Media company I'm sorry about it so this is what we are not at and maybe you need another company for that now as for parness we have Advantage because we are using tools so every commit that we have we are getting the rules you can use f we use our appr it doesn't matter so our client we seen even our published that they change the code and even before us it actually find the bug because it have these Woods that we work and also when we work with other Auditors we look what they find and we write rules for that for example you saw recently the Unis swap updated their code after the contest and then they run the rules and it fails we see the thing so we our biggest uh value as as a as a tool provider is to integrate into the CI so basically every time you change your code you want to check that so that's sort of where tools can be more valuable than you you are not a minority okay thanks so can I add to the the original question on like the opaqueness the the transparency and the pricing so we are the youngest company here we started in like late 20121 and one of the reason of starting know speedit and later canina is because we saw this like we saw that the audits were very opaque there was no transparency they were you know extremely pricey and uh we wanted to do something different um so we are extremely transparent as a company we are very transparent about what the security searches make how much we make and we pay our security just a lot of money and because of that we have some of the best talent in the world like they're not necessarily like security Talent just the best talent in the world at what they do and it's a privilege for us as a company to get them to work on know security and you can see over time that you know the smart contract hacks have gone down significantly and part of the reason is because we are able to attract a lot of talented individuals they would be excellent at whatever they do it doesn't matter security or something else these are extremely Talent people and the money you pay them is 100% worth it and we also built canina later on to make it more like affordable and flexible for people so today like if you come to us or like many other providers like I think there is something for everyone like if you are a small project that has something that you want to review there is some something that we can offer you that will fit your budget um and to like answer maybe like some of the points over there I do not believe we can grow the industry if feel like shame companies so we should like avoid like shaming companies that's my two sents yeah what what we always say to our client that if you want the report to be public it's your responsibility to educate your user on how to read the report and you know like even if critical Burger found in a report what have you learned through this process know how how have you improve whatever you needed to improve to get better so there is like part of it which is from the moment you want to have something public you need to think about how it's going to be we by the by like the user and that's not our responsibility to do that I think it is to a degree to a large degree actually because we know like we in a different industry than the others which usually keep reports private it is going to be read by the public is something which is important that many understand like of course you can have technical details but um the audience is not only the project this is also why we call it audits to be honest audits are traditionally not reviews right and what I would never want to have is that there is a false impression of security because of uh audit done by by anyone right so I agree with the client doesn't have to publish it and that's that's up to them I would never go in and say oh now send us a new code we review from like as if that was the original code we give you a report which says zero findings and now you think it was perfect right if you publish a report it will have everything in there and in in that sense I agree was like if you know there is a report upcoming and it's not being published there might be very good reasons for it right uh but it is a sign of look out right be a little bit careful what's going on we I there are many many more and our timers is is already you know changed colors to Red so as you can see we can go on and on so this I think achieved the desired effect right in terms of turning up the heat and bringing the disagreements or I mean I I think we all at a certain point agree uh it's just about the termin ology the factors the incentives and you know the industry or or the space as it is now versus as it should be and obviously we'll have differing opinions on that so the next one Switching gears a little uh this one is for MDI smart contract security onchain security is overrated compared to web 2 offchain security yeah interesting um kind of want to say you don't need context this I want to say fact uh for 2024 that is I think um one of your earlier questions was whether we've sold smart contract security I don't think we did but we've gotten a lot better right and the the numbers actually show this the past year and the past 18 months we've lost more money uh to threat malicious uh actors in traditional web2 uh security uh problems um unfortunately what we still see um to a great extent these days is um protocols solidly thinking that smart contract security is the only thing that matters and if I get a gazillion number of um security assessments if I have uh a Bug Contest if I have a bug Bounty program targeting my smart contracts my onchain operations then I'm good then my users will be good and there's absolutely no other vectors for me to get popped that is a huge policy that has actually cost a lot of money um this year alone uh Peter that you mentioned had these uh great numbers up uh in his presentation at DSS um but it's um it's something that I think uh we're actively trying to fix just by educating these protocol saying hey you know if you're um have a multisig and you're dealing with user funds and there's probably other ways that these threat act could get and uh and and unfortunately cause uh cause you to lose your your user deposits um it's it feels like we are at the same stage of um like the same place we were in solidity security maybe 3 years ago four years ago so I'm quite um hopeful that things will change but at the moment what we're seeing today is a lot of money so much money lost to um you know North Korea not to name them um through um things that really really shouldn't uh shouldn't no care anymore uh web to security I wouldn't say it's a solved problem but we we've learned a lot of things over the years right uh so security hygiene raising the bar is everyone's responsibility within an organization um and I think you know through education and also um you know some of these obsc audits that some people have been uh hearing about we can we can help these protocols raise the ball may be a good time to mention the security framework from the secretari yes great great see thank you thank you all right so if you go to frameworks. security alliance.org you will land on a page that has been put together by the security Alliance uh Kudos Tata who's done an incredible job on this initiative and essentially it's a collection of best security practices across the entire stack of a web three organization forget smart contract security right there's a gazillion number of resources and experts out there when I talk to protocols they don't really know how to secure their cicd pipeline they don't really know how to harden their ec2 instances they don't know how to prevent Sim swapping and Harden their Discord servers all of that information is out there somewhere what we did was consolidate it and put it in one Central repository that everyone is actually welcome to contribute to and we want contributors we want people to go and um know close the gaps that we have CU we do have gaps it's not a perfect release uh in fact it is not a release um so please take a look frameworks. security alliance.org and this should hopefully hopefully help um raise the ball thanks JN so can I add to like maybe like I agree like a lot of money is getting lost today by traditional attack vectors so much so that if you run a company that is like building in crypto or if you're like an engineer you're going to get constantly fished or like social engineer right now like if you if you're not getting getting fished your teammates are getting fished and it's even more important to build like very resilient protocols like we see examples were protocols that were very secure on the smart contract level lost money because somebody's private key was compromised because of a social engineering attack like often times this would look like hey I have a job offer for you do you want to interview with us and then they would ask them to download like a malicious npm package and accidentally like compromise their um machine which will eventually have some privilege uh privilege like roles as private keys somewhere so it's so important today I think here the fallacy is to think prevent fishing and you'll be fine on this level like smart contract security we have seen hacks right and we may not drop the ball on this but um the hackers are often like very talented individuals but but they aren't usually the uh leers groups these we have seen on the other side so the threat is here an actor a state actor right which has different resources they will not get you through fishing they will get you through zero days right the level of sophistication you need to put in there is a different one there are great guidelines of how you can improve your security out there but as a project which has like eight nine figures which someone can take by compromising a few Keys the game changes the game changes completely right and it becomes something unique right where generate guidelines don't help it becomes similar to Smart contracts every smart contract get hacked differently right so that's why we have these custom audits here but only for these very large projects I think the real new threat is a state actor compromising them right ethereum being out there the first time kind of against a state right so this this will be interesting to illustrate what you're saying I like this quote from morelan from optimism who says we should build our processes is so that even if we were to hire 49% of our task force and dpk agents we would still be fine and I think uh if you know people who are building the next Protocols of Tomorrow can keep this in mind um then we would you know be a lot more resilient uh to this none is Right none is today perhaps a handful a couple of protocols out there that are trying at least but yes you're right not enough great great point so um moving on to moly so this is something I think there is a topic that you're intimately familiar with in Sor formal verification should be used by all projects I think the stress is on all the answer is yes definitely and even more the earlier the better and even more and that's contrary to some of what our competitors say you do not need a PhD you essentially can use start with fuzzing start with unit testing you don't need to necessarily prove of course sometimes it requires some skills and don't wait until you have all the tvl and don't wait until the tool is the code is complex or or the code is complete and don't write a lot of assembly code I have want to challenge it I have a different opinion that a probably ofen mly who who is my soon to be neighbor um I don't believe that I I think things for verification does not scale at all to the level uh of complexity of today's code base I respect Satora for like really pushing the limits but it's fundamentally something that's like unscalable by the by Design so let's see examples for example let's take the recent Unis swap V4 it was forly verified by Yen who somewhere there and then the Cana tried to find a bug and no bug let's take Oiler also un the coner didn't find the bug so of course the the the real answer it depends on the time that you spend and the but it depends if you have three or four weeks let so far at least from the using the experience of the great security researcher at least it's a it's I I understand what you why you're protecting your territory but but and it's good actually I like it but but the issues that it's a we are seeing actually I think a cour here from the maker team who is now in your team actually has written a beautiful Rule and found a like a huge mistake so we are seeing people writing rules uh on code which is complex and simple yes it is true the the the the tool is costly sometimes and people are building open source software like the hmos and others and we are trying to get our tool better but I think I think the the the the technology is getting better and actually the thing which is hard about formal verification actually for that matter fing to is writing the specs I think the issue with why our tool is not used more is of course there are technological limitation but writing spec and in defi I work in formal verification now for 40 years and I can tell you def is is a beautiful domain because the the domain is mathematical so specs are very natural think of something like a constant pool it has a beautiful environment multip ation is constant and we work after the top auditor and the team WR this constant pool and in fact it prevent in the triy then prevent losing all the money in the contract so so I think formal verification is is a and formal specification use fing I don't the issue is that writing in variant is a very interesting concept actually I think you should use it even if you're doing manual auditing if you don't want to use CVL want to write it in English is fine but I think writing spec is a very very crucial thing and you should write it whether in a white paper you should write a spec you look at the compound V2 compound V3 you look so writing the spec is a very very important concept whether you use CVL or other languages but running the spec I understand and you they can still pay you no way so good so as you can see as you can see we we're all really passionate about our uh uh you know about what what we have been working on for for a really long time so this is this is good I mean this is what we wanted to talk about so now can for like I think in like 5 seconds so I think the problem is that the complexity of DFI is increasing like linearly but then the complexity of formal verifying increases like exponentially and we got to a point where you know you must have V1 or V2 and maybe V4 you can verify it but I don't think like the next generation of We Will We can scale to that point so the only way to scale system not formal verification is modularity and the issues that with modularity you can scale formal verification better than fing and other fing is good for many things but with formal verification the beauty of it if you look at Oiler V2 un like I like Oiler V1 it's very very modular if you write code modular whether you use formal verification or not it's a good thing so you have to design your code well and then it can complex actually you can bre the blockchain modular the more things are modular it will be more scale you write your spaghetti code and yes maybe they can pay you but it's not going to help and I'm here with mly like formal verification to me made blue screens go away for someone who is that old that they grew up with constant blue screens then this is something which Microsoft used to make device drivers like proper like I mean mly did actually and um we'll get there uh the white wide west is not suitable for that uh manual audits are more efficient things change too much we'll get steady we'll get in more modular way and then we can build and then the time of formal verification will come to to its full power right that's what I believe I think can I can I quickly interrupt we are going to get into Q&A the last 10 minutes so while that is coming up um I know we can you know rebut quite a bit and agree so there are I mean we just warming up right so let's also give maybe some of the questions um and then okay we see it here as well all right so the top voted one five in 5 years more than 80% of new code will be AI generated I think that's a fact like there's likely that a lot of developer are going to use for part of their code AI uh oh sorry no no no sorry cuz you're all nodding sorry everyone was nodding I feel like I'm the only one who doesn't think that's I think I guess the the question is like what does security mean when Cod is going to get know AI generated and like you know it's spe a bit on the Cano like we are building towards this Vision that there's going to be a billion developers in the future and we want to solve security for those people we know how to secure like in a code basis for there's like no room for mistakes but I think the real challenge in the next decade is going to be like what does it mean to secure when a billion developers are now writing code okay any rebuttal any yeah I don't think so I don't think um let's see the deployed code deployed yeah smart contract code that will handle billions hundreds of millions of dollars of value like properly depl coded by AI agents and deployed on chain without any human intervention within 5 years uh I I don't think so so without human intervention probably not but use human scrutiny sorry yeah yeah I I have seen code where which was deployed for like real protocol where I am somehow confident that it was Solly generated by you know chpt or whatever right did you edit that code ndas Burger easy to found when it's good so let's let's go on I mean some of these questions may be repetitive in nature so we'll skip the obsc one but the one on top L2 fragmentation makes Smart contract security more difficult I think presumably some extent because there are changes in the evm across like l2s and if that is something you have to watch out for for example cing does has some de deviation like the Crea 2 cha pricings are different so it makes it a a little bit more difficult but not really could make it because you change small thing we have seen it like the llvm buag of the ZK so the issues that you small changes and now we know account obstruction is being built so I think for us we ended up because we have to model everything in the thing so it it's things are tricky the most changes are small but people are there are some changes and people should be aware even things like cello so there there think maybe that's actually an opportunity for the Seal team you guys at least document it yeah we we see that I agree with Harry I think there's different like push zero for example not being available across all the evm chains um but it's not really making it that much more difficult you got to be aware of those differences um but it doesn't really change the game I'd say fantastic all right next one um okay this is this is I had a different version of this okay these keep getting switched like okay and thanks for uh marking those answer smart contracts are insecure because solidity is a flawed language and somebody panel may want to answer that or not so I want to say that there is an opportunity to make solidity 100 times better I believe in that and we need to make it 100 times better but at the same time I would argue a lot of the bugs are really like like at the logic level for example there are rounding bugs that are you know that exist in smart contract that has been there like you know 10 years ago like there are rocket launches that fail because of rounding bugs and now D5 Protocols are getting Happ because of the same rounding bugs so fundamentally like it's like logic issues not necessarily like language issues for example you don't really see like memory management being a problem in solidity whereas you know in traditional uh compilers that is a big problem like you don't allocate memory in see correctly like you can get exploited um so I think two things there is an opportunity makes 100 times better and we should do it but the bugs are that are out there that are I mean it's across every language totally agree and the issues that the the thing and actually I don't want to talk but there are so many other languages which are proposed they say we go to this new language it's type safe and we we solve the problem it's not the case I don't want to go to this other languages are proposing solidity has problems but most of the bugs they are logical mistake they excess control there are things that if you move to another language and you have beautiful language design maybe this new languages it's still not going to solve so I believe I believe solidity has fundamental flow that leads to issue with respect to security for example there is no inbu testing in solidity that's for me a huge problem in security because now you have to rely on third party tricks and hacks and like cheit cod and whatever no debugger too yeah like there is a lot of fundamental flow like the optimization of the compiler are not great this led a lot of people to use assembly to do like basic operation that's a fundamental flow of the language which LEDs to like a lot of security issue so I do believe like a lot of security issue stem from some of the design of I agree with all this point point there are like opportunity to improve but on the optimization I would say that if you know what you're doing you can always beat compilers any compiler if you know what you're doing you can beat it compilers can never match like you know creative humans I I don't know if it's true I always heard uh JavaScript was the inspiration for solidity and what solidity did absolutely right was make a language you you can easily understand right like only python perhaps is easier to understand from the get-go but JavaScript is very close to that and it is an very auditable language it is not a language which makes it hard to make mistakes but as was said already the mistakes are in not understanding what the code is doing not because of language features usually so this is what solidity got really right to to make code we can easily understand uh we we were on a I was moderating a panel with Harry uh at DSS and we I think this is conception that solidity is flawed and I totally agree with what you're saying but I think the biggest problem come from the evm as we were saying right so solidity can pass down to evm B code and there's been some just say questionable design decisions that have been made at the evm level years and years ago that we're kind of stuck with but there there are actually the good news is there are ongoing efforts to remediate those in the hopefully near future I think that's an excuse because for example again no inbu testing has nothing to do with evm that's a design choice I agree with what you said I agree with what you said all right so we let's I think some of the interesting questions are popping up that we couldn't get to so the top one right skin in the game as some people tend to call it the first thing that happens when a protocol gets hacked is at least on crypto Twitter is who was the auditor right and it's and there is a school of thought that believes that reputation is not enough that they should have skin in the game and they should uh you know be paying more than with reputation what do you guys think I mean I think it's a practical question like at the end of the day like we are Security Experts that's what we're good at if you want to do insurance that's an entirely different ball game it's it's something that's like fully mathematically you can model it with mathematics um that's not our expertise and I think it should be a second party that should come into like it and that part is not there today like most insurance companies they like you know sell off the you know sell off this to some third party and we don't have that today so I mean we would love to make that happen but we are Security Experts not like Insurance experts if there are people who want to pair with us like we're happy to do it I I have to say it already happens and it happens in a different way while this small money you might reaw from an audit that's usually not compar compared to if you really got hacked on a large project right it's just peanuts in comparison the real value brought if you have an auditor who who is with you right is that they'll be there for you if there is an exploit if there is a buck report if anything was missed and they put all they can in to help you for free right they'll they missed it it is a reality and now they are there to reduce the damage at kind of no cost right and and then that is something very important I think this is something you should ask for so that you know like if hits the fan someone has you as much as it's possible now and that's a real value out there cool we have 30 seconds so I want to take this opportunity to give each of you sort of a closing statement which you believe is the top thing that is considered as a fact but is actually a fallacy or the other way around starting with hurry I mean I would I would just double down and say formal verification doesn't scale yeah all right yeah we don't have time for discussions or rebuttal we'll take that off stage Jos J invariant driven development should be the future one auditing small changes is easy easy that's a policy tithe up sex security um can save you so money is that basically now he put me in a difficult situation I think we need to understand that actually smart contact security is not everything there lot of actually other things there and we should be aware that actually a lot of the problem and this we see in DSS and we see it also from our client is not actually in the smart contact security all right do you have one Rajiv sorry do you have one I would you know agree with all the statements here I have quite a few myself haven't I think a lot of lot of it was reflected in some of the comments earlier but yes maybe maybe one do we still have four minutes or is that overtime oh okay do we have a talk after this can keep going please please oh I do I do have just one closing statement I think we need more time for the

Automatic transcript — names and jargon may be misspelled.