Decentralized Coordination & Responsible Disclosure with Millions at Stake

Transcript

[music] Okay. Hello everyone. Um, very nice to be here to close out this great um, section of panels around security. So, I'm very happy to be moderating this last round, decentralized coordination, responsible disclosures with millions at stake with everyone here. So, I'll let each one of you quickly to introduce yourself.

>> Okay. I'm Griff Green. I lead the DAO security fund and founded GTH, DAP Node, and a bunch of other things. I'm on a bunch of security councils. And back in the day, I actually led the White Hack Group, which rescued a lot of random projects, probably $400 million across 20 different projects or something from 2017 to 2019. >> That's going to be hard to uh one up. I'm Dennis. I'm with uh the Sky Frontier Foundation. I'm a director of engineering. I've been with Sky for 5 years back when it was still Maker Dow.

And I'm mostly focused nowadays on like setting up cyber security team but also like uh yeah coordination on the govop side for example. >> Yeah I'm Philip uh I'm head of infrastructure at Nosis uh everything on the chain side so developing it but also keeping it secure. Uh we've had some incidents lately. So yeah >> I'm Janis Mark Dakis. I'm co-founder of DOB. uh so I've been an academic researcher in program analysis for many decades and uh then moved to the smart contract space and uh we've participated in several vulnerability disclosures that were ecosystem level uh so I may have something to say for this panel

[laughter] I guess yeah this was mostly an understatement for most people on what they do um yes uh myself uh I'm Matias I'm with chain security one of the founders ers um and involved in this topic through being one of the teams which from time to time find new issues which that need to be uh disclosed responsibly and uh continuously trying to figure out how to do this and I'm actually very interested to learn from this panel how to do it better um and and and this is why why we have this topic here um yeah we'll get into a little bit more what those people are doing which they have not shared yet But perhaps to start off

incidentwise, what was the one when which kind of opened your eyes to that this thing is very hard? What was your hardest incident you had to deal with? Um yeah, let's start perhaps with uh with Yianis. I'm not sure that I will be able to pick the hardest incident to deal with because probably that was pretty far in memory, but I can pick a couple of incidents that are fresher in my memory even though they may not have been such high impact. I mean, we've had like at least a couple of incidents that were very large, so they were probably very hard uh because we were dealing with over a billion dollars, but that was

five years ago. So, they're not as fresh in my memory. Uh so I would probably just go just for vividness with uh the most recent thing that I've been involved in which was like a year and a half ago and it's something it's a vulnerability that we um we named it cimp for uh proxy in the middle of proxy. So we tried to give it a kind of an interesting name but there were a bunch of um there there were a bunch of takeovers of uninitialized proxies for many different protocols for several tens of protocols. So this required a mass disclosure and it was very hard because you have a war room with if memory serves over 50 people from many

different protocols and everyone is interested in saving their protocol at the same time. if they're saving their protocol, they're alerting the hacker or hackers as to being on their trail. So, everyone else is more at risk because uh the the proxies that were taken over were sitting there for months. I think this was done again. I may be off by a little because it's not that fresh. Uh I this was the the proxies were started to be taken over like in March I think of 25 and the rescue was in July or so. So this was a while. So the hacker had access to lots of things that were just waiting for the right time to attack a

whole bunch of protocols and there was a rescue that needed to be very tightly coordinated. And of course the very first thing I'm going to say every time you have any wide reaching rescue reach out to seal 911. I'm not going to say don't reach out to me. [laughter] So they are coordinating obviously. Uh but that's that's a very hard incident and I can say more but the the difficulty of this incident was exactly that everyone was trying to save their own protocol but by doing so they may might be alerting the hackers. So the coordination had to often say, "Hey, don't execute that just yet. Just wait a little. Well, there are these other guys

that have a lot exposed. We need to be sure that they're ready to go with their transactions first." And this was very hard to coordinate. >> Yeah. Anyone else? Uh I have some really interesting ones like the DAO and the parody multisig hack, but one I've never talked to that was actually even more difficult was uh this I'm not going to call out the ICO, but they had a basically an off by one zero error where they were accepting Ether and tokens and then when they issued the tokens when they received the tokens they gave the people who sent tokens onetenth of the amount of like ICO tokens that they were supposed to

