Can Standards Really Make Blockchain More Secure?

Transcript

All right. >> Closer. >> How about now? All right, that sounds better. I got the thumbs up over there. So, thank you. And I was able to waste like 15 seconds of the presentation. So, um, thanks for being here. We're really excited to talk a little bit about, um, our standards and the blockchain security standards council and the work we're doing. But first, let me introduce our, uh, panelists. So the first is Hot Carpinelli. He's the head of security services at Open Zeppelin. So >> hi everyone. Yeah. Uh of security services at Open Zeppelin. Joined the company around 7 years ago. Have been working at the beginning uh in open sink

contract. So I kind of like understand why it's important to uh start discussing about standards and how important they are for our ecosystem. And uh yeah, I'm super happy to be here. >> Awesome. And then next, and I always mess up Max's, we're just gonna go with Max. Max is a security architect and red team lead at Figment. >> Yeah. Hey everyone. I've been Figment for about two years now. Um, largely in offensive security. I do security architecture. So that's like broad design, a lot of uh design review, system review, and I lead the red team.

Um, so in the red team, you know, we're trying to think like attackers, study attackers, understand how they break into systems, uh, and get there before they do. All right. And the last uh panelist we have is Joel Kerr. He's the head of DeFi security at uh Coinbase. So go ahead Joel. >> Hey everyone. My name is Joel Kerr. I'm at Coinbase. Uh I run the DeFi security team there. So we do everything related to the offchain components with custodial nodes, key management to the onchain pieces of what we list from both the retail deck side of it to the exchange side of it. Um, so it's the whole gambit of technical security, security architecture for Coinbase.

>> Awesome. Thank you. Um, so let me start with the first question. It's kind of a guess a little bit of a basic question, but you know, we all these you three are all members of the blockchain security standards council. You joined for a reason. So, and with that initial question, so why why are you why did you join? Why why standards? What made you want to come and help develop standards around blockchain? What was the what was the driving force around that? I'll start with uh with Joel and we'll work this way. >> Excellent. All right. So, uh I've been at Coinbase for four years. We've been building secure, you know, technology and services that entire time. Um so, I have two main things that I wanted to have with this this standards council.

one was, you know, taking a lot of the learnings, best practices, um, everything we've been doing for the past, you know, I mean, Coinbase has been around for a very long time. For all that time, putting them in a format that is, you know, public that both, you know, developers, retail investors, institutional investors, they can all look at it and say, "Okay, these are the baselines that we want to agree upon. This is what a security secure token looks like. is a secure um system looks like for web 3. So make that public and make that so people can contribute.

Second one is we have a lot of fantastic companies in the BCC. I mean Figment, Open Zeppelin, I love working with them. They are also top tier in their class and so I'm you know selfishly I think we have a good program but working with them I get to see even more of what what these other talents and other companies bring. >> Go ahead Max. >> Yeah. Yeah. So I think you kind of covered it. Uh we got like a lot of different backgrounds. Um and because the industry is pretty complex, you need the various backgrounds. Um you know at Figment we're we're node operator. We operate um validators. We operate a lot of nodes. Um we're we're a lot uh you know we focus a lot on the offchain security side. Um so in integrating with you guys and talking about DeFi, talking

about more onchain security too uh is a good thing and it levels the playing field. Um and I think we bring a pretty unique angle to um to to security as well right? >> Um in in our case, Open Zeppelin, as you uh know, we have been building secure smart contracts for the last uh 80 years. Um we also perform audits and we've seen so many times uh code that is not secure and we're kind of like trying to find other ways of taking security to the next level and just by seeing other industries that are not smart contracts they all follow standards and I think there's a reason

for that. Uh when you build smart contracts you also follow uh some standards. ERC20 is a standard. ERC 721 is a standard and these standards kind of like define the way we interact with smart contracts and the way we operate with smart contracts but also how we build smart contracts. So uh bringing standards throughout this the development life cycle but not only while you build smart contracts when you do operational security uh there's when you uh work with nodes uh you need standards to make sure that at least there's like a baseline of things that you're doing right and you comply with that.

