Decentralized, Not Defenseless: The Governance Security Checklist - Shelby Steidl

Transcript

Awesome. Hello everyone, excited to be here today to talk through some governance security considerations. This is very much so framed with the lens of L2 governance and very much so focused more on protocol governance protocol security, but hopefully there's some good applicable considerations for for for everyone. My name is Shelby. I am the governance experience lead at the ZK sync association. The ZK sync association is an independent entity within the ZK sync ecosystem that kind of acts as like a steward for the ZK sync governance system, which among other things governs the ZK sync protocol.

Before we dive in to this fun little checklist I have brought with me today. I think it's important to take a moment to remind ourselves the role of governance and specifically the important roles that it plays in protocol security. Governance has become a very loaded and sometimes triggering term for some folks over the last few years, but it's important to remember that governance is not just a tool like a voting tool. It's a critical element of decentralization and it's a protocol's ultimate defense mechanism. And we know this from the security that is enabled on an ethereum one.

In regards to L2 governance we have learned over the last few years of playing around with it in different models that in order to design you know a really secure and effective governance mechanism for your protocol needs to be a lot more robust than simply your on chain governance contracts and processes. This includes possibly having you know, special uh governance bodies that hold special responsibilities and powers like a security council um or possibly, you know, deploying security-focused initiatives like bug bounty programs.

Um in designing these uh effective governance secure and effective governance mechanisms that are also aligned with decentralization um is very tricky and everybody has a different idea of how that should be done or in what way that should be done. Um sparked a lot of debate as we are all probably aware. We saw this most recently recently in the Kelp DAO um Ave incident in the crypto Twitter debate that followed. Um uh to recover funds or not to recover funds. Um and I think this this situation really highlights um the friction between, you know, core pillar of decentralization, censor-censorship resistance, um and also, you know, the desire to um utilize

certain uh emergency processes that are in place to protect the network or recover hundreds of millions of dollars. Um and again, this is a very kind of heated debate across the industry right now and there's lots of different opinions and that's great as there should be. Um however, I would like to point out that or remind folks that power within a decentralized system isn't necessarily a problem. Um however, unaccountable and undefined power is and that's where we're still seeing um a lot of this conflict or tension. Um you need to have responsibilities and power very clearly defined um and you also need to have really strong accountability mechanisms in place that um go beyond just on-chain accountability. Um I'm talking about

real-world legal um accountability and consequences for on-chain actions. Um and all of this to say uh that designing a uh secure governance mechanism uh there's a lot that goes into it. There's a lot of considerations that go into that. Um, and with me today I have a governance security checklist. Um, and but this checklist is not meant to be like an end-all um, fully exhaustive um, list. Uh, it's uh, meant to be more like a list of considerations that can be applied in different ways depending on what you're trying to achieve. Um, also what worth noting that each protocol is going to have completely different needs and completely different you know,

designs um, or setups based on what they their protocol is um, you know, trying to achieve or also who they're building for, who their clients are. Um, so the first one is in regards to security council design. And this is more it says security council here, but this is really applies to like any governance body that holds some sort of um, you know, power or special responsibility within your uh, governance system. Um, and things to consider here is like who's on your security council. Are these individuals or are they maybe formal entities, maybe uh, professional security teams. Um, what's their reputation within your ecosystem and like broader um, across the industry.

Um, how are they selected? Uh, are they elected or are they maybe appointed? Um, what are the criteria or credentials um, that are uh, considered for election or appointment? Um, where they located? What's your geographical distribution of your security council? Um, if are they able to respond to security incidents at any time of the day? Um, and what powers do they have? This um, obviously should be very clearly defined and publicly available. Um, and this is in regards to not only standard procedures um, and responsibilities, but also in cases of emergencies.

Um, and last what are the checks and balances with other governance bodies and stakeholders. Um, is governance able to uh, revoke or remove individuals or entire bodies um, who hold these positions or if you have other governance bodies like maybe a separate like veto body or entity what how do they interact with each other and how do they all hold each other accountable? Next up is legal accountability. Who do the members on these bodies like a security council have a legal counterparty and if they do do they have a formal contract with them? What is the actual

legal teeth within that contract? A lot of folks a lot of security councils members today they contract with a foundation but there's also issues on that front with in terms of like independence there and so maybe are there other ways or other models that could be explored to to kind of address that. Do you have a legal counterparty for token program admins and service providers? If you if governance approves a program there there's usually like an admin multi-sig who is responsible for managing and executing transactions on behalf of that program.

Do they have a legal counterparty or is it trust me bro it's in the on-chain proposal I promise I'll do what I said I'll do. Same goes for service providers. Um Most of the time the answer is no. Um Layered protocol security approach so in regards to protocol governance specifically what are the steps? What is the process that a proposal has to go through in order for a protocol upgrade to be executed on chain? Does it maybe for example require an independent security audit before it's even submitted on chain?

Do does it require you know does every single protocol upgrade have to go through governance review and approval. Is there maybe a separate process or like a like a an extra step in the protocol upgrade review process where security council reviews it and and approves it from like their technical expertise standpoint? Do you have bug bounty programs to help catch and identify bugs in code because I think somebody said it in a talk earlier today that code like code is made by humans and humans have errors so code is going to inevitably have errors.

And do you have an emergency upgrade process in place if bugs are identified to help fix those bugs in a secure way without jeopardizing the network or to be able to step in in cases of emergencies? And last I have security aligned token program priorities. Do does your governance system or do your delegates understand the importance of protocols security and do they uh is it generally are they generally aligned with funding different programs such as audit reimbursement programs, bug bounty programs, funding for security councils or guardian network or bodies?

I think we see this across all industries or all ecosystems that your delegate base is always going to be very diverse in terms of experience, background, technical ability and understanding. So there's maybe some education that needs to be done here too or like you know priority work in alignment as an ecosystem to to be able to support this. And to help solidify some of these examples or considerations, I have brought with a few examples of how we are applying them at ZK sync.

The first is the security council design. So the ZK sync security council was designed specifically to be a professional security council. These members were appointed at the time of governance launch back in late 2024. And you'll see you'll notice that all of them or most of them are professional security teams. So, OpenZeppelin and Sifr Spearbit Nethermind and they were selected based on their technical expertise, geographical distribution and the strength and reputation within the Ethereum ecosystem.

And now the community or governance is able to remove, add, replace members of this body via governance proposal. But in addition to that accountability, there's actually we have a three-body governance system within the ZKsync governance system. And where the security council is one of those bodies. You cannot see this very well, but that's okay. Other two bodies are the token assembly which is just a fancy word we use for delegates. And the ZKsync guardians over there in the blue and if you can't read it, the orange is the the security council. And essentially how this works is that the token assembly votes, reviews and votes on all proposals.

If they are passed or approved, the ZKsync guardians are able to review and in special cases veto proposals. And then the security council actually plays a very specific role in reviewing and acting as the final approver and executor of any protocol upgrades. And you'll notice by this in in this system that no single one of these bodies is able to independently execute a proposal on chain. It requires review, kind of coordination between and checks and balances between them.

And that of course is just or this is just in regards to the standard proposal process. So, like the standard governance process that most that proposals go through, but there's also emergency response procedures. And um all of these are can be found in our docs at docs.zknation.io. And in the formal governance governance procedures, including the emergency response procedures, there's a board called an emergency upgrade board that is able to do a few things: freeze the protocol, unfreeze the protocol, and also execute an emergency upgrade.

I don't know if you can read this. Apologies if not. Um but the emergency upgrade board is not actually just one entity. It's not just the security council. It's actually made up of three independent entities, and including the security council, the guardians, and the ZK Sync Foundation. Um and in order to execute an emergency upgrade, you need to reach consensus with all three of these entities. Um and each entity has kind of like an independent signing threshold on their individual multi-sig in order to to reach that.

Um on top of that, there's also an additional layer of legal accountability that was built into this design. So, a governance body design. Um the ZK Sync Security Council has its own independent entity, the Cayman Foundation, with two independent directors. And all members, security council members, actually contract directly with this entity. Um this entity is bound to a set of bylaws that were drafted specifically based on the on-chain roles and responsibilities that are outlined in the governance procedures. So, it adds a layer of legal accountability to what's actually

written in the processes or what's on chain. Um same thing with the guardians. The guardians also have their own independent entity and bylaws, and all members are bound to these bylaws that are drafted based on the on-chain roles and responsibilities. If governance votes to change those um those uh rules and responsibilities, bylaws will also um you know, be be impacted there, too. Um and this creates this starts to help solve this independence um uh point that I mentioned earlier, where if you have security council members contracting with foundations, that kind of makes them that builds a connection between these members and the

and foundations, um where in this case, they're completely independent um of of each other. And uh another uh entity that exists is called the ZK GPS at ZK Sync Governance Program Systems. ZK GPS is a little easier. Um and they are also their own independent Cayman entity um and also have their own bylaws that bind them to act in service of the token assembly. Um and they are actually a contracting counterparty for all token program admins and service providers. Um so, that admin multisig that's running a program and executing transactions, they are legally bound to um uh act and perform in uh or deliver the

services that they agreed upon, that's written on chain, but it's in a legal contract. Um and they also perform uh KYP KYC for these uh for any like recipients who are getting paid for these programs just to make sure, you know, your service providers aren't uh Kim Jong-un fanboys. Um So, and this is this it can all be found um like I said, on our docs. Um not only the outline procedures, but all of the bylaws are linked for each of these entities on our docs, as well. ZK Sync uh the Security Council Guardians and for ZK GPS can all be found if anybody wants to go take a look at those.

Um Next is the layered protocol security approach. So, at ZK Sync uh a protocol uh upgrade goes through a series of steps before it is executed on chain. Um uh one of them being independent security audit before being submitted on chain. Although this isn't a formal requirement um anywhere, it is very very very unlikely delegates would vote to approve it, and the security council definitely wouldn't if it doesn't have an independent audit. Um uh token assembly review and approval.

Token assembly again is the word the term we use for our delegates, so your standard kind of governance delegate review and approval process. Um next is a guardian legal review period um where they are able to review and veto um uh a protocol upgrade if uh they if it, you know, fits the parameters and what under which they're reviewing it. And then the security council is the final step of the review and approval process um for a protocol upgrade before it's executed on layer one, and they of course apply a technical review um of of what what's included in the upgrade.

After a protocol upgrade is executed, um there are a few additional measures in place um including an immunify bug bounty program um as well as the emergency upgrade procedures um uh that I described a bit earlier. And here you start to see this kind of tiered approach to protocol governance security beyond just um you know, uh governance contracts and security council. Um and last, uh just a few examples of um security aligned token programs that have been deployed over the last year and a half um in the ZK sync ecosystem.

You can't really see it. Um but this includes two audit reimbursement programs. It includes funding for the security council and for the guardians, and includes uh also funding for the immunify bug bounty program that I mentioned earlier. And just to close it out, I wanted to also take some time to talk a little bit about why this matters. Decentralization can feel very hard sometimes. And even though we will continue to fight over, you know, what is sufficient enough or different definitions of decentralization or the ideal stage of decentralization,

it still remains like the core underlying principle or North Star of the the ecosystems and the governance mechanisms that we're trying to build. And governance, of course, is an important part of that decentralization process. Admitting that there is a need for controlled mechanisms to be able to, you know, jump in and fix bugs or respond in emergencies is not a rejection of decentralization. It's a recognition of you know, realities and also desire to protect protocols and networks that we care about so much.

And again, power is not in decentralized systems isn't necessarily a bad thing, but unaccountable and undefined power is. There's still a major trust issue between communities and these bodies that do hold these kind of pockets of power, whether that be security council or whether that be, you know, program admins for different token programs. And the on-chain accountability doesn't quite go far enough. The threat of being removed from a security council isn't necessarily it's obviously not a strong enough accountability mechanism to allow people to really feel that these people are acting in service of the community.

But by introducing additional accountability mechanisms beyond just these on-chain ones like real-world legal accountability or consequences for actions on-chain um or actions that go against um whatever is in a legal formal legal contract, um may help relieve or reduce some of that tension. And last, but certainly not least, um especially today, is institutional adoption. Um over the last 6 to 12 months, we have entered a completely new era of blockchain adoption.

Um where we've seen a variety of different institutions, um anything from banks uh to governments to other just traditional financial institutions, start to explore the possibility of bringing assets and services on-chain. Um and these institutions come with an extremely high standard and expectations for um security and reliability. If your ecosystem or if your protocol is wanting to go after this new um you know, client base, um that will likely significantly impact how you consider protocol governance design and part of your

protocol security approach. Um not only, you know, your governance mechanisms, but also like who's on your security council, um uh who uh your your emergency upgrade processes, what those look like, or how strong those are. Um and uh Yeah, and and you know, this this also, if you want to actually go after stage two decentralization, if that makes sense anymore, um if you are trying to appeal to these um sort of sort of new clients.

And again, there's no right or wrong way. I don't think there's a right or wrong way that we can say um we can do this. And also, all of these considerations are, as I mentioned earlier, completely in the context of what you were trying to build or who you are building for um or what values you have or trying to achieve within your communities. Um but I hope that the framework that I provided today was somewhat helpful to give a little bit uh new perspective or new some new ideas as to how you can think about designing uh your governance security mechanisms. Um if you want to learn more about the ZK sync governance system, um you can go to docs.zknation.io or scan this QR code that you probably

can't see. Um and that's all.