get. So the people who put in stables got a bunch of less money, a lot less tokens than the people who put in ether. And u there was like a JavaScript error. I think you guys probably know what I'm talking about. But what was interesting was the team outsourced their technical solutions, right, to a different team. And when we were trying to reach the technical team, uh this is with the White Hack Group. We rescued a bunch of ICOs back in those days. when we tried to reach out to the technical team and I finally got a hold of the guy. He was like, "I don't work on the weekend. It was like a $12 million ICO." And I'm like, "Yeah, okay." So, he's like going to the lake with his family. I'm like, "Dude, like, well, you [ __ ] up and you

need to actually like help us understand what the problem is so we can solve it for you." And he wouldn't. He was very strong about his weekend boundary. Yeah, for me probably the most memorable incident was in uh yeah, it was called Black Thursday. I think we all some of us they remember I wasn't with uh with Maker or with Sky back then but it was basically the moment when I think collectively everyone was like is this it like is is DeFi collapsing? Are we all dying?

And there was this uh moment where like on the maker yeah back then it was still called the maker protocol like there was this person basically spamming the chain with lowball bids on on the collateral auctions and it was just like basically yeah seemingly running to basically get getting everything for free and what's unfortunate is back then I think as an industry we were really like decentralization maxing and I think that's of course a good thing but it was done in a way where everything uh had to go through like this governance delay which basically meant that as a as a project or as a team, you were basically sidelined until the delay was uh was passed. And that's something that led to a bunch of learnings and this like new

approach to how to do like uh onchain governance for live systems. basically having means to quickly uh halt and pass the systems but then still having to go through yeah basically governance and delays and all these like uh thorough steps for any changes that involve changing money or changing onchain parameters but that was a painful one and uh yeah very memorable. >> Um we had two incidents I guess in the last year. Um one of them was balancer so not directly nosis related but because we have a chain and it was a lot of the TVL of the chain uh we kind of had to or or wanted rather to uh fix it

to some degree because we are this chain and we have a DAO we have to go through a lot of governance um which is problematic because this hack basically like recovering the money it was for 9.4 4 million um we couldn't tell anyone anything but at the same time we had to get buy in from you know the DAO from the validators from the core devs and whatnot. So yeah organizing all those people all those groups and taking the decisions that we as Nosis are not allowed to take that was very complicated.

Um and so we started with a soft fork kind of to lock the money out without modifying the chain, without doing a hard fork. Um that was very unstable. So we had to quickly find a different solution which was a hard fork. And this we had to execute without the hacker being well knowing about it because if they did they could just simply move the fund somewhere else and then we would lose them again, right? Um, so it was I mean very timesensitive, very it had to be private but at the same time public.

So that was very interesting, very complicated. And then the second hack was uh linked to nosis pay or rather a uh safe module uh that we were using and that was uh quite problematic and uh couple of million were were sold as well. But also that module was used by a couple of other projects um very big ones actually with tens hundreds of millions and we also had to keep them updated without you know alerting um potential hackers that they could do the same they did to us to other protocols as well. Uh so yeah definitely very interesting times.

Perhaps following up on the last one like you mentioned the challenges but how did you then approach it like when you have to talk to in the specific case to other projects but you also need to secure yourself. Every disclosure is a risk. Which decisions did you make when? Who was able to make those decisions in the end? um who stood up to make them too, right? Sometimes you need also to to risk a little bit. Um yeah, how how did that work internally?

>> So here I will echo what Jan said earlier. Definitely contact 911. Uh they are amazing and they did a lot of the work of uh finding all the protocols, contacting all the people that were responsible for those protocols. um helping us with understanding what the issue was, how to solve it. Um basically a bit of everything, coordinating in this particular issue. Um so basically there was a hack that could not well that needed to be executed in different ways depending on uh the contract. So the attacker um found it for Nosis Bay which executed but doing it for other projects was not exactly the same. So we were able to kind of fix