Great. Thank you. So when you know if you look at standards I think sometimes people see especially if they're maybe not industry standards but the more government standards and regulations you hear a lot of times are you know this is going to limit innovation this is going to cause challenges to innovation. Um do you think that's true? Do you think it it it or do you think it helps to promote more innovation around those standards? what if if someone were to ask you that question and say, "Hey, Max, you know, you want me to do these standards, but it's going to really impact what I can do and innovate um in my space." I think that's a problem of a standard um and not standards in general. Um so you can design a standard to be flexible, to be approachable, to be agile to use the term, right? Um I

don't think we should have 100page standards and complex standards. I think we need to really as an industry make them adoptable, approachable, uh, and maybe even more peace meal, right? So, let's not try to secure absolutely everything all at once. Let's break it down into something manageable. Let's let companies and projects um choose to adopt a specific standard that is uh, you know, that works in their niche uh, and to to do it well. >> Yeah. And also standards can evolve. Um it happens for example with the ERC20 standard that people use it everyone uses it and then if you want to add a feature on top you can for example you want to use a vault you also have a standard for that the 466. So as long as

you understand that for adoption of standards it's important to make them so that people are happy using them and you're flexible enough while keeping security that people are going to use them I think is the the way to go. Awesome. Joel, do you want to add anything or >> Yeah, I mean I think they touched on it very well with what we would look to do with the BCC. Um the only thing I would add to that too is like I think the goal of what we've been doing and how we've been doing it is really to have like a baseline approach. We have a very approachable, you know, you look at the standards, they're not like 100 pages.

They're not like very discreet controls. It's more of like general guidance around security of you know major domains in web 3 but you can go through and read it in you know minutes not hours you know you don't need an LLM to read through it you can actually go through and understand it yourself and be like am I doing these things in my program today great thanks and so you know we we started with a we released the first set of standards in May of this year so they were covering sort of token integration key management uh node operation and some baseline security standards as well. Um I I would note that I we had a conversation today with somebody who's already looking at the token integration standard already starting to use that in some of their

solutions. Um so it's great that adoption is starting to happen and people are starting to use it but why why why those four why was that sort of where we started? I know both you know Joel and Max you were helping to draft and editors for some of those standards. What was the driving force to to start there? >> You want me to go first you Max? >> All right. So, so I mentioned it earlier around like the reason that I want to get involved and the reason that Coinbase wanted to get involved and the first reason was like we have had this program for many many years. We've built it out. Um, and so I think with these four, the the goal and at least for the token integration standard, the one that, you know, my team has really written and we've put out is to take a

lot of what we've seen on the um secure asset side, you know, what Coinbase will look for when we we look to add assets to the exchange [snorts] and put that in a point where like people can then go and say like, you know, what is our baseline there? Um, so I think from the the for side of it, at least on the token integration side of it, it's one that we know very well. It's a structure that we use every day. It's something that I would love to also take to tokens and say like, hey, here's your starting point. It's not the entire program what we do, but it's a starting point of security. And I think that's why like when it comes to I'm not going to speak to like the node operator as much. Um, but I think Max might have a

similar answer, but it's like, you know, it's part of our bread and butter. It's part of what we do every day. It's our, you know, strongest kind of like here's our our first step in it. We're going to take that approach. Um but even with the key management and general security and privacy one that's kind of the same idea around like you know we've we know these areas very well is a discipline that we want to start with and that will give us a foundation to build on from there. Yeah, I think we just we we picked bedrock standards, right? So, we picked, you know, every chain protocol, whatever it needs to operate nodes. You need to think about how you're storing your keys. You need generic kind of like um security guidance. So, we kind of picked those also just based on what our

company's backgrounds were. I think what we knew best, what we curated over years and understood very well. Um, and now we're seeing sort of like the the next wave of standards that we're working on is is kind of broader and because we've been having these discussions for years for a year now, we're starting to talk to each other. We're kind of understanding a bit more about like where those uh blind spots are in the industry. >> Awesome. Oh, go ahead. You're >> I was going to add on that too. >> Go for it. >> You know, so I think Max said it exactly right. like these are baseline bedrock standards and not only are they meant to be like here's your starting point but for for you individuals but also for us we can say like well now that we know what like secure key management looks

like we can now say and nodes we can now start saying like well what does the relationship between these two like what is a transaction security look like and we can reference these standards and say like you know when you're looking to sign use this when you're looking to broadcast use this and so like it's it's also foundational for us just as a organization of like now we can build on top of this and get into the more complex stuff or the more niche >> and I think that the easiest uh answer to your question is basically to avoid hacks to stop seeing protocols uh losing money to stop seeing companies losing money and if we want to see this new next wave of liquidity coming to crypto

coming to blockchain uh they're also going to feel comfortable having those standards and seen that there's a framework that they can follow to mitigate as much as they can uh these losses. >> No, I think that makes sense and especially with sort of the baseline security standard, it's not complex. It's pegged a lot to the NIST uh cyber security framework, something that works and so that a company that's two people in a garage can can hopefully follow that standard, get that baseline, put more trust in the space and then build out with the other uh four standards and kind of grow on top of that. So, a good baseline for us and a good sort of initial step. So, we we've sort of got those four out. We're working on

adoption, but that's not kind of all. There's a couple more in process right now that aren't quite public. they're they're getting there. Um, one is smart contract which is one that we we've we've been working on. I think you know really important next step and I know um Hodto you've got some thoughts around kind of the importance of of the smart contract uh standard and where that's going and how that uh may play a role within you know some of the additional work some of the work we're doing already. Um so yes of course after auditing so many projects throughout the years uh you can see that developers follow uh different rules. They have different ways of doing things. Some of them adopt audits as a way of securing their smart contract. Some of them just do testing to do that. Some of them are

doing fussing. Um some of them are just uh vip coding. uh so it's tough and uh having a baseline in smart contracts I not only think it's necessary it's a must but also I don't think it's that difficult to adopt um if you think more of like the shift left mentality of not only thinking of an audit to be something that has to be a standard which I believe it should be at least for now um just thinking about going to the very beginning of a team of two people in their crash developing smart contracts thinking of like okay what are the best practices that I can follow for this well I might just go out there and

see if there's opensource secure contracts that I can build on top and use that those ones see that they're battle tested that gives you some peace of mind and also kind of like a baseline to start working and building from there um following that when you enter to the development life cycle also understand that there's certain rules that you should or at least it would be nice for you to follow in terms of how you test your code base. Uh it's not the same having 50% then 80% then 90% then 100% of test coverage. Um it's not the same just uh testing um business logic when you write a unit test than trying to actually break your code while you write a unit test. And

that also brings to fuzzing. Fing should be part of a standard that says that every single smart contract in unit test you can't actually check everything you want. Well, fuzzing really helps uh on that and where you're developing also follow uh best practices. Know that you have to document your code so that your other developers on your team understand what you're doing and also auditors understand what you're doing and also the community because we know that this is an ecosystem where we like open source coding. um can understand what you try to do. Um so I feel that it's something that has to be from the beginning of the development life cycle. And then of course the obvious ones uh the one that

I already mentioned auditing is uh super important and having a standard of the things that you would like to see in an audit is also something that should be uh standardized. And beyond audits after someone reviews the code is if you're going to continue iterating your code is how do you evolve internally and what uh baseline rules you follow to make sure that when you introduce a new PR with new code you are secure. Beyond that, it can happen that after three years, you want to add a new feature to your code or you want to go to a new version of your code. And knowing that all this is still public, your old smart contracts

might uh still hold money. We've seen a pretty bad hack in a in an old version of uh balancer happening uh a few weeks ago. uh defining standards on how to move liquidity from one version to the other also could be something very uh very useful and from there onwards uh when it's not related to only like coding smart contracts is how you interact with smart contracts uh knowing that interrupt is a thing you're going to like smart contracts don't work by themselves they talk to other smart contracts if you have an AMM or you have a lending boring protocol you will likely work with other smart contracts to check Oracle prices to uh deposit your liquidity to other pools and having

standards where you have clearly defined how those communications happen is also easier for uh developers to interact with your system and for you to interact with those other systems too. So it it's [clears throat] a lot to take in. So I would say I mean one of the things I I want to touch on is sort of the auditing piece that you talked about. Um because that's sort of a next step for us. Like otherwise you you sort of put these standards out and if they just sit there, nobody adopts them, we're not auditing against them to get them in the and to sort of build that trust and build that hey, you know, we're you're certified as BSSC. You've got uh you know, let's just say Open Zeppelin's a

BSC certified playing it forward uh standards organiz uh company. You're certifying your clients. I mean that's that audit is the next step and and something that needs to do sort of what's what you know is that the right next step for us to be doing we've got some standards out we got a couple more um what what should be next after after those are in place. Uh we got this uh question pretty often uh lately of what's our methodology when we audit. Uh most people usually think of uh smart contract audit firms as maybe one, two, three security researchers reviewing code doing this like line by line process to make the code ballot proof.

Uh but sometimes they don't know the things that we check on the code. So a good starting point would be to have a list of everything that a smart contract auditor should be checking uh in a smart contract. Uh, of course again it's a baseline because novel issues are the ones that uh in the end make uh protocols uh lose money and the important thing also related to that is that you can evolve the standard and add all these ones once something happened hopefully nothing happens but if there's a back bounty and in that back bounty you see that there was a novel issue well try to adopt that in the standards as soon as possible and put that during your offering your smart contract audit process.

>> Perfect. Joel, go ahead. >> Yeah, adding on to um a lot of what's been said here on the audit side of it and smart contract security side of it, a couple of thoughts. The first one is you know the first four standards we put out we had the token integration standard and that was um you know mainly looking at what can you as a third party verify about a token and like um both just said earlier the new smart contract standard kind of eclipses that in a way of it's not just what you can see on chain it's also like what does the company do you know how do we audit against it and everything like that um and I think we covered that really well but that's a good example of an evolution of a standard of token integration we we looked that and we

said well really this is this is a lot similar to the smart contract standard and so we're looking at like what elements are we keeping what elements are we merging so there's that piece of it on the um compliance and you know business certification side of it this is something we really want to start standing up uh we mentioned it earlier but we have the four now the four standards and we putting out two more but those are not really effective unless you have a way to say like how do you go to a uh digital asset or a you know custodial company or a node provider and actually hold them to the standard that we're writing. And so that's a lot of what we're doing now on that side of it of like figuring out what that audit track looks like um the comp, you know, business compliance

track, working with other people in this industry, you know, on doing that. Certainly for Coinbase, you know, we want to um take the standards we've written and apply it to ourselves. So we actually, you know, so Figment was one of the primaries on the node operator standard. We've taken that, we've self-er like self-certified, you know, we've gone through and see how it applies to us. So now we would love to have that where it's like companies can come and like, you know, actually hold us accountable for what we've done. >> Yeah. I think it's about creating trust too, right? Like um we can write standards all day. There's a whole bunch of stuff to write standards about, you know, we can go on and on. Um but if there's no pull through, then you're not really um creating an environment for end users or end companies to trust the

other companies, right? So like that's why you need this auditing kind of um you know the whole other side of the BSSC which is really what we're you know working on now is okay how do you how can you prove that you know I'm holding my company up to the standard how can I prove uh to my end users and and and my customers um that I really care about my smart contract security or my node operation or or whatever right it's about expressing that you're like a mature agent within the space and that you understand the the the material IO well enough that you've you've chosen a standard to adhere to.

>> So we touched a little bit on the so we've got one other standard that we're working on right now which is um really looking at the life cycle of a transaction. So really and and security around it. So it's transactions security is kind of what it sort of working title is at this point. um with with that standard or that draft standard, what what kind of attacks are you hoping to help defend against um in developing that standard? >> Yeah. So, I I kind of see transactions as the like buffer zone between offchain and onchain, right? So, you're you're creating a transaction, a string of bytes that can be super simple or complex and you're giving it to a user or a system or or or something to sign and then that gets immortalized on

chain. Um, so we really need to get that that sort of buffer correct and we have to make sure that we're doing as much as we can as an industry um to both empower users and systems to not so blind sign stuff or or whatever. We also need to make sure that our our security teams both internal external can you know have a kind of understand what the chain of custody of a transaction is as it goes from like the system that produced that transaction. Maybe it trans transited a whole bunch of other systems. Did it get modified? How was it modified? What triggers do you have to know if it was modified? And then what actions can you take to make sure that this modified transaction doesn't keep getting propagated through the network and given

to a user. Um so yeah, we're working on this transaction life cycle safety security um standard. Now um I think we're we're zeroing in on really the structure right now. Like we all understand that it's important internally. Um, we all understand the bits and pieces of how we want to express what we what someone should be thinking about when they're looking to sort of secure their transaction supply chain. Um, and really that comes down to like, you know, producers of transactions, relays, you know, systems that move a transaction, a string of bytes from one system to another, signers obviously, and then the whole process of like broadcasting, right? You put it on chain. Did it did it get accepted on chain correctly? Was there an error? Do you have to retry? How do

you retry? How do you Right? All these kind of meta things that we kind of take for granted that if you don't do correctly could have some pretty bad um bad outcomes. >> Yeah. I mean, adding on to that, I mean, Max covered it great of what we're looking to do and how we're looking to build this and everything. Um just a little bit more about like why this is so important is like you know at least within Coinbase this is very near and dear to like our heart and our mission of like you know if a user is sending funds we want to make sure that request goes through untampered you know it's fully verified and validated multiple steps and so that's something that like we've been working on a lot um and other companies as well and so getting that where that's a that's a very mature side

of it not just like how do you generate these but how do you actually shepherd them along the entire entire process and verify them along the entire process so the the end user is secure and and they feel confident on that transaction and even though I know we're looking at it like you know Coinbase we're looking at money custodial side this is also something that applies even in the self-custody world you know you're still generating transaction you're still signing it you're still broadcasting it so that's something that like I would love to even have for like end users to say you know is this uh protocol is it handling my transaction safely and like bring it in here on that side of it.

>> Um to add to that is that I actually think that transactions and signing transactions is one of the worst user experiences anyone can go through these days. Even for security people like me, it sometimes is like how do I validate this transaction? What's the best way of doing it? Have my ledger. I see all these like uh characters. I'm going to have to like scroll it and write it down and actually check what's doing. Uh so it's clearly a problem for technical people. Imagine for someone that has their ledger and they just want to move funds from one account to the other or put their money in a protocol making sure that their computer is not

compromised and has changed the transaction uh itself to move the funds from one place to the other just like changing the address for example or changing the uh the amounts or or whatever. So uh having a standard around how you generate transactions and how you propagate transactions is is super important. So I want to stick on sort of the overall security side of things. So I I've heard people say kind of web 2 is a back door to web 3. Um you know is there truth to that? And if I'm a web 3 company what should I be concerned about? What should I be thinking about?

Uh well there's a fact and the fact is that uh in the last few years the most of amount of money lost hasn't come from smart contract hacks has come from maybe what you say web two related stuff uh keys getting compromised transactions being modified mpm packages uh with some sort of like malicious code injected uh so I wouldn't say that web two is a backtor for backdoor to web 3. But clearly smart contracts and auditing has gotten to a place in my opinion where the security is relatively good and then hackers are looking for other things.

What are the weak links these days that go beyond smart contracts? Because if I sit down and I start reading a smart contract, I can't actually break it. It's like, okay, but I want to steal this money. What's the other ways I can do it? I just have have to go back to web two and see what were the ways back in the day, not in web three, uh where you could steal money and things like fishing are already happening and again losing a lot of money from things that we shouldn't be focusing on but actually yes we must focus on this uh because it's happening. It's just like a new, not that new because it's been happening for a few years, but a newish attack vector that we weren't considering several years ago because everyone was so focused on smart contra security. Uh,

yeah. Now it's super important. Yeah. So, like thread actors are always going to take the path of least resistance, right? Like they're also an economic agent. They are doing costbenefit analysis. They can spend years trying to break your smart contract system. um or they can pay someone a few thousand dollars to send you like a fake resume that you're going to open, right? Um so they're always going to take that that path. So really it's it's a it's less that like web 2 is a back door to web 3 is that it's a whole system, right? Web 3 doesn't exist on its own. Um it's it's it's sort of underpinned by, you know, real compute and and and real data centers and real people behind it. Um you know, real systems hold keys and and humans hold

keys. So everything that like the last 40 years of like cyber security has learned still has to apply to web 3 companies and that could be a pretty big big burden. Um so that that's you know through our standards we try to think about that angle too and not bucket us ourselves too much on the web 3 side. >> Yeah I mean on that side of it you know you can look at it web two web three you know I think that's like traditionally how we always think of it. You could also think of of like local actions and onchain actions, right? And I think a lot more of, you know, back in the day when blockchains and uh DeFi was a little bit more immature, our onchain services were, you know, growing, they

were like kind of dynamic and like, you know, it was easier to say like the smart contracts insecure, this protocol is insecure. Let's attack it. And like over the past years, we've really been maturing more with our onchain services and our onchain like just the whole, you know, ecosystem has. So that's why like Max said there, you know, attackers are economically motivated. It's, you know, easier or, you know, a null and attack path to to look for those local actions, those web two actions. So I think that's for for us like just in this space. We have to think holistically. It's not just, you know, what is the onchain piece of it. We have to think about like how do our users interact with it? How do we, you know, how do we interact with it as companies? Um, and I think we're gonna start seeing a lot more of this as

we go and become even more and more, you know, larger the whole DeFi space. >> So, and I want to jump back a little bit and Hoda talked about the sort of smart contract side and that's generally pretty secure and there's other gaps and we're looking at weaknesses. So if you're a, you know, a DeFi team and you're about to deploy a smart contract and you can kind of take our standard in in in mind, what what are people normally what are they missing? What are they forgetting to do? >> Okay, I can kind of so I'm I'm somewhat biased. I spent a lot of time looking at CI/CD pipelines um and understanding those and attacking them. Um, so like at the end of the day, smart contract is is

code and you have to manage code and and you're you're managing you have a software development life cycle. Um, and that code has to end up on chain somehow. Uh, so my advice would be take a look at your pipelines. Uh, understand what kind of third party code that you're you might be depending on in your pipeline. We're talking even even GitHub actions, right? We saw TJ actions was a massive um, compromise uh, which thankfully didn't work but was definitely targeted at our industry. Um so yeah if if you had to look at one thing I would say go take a look at your pipelines understand them very well.

>> Um to add to that in the smart contract side um have a security mindset when you when you code um business logic of course is super important because the code has to do actually what you think uh should do. But the mindset should be the the two questions that people should be asking themselves is the first one is this secure and the second one to be is this following the business logic instead of this is following the business logic and then if it's secure or not okay you want to add one more you good >> I think I'm done yapping I want to hear you know questions

>> uh so we've got a few minutes left uh we save some time for any questions from the audience. Um, does anyone have any any questions for the panelists? >> Wow. I guess I'm not done yet. >> Not see we we answered all the questions ahead of time. Apparently, >> we're just that good about standards. Or maybe standards aren't as motivating as we think. >> Maybe not. >> We're going to be out there. So, anyways, see if you Oh, there's Go ahead. I think the question was are you Oh, let's we're going to get a microphone to repeat it.

>> Are you considering for the future work of standards also standards in zero knowledge proofs and other fancy cryptographic uh protocols? >> All right. So, I will say absolutely we would love to consider those. We would love have standards on those. And I think one of the constraints that we've had as a group is the knowledge and ability to accurately represent that in a standard that's usable, right? Um the two standards that we're doing now, smart contract security and transaction security, these are things that like we know very well. Um and there are there are more people to be a CC than just this. But uh you know that's our bread and butter. That's what we would know a lot more in. So on that yes, we would consider it. We would love to build it.

I think that's something that like we would want to invite others to come to us and help do that. Particularly if you're in that ZK space, if you're in that cryptography space um and say like, hey, here are some things that we need to consider as we start looking at things like quantum computing or we start looking at things like, you know, more ZK built into chains. And so like I would invite um you know, feedback for that. I invite you know, us you know, approaching us. Um, something I didn't think we really touched on is like, you know, even though we're up here and we're big companies, you know, we really want to invite a lot of commentary and a lot of engagement from everyone on what we've put out there. Like, you know, uh,

we this group, we meet weekly and discuss the standards. We discuss what we're doing. It is not like a room with a bunch of suits creating these. it is you know the technical leaders in this space like coming together and saying this is what we're really doing and so if you're a technical leader that's like very knowledgeable in a space we would love to like get your engagement your involvement you know teach us and then we'll also teach you so I would say like that's a very long way answer saying like yes we would love to consider it but I don't think it's something that like is our primary objective right now and it's something that if we had people that are more knowledge and learned in that and certainly we would love to consider I think that's a a good point, Joel, because we we have about 11 companies

that are members now and there's more room at the table and there's places where there's gaps for us as well. So, for I think to follow up, we've talked back and forth about do we need to do a stable coin standard and I think we've sort of come to the conclusion like we need a couple more players around the table to help really develop it the right way and making sure that it's it, you know, it is a good standard that holds up to the other work that we've done. Um, and again like to Joel's point, we, you know, we're we're working to be as transparent as we can once we have our drafts out. We put them out for public comment so that, you know, we we can get that extra feedback. Uh, cuz we don't have all the answers. And so we want to be able to get that feedback and

understand, you know, where we may have missed. But, you know, the more people we can get around the table helping to develop this, the better off we all are. Any other Oh, I have another question here. Oh, here we come. >> Um, when I think about standards in the normal web 2 world, I I think about processes that takes years to build and that are meant to stick for years, too. How do you see this coupling with an ecosystem that is continuously changing?

And how do you see standards that evolve to be adopted if they change quickly? Probably moving fast. Um being communitydriven. So the people that are innovating are adding all these changes should also think of which standards should be built so that the things that they're building come already with this baseline that we're talking about. I think that's super important because otherwise there's only so much an entity I think can do. It's what he was saying just uh now bring to the table all these innovators uh all these people working in different fields and work together on

okay this is going to go live what are the things that we have to follow what are the standards the minimum based on and then build on there from there because you can define a standard and you can define something very simple but then again it will keep evolving and you have to add things on top but at the same time keeping it um flexible enough so that others can also uh implement that that standard and I think we mentioned earlier like we're we're not trying to develop 100page standards that are really complex and that we want to get that baseline going and I think you know we're constantly looking and evaluating the ones we have published to say hey are there are there small changes are

there things that we should look at to update those standards um over time as as the industry evolves and things evolve as well. All right, any other questions? All right, so I'll I'll give you guys all like a quick closing remark on um any like last remarks and then also favorite thing you've done here this week.

>> Wow. Uh, okay. Uh, closing remark, I guess. Uh, don't forget about off-chain security. Um, it's the world that I live in. Uh, so I I I care about it deeply. A cool thing I've done this week, >> I don't know this. I don't know. [laughter] >> I wasn't ready for the question. >> You know, you must have gone and seen something, had a good dinner or did something. >> Oh, yeah. We went to uh Fonasado. It's a really, really nice restaurant. Like amazing barbecue. We loved it. Um, in my case, my take is the contrary of what you said is like don't focus too much on off-chain stuff and also remember that you have to take care of the onchain stuff. Um, and fun stuff. I don't know. I love the city. So, uh,

everything has been fun. All right. All right, Joel. Closing. Closing. You got to close it. Make it a good one. >> I mean, of course, I have to say you have to balance your onchain and off-chain security program, right? have to say it. Um, what I would say is like, you know, I'm I've really enjoyed being part of Blockchain Security Standards Council. I I said at the beginning, but like these are a really great group of people, really great group of companies, and like I'm really excited for this going forward. Um, and so I invite anyone to help reach out or, you know, to me or Adam or any of us, like be amazing to work with more people. Um, and so I just invite you to do so. uh as far as uh fun

thing I've done. Uh did you know they have really good steak here and like you know so I've been eating a pretty good amount of that. >> Yeah, it's kind of good. So >> all right agree. >> Three votes, four votes for steak. Um all right. Well, I just want to thank all our panelists for for being here today and thank you for being here. Um we'll be around and look forward to chatting with you more about the work we're doing and uh enjoy the rest of the conference. Thank you. >> [applause and music]