Securing Billions in Crypto

Transcript

Cool. Uh, welcome everyone to the securing billions uh, panel. Here we've got Michael, head of solutions engineering at Turnkey. We have Yolanda, chief security architect at Coinbase, and Anders from Brownworth. I'd love to start off with just a brief introduction from everyone. Um, I am Samara, head of growth over at Cantina. Uh, we're a security platform who has worked with a bunch of people in this room. Um and I will pass it over to Anders first. >> Hello. Uh so I'm Anders Brown. Currently I work at Radius. We were a sponsor of the event. So uh there there that's uh you know so so it's stated. Uh I uh used to work at circles sort of an early

employee there. Built uh the cold storage operation there. So um that's why I'm here. >> Hi Yolanda. um about eight years at Coinbase when I started um sort of designed from scratch and green field with a small team of engineers what at that time was going to custody about maybe given the 2018 downturn you know $6 billion of AU we had on the platform have continued to work with the team to evolve that as we're looking at today's crypto prices maybe going to push half a trillion before the end of the year >> everyone I'm Michael Llewellyn uh actually just recently joined the team at turnkey But uh my last background was at Open Zeppelin for about four years.

Did a lot of smart contract security audits. Worked with a few DeFi protocols. Pulled a few of them out of hot water and some uh and then had a brief stint at blockage for joining the turnkey team. >> Awesome. Let's dive into it first with the meaty stuff. So many teams still treat an audit respon uh audit report as kind of a seal of approval. How do you explain to people that they are only like one slice of the the Swiss cheese model that we're all familiar with? Like why are why is a layered defense a non-negotiable at this point?

>> I guess I can add that like it opens up when this is always an interesting conversation with clients because obviously you want them to buy your audit services. Um which first of all I'll say that calling them audit services is probably not great. Most smart contract uh audits are just security reviews. They're not really going by a standard. Um but yeah, we I think the biggest challenge we had is that we would review a smart contract protocol and we would mention the fact that like by the way every all the these uh roles you've carved out for like admin controls and upgrades are like uh you know there's a lot of assumptions that you're going to control these securely. Uh and then you'll often see smart contract hacks that are more just private key exposure. Uh so our our challenge there was like kind of having

to like push our clients to consider the risks of things that were kind of out of scope for the work we were doing at the time. Um and then also convincing them like hey you should consider a threat model. You consider ways that these things might go wrong that are kind of outside the scope of what we're doing. Uh and have some sort of monitoring in place. Think about like what are some disasters that could occur. So, we tried to kind of just tell them like here are ways that could go wrong beyond what we are trying to help secure for you. On top of the fact that, you know, there's never a guarantee that an external review is going to catch all the bugs either. Um, and it's just a snapshot in time. Like if they upgrade the code or they change the code later, that report

is really only going to apply to that particular version of the code. So, you have to do kind of rolling audits or rolling security reviews if you kind of want to like maintain that level of assuredness. Um, and so yeah, it's it's generally telling people like this is an ongoing effort. This isn't like you audit, you deploy, you're done. Um but yeah curious what other people think. >> I think on that note as well uh that mentality has kind of shifted. They said in the first panel like the understanding that security is becoming like more of a uh necessity is shifting. Back couple of years ago people were like I don't need an audit everything is fine. Now it's like I need seven audits threat modeling all of the things. Yeah.

Did anyone else want to add to that question? >> Yeah. So when you there's one thing to build a system um have what you think is like a very secure tech stack that you've done auditing um for all like the hardware as well as like software tech stack they're using it's another thing to operate securely right so you know one thing to take away is that in addition to having a trusted tech stack um that you've built to make sure it's operated and maintained securely and making sure you've got the right sort of like segregation of duties as well as consensus enforcements all the way through up up and down laterally as well as like vertically in each stack, right?

Um like what you know one one of the best practices that we do is like talking about like continuous audits. Oftentimes audits are point in time check, right? You actually want to verify you're actually operating and maintaining your systems per you know what you had set as a policy. Um it is very natural is that you're going to see drift in operations. No time have I ever designed a system that actually was actually built the way we originally architected. I think all of you know this, right? The same as when you develop software, your initial design concept actually isn't what you put into production. So, it's good to go back and sort of check your guard rails, your hard limits and variance, and to be able to do that continuous regression testing of your actual operations deployment.

>> Cool. And kind of building on that, maybe too big a question for this short time, but in a nutshell, how would each of you describe what true coverage looks like for a protocol? >> I would say you start by threat modeling before you've written anything. Probably like if you talk about full coverage, it starts before you've written any code. And then I could go through the whole like software development life cycle, but you generally would follow a pattern of how that code gets built out over time. And then once it's actually in production, you you probably are. I would say uh one measure that I think I'm trying to stress now now that I no longer work at an audit company, I'm stressing it even more than I would have otherwise is if you're paying external

security vendors more than you're spending on internal security in terms of like having like paying like having an additional like security personnel to handle like your internal security, making sure that personnel's laptops are secure, making sure that uh you know everything related to the operations. Um, even if most of that code is like an on onchain smart contract, like you're focused on that and you're also doing internal security reviews before you use external vendors. Like if if you're lopsided and you're spending most of your money on external security reviews um or bug bounties or things like that or code competitions that are very uh you you can performatively say look how much we're spending on security but like the value you're getting back for that is probably not as good um as if you just invested in an internal practice that's going to be like much quieter but

probably much more effective at actually avoiding like bad things from getting into production or happening in production when you're operating. Um, so that I would say full coverage means that you have strong internal ownership and when something goes wrong, you're not relying on any external vendor to handle it. You might still like have them support you or or bring in external vendors to like point out things you might not have caught on your own, but you should have like really strong internal ownership. And I think that's something that some protocols struggle with, especially if they're also decentralized or they don't have like a clear uh like command structure effectively for like who's running security, who would handle an incident, who would do a hot fix, that sort of thing. Cool.

Yeah. And I think uh we've had conversations before with people at Coinbase speaking to the importance of those internal processes in terms of how much they you know in the event something does happen, it it sets you up for success and obviously helps mitigate it happening as well. Uh sorry, you go. >> I just want to add one thing. I think this goes back many many years. um regardless of whether you're doing proof of work or or a proof ofstake network is it might be a decentralized protocol but you can actually see very centralized behaviors right depending on like the token ownership how the staking is centralized and whatnot. So that's the very first thing because once you

although it's labeled decentralized but if the operations and execution of that protocol actually is very centralized then what you're giving up is actually at the end of the day control of anything that's built on it and that means you're giving up custodial right that a token that you believe you own in your wallet actually belongs to you. >> Cool. And jumping into the more lessonsy side of the conversation. So, Yolanda, from your vantage point at Coinbase, you work with hundreds of uh partners and integrations, what's the most common security gap you see after that that first audit with them?

>> Um, give me a little bit time to think about that. We actually have a whole team that like works on like the partnership audits. Usually, they're auditing us, right? It's it's the way we look at it. Um, and it varies depending on whether you're talking about um a a protocol integration, if we're looking at um integrating with like a thirdparty staking service provider um so like or we're looking at a M&A target to bring in sort of their um you know crypto native product and or their uh you know crypto financial product into our domain. So, >> Gotcha. on that last one with the M&A, what does that process look like without giving too much of the the secret source

away in terms of the security review outward? >> I mean, I I'll tell you we 90% of what we do is motherhood and apple pie cyber security best practices, right? Um I would say there hasn't been a team that I've looked at in the last 12 months that hasn't been owned by the DPRK at least once in the last 5 years or since COVID, right? So that's given, right? Like that should no longer be a surprise. Then after that, it's like what was the um what was the team's reaction? How do they remediate it? What's their confidence 24 36 months later that um they're still not being targeted, right? And so um those are what you know those are the things we're looking at from like a you know securing the billions um angle and perspective.

Um and then everything else is um you know what does your perimeter look like? What have you outsourced right? um what do you insource? What's the bench that you're you know you're working with? Um you know the traditional like cyber security practices, identity, asset management, access management. >> And that ties into a question I had for Michael. So when an incident does happen, what in your opinion separates the teams that recover successfully from those who kind of collapse afterwards?

Um, it kind of gets back to probably what I said earlier of like there's someone that is going to be in charge as soon as the incident hits. There's there's an immediate understanding of like who needs to do what uh or at the very least who needs to decide what to do next. Um, there's like kind of this joke in like the kind of wider security like web security world is that like whenever there's a an incident, people just like hop into a telegram chat and just like start figuring it out. Uh, and these can classically become very like unwieldy. you start adding too many people, which is bad because not only can that be confusing, you might expose key details to people that don't need to know it and and might not use that information uh securely. Uh so like I've seen this done really well and really

poorly. And the ones that do really well are the ones that have like someone who's like incident commander number one, whether that's an external vendor you've hired to handle your incident response 247. Zero Shadow is an example of this. Uh or you have an internal security lead and they're on call. they know that it's their job to respond immediately to bring in the people that they need and only those people. Um, and then from there like having I think really strong connections in the community because if you are in an incident where unfortunately funds might be lost or might be stolen like it speed is of the essence like you need to figure out where's the money going, you need to have people that can trace it quickly. You need to figure out who you need to reach out to potentially freeze it. That's very difficult. Um, ideally

you never have to get to that point, but if you do, like you it's really hard to go through any official channel to get like an exchange or a stable coin issuer or a smart contract protocol that if they even have the power to freeze it uh to get them to do it quickly. Um, so if you have established connections and you know exactly who you need to reach out to to like expedite that process, that makes a world of difference. And that's why like if you don't have those contacts then like finding uh someone that does or or working hard to establish them over time I think is what distinguishes like really good security leads at protocols versus ones that are just delegating a lot of that responsibility to external vendors or others. I think that's like the the relationship component is like what

makes like head of security versus like a security engineer. >> Cool. And Anders one for you. What would you say the biggest learning was in terms of uh securing the cold wallet storage system back at Circle? >> Yeah, so uh I mean it it it really comes down to what worked once uh doesn't work when the value 10 x's, 100 x's, thousand x's, whatever it might be, right? So, uh, if you are trying to store something that's worth a million dollars, you know, maybe makes sense to spend $100,000 and try to attack that, right? Doesn't make sense to spend 10 million or a hundred

million, but that does if you're securing billions, right? So what infrastructure you created early on for your you know you think about it like if you have a um a consumer shows up right and they they are told oh you know remember the seed phrase write it down somewhere what is this you know why am I doing this right and uh you know down the road that seed phrase could be securing quite a lot of value so you know that that's why people that are building hardware wallets for example or MetaMask whatever they're trying to impress on you that you need to treat treat this carefully. Um, you know, but there there's there's more than just simply, you know, the value sort of just

gets out of control and you have to constantly go back and look at, you know, and what is what I'm doing adequate here. It's also, you know, what are what are you storing? You know, you're you're you have these very simple primitives in your mind. this value is controlled by this private key. Well, I mean, yeah, but totally completely, you know, kind of to get what to what Yolandre was saying, you know, there's that is one thing, but if you can overtake a chain, anyone can can take that value or remove that value, right?

So, not necessarily the only thing. It's a very important thing, but like so you got to really kind of break everything down and suddenly things that were so simple look extraordinarily complex. Like what does it mean to own a digital to hold a digital asset, right? You don't have ETH, you have the power to spend ETH. That's different. And you kind of got to go through those thoughts, right? And that's true of really any digital asset. So, um, yeah, like kind of taking something that looks simple and it gets like extraordinarily hard.

>> Is there something I can add on to that? Um, you know, one of the things that, um, our blockchain security team now is trying to do is make sure we get in as much observability of what's happening on chain as possible, right? You cannot detect or anticipate incidents if you don't have the observability. Right? Now, almost everything that happens in incident, everything we learn is post incident, right? Oh, now then I had my blockchain analytics team go on there. There's, you know, onchain threat intel team go and do like the retroactive, you know, TTP, you know, formation and whatnot. Actually, one of our experts in like um onchain monitoring um is right back right there. Don Ryan, you can talk to him and he's right now like owning how do we get that right level of

observability and all the smart contracts we deploy. Um you know, we get in there. So then eventually once we have the observability in and we know what the TTPs are hopefully we can start writing sort of detections and if you know I don't think we've cracked the nut yet but we're trying to get there is like how do we get into a state where we can actually start building and this is a good hard problem for you guys to be thinking about is like if you want to get into the space how do you get leading indicators of compromise right are you looking at just at mainnet are you also looking at testn net behaviors and what are the signals that you should be looking for >> I'll just like say I agreed everything you just said and I was having to tackle some of these issues when I was at open

sap and figuring out how do we help clients with monitoring and it was like I think the people that put in the work to actually have like the observability to detect things ahead of time or at least have a good chance of it like probably distinguishes like great teams from good teams. Um like it's it's really hard but it's like very it makes the biggest difference in potentially being able to like stop an attack. >> And I'll add on to that it's not just onchain observability, you also need internal observability as well, right? Because look, you have DPRK like you know throwing a thousand resumes at you in a month, right? You like you might think you've caught all thousand of them, but you might have missed like the one, right? And so internal observability anomalies um you know a

couple of you know the larger hacks. I think the KN hack that we just saw yesterday um you know what looks like the transaction you're signing isn't the transaction you're signing right. >> Yeah. Yeah, and I think that has been a trend over the past year or so in terms of the hacks that we've been seeing have really had to do with the smart contracts themselves. It's going back to like traditional OPSAC processes, everything. Um, and I think all of you touched on a very important point in terms of like proactive security versus reactive security, which is yeah, you're also working within a company that has a uh, you know, a business to run. And so suddenly they might turn around and buy

an exchange and suddenly you have all these assets that you had no idea you were going to have to secure that you have to secure. So yeah, there you have a lot of pieces to that. >> Goes back to that uh continuous security mentality Michael was talking about. Definitely. Um, next question for Anders. Kind of building on what you were talking about before, but you know, one motto that you'd uh put forward in terms of how to apply that proactive forwardinking mentality to security. >> Sorry, what is the question?

>> Uh, what would your motto be? >> Oh, what the motto be? Oh. Oh. Oh my goodness. What would the mo Well, yeah. I mean, uh, uh, treat everything as if it could, uh, 100x tomorrow. And, and you know, are you doing the right thing? Uh, you know, the answer is always no. Um, you're going to spend more time sort of thinking about potential ways this could go than you are going to be actually doing anything. >> Yeah. Yeah. And I think that um maybe paranoia is too strong a word, but that is No, it's not. Okay, cool. I have seen that mentality in the best security people I know and that that is how they live. Um

>> all right, so question for Michael, but kind of branching out to everyone. Uh you have taken a public stand against the criminalization of software development by suing the DOJ. One related concern that we hear within the security circles is whether white hat rescue operations could kind of face the same legal risk. Is that something you envis envisage happening? >> It's a good question. I I think I'll just briefly explain the lawsuit because it's slightly separate issue. Um, but the lawsuit is kind of related to the tornado cash and samurai wallet cases we've seen over the last year, which is basically like are developers liable for

code they deploy if they don't actually have control of the funds that that code is operating, which would be in the case of privacy pools, criminals like North Korea moving money. Um, the answer from Fininsen in 2019 was effectively no and the DOJ later on decided we're going to actually come up with a different answer and prosecute people under those lines. So that my lawsuit is basically like you can't you shouldn't be able to do that. Like that's there's a due process problem there. broader question of like you know how should we regulate privacy protocols like let's bunt that for something else I think coming back so that's why I'm suing the DOJ um but the loss the the like white hat issue I think is a tricky one uh the security alliance has put out something called safe harbor to kind of try to address

this which is basically hey we want to carve out an area where if in very specific circumstances and I think this is a key point you are a white hat and you see that this protocol is about to be hacked imminently hacked and the only thing that you could feasibly see as a way to save those funds is to hack it before the hacker. Um, then we'll carve out a legal area where you can do so. You've been kind of given legal permission to do so and there's a process by which you will return the funds promptly to the protocol uh and potentially be rewarded for it. Um, I think it it is very controversial because it kind of you have to be make sure that the people that are interpreting this are interpreting it well and then executing on it well. Um, it's not like a free

pass to hack a protocol and then say like, "Oh, well, I found a bug." It's like, well, no, if you found a bug, the the straightforward practice is always to report is always to report it through bug bounty platform, email disclosure, whatever. Um, and so you have to be very careful. The only circumstances where I would normally see this being applicable is like if you literally saw a transaction like in the me poolool like about to rug the protocol and you could like frontr run that transaction instead. It's like I there might be other circumstances for sure, but like that's probably the most realistic one we'll likely see. Um, so I I I think in principle, yes, there should be like protections for developers there, but I I'm also a skeptic of how widely we promote that because I do think it's like one a very very specific scenario

that doesn't come up a lot for hacks. Um, and we want to be careful about how much we tell people to like proactively white hat things when the best practice is to disclose and like do no harm. Um, so I think that's the caution I come up with. I'm glad that there's kind of like a recognition that like white hats in these scenarios should be protected. But I also think that um, yeah, we just have to be careful about like what sort of like standards we're setting. And I I would also say like uh, this is a very uncommon thing. You probably never see this in normal like you know, fintech world. Like you know, it doesn't matter if you were hacking for honest intentions. No one would be okay with that. And you have to consider like are the teams that are going to like

implement safe harbor uh are they willing to take kind of the legal risk of the fact that they're putting this out there and saying like it's okay and and hope that people will interpret this correctly and operate effectively. So that's my kind of uh middle of the road take of like good thing but comes with a lot of caveats and I would I would stress teams that like would want to implement safe harbor really think through that and define what they consider to be appropriate scenarios um and and whether those might even exist. Um, so I could say more on that, but I'll stop it there. >> Did anyone else want to add anything to that question or should we jump to the next one?

>> Cool. All right. So, last section. Each of you obviously comes from heavy security pedigree, strong background, but now we're not just looking at things from like an attack vector point of view. We're looking at them from how institutions will look at it, how it kind of how regulation applies. Do you think with this in mind the industry will move forward kind of applying security standards as a whole? Do you think it'll be more on like an ecosystem level? How do you see that progressing as as we kind of mature as a whole?

>> I'll take a cut at this because I actually do work a lot with regulators around the world. ideally before the regulations come out and the standards come out. Um and one of them I'm working with is this um the single core standards board that's actually trying to put out um you know cyber security standards for digital ledger technologies and blockchains and you know as we've gone through this process in the last 18 months like you're bringing in both crypto academic and sort of treadfi and cyber security experts and we're like wow most of this is actually just best practices of standard you know security operations for any enterprise right there's only a very small sliver coming out there and so you know you don't want to create yet another audit platform right yet another

set of regulations that you know might conflict or you know eventually sort of diverge and so like how do you cover that properly I think part of it is like tying back to sort of like the principles of availability um integrity and confidentiality um on behalf of you know the constituents in that particular regulatory domain right and so like when you're working with whether it's like a Singaporean um regulator or like recently, you know, a lot of exchanges are going after the Mika license in the EU, right? The principles that they care about are all basically the same. They tie back to a lot of the guarantees that people are used to seeing in the traditional finance um world and and it's just a

matter of like the degree to which they care about it and then how we solve for that, right? And what we're trying to do I think as we talk to these regulators is to um let them understand that you know at the end of the day we are ensuring custodial ability and ability to you know quickly identify and return funds to customers at the end of the day. And what that security stack looks like underneath there is is a it's a tech stack question right it's not something that you need to regulate um but you just have to ensure you're be able to like deliver on that capability.

So what we're seeing now is like very high level um concepts of custodial um of assets and return to um customers and clients as opposed to going down to specific you must use a hardware security module, you must use this particular cryptographic standard and whatnot. And we don't want that because this ecosystem is still primordial soup, right? There are new curbs coming out. um they're new, you know, protocol efficiencies that require different compute stacks and structures. And so if you regulate to that level, you're not going to promote uh evolution and quick evolution that the ecosystem needs.

>> So you'd say it's more of like an educational piece on both sides in terms of how they can meet the needs of each other, >> right? >> Yeah. >> Yeah. Ongoing ongoing, you know, uh education. It's not a uh you know I wouldn't say anybody really has this all kind of figured out. So it's it's a back and forth thing but generally there's a lot to be done and the education side before you know we start putting things down very specifically in law. >> Cool. And then the final question for today because I always like to end on something tangible and a couple of you have mentioned something in this direction already, but in terms of one security practice for every team that

they can take away to educate on both sides, meet the needs in terms of minimizing the attack vectors, but also ticking the boxes of making institutions feel comfortable as well. if there's one thing that they can do today. >> Okay, I'll start easy plug uh private key management uh with why I joined turnkey. Um but but I think like practical and and understanding what are the risks. Um so like you know if usually if you're doing crypto business in some way you're going to be touching private keys you're going to be using private keys. So understanding like what are the risks you're going to see there.

You could have very sensitive private keys that are controlling large amounts of money or are going to be uh like managing really like critical privilege permissions and smart contracts and those need to be like high level of security and probably multiple approval steps and redundancy. no reliance on any one person having control. Um, but you you definitely need to then balance that with like how often do these keys need to be used? How often do they need to be accessed? Um, and then how are you how are you like physically securing those keys? You could do a very uh rudiment not maybe not rudimentary but like a very bare bones like uh like cold storage setup where the keys are are completely airgapped. They're they're uh they're separated. Uh but then you know using that regularly is going to create

issues which is either going to mean you're going to have slow business operations or you're going to some you will inevitably start taking shortcuts that will undermine the security you're trying to go for. So trying to find like good balances. I like the turnkey approach because it lives in a uh essentially a secure enclave. Um it's got a large amount of uh protections built around it but it can still be accessed through an API key. Um but if let's say something went wrong with the API key or and you can also use like normal Google alloth or or other things for user uh facing applications but you know those things can still be hacked. So like we also build policies into the enclave itself that can define like you know what can this key be used for who can use it and in what way uh you can

you know whitelist the address the where accounts can go. So a bit of a plug but I would say like coming down to like in order to implement that effectively um you have to know like what am I using this key for? what are the risks it could be exposed to? How do I balance business efficiency with like securing it as best as possible? Um, so I I think turnkey is a great tool for that, but it's like not going to do you any good if you don't think through how I should use this effectively because ours is very like API primitive driven. There are other solutions out there that are a little bit more uh plug-and-play, but they they're all going to have their own trade-offs if you're not and you know might create issues either on the business side or the security side if

you don't think through like where do I need to sit on that spectrum? Go for it. I I I would argue that you you need to uh sort of promote a culture of uh you know just operational security like what is what does that look like and and um you know not if but when you have incidents you you handle them quickly and and uh you know so everyone in the organization is aware of what we're doing you know about this and so you don't you know something doesn't get ahead of you cannot you know You cannot ignore things. Uh you have to you know be very very clear and obvious about it.

>> Fire drills. I >> actually have two things. Number one consensus enforcement all the way down and up the stack right and where you can cryptographically or mathematically enforce consensus. Um so that you know that's one principle. Um and the second principle is you have to track the original intent. you know get a signature to attest to it that um that you trust and you have to verify that intent at every single service that touches that same transaction right you cannot trust that it has not been modified whether it went through the ledger properly it went to your um bitcoin you know transaction unsigned transaction after it's been signed you have to unpack that transaction and

reverify the transaction parameters are what was originally um registered as an intent and it has to be done in a separate thread And ideally, it's parsed after it's been signed um by two different parsers to verify the integrity of that transaction before you ever broadcast it. >> All very solid suggestions. Awesome. Thank you all three of you. >> We also have some time for Q&A if anybody's interested. Uh kind of cool to have a bunch of um wallet uh vendors up here if to when you were starting out um talking to

customers to institutions. What was the craziest amount of crypto on the craziest, you know, wallet structure like $80 million on a ledger in somebody's, you know, closet? What What's a story? You don't obviously don't have to name names, but Yolanda, you can probably go first because you're laughing. >> Um um remember in the early days there was like um very early like okay this is 2018. This is when I like started diving into crypto like there was a address for like ETH and then I think ETH Classic, right? and they were like was one of the Ethereum tokens, but like there were two

different formats and you could literally like black hole your tokens by sending them to the wrong network. Like I can't tell you how many times that happened. Um uh you know other crazy things are like you know people wanting to you know at the peak of like you know um board ape like people buying them and putting on their wallets on their on a phone on their back pocket you know those some of those you know wallets uh those apes were like pushing a you know seven figures right so >> the trenches >> yeah I remember those days around that same time I remember there was one project we did an audit with and uh they had it was a smart contract for a token.

That token was trading in the billion dollar like market cap range and they had a the the worst access control permission setup. They had an admin and a super admin and an owner and it was like what are the difference between these three. Um and one of those permissions had like uh had basically god rights like it could move anyone's token. It could do whatever it wanted. God knows why they put that in there in the first place. Uh but the worst part was they had hardcoded it. it was an immutable thing and it was sitting on some developer's laptop. Um, so you you're basically in a position where it's like you can either go through an incredibly painful and public migration to get off this thing or you are just going to have to take the chance that that developer and that laptop are

haven't already exposed that key. It was like your your only recourse is to like I guess burn the laptop, kill the developer and like just hope that no one ever finds out about it. >> Oh, that's terrifying. >> Yeah, you you you can't prove that you do not know a private key. It's impossible to prove. Um I there are many stories. Uh the one of them was uh a backup in mom's basement. I have to leave it I have to leave it there. But it was a very very very significant amount of money was literally in mom's basement. So >> a story of 250 million on a hot wallet phone. Uh I was very >> This was a lot more than that.

Yeah, when I heard your discussions on security, it reminded me a lot of like when a manufacturing concern underos an ISO 9000 audit or or QTL 14,000 audit. Um, is there any overlap between those worlds? >> So, there are like exchanges out there especially um in like you know it just depends on like what your customers ask for and you know what regulatory regimes that you're working in. So ISO 27,0001 is like the standard one you're going to see um teams go after is is turnkey going I I turn key at some point was maybe thinking about going after that.

Um but at the end of the day like when you do these audits you got to ask the most important question here what's the scope of the audit right they'll show you the certificate or whatever that the audit you know statement sa but then the scope was so small it doesn't actually touch the most critical services right so yeah that's usually the one I I'm I'm coming by these days is ISO 2701 I know ISO is working on sort of like a blockchain standards I think you know they've drafted something but that standards bodies work so slowly like you're probably going to see it in like a decade right but in the meantime we have to continue to build and scale securely >> so I think one thing in that direction

as well at cantina we've been working on actually with um Coinbase inspired by ISO 2001 is a set of security risk regulatory operational assessment ments that tow the line between both worlds. Um, so you can take a look through that framework if you'd like. Plug. >> Yeah. >> Hey, how you doing? My name is Mario Butler. This question is geared towards uh to Yolanda. I heard you I'm the founder of Dreamster Music. Uh we're a web 3 music tech company and uh I heard you mention something about um the Mika Mika regulatory authority over in the EU. And so we are we've worked with um

uh Mika, we worked with um Barra, you know, we've been based in Dubai, we're based in the EU, right? Right. And so now that uh you know crypto is becoming more relevant and more um I just say more you know more regulatory now in the United States. What aside from the SEC what regulatory authority do we are we putting in place here in the United States that is you know going to give us more clarity and more clarification on why we should come back to the United States to do what we're doing. you know, some of because we've been doing a lot of business, you know, in offshore jurisdictions, you know, for quite some time, >> right? No, I mean, this is a great question. I've worked with both of those

regulators. I think in the interest of keeping us on schedule and then I think there's another regulatory panel later, why don't we just take this offline? Um, happy to talk to you oneonone. >> Yeah, and we do have a regulatory panel later with four of the most excellent policy people in Boston. >> Hello. Uh so my question is um guess kind of building off to like regulation um when you're looking at like a potential customer that um you might be doing a like a audit for um depending on like where they're station located and all that kind of stuff. Um and maybe the potential friction of like you know maybe what they're trying to do. Um, does that ever kind of make you try to

lean towards, you know, maybe certain locations or markets uh that you try to target customers for? Um, and if not, uh, I guess what would that reason be? >> I I guess to understand the question, you're just saying like do do you target customers in certain jurisdictions that have certain needs for security audits or things like that? So let's say like I don't know like there's like certain um maybe like there's like a certain you know web 3 company that uh has like some sort of use case that um there might be regulatory concerns.

>> Oh, so I'll give you an example of that. So for example like gambling is legal here in the US, right? But gambling is completely forbidden in the Middle East, right? So that could be like a web 3 use case that you know is you know is perfectly valid here in the in the US. We could you know launch sort of uh a gambling prediction markets type thing on like the base chain or whatever. I would never bring that into like Saudi Arabia or the UAE, right? And and that and those are those are like the very like regional cultural sort of like divides that we have to we have to um sort of like work and as and really honestly the compliance and like the product design people help us tread that from a security perspective like we need

to secure the smart contract the application um that protocol irrespective of like what region can actually and what regions customers and clients can work on it. So I would say like from a security perspective I at least am agnostic to that. >> Yeah. I would say like if you have if this is a concern with secure auditors you should work with like legal professionals to define the requirements that the smart contracts need to operate under and they can audit against that. They can say does it satisfy these properties technically, but they're not going to likely be able to come up or or even be willing to define on paper what your legal requirements are. You probably need to figure that out separately. Some audit firms will tailor that and they'll they'll have legal professionals they'll they'll pair in together, but most would treat that as a

separate concern. >> Goes back to the scope of the audit like if that's included in it. >> Any final questions? >> I think that's all we have time for. So I can give them a round of applause. I hope you can see why I like this panel now. Um, we can take some bikes off the trails.