on our side while at the same time alerting all the other projects. Um and then that became very interesting because I mean it's just contracts right contract addresses and then you have to find projects responsible for those contracts contact them somehow if you manage to find them and then explain to them you know what's wrong how they need to fix it and whatnot. So yeah, for one contact seal one 911 very important. Um and because it was kind of different depending sorry on the project um we were able to do everything in parallel.

So it was uh interesting and so the way we fixed it is that basically it was impossible to fix. So we white had hacked um all the saves ourselves. So all the ones of course that weren't drained yet. Uh so we basically well raced against the hacker to yeah steal all the funds before they were able to um and then as noises of course we refunded the rest that was um stolen. [laughter] >> Yes, this was surprisingly nice to see that much action because I know how scary it is to have to like press a button with like legal being there and saying we don't know. uh and better not

do anything. You are always liable for whatever you do. But not doing apparently is a smart move which in our industry is generally not a smart move. Um because then a lot of money is lost effectively. Right. >> And not only lost but goes to bad people. >> Yeah. >> And it incentivizes scammers and and thieves to come and hang out on our chain so they can steal more money. >> It drives also the next attacker, right? Um, no, this is true when you know we talked about hacks. Um, but luckily a lot of things get fixed one way or another before it's being hacked. So when you get a disclosure like

especially in the hard cases of you can't simply with your own uh wallet pause whatever you need to pause. H how do you deal with it? Perhaps let's start with like a hard case where you need to manage a DAO to do that. Uh hypothetically you get a security disclosure, you know, funds are at risk right now. Um which measures do you take? How long does it take? Um what learnings perhaps also did you have from like having been slower than you are today so that others can learn from that? How how is it done in Sky?

>> Yeah, it's a good question. I think Sky is an interesting example because the protocol has been out there for a very long time, right? It's been like running for years and went through a couple of rebrandings and like stuff being built on top. But yeah, basically it's been running and especially like the decentralized governance aspect where the actual controls of the protocol are no longer done by a foundation but rather by an onchain governance contract and you're basically forced or your your hands are tight and you're you're stuck to how that governance system works. Over the years, it has evolved towards a model as I just mentioned where if you want to make any changes, it cannot happen instantaneously, right? It has to go through a process and then even if

the voting occurred and the like the the vote has gone through then still there is a delay before it actually gets uh actioned on chain which also means that if you want to change something on chain the payload will be visible even before it executes right so that's a huge a huge problem I think um when it pertains to sky protocol itself like the pretty much the only thing we can do during a live vulnerability is either white hating, right? So just white hat hack it >> yourself and then disclose or just freeze which doesn't require this like governance delay and then fix. The problem is that if you go with that approach then you might disclose the

vulnerability especially if it's something systemic and it could affect the rest of the ecosystem. That's a more difficult uh problem. Um especially nowadays where everything seems to be instantaneous, right? Everyone is on X, everyone is just connected, everything is automated. The the adversaries are using AI as well, right? To just respond fast. So yeah, there's a few yeah a few things that can be done like specifically to sky we have this concept of uh dark spells where you basically publish uh a onchain governance payload attached to like a vote where you you cannot see the payload itself >> but rather you just have the hash basically and then when it executes then

you can have the the payload be uh be visible. That's of course a very yeah something that should very scarcely be used because it can also be used for obfiscation. So there should be like a a strong process for it in terms of when is it appropriate or not and have like proper communications around it. But yeah, those are some ways to deal with that scenario. >> Yeah, that's an interesting one. Yeah, it's true that in the past we had cases where we were able to obuscate a little bit like make a lot of noise about something, sneak in something else and and fix things this way, right? It definitely feels like those days come to an end. Um uh it is uh through the power of AI everyone is able to inspect what's

really going on and from what we see it's happening um up to that DAO proposals which um are potentially malicious the project gets informed about by just people watching. Um so so there's good things more people can watch. There is bad things in that sense that um if you know and you try to sneak in uh you you will get detected and you will cause pain. So for me the question here is a little bit what where do we go next with this right? We had some ways to disclose in the past and try to inform people but in a year from now which of these

measures will still work? which measures will we have to invent to be able to mitigate the next mass hack? Uh uh well I can speak for some of the initiatives that are up on the DAO security fund right now that are addressing this. Uh one that you put up actually the directory of value uh I think you put that up right? >> I don't and I don't in the latest one. >> Okay. Well the the directory of value is just getting the information out there of where the money is. It's actually really hard like when we did the parody multisig hack there's uh it's like finding the addresses that are actually vulnerable. How do you even do that?

Just having a list of where money is on chain that people can refer to and check to see if they're vulnerable contracts. That alone would be like really valuable. There's another one. I think personally to address your question directly, I think we have to support white hat actions. uh responsible disclosure is of course important and and valuable, but in the age of AI where every transaction is read and then used against every other contract out there, you you really need to think about, okay, I just found this bug. Who's going to how long is it going to take for someone else to find this bug? And and I don't know if that's minutes, hours, or days. So, uh, there's one initiative

that I really like that's, uh, effectively trying to create a global bug bounty for Ethereum. And, uh, there's this company, uh, there are companies out here that do this where, uh, white hats, you know, rescuing the money is the easiest part. The hardest part is actually distributing it back to people. And that's where white hats don't really want to do it. There's legal challenges. There's fear of like, how are you going to do this, right? So this initiative actually tries to separate it and it's a legal initiative for uh lawyers to come up with a legal structure to actually be able to receive money from white hats that was rescued and give them a bug bounty without KYC

and uh distribute the money to the victims and that the bounty is only paid to the legal organization and the white hat upon the claimment. receiving the money. Uh, this is the only way to align incentives in my opinion. There are projects like this that do this service where a white hat can send them money, but the way that they make money, they send all the money back to the claimants if they come and claim it, but they make money when the claimants don't claim after 3 years. They can call it abandoned property and take the money.

So, they don't have the right incentive to actually get the victims the money back. Whereas this this proposal actually is supporting the white hats. It's supporting Ethereum in total so that white hats can go wild, rescue money that's at risk, send it somewhere and know it's actually going to go back to the victims and also they will receive money when it does so they have the incentive to help the legal organization figure out how to get the money back. Um, on this I'm just wondering what about if the default of unclaimed money is the same as what happened to the DAO and it just gets added to the big fund which like works towards protecting it in the future.

>> Yes. Yes. They they can after I can't remember what it says in the proposal if it's 3 years or 5 years or seven years but they can uh start staking the money and use it in DeFi or or whatever do responsible yield. They can't take the collateral but they can use it for yield after so many years. >> Yeah. But it's a detour. You mentioned some tools. Um which other tools do we actually need for the future of like responsible disclosure at this scale? >> I don't think that there are many tools that become better in the future. But uh let's take it more broadly as what's changing in the future of responsible disclosure. Well, the one thing that's

easier is that LLMs help us as well. They are a dispassionate participant uh during a rescue. You can ask someone who keeps their cool because they are a machine and you can ask is this the right rescue plan? Is this transaction front runnable? So, at least we get a little bit of help. Uh but uh things are becoming much harder like you said we have more limited options in white hat rescues. uh everyone is analyzing transactions these days. Uh the time to find a vulnerability may be very limited like once someone knows there's a vulnerability in a protocol they can probably discover it. At the same time the diversity of vulnerabilities is a lot greater than in the past. So in the

past you know you you kind of if you had a test case that was failing you could probably find the vulnerability. Now we've had cases where the vulnerability is so obscure that you have a failing test case in your hands. You know the invariants are violated. You know something can be exploited and it takes you two weeks to see what's the right fix for the bug as you uh you may know over code that both my company and yours have audited and we've had a lot of difficulty with very obscure rounding errors. Uh so vulnerabilities can become extremely obscure. How do you deal with that? If something like a major rounding error affects multiple protocols, that would be a nightmare. But of course,

most vulnerabilities are very shallow. Uh they could be obvious things. So, uh clearly an LLM can find them for anyone and we have to worry more about the meta aspects. How do you do disclosure? How do you make the the decisions on whether to freeze, rescue or whatever is applicable in every case? And uh that doesn't change but our options are becoming a little limited in the future. And in the future, you know, nobody expected four four days ago that we'll see the largest hack ever this year. Uh in the future, we may see even more uh enormous hacks, maybe even at the chain level. Uh definitely the ability to

discover bugs uh has grown tremendously and uh who knows what's going to happen and regardless of whether it's a bug, it could be a human failure, uh it could be an obssec failure. Uh we we have lots of threats in our future and more limited options. Uh so it's definitely pretty scary. So one thing we do is this um disclosure to selected people trusted people like limited like if you have a TLP red room or whatever right so timelinewise something which a lot of people follow in the general IT security world is these 90day disclosure windows in the past um in in crypto we had cases

where it's years because it's tricky to fix even in the past, right? I I remember the Berlin hard fork. It had some it fixed some issues about gas cost which were known but to very few a year before, right? And then now you also mention new vulnerabilities which might be out there and you know about them but very few do. Um and and you have the challenge of distributing that knowledge to the right people. So if we look at projects, protocols, right? [sighs] How do you want to be informed? Do you want to know who else knows? Which

timelines do you need to react to these harder and harder problems? Um yeah, how from a researcher perspective, how should responsible disclosure of this information? So if we abstract a little bit away from the technology of like we need to white hat, we need to rescue whatever not this part but just like sharing info about a new kind of vulnerability about a weakness in a library something not known yet publicly. So to give an advantage to the defenders to prepare what do you need for that? which timelines, which information channels,

which processes internally to also know and also give trust to people like us who are disclosing that we limit that that we do the responsible thing and we don't accidentally leak it to everyone. These kind of questions. Yeah, I think um as of today, at least based on my experience, the industry still feels very tribal and very high trust in the sense that um if something happens, someone that is trusted or holds authority, which can be like someone in an auditing firm, it can be someone in a researchoriented firm or someone at one of the D5 protocols gets in gets in touch with someone that he knows from

another authority, right? or D5 protocol and then suddenly just it just happens right there is internal coordination we don't know exactly how it happens but it happens right and we end up with a war room and then it it plays out I think that I mean it it works in to some degree right but I would what I would really love to see is just more formalized and more more formalized coordination in the ecosystem right where it is known up front like okay if something happens this is the person we go to this is how to contact the person that person is 24/7 available to for these kind of matters, right? So, there's like some kind of pager duty setup configured. Um, yeah, and we we have some hands-on practice on how to

coordinate in situations like this across various organizations and teams, right? This still feels like a stretch. I don't think we're there yet. Also, because each of these organizations like DeFi protocol related organizations, auditing firms, even SEAL, um, they're also very dynamic, right? they change all the time. But uh that is my take. I think we need more like formalized and practiced coordination uh across the ecosystem basically. >> Yes, I would agree on that. Um timelines I would say are always a tough one. Like it really depends on what the issue is, right? If you have to patch a chain for example, hopefully it will take more

time than patching a contract. Um so that's a bit hard to say. But one thing I think would be interesting, well slightly different topic, but um based on what you just said, um having like projects kind of mentioning their contracts or the addresses they have, they own uh that would be very practical. Coming back to the issue we had with this reality safe module, um we knew which contracts were vulnerable but not who they belong to, right? Um, so some projects they just listed these are our production contracts, these are our test contracts, whatever. Super practical. That's great. Um, and maybe we should kind of standardize around

that. And then also, um, security standards of who like what's the email address you need to contact or the signal group or whatever. Um, there's this standard for websites like a security.txt. I think probably would be great to have this um, for smart contracts as well. I think that's one area where LLMs can help because probably right now like two years ago it would have been hard if you have a protocol to rescue to find all the current addresses of contracts but now I think probably clawed with a good database with a good CLI can give you that in 10 minutes for the most part it would be still good for protocols to

maintain that but that's another thing that thankfully has become a little easier. Uh but uh yeah, I mean it's it's very tough. Nobody can give you good answers about what to do. Nobody can give you great answers about the timeline. What's the right timeline for disclosure when the project is not being responsive but some user funds are at risk but the project refuses to fix. I think these are fairly impossible questions. So I will just ask answer an easier question. Uh so what you need during disclosure my opinion is that you need two kinds of things people with experience and people with a cool head and that those two elements are absolutely essential. So

that's why I recommend before go to seal 911 or generally find people with more experience. So uh definitely always navigate through your context to people with more experience uh first because they can help. And secondly, cool head. Cool head does not necessarily mean it's not necessarily a personality trait. It could be uh a result of only having one thing to do. So for instance, if anything has to do with public communications, there should be one person who's only doing that. They don't have to think about anything else, only that. They may be 10 times smarter or dumber than you, but they will do a

better job even if they're dumber if they only have to think about that. So, that's kind of my easy advice. Uh, even though I know I'm answering an easier question than the question you asked. >> Yeah, there's two takes out of this for me. Like we talk playbooks here because in the moment of the heat to be able to say your job is only this, someone needs to be able to make that um and and they have an easier time with following something which which has been tested before.

Then there is also the case of having an organization like what Seal grew a little bit into for incident response, right? But we are talking here not incident response per se but more responsible disclosure more something with longer timelines. Seal I know is doing this actually too right if you have an issue like you said you'll tell them and they help out to reach they have the contacts um and this still feels to me like an thing which can be approached much more holistic much more sustainable across the industry um often a question of who and who pays for it um given the threats

we case today, right? Where hacks multiplied by magnitude uh in the same amount of time. And this topic of decentralized coordination is are we are we in crisis mode where usually decentralization gets sacrificed for centralization so that more action can happen. Is it time for Ethereum to say okay we'll get back to decentralization on security later but now some organization has to deal with this and we'll set it up and we'll supercharge seal we whatever it

doesn't matter right but we centralize it is that is that the time is of this I >> I don't think so well I think there's a difference between uh central like decentralization and and having for instance there's seal 911 there's the Dow security fund the Ethereum Foundation and we all do different things and and we step into the roles and I would say it's still decentralized because we don't have a monopoly over it and I don't think that there is a way to give anybody in Ethereum a monopoly necessarily over any of these things so there is uh absolutely we need leaders and we need leaders to step up and take roles but that doesn't mean it's sacrificing decentralization

It it means that you're appreciating the value of leadership in these trying times and uh and that's okay because in the end it's it's still competitive. If there is someone who can do a better job then you give it to them instead of uh seal 911 for instance. Um but I think it's incredibly valuable to have seal 911. They basically do have a monopoly but it's uh it's not a monopoly. It's just a huge advantage on incidents response, responsible disclosure. You go to seal 911. But if they stop doing start doing a bad job or something, they don't have a monopoly on it. And I think that's it's it's just appreciating leadership. It's not doesn't make it centralized.

>> Yeah, I completely agree with that. I think that is uh what one thing I would add. What could be an idea is that even though an organization like EF wouldn't have to be like the the one holding a monopoly on that role, it could be the organization that funds and coordinates the the the setting up process basically. Right? You mentioned incident response playbooks earlier. I think right now organizations have those but they're very much internal oriented, right? And we don't really have one for like systemic issues, right? which most of the issues that come up they are systemic right?

>> Yes. >> And that that would be an initiative that I think >> yeah all the companies and teams that I know that would be supportive and they would be collaborative but no one has time or money or is incentivized to take that leading role. So that could be an opportunity for an organization like the EF >> or an initiative on the Dow security funds initiative board because this is exactly what we're trying to solve. uh is you know I think there's this is a big problem in general in in the Ethereum space everyone's focused on securing their project but actually the best way to secure your project is also to contribute to securing Ethereum you know if you if you secure your apartment

but there's no door man on the front door of the lobby you know your apartment is not very secure because they can still get in the building so pay for the doorman and you know we need more HOA a level kind of security responses in this space. Uh we need to work uh let let's get some playbooks on seal frameworks right and and get them up there and if there's a you know if there are any ideas for initiatives like talk to me because that's exactly what we want to do we want to support these bottomup initiatives.

>> Yeah that's a great call. Um I think the ideas are there right and so it's a little bit surface them know that there is actually money around to support them um many of these might become products services in the future um and and it's dearly needed right so yeah I I fully support this um before we get to Q&A from the audience also as a reminder you can use the app to ask questions. Um perhaps an outlook, right? So we we are where we are today.

Um and and I think what you have heard all in these sessions here is that in a year from now the world is already going to be very different and in 2028 we have completely different problems. Um uh but we kind of see them coming right. So for each one individually um at which point uh what what are you scared about? What will happen? What causes us to have to overthrow everything of incident response reactions to disclosures? We have seen where we need to be a lot more dramatic drastic in our actions than

than we were. What what do you see coming our way? What we should honestly prepare for because we kind of fear it even if it's just 10 20%. It's too risky. What What is coming? What do you see coming? >> I think urgency and I I honestly worry that responsible disclosure is is going to be too slow. you know, it might already be too slow and that we just need to support the white hats that hopefully, you know, it's not about going out there and just hacking whatever you see and risking the money because that if you do it, you know, not responsibly, then you are putting other protocols at risk obviously. But, you know, you can try to do some responsible disclosure, try to

get the war room, talk to Seal, but I think we're really going to have to lean on white hats to start just rescuing money because it's so hard and people are finding bugs so fast. It's uh it's just really scary. >> Yeah, I would add uh which goes back to something that was mentioned earlier. Um let's create a safe environment for white hats to do their work, right? There's actually a very specific uh uh initiative from seal called safe harbor which a project can implement and that basically yeah uses their all their frameworks to uh create an environment where a wat can basically do do the white action and not have to worry about the legal um yeah repercussions

basically and there will be like a predescribed process for handling the return of funds and also any any bounties Um yeah I mean in terms of attack vectors that could be coming uh soon because of AI mostly uh they are so vast that I think we cannot really prepare for everything like for example we have um I mean at nois we operate from the chain to basically visa like paying with a card there's so many different things in between that we cannot really account for Um, so I guess we have to defend ourselves a lot with well AI as well

because those are the same tools that are being used by attackers. And yeah, agree on the white hat thing. We need to make sure that we have good um bounty programs that it's clear when a white hat can get something. Um, and yeah, make all of that e more easy. Yeah. Um okay then we have some excellent questions here. Um perhaps the first one I want to pick up which duty do we have as protocols as researchers towards the users? Do we need to tell them? Can we just take it from them? Um

like who are we to decide? Basically, what do you think? >> I would say we're still in a phase where DeFi and especially like fully decentralized uh yeah protocols, there's not that much regulation that spells out exactly what are like the the the obligations towards users. Uh so it's it's still quite subjective. I would say from my experience or and from my perspective is our um priority should be to to protect the user's funds, right? We should not expect the user to be able to make the right decisions in the heat of the moment. We should take action collectively based on experience and based on consensus among the experts and

only then figure out like the disclosure. Make sure that it's very transparent record of what happened and when. But let's not inform the users and involve them before the funds are actually safe. [snorts] I think it's very hard to have a general recipe, but the standard advice for white hats, for ethical hackers, has been every time you do something, ask yourself, is this for the benefit of the user or is this for the benefit of your reputation, your income or whatever. So if all your actions are have a clear argumentation that they're done for the benefit of the user, then I think that's a good guiding principle. Obviously there are no absolutes.

>> Yeah, that's that's a good guiding one. Yeah. Uh we have another question here. So today public disclosure happens on X, right? So it's these kind of things where you um get a tweet um with like this transaction, you have a problem. Um you um have different forms there, right? So it's not the private disclosure, it's a public disclosure. What should happen here to allow to do these kind of disclosures better? like someone knows but they might not be in the known. We we already mentioned one obvious one

which is called seal. Um beyond that what can we recommend? >> Well the question is is about onchain disclosure right I mean it's not first of all I will dispute the premise a bit uh public coordination and disclosure does not happen on X. uh it happens on X when the hack has already taken place but otherwise disclosure if you find something that's undisclosed before you don't go on X and most ethical hackers will not go on X they will first go to uh C911 or someone who can act responsibly

uh whether there can be decentralization in this disclosure uh I think generally one can say if something happens on X, why is X not decentralized? Uh, in other words, the mission of Ethereum is to create the world's computer. If Ethereum is high throughput enough and efficient enough and secure enough, uh, we can perhaps envision that a few years from now, whatever takes the place of X will be running on Ethereum. But otherwise, I don't have a good answer. I don't think anyone should go and create a protocol, a decentralized protocol simply for disclosure.

>> Yeah. I mean, when people disclose on the blockchain, they're usually just scammers trying to get a larger bounty. That's uh that's not really because and then you know how I hear about it? Well, I hear about it on X. So like I mean that's that you disclose where people are and people aren't reading notes on the blockchain. So not yet. Yeah. Very good. Um yeah perhaps let's let's wrap up. Uh final words like for me it's more vicious usually um so that you can address all the people listening of um where they can put their effort to

make a difference to make responsible disclosure easier, better, more effective uh in the future. Um but yeah just in general closing words for each one. What what do you wish that what what you say now will have an impact in a year from now or two years from now at next Defcon we can talk about it and say yeah that was really important. >> Well on my side I think we just really need to think from first principles how to be more secure. uh responsible disclosures can happen in like uh smart contract hacks and things like that. But in the end uh most of the hacks these days are operational security and when

we have any kind of single points of failure like a private key is a single point of failure and when that's our base like building block a foundational building block then we're just not actually doing security right. If you think about it from first principles, private keys are just worthless for holding value. There's no guardrail. Imagine if your house had a button where you push a button and it explodes. That's a shitty house. And we have a shitty foundation built on top of private keys where someone gets access to that private key and all the value is lost. We need to rethink this approach.

We need to be using guard rails more effectively and and honestly just get rid of the private key for holding value. Yeah, my call out would be that uh if you're in this industry as a user but also as a contributor, I think the the most effective means to make the industry safer is to start with yourself and your own opsac uh and also your company, right? So, uh I think especially this year but a bit longer, I think we've all have this like awakening that cyber security is more than onchain uh security, right? It's also like OBSAC and infrastructure. I think it's very important to double down on that and really make that a strategic priority.

But also actually doing the work, right? Because fixing your OPSAC as a person, it's a lot of work. It's very tedious and it's easily something that gets pushed uh uh pushed further out because we're all we're all tired and stressed, you know, but it's really important and it's and it's the most effective thing to do. >> Um yeah, I guess I'll talk then to companies that are operating in crypto. um be ready in case something happens. So know who can or who should do what at what moment. Um when a security incident happens, that's not the moment to go wake up the CEO to ask for permission or ask your boss if you can kind of execute a white hat hack or who needs to do what. You have to be ready. You have to

know this person needs to do that. I mean, who's responsible for what, who can do what, and have all the tools available pretty much. >> I don't have any great advice. I don't think anyone has any fantastic advice in that respect. But everything everything we just heard is is good advice. Guard rails, if you can compartmentalize, reduce the damage. If you can at least give five minutes of thought of if something is to happen to me, uh, what am I going to do? Definitely if you can improve your OBSSE, it's not going to be the case in the future that the highest value vulnerabilities will be OBSC vulnerabilities. We will see a chain level vulnerability. We will see a cryptography level vulnerability for

sure in the next 10 years. There are major threats happening and then there's going to be a very intense social effort to recover from that. But I think we will see more than just uh private keys stolen. So keep a cool head, have some plan and always reach out for more experienced people. Have a plan to know who to ask for if it's only your protocol affected. If it's the ecosystem level, of course, we hope for cool heads uh that can make the right decisions at the right time.

But there can be very serious vulnerabilities lurking ahead of us. [music]