# [CLS] ETH Escape - Speed Hacking Challenge

- Channel: [Devcon 7 SEA](https://streameth.org/devcon_7_sea)
- Date: 2024-11-19
- Duration: 2:28:51
- Watch: https://streameth.org/watch/673cc095982f234a126a635e
- Download: https://vod-cdn.lp-playback.studio/raw/jxf4iblf6wlsyor6526t4tcmtmqa/catalyst-vod-com/hls/c3fd85k5jbq04svg/1080p0.mp4

## Description

​Prize Pool: $50,000

​A High-Stakes Speed Hacking/ CTF Challenge
Are you ready to dive headfirst into a thrilling web3 adventure? Join us for ETH Escape, a heart-pounding Speed Hacking & Capture the Flag (CTF) challenge designed to test your coding skills and problem-solving abilities on Ethereum.

https://lu.ma/viyjky8t

## Transcript

Thank you. Thank you. Thank you. Thank you. 15 minutes in, 90 minutes remain. No solves yet. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. All right. We have our first solve here at minute 76. Ddust2, Ddust2, where are you? Congratulations on getting this started. Kicked off here in the finals. You've got the lead. How does it feel? A little bit nervous, actually. A little bit nervous. What is your hacking spirit animal that you try to inhabit while you hack? Alright, we'll go with the elephant. They're very smart. Thank you. Thank you. Thank you. Second solve, NP Hard. We've got two people up on the leaderboard to take the top two spots so far with 72 minutes left. NP Hard, where are you? Remind me. Alright, good work. What did you eat for breakfast that's making you so successful today? Power of Corgi. Alright, love it. Power of Corgi, and the shirt says it all. Let's see, you can jump into the number three spot. I'm betting it's happening soon, and then it's gonna be a race so you could finish the next two challenges. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. In the leaderboard, third solve. Looks like they went with a different challenge to start. So one, now in first place, currently poised for $10,000 rewards. We've got DDoS2 in second place, currently poised for $10,000 rewards. We've got DDoS 2 in second place, currently poised for 7,500 rewards, and NP-Hard for 5,000 in rewards, currently as it stands. Where is one located? Top of the leaderboard. Where are you? Is that you? All right, they're staying in on. Okay, fair enough. 65 minutes remain. Remember if we have three people solve all three, that will end the clock before the remaining 64 minutes. away guys. Thank you. Thank you. Thank you. Thank you. One hour remaining. One hour remaining. One hour remaining. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. We've got a real race for the prizes now, Rage. Congrats for getting on the board. We've got three folks who have solved one particular challenge, and then one at the top of the leaderboard who solved a different challenge. So wide open for who's going to get the rewards but again as it stands now we've got one taking home ten thousand dollars in addition to their winnings already 7500 for ddust2 and np hard would get five thousand dollars in this round so anybody's game still 51 minutes and 45 seconds left. Keep hustling. Everybody's doing a great job. Thank you. Another update to the leaderboard. One pushing ahead by solving the second challenge. So on their way, it's possibly capturing the $10,000 grand prize. A reminder that places four through 14 in the finals all receive the same amount. So if we have a top three that solve all three before the timer's up, the finals will be over. Thank you. Thank you. Welcome to the Leaderboard Mage Intern. It's heating up. Who can get into those top three spots for the big prize money? 47 minutes to go. Thank you. Thank you. Bill joins the leaderboard in position two to shake things up a bit in the top three. MP Hard drops to number four. So good work, Bill, getting in there for the $7,500 spot as of right now. Thank you. Thank you. Thank you. Thank you. Welcome to the leaderboard, Slipper. Slipper with two solves very quickly. So put them into second place now over Bill. So it's heating up. We've got two folks with two solves. The first one to get the last one is gonna take home the $10,000 prize unless someone can solve two before they get to that last one. With third place wide open still, but being held by Bill as we speak. Just under 40 minutes left of the final round coming into it before in case it ends as people start to solve things. I want to give a big thank you to the Ethereum Foundation. I want to give a huge thank you to our friends here at Friendly Maltese Citizens putting together these awesome challenges. We appreciate all the hard work you did on that. And then we also want to give a huge shout out to the upcoming Ethereum Protocol Attackathon with rewards up to 1.5 million and the wonderful support that we've all received from Bybit, Wormhole, Arbitrum, The Graph, GMX, and Base. But thank you again to friendly Maltese citizens. You guys did a great job to create a great event. So keep it up, everyone. Keep your heads down. Coming in on the home stretch here. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. 30 minutes remaining, 30 minutes remaining. Thank you. Thank you. Bye. Thank you. Thank you. Thank you. Thank you. Thank you. The only change to the leaderboard we have is Bill getting a second solve a few minutes ago. That means that our 1, 2, and 3 right now are all racing to get that third solve. First one to do it gets the $10,000 grand prize. Coming down to the wire, we have 22 minutes left. Three people in the driver's seat to stay in one two and three and Plenty others behind you can certainly get up there as well. So keep it up. Let's see what happens Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. All right, players, we have 15 minutes left. And as a token of my appreciation for letting me bother you all day while you're trying to focus, we will release a hint right now to see who can try to take home the prize in the last 15 minutes. Thank you. There were typos in the first hint, so there's a second hint out there now to clarify. Thank you. As it stands now, we still have one in first place with $10,000 prize. As it stands now, $7,500 to Slipper if things stand as they are. And Bill would take home $5,000 prize as it stands now. $7,500 to Slipper if things stand as they are and Bill would take home $5,000. The rest of the pool up to the rest. However, it does seem that if there's one solution to one of these, to one of the ones that has not been solved yet, that person can easily jump into first place if there's no other solvers. So anybody's game in this room in the last 12 minutes, good luck. Thank you. Thank you. Ten minutes. Thank you. Thank you. Thank you. Thank you. Thank you. Five minutes remaining, but we can now say with confidence that Slipper is the inaugural champion of the DevCon CTF and will take home the grand prize of $10,000 in addition to what he's already made today. So $10,000 plus what he's already made and the physical gift we'll be giving him. Huge hand for his work today. There's still a few minutes left to see who can take the other spots because it's wide open with one more solve for pretty much anyone on the board right now. Thank you. Thank you. Thank you. Five seconds. In five seconds will anybody be able to get a solvent. Thank you. All right, pencils down. A big round of applause to the whole group here. Everyone in this room should be pretty proud. That was a lot of people that came in this room and did some speed hacking today. And you are the best among them today. A huge congrats to Slipper. Where are you? Slipper, come on up for a minute. Congratulations on winning the whole thing. I have a question for you. You took a little bit of a mitigated risk there in holding two answers at the same time it looked like you submitted them back to back. Was that intentional strategy to put pressure on one? So I saw that I had already submitted the one solution, but it turns out I was not shown on the scoreboard. So I just realized I didn't submit the one successfully. So it looked like a brilliant strategy that was actually a brilliant accident. Congratulations, you did a fantastic job today. How do you think you'll spend the money? How much would I get? $5,000, because you and I will split $5,000. No, $10,000 plus what you already got from the previous round. So you'll get a little over $10,000 and a gift from us at the awards ceremony later. I haven't decided yet. But I would thank ChatGPT for helping me. So I would pay for them. So a nice donation should go to ChatGPT for helping during the competition. Congratulations to you for being the inaugural winner. I want to shout out really quickly again our great friends over here, the friendly Maltese citizens for putting these challenges together. I think they did a really great job of putting challenges that were of all difficulty types and managing the event and the platform. So we really appreciate their help here, our team here as well. I want to thank the Ethereum Foundation for allowing us to run this, the first one they've done, I believe, at DevCon, and hopefully not the last, and for being our partner in doing so. And I really want to thank the, as you know, the upcoming attack-a-thon of the auto competition for the theory and protocol, the entire things in scope. Saw a lot of really talented people in this room today who I think could do a really great job working on this project that starts in about 12 or 11 days. Eight weeks of hunting, a ton of educational materials to get you up to speed, and the sponsors of that program who are supporting it we'd also like to thank, which is Bybit, Wormhole, Arbitrum, The Graph, GMX, and BASE. So a huge round of applause I also want to I want to congratulate our second and third place winners for respectively earning seventy five hundred dollars and five thousand dollars so that's one where's one raise your hand one stand up one congratulations Congratulations. And then Bill. Where's Bill? Bill, congratulations. Winning $5,000 plus what you did earlier today. So really great work by all of you. I think you're all coming out in the black today by getting some rewards and cash. We also have a reward for you you later which we'll do at the Award ceremony here After we do a little bit of a fireside chat Regarding security So hopefully you'll stick around for that so you can collect Your gear and then get to Our team with Your wallet numbers if you haven't already done that So you can collect your USDC in the Next few weeks, the last thing is a lot Of the folks in this room, which is amazing, didn't even sign up until they walked up today and just came in and dominated. So really great job on you all for showing up, coming through here, getting into the finals, making a few dollars. And because of that, I don't believe you got swag packs. So we have swag packs for you as well. Ash if you could raise your hand over there He has them for you. So make sure you collect those as well before you before you depart But yeah, thank you all for participating Find anyone in an immunify shirt to give some feedback to because we want to make sure we give feedback to the etherium foundation So when they run these again, they can kind of decide, you know What the best are out to do and get some good feedback from you all of what's too hard, what you would have changed and we'll try to adapt it that way. Thanks for participating in the first one and have a great day. Stay tuned for the fireside chat. Thanks gentlemen. Thank you. Thank you. Thank you. so Thank you. All right. We'll start the fireside chat here in about three minutes, folks. Thank you. Thank you. Thank you. Thank you. Thank you. All right, folks, we're going to get started here in a minute. If we could actually just get folks to sit down to the left or the right and not in front of the camera that would be great. Thank you. Just a reminder to all finalists who just participated. Quick reminder to all finalists who just participated. Please stay here for the award ceremony so we can give you your gift. And ensure that you've talked to our team and given us your wallet address so we could deliver your reward money. All right. With that, I think we'll start to get the fireside chat here going since we got the live stream. And what I think we'll do first to make it quite easy on ourselves is just introduce who we have here you've heard me talking all day so enough of me but I'm Mike O'Keefe I head up sales and customer success at Immunify which is CrowdSec bug bounty programs and audit competitions and I will let's just move left to right to start. Alright hey everyone my, everyone. My name is Michael Llewellyn. I'm the head of solutions architecture at OpenZeppelin. I focus a lot on working with our security audit team with some of our top clients, working on kind of weird, out-of-the-ordinary sort of audit requests, maybe things that are outside the EBM, and then also do a lot of work on security operations for DAOs, security councils, and lots of other very particular things for the industry. Hello, my name is Neville. So I'm a program analysis expert primarily in management in B-Dub. So I'm also a co-founder. My time is spread throughout, you know, like engineering, management, sales, and a lot of operations as a co-founder. But yeah, I'm a security researcher at heart. Hey, I'm Luna. I'm the co-founder and CEO of Zellick. My background is in vulnerability research, reverse engineering. So I used to do iOS zero-click. That's the kind of background I have and then yeah nowadays I mainly just do Zollock with my co-founder Jazzy we recently acquired a company called Code Farina you might have heard of it I worked very closely with that team as well now so that's kind of what I do yeah I'm Pietro I'm a lead auditor at Chain Security and we are an auditing company based in Zurich who specializes in complex DeFi projects and we've audited a bunch of projects that you might know, Maker, Curve, Lido, Polymarket. We've got bugs if you want later. We find them and we package them. And we specialize on EVM ecosystem. Awesome. And so thank you all for joining the panel. Thanks for coming here today. Nice way to end the long day of deep focus these folks had. And I think it's been great because I think Immunify has worked with all of you in different capacities throughout the years. So it's a great collection of folks here. I'm going to start with one that's a little off script that we hadn't talked about yet. It's Pietro. Pietro, you participated today. What did you think of the CTF? What did you think of the strength of the challenges and how you felt you performed? Yeah, so I'm not too satisfied with how I performed. I review code eight hours a day all year, but I very rarely deploy anything, very rarely interact with RPCs myself. So I found the bug quite rapidly. I was in round three, and I think they were very easy to spot. But then I had some trouble with the on-chain part. It was an interesting challenge still, but I'm curious to see what the other rounds were about. There were six with different challenges, and the finals also seemed very interesting, but I haven't read the code, so I'm curious to see that. Perhaps a team format would work better for you next time. You spot the bugs, and then you hand it off to a teammate. Yeah, probably, or just taking a couple of hours to get used to deploying stuff beforehand also would have worked. Well, we were thrilled to have you participate. A lot of the audience today, a lot of the participants in the CTF today, which was fantastic, were developers, security researchers, auditors. We had a really great mix and many others, I'm sure, as well. So I think keeping that in mind, keeping the audience in mind when we go through the next few questions over the next 15 minutes or so, we can kind of cater to those audiences however you please and whatever angle you guys want to come at it from. But the first thing I'd like to ask is a lot of these folks are involved in CrowdSec security. That's kind of what the, you know, what the Ethereum protocol attack-a-thon will be about. I'm curious how you all see CrowdSec security next to your businesses and how you operate. And maybe where I'll start actually is with you, because you all recently acquired Coderina. so you obviously see some value next to the audit So i'd love to hear your perspective Yeah, i mean the main reason we acquired code arena is we just think we can deliver like better experience better security for our customers The main thing that i would show is this concept that we have introduced called audits plus So when you have a consultative audit you're're going to get, like, you know, a small number of very highly skilled people, and they're going to look at the most important parts of the protocol, but it's fundamentally a time-boxed audit, right? So they're going to get maybe one week, two weeks, three weeks to look at this thing, so they can't afford to look at every single, like, gas optimization that there could be, or like, oh, no, this function's not documented, they need to go find and make sure that the critical invariance of the protocol are firm. Now, on the other hand, a lot of times you do want to get information about all the possible things that could go wrong, and not just that, you might want to have, you know, hundreds or thousands of eyes on the code base, because that is what you want before you not just, you know, ship it to mainnet, but also before you put it in front of a bug bounty, because that would be very expensive. The earlier you catch a bug in your development lifecycle, the cheaper it is, whether that be at the integration test or the unit test or the code review, internal audit. The earlier you catch these things, it's cheaper. So you want to get a consultative audit because you can have a firm authority say like, okay, yeah, we looked at it and we're pretty sure it's secure. And then you want the additional reassurance of like, okay, not just that, we've got a crowd of people that looked at it and it's definitely been very thoroughly picked apart. So because of that, we think that consultative audits and competitive audits or, you know, crowd security, these two go hand in hand in creating something that's extremely high assurance. So that's kind of what we think. We think that crowd security is very important. Yeah, that's why we call it crowd arena. Wonderful. I'll open it up to the rest of the panel for anyone that's got a response to this question as well. Well, crowds, this kind of security is really, really effective. And it's really enabled by the community. I mean, listen, everyone is motivated to learn new technologies, make a name for themselves, and also do the right thing, and finally make a little bit of money. And especially for bug bounties, which is the last line of defense, I mean, having participated in bug bounties myself, I feel that you are highly motivated, you know, like to spend a whole night looking for a bug or something like that. So, yeah, it is highly effective, you know, in certain contexts, but it really depends who's there, you know, looking at your code. To be fair, White Hat program is the last line of defense? Right, but that's something that I wouldn't do because of legal issues and things like that. Sorry, I was just posting. I can't help myself. Pre-deployment, post-deployment. Yeah. It's a model we've definitely seen a lot of our clients start to work with. Like we do mainly consultative audits, slash private audits, lots of different names for it. We expect to continue to see demand, but we've definitely seen a lot of clients that are specifically integrating us into a broader process where we're typically doing a private audit or consultative audit, and then they plan to later go to a crowdsourced competition. So it's good from the perspective if we did, by some chance, which is always some chance, miss something, like there is additional layers of security that are going to potentially catch that, so it's not all on us. And potentially there's several private audits as well. And then afterwards, we've actually found ourselves working more and more with clients in the fixed review process of competitive audits because of the fact that you can't have a lot of issues coming in. Even if they're low, that could be applied to the code base, and having someone who's already seen that code base and picked it apart a bit can help the fix review process as well and ensure the code is as secure as possible before it goes to mainnet. I do expect this is going to be a model that continues to grow, and there's going to be probably a lot of coordination between both private and competitive audits and the ways that clients use them. Yeah, so we work with traditional audits, but we also recommend a competitive audit if you can also afford it. We have seen the class of bugs that are code are not necessarily the same between the two. Competitive audits don't guarantee that you will have good people, but in general you have a high probability that people who are skilled at what you're doing will look at it and they will find specific things in which they are very proficient. What we do is really more trying to cover everything. And we try to give guarantees in the sense that we know what we understand and we know what we don't understand at the end of an audit. With a competitive audit, it's harder to know what's been seen and what's not been seen. Yeah. And one thing we really like about the collaboration between an audit firm, like OpenZeppelin, Chain Security, or Zelleck, for example, and a competitive audit is that, for example, you do the private audit and then the researchers who are assigned on that private audit, now they have a very high context understanding of the code base, and they can prepare the notes that then arm the, or equip the community auditors to be even more effective than they would if they had just been going in blind, so to speak. They can be like, hey, watch out for these parts. These parts are especially important to check, but of course, don't let that rabbit hole you. One more thing I'd add is if you start with a private audit first, you're more likely to be told you're not ready, go back and try again. As opposed to a competition that's just gonna say, all right, it's payday. So, probably do the private art first. 400 issues. So true. Excellent point. So I'll skip around a little bit, especially for the audience who I know is here since I surveyed them earlier. Particularly for developers, what are some of the best practices you see as auditors that you wish were more widely adopted? And why do you think they may not be widely adopted? So I think developers often think about security in a later stage of a project. And they're not thinking about their code in an adversarial way from the get-go. They should do more code reviews, internals. They should do more internal audits in a way where some part of the team tries to break the protocol. I think this is very useful. Yeah Two things you can do today To improve your security Is 100% code coverage I know you guys out there You guys do not have 100% code coverage I know And the other thing is Write your functions I read this great blog post by I think it was Nillian I think they're totally right You should do function requirements and then checks and variants and then protocol and variants at the end. So you should just assert that the, like if you have like a, you know, CFAMM, just assert the constant function is still constant at the end. Or like, you know, like the whatever solvent, that kind of thing. If you just throw in a bunch of assertions at the end, it can just kill a lot of attacks, or at least mitigate them. What might have been a crit might now be a medium. Yeah, so one other thing that I wish people do a bit more is more static analysis and more formal verification. We don't see this as much, probably because it's a little bit hard to use some of these tools. Also, these tools haven't evolved, haven't benefited from enough money for R&D at this point. And also, the underlying language changes so much, so it's hard to make them really, really spot on. But yeah, it might also be a cultural thing, and this also like this is like offloaded to towards the auditor so the auditors do use these tools but like the developers themselves don't use them as much currently yeah i definitely put like a big plus on invariants and just like doing it throughout the process like both defining them building a threat model around it testing against it and even when you're going to production like monitoring and looking for for flaws in the invariance occurring later. Another thing that I think doesn't happen nearly enough is for people to include the access control and deployment process and other things, if not in the scope of the audit, then at the very least being very thorough about how that's going to impact the code. We have actually seen things that we were basically putting down as a credible vulnerability because we saw in the documentation about how they were going to deploy the code in a way that was basically going to wreck them. They actually were arguing with us saying, oh, it's not in the code. I'm like, well, it's in the docs that was in the code that was in the scope and it would have wrecked your protocol so we're going to count it. I think people, including the deployment process, is almost part of the code and scripting it and being very careful about how the keys that are signing deployments being done, using a multi-sig or something else to handle that process. And yeah, never putting yourself in a position where some EOA key on some developer's laptop is hopefully not going to get phished and wreck the protocol. And I wanted to add on to what Pietro had to say. It is true, I think all of us will empathize with the fact that a lot of teams, essentially, this is very common, and I totally understand why they feel that way, because they just need to, you know, go to market. They think of security in, like, a, oh, we'll just do it at the end kind of way. But that's really bad. It's actually more expensive. it's more slow because you're going to get an audit by one of us because all these people here are very good firms. And we're going to tell you, like, hey, your design does not work. You're going to have to rewrite this entire component, come back in two months after you've rewritten it. So before you thought you were going to launch in December and now you're launching in March. So it's like tax planning. It's like post hoc tax planning. It doesn't work. It's really bad. You should think about your security as you are building your protocol at the design phase. Yeah. Yeah. And something you said earlier is the biggest ROI splash you're going to get is catching that stuff to the left of the audit beforehand, which is not as sexy as the bug bounty business or just giving it to the auditors or all of that stuff. But I equated it to the job of Homeland Security. The best job you do to the left of the audit is never going to be talked about, but it's the highest ROI and the most difficult to calculate, avoiding those situations. Sorry. A lot of the work you do initially is also relevant to security, even if it's not security-oriented sometimes. Like, good design is something that makes security assessment much easier, even if you have been thinking about security the whole time. So I would say being good at software development helps security in general, yes. That dovetails nicely into another question I want to ask the panel here, and then maybe we'll have time for a question or two from the audience if they have some, which is talking to some folks here today who are developers early in their projects, some of them being first or second time through this process. which is talking to some folks here today who are developers early in their projects, some of them being first or second time through this process. What's the best piece of security advice you can give them at the earliest stage of their journey of creating something new? Yeah. Oh, sorry. Michael, did you want to go? Yeah, like figure out what you want your protocol to do and what you want it to not do and write them down and then like look at them while you're developing your code and then add tests for them, add assertions for them. Like we find this to be a very common problem in our audits is that we talk to the customer like, okay, so like what are you worried about? And they're like, well, you know, we don't want to get hacked. I'm like, okay, what does that mean? Right? You should know what it means for your protocol to get hacked. So then you can, like, actually think about like, okay, well, I'm worried about this or that. Basically having a real threat model. I'll add to that. Like, definitely 100% threat modeling is, like, where you should start. I think, because the other thing is, like, people like security has to scale with the project. Like, are you going to be able to afford to have, like, a full monitoring infrastructure set up, like, going to deployment if you're, like, you know, you don't have any TVL, you don't have a lot of things. Like, we will still say, like, yeah, you should probably do that. But if you, like, literally can't, you don't have the resources, like, a lot of teams security infrastructure support. But then suddenly in a couple of months, TVL has grown, it's gotten massive, there's a lot more value at stake. They never really thought through how are we going to upscale our security. I've seen people that will build up their access control and hard code in something like an EOA owner and they're like, well, maybe we should transfer it to a multi-signal. And they're like, actually, we don't know how to do that. We didn't prepare for it. That's a particularly egregious example that does exist in a billion-dollar protocol. Try looking for it, where someone just hard-coded the owner, and you just hope that whoever has that key never gets kidnapped or decides to go rogue. But just in general, be prepared to scale up your security as you have the resources't spend on it today, plan to know, okay, at some point at this level of TVL, let's start taking whatever profits might come from that and invest it in making our protocol more secure. Because most of y'all here, unless you win enough from this competition to pay for a whole audit, you can't get your code audited from a top tier firm, but maybe at some point you do or want to. And be prepared to upgrade and other things. Yeah, like you want to have escape hatches for yourself. It's kind of like lawyering stuff up. Like, has anyone here worked with lawyers before? They're like so expensive. It's like so annoying. So you tell them like, okay, okay, we don't need like this like frigging Cayman Islands, Panama thing. Just like make me the Delaware LLC and just we'll fix it later if it gets really big. But these things are, you know, lawyers are good at like, okay, yeah, we'll just move all this stuff over, it'll be fine. They're good at having these escape hatches for you because people have been making legal contracts for a long time. Think about your security in ways so that you have escape hatches for, okay, now my thing has scaled, how I'm going to keep this secure as it's growing. But you don't want to be dumping tons of money on making your protocol super fancy, secure, early on, because you probably don't need it. Yeah, I would say start really simple. You might have a lot of very good ideas, but really make the minimal protocol you can do, and you will save a lot of money on security, on audits. Reuse valid components that have been audited previously and understand how they work and the audit process will be much simpler for everybody one final thing that I'd like to add is probably what you're gonna be building 99% of the time it's not gonna be original like a lot of people have built something which is similar and you can look at what happened to that thing probably it failed probably it had some security issues probably it had some economic which is similar, and you can look at what happened to that thing. Probably it failed. Probably it had some security issues. Probably it had some economic issues, right, if it's a Web3 project. So go back, see what happened, how it failed, and make sure that your design at the very early stages and also your requirements are such that this will not happen. That's obviously very hard, but if you do it at an early stage, it's going to be much cheaper. Excellent. Any questions from the audience? Any that we could squeeze in one or two questions if people have it? Hi. So I'm building a debit card solution where I'm assuming that once a transaction is signed and went to the network, it will be successful because the whole thing is standardized. But on the parallel, I am running a consensus model which will monitor those transactions if those are successful or not. And if it fails, it will trigger the system and act accordingly. So what things I should keep in mind, like what could be the security threat which I could face? Yeah. So just understand that you're trying to build a system where someone signs a transaction, submits it, succeeds or fails, and this is just for a normal payment. So what we are trying to do, we are providing the transaction time to four to five seconds. So once the transaction is signed and sent to the network, we assume that that will be successful. But on the parallel, we are running a consensus model that will monitor those transactions and build a consensus that the transaction is successful or not. If it's successful, we are good to go. But if it fails, we will trigger the system and that system will act accordingly. Like if it fails due to network congestion or some logic error or something. So what other things i should keep in mind like what other Scenarios of which transaction could fail or how? It's hard to say exactly because i think there's a lot more i Would need to know about the system. But just off the top of my head, I would say there could be an instance where the way that you're, like the node that you're monitoring it from is somehow down. Or like I guess be prepared for whatever infrastructure you're relying on to be able to confirm success or failure. You have like a backup plan if it goes down or you're, like, ensure that someone isn't able to exploit that, making some very general assumptions here. Like, we are using blockless protocol, which have different nodes. And I think those nodes are building the consensus. Not a single node is building the consensus or a proof that a transaction is failed or successful. So I think that wouldn't be the case. But there could be something of which I should be aware about. Again, I'm trying to second guess about how your system works. But one of the things that comes up is whether the consensus algorithm has a finality gadget, whether you can actually tell whether a transaction has been finalized or not, because otherwise you'd need to wait a lot more time than four seconds. Four seconds does sound really really low though. Thank you. Time, one more question if anyone in the audience has one? One question over to the left there. Hi. So I'm not a security researcher myself, but I've seen a lot of hacks that are due to consensus mechanisms and sometimes mass social engineering of a protocol. I was wondering what do you think about how we can basically build mechanisms that are more hard-coded to prevent such exploits? More hard-coded? Yeah, because basically the human factor is more unpredictable. How can we hard-code consensus to be less... Maybe it's a difficult question. When you say consensus, do you mean like, for example, a multi-sig, does that count as consensus? Yes, and also at scale like for a DAO. For a DAO? Yeah, so transparency is very important here because it makes it a lot easier to see what you're actually voting for, for example. I think one notable example was there was one for Tornado Cache where they just proposed a thing and they were like, yeah, it totally does this, and it just did something else. So yeah, monitoring your DAO is pretty good, transparency. Another thing is just time locks. So make it so it's easy to cancel a thing that's in the pending state in the time lock. So this way there's a longer window for things that are potentially breaking to get canceled and noticed. Of course the downside there is you get a lot more latency, so if you have some critical thing that needs to get jammed through, it may make it hard to do that timely. So that's another trade-off. Do you guys have any ideas? Yeah, we've had some really fun experience, and I say fun in a sarcastic way, with DAOs that were under some form of governance attack. In one case, a whale buying a lot of tokens and trying to push through a proposal on compound that would have given them an even larger part of the treasury and then control the DAO. The way they did it was very tricky. They took a bunch of tokens they had purchased, they spread amongst a bunch of accounts. We did actually have security monitoring that picked this up as strange activity. But even then, it's like, okay, so who is a genuine new delegate and who's one of these many accounts controlled by this one entity? There's very few ways to do that in a permissionless system because it's essentially a civil attack in that sense as long as they have the resources to allocate. I think at least being aware, I think ultimately having a reputation in the ecosystem and then having some checks and balances on them and recovery mechanisms. In that case, having a multi-sig that can veto proposals if they're somehow violating the DAO but you have very specific rules, that multi-sig is elected by the DAO, they're accountable. That's where I'm starting to go towards, especially for DAOs. And for multisigs themselves, I think definitely having strong reputation. Possibly even KYC, it kind of depends. People are controversial around that. But I think if you can, if it's appropriate to say, we know these are individual people, do a signing ceremony where they're all in different places and they can verify they're all different people it's not like one guy controlling four or five different keys yeah I think it's like there's no good technical solution to these things these are just like okay having strong social mechanisms to recognize who's a good actor and who's not because it's not as easy as like Ethereum where it's like okay we're running a bunch of nodes that are all coming to deterministic answers And the general idea is just like make sure you have enough notes that they can always outvote the bad notes on the deterministic Answer with multi sigs and nows these are not determined because these are not deterministic answers are like yes This is good. Yes. This is bad. So there does have to be a lot more work on the consensus of who are the actors, why are they allowed to participate in the system, and how do you root out bad actors and prevent them from gaining control. As a shitpost, you could take the MakerDAO approach and you could make the decisions deterministic by offloading it to AI. All right, end of shitpost. It's also an interesting experiment anyways. I'm curious how it goes. So another mechanism I've seen is to make the quorum of a governance mechanism increase in size, the more contentious the vote is, so that the simple majority is not enough. So it's a variable quorum. Yeah, of course, it's like a tradeoff between how easy it is to get stuff done, same with time locks, and how safe it is. Yeah. I mean, on one end of the spectrum, it's just everything's hard-coded. On the other end of the spectrum, it's just like whatever goes. Any other final comments from the panel here today? I know we're a little bit over time, but I want to thank you all for joining. For anyone in the audience who hasn't had an opportunity to work with either Immunify or any of these firms. These are some of our favorites in the industry. There are many others that are great too, but I was really happy to put together a panel with this group because it's really great. Can't go wrong with anyone sitting up here. Anything? Any last words, panel? I think everyone on this panel is really awesome. Likewise. I agree. Very nice of you. Thank you all for joining us. Really appreciate it and hope everyone has a great rest of the week. And with that, I can let the panel go and I think we owe some rewards to our CTF participants today. Thank you all again. Vielen Dank. Thank you. Close out the day. We have here our awards for our wonderful CTF participants. We're going to go ahead and start with Slipper again. What's that? I'll let Slipper show you. All right. So in addition to your cash rewards, again, make sure that you've given your wallet information, your correct wallet information, double, triple check it, so you get your correct payment. But if Slipper is still here, we do have a physical gift for you if you wanna come up and grab it. Slipper, are you still here? Come on up real quick. So in addition to the cash, congratulations again on being the first one. Maybe you can show the rest of the participants what we'll be giving out here to the finalists. So in addition to the cash prize, we've got a nice set of Beats by Dre Studio Pro headphones for everybody to take home. And make sure you get your Immunify swag bag as well, commemorating the event here today. Let me go through and call names up to come get your stuff. I'm going to go in a random order now just because my spreadsheet is a little screwy. Wait, no, something's wrong. All right. Billy, is Billy here? Billy, come on up. Receive your gift or I can bring it to you. Billy? Here you are. Sir, congratulations. A great job done by you today. Chain security also left a little bit of swag here too, so feel free to grab something there. All right. Next, we have Tony. Tony, come on up. Congratulations to you. Way to be a finalist here in the CTF. A lot of hours spent here today. Heads down. Next, we're looking for Naoya. I hope I'm pronouncing that correctly. Is Naoya here? Naoya. Maybe that's the better pronunciation. All right, we'll hold that one off to the side. . I can call it last name. Is that all? I'm getting good username. But are you sure that's it? Yeah, this is from Mixi. No, no, no, thank you. Did you want to go next? All right, yep. Harry. Harry? All right. Congrats, great work today. Good work. Chi-Sue. Chi-Sue. Chi-Sue. Chi-Sue. Great work. You can give us one of these, j or rkskek. We've got somebody that's going by the name of just j. J. The email is rkskek and some numbers. Oh, you got one right. Okay. So that's okay. It's all the same. That's fine. Yep. So that means we're missing a bill still then right? Yeah, it's all good. Yeah, just, you can just, yeah, it's all the same. We can just pass them out. Great. All right. Perfect. Rage next. Rage. Rage, I love the hat. Good work. All right. There we go. Already new. Just need a bag. Congratulations. Great work. Great work. Thank you. great work mage intern mage intern great work M4K2. Congratulations. Vlad. Vlad, are you still here? All right, Vlad. Vlad, I think you even won your group, too, I believe. So congratulations. Nipun. Nipun. Nipun. Great work. The early leader stays on the leaderboard. And Valera, last but not least. Valera. Congratulations. Great work. Great work. Once again, thanks everybody for coming through. Thanks for participating in the CTF. I know it was a lot of hard focus work in one room all day. Please look forward to the $1.5 million Ethereum Protocol Attackathon that will be hosted soon and with the sponsors for that program. And again, a big thanks to the Ethereum Foundation for allowing us to run this event here at DEVCON and the friendly Maltese citizens. Okonami, are you still here? Okonami? Minamoi. Minimoi. And take care. Have a great rest of your week and enjoy the rest of DevCon. Thank you.