S.1 Ep.6 Inside ZKSync’s Governance Revolution - with Shelby Steidl & Rafa Fernández
In this episode, hosts Jamilya Kamalova and Eugene Leventhal sit down with Rafael Fernández and Shelby Steidl from ZK Sync to unpack one of the most forward-thinking governance frameworks in Web3 today. Rafa is a Director and Governance Lead at the ZKsync Association, where he supports protocol governance design, token mechanics, and operations. His work spans the entire governance system design, from contracts, to legal architecture for regulatory alignment, and scalable processes for decentralization. He brings a background in organizational design and analytics to help ZKsync evolve governance into public infrastructure—credible, composable, and built for the long term. Based in Berlin, he's always ready to share stories of niche too-online lore and previous research on digital swarms. Shelby is the Governance Experience Lead for ZKsync Governance. She is responsible for all things governance UX, resource management & creation, Delegate coordination, and supports with token mechanics development for Token Programs. She previously worked on governance at Radworks (RadicleDAO), bringing 3 years of gov ops experience to help launch and cultivate the ZKsync governance system. Shelby enjoys flat whites, a groovy house beat, and contributing to the grand experiment that is decentralized governance.From their personal journeys into blockchain governance to the challenges of designing systems that balance decentralization with accountability, Rafa and Shelby share the ideas that shaped ZK Sync’s approach. We dive into their use of the Austrian Association model to provide liability protection through opt-in legal membership, the design of a three-body governance system (Token Assembly, Security Council, Guardians), and the importance of creating governance environments that foster participation, mission alignment, and cultural integrity. The discussion goes deep into the mechanics, exploring ZK Sync’s capped minter system and modular token mechanics that enable on-demand minting while embedding safeguards, accountability, and legal enforceability through ZK GPS. The guests share how these systems prevent abuse, measure performance, and keep governance adaptable without sacrificing trustlessness. From DAO evolution and mission-centered safeguards to performance metrics and the future of decentralized decision-making, this conversation offers practical insights for protocol founders, DAO contributors, and governance researchers alike. Whether you’re building in crypto or studying the intersection of blockchain and law, this is a rare look at how to design governance that is as resilient as it is innovative — and why the future may be all about simplifying complexity. Some of the papers we mentioned during the conversation:- "The Swarm and the Formation" by Rafael Fernández https://summerofprotocols.com/research/the-swarm-and-the-formation <br>- "ZK Nation docs": https://docs.zknation.io/voting-and-delegation/zksync-governance-101#how-are-token-allocation-through-governance-different-at-zksync-than-other-onchain-organizations.Timestamps 00:00 Intro & Teaser 02:57 Origins of Governance in Blockchain 05:37 The Role of Environment in Governance Design 08:22 Creating Safe Spaces for Governance Discussions 11:01 Understanding the Waters of Governance 14:03 The Evolution of DAO Governance Models 16:46 Legal Structures in Governance: The Austrian Association 19:38 ZK Sync's Unique Governance Framework 22:27 On-Chain Enforceability and Accountability 24:57 Mission-Centered Governance and the Role of Guardians 39:58 Guardians and Their Role in Governance 42:16 Decentralized Governance Structure 50:34 Capped Minters and Token Governance 01:00:27 Safeguards and Accountability in Minting Rights 01:04:52 Measuring Governance Performance 01:11:23 The Future of Governance 01:14:00 Quick Fire Quiz - One Word & Conclusion
Top Keywords
- governance 0.022
- token 0.016
- rafa 0.009
- zksync 0.009
- protocol 0.008
- governance system 0.007
- shelby 0.007
- system 0.007
- guardians 0.006
- token assembly 0.006
- delegates 0.006
- mint 0.006
Transcript
Code is law, has a fundamental flaw, which people will exploit the code interpretation,
for their own personal gain and will try to capture the system. Well, I don't know, Rapa. Maybe our waters are very different. Maybe we're swimming in completely different streams. You know? When did you know that was the thing that really got you excited? The ability to collectively govern a product
or data,
or or tech in general was such an exciting concept to me. It's always interesting to see the kind of people that are drawn to the chaos and instilling order in some kind of way. What do you mean by, like, decentralized
governance body? The zkSync governance system has a three body governance system. So What do you see as the vibe in DAOs these days? One word.
Hi. I'm Eugene.
And I'm Jamila.
And this is the Governance Futures podcast, where we explore the past, present, and future of decentralized governance.
This week, we have the pleasure of speaking with Rafa and Shelby from zkSync. Rafa is director and governance lead at the zkSync Association where he supports protocol governance design, token mechanics, and operations. His work spans the entire governance system design from contracts to legal architecture for regulatory alignment and scalable processes for decentralization. Rafa brings a background in organizational design and analytics to help Ziggy Singh evolve governance into public infrastructure, credible, composable, and built for the long term. Based in Berlin, he's always ready to share stories of niche to online lore and previous research on digital swarms.
And Shelby is the governance experience lead for z k sync governance. She is responsible for all things governance UX, resource management and creation, delegate coordination, and supporting token mechanics for any token programs. She's previously worked on governance at Radworks, which is part of RadicalDAO, bringing three years of governance operations experience to help launch and cultivate the z k sync governance system. Shelby enjoys flat whites, a groovy house beat, and contributing to the grand experiment that is decentralized governance.
This was a great conversation where we started with Shelby and Rafa's journey to governance, which is always fun to hear.
Yeah. It's cool seeing that no two paths into governance are the same.
That's true. We spend most of the conversation diving into aspects of zk SN governance architecture from the legal design with the Austrian Association to how they both see the future of governance.
Before we get into the interview, a reminder that if you like what you hear, please subscribe wherever you're listening, leave us a review, share with a friend, or reach out to us if you wanna chat.
And now here's the chat with Rafa and Shelby.
Welcome, Shelby and Rafa. To start the conversation today, I kind of wanted to touch on both of your backgrounds and journeys into the space. Shelby, you were working as a governance facilitator at Radical. I had experience volunteering and even did a master's focused on digital governance and digitalization. And Rafa, you had consulted on chain organizations around governance and conducted research, especially in a very public way and contributed to ecosystem building efforts at Mirror and beyond. And this is obviously all before both of you joined z k sync. And for both of you, looking back on your journeys and the paths you took, when did your interest in governance really start to to crystallize? When did you know that was the thing that really got you excited? And, yeah, Shelby, if you don't mind kicking us off, that would be great.
Yeah. Sounds good. And thanks for having us. I got into governance a few years into my journey into blockchain and actually started working on it or becoming an operator before I actually even contributed to a governance system, which was kind of a kind of might seem backwards. But, yeah, I was I was lucky enough to start help to help contribute to build out the radical DAO back then, now known as RadWorks, governance system. And I actually didn't know a lot about governance before joining. I was just very excited to have an opportunity to start working in the ecosystem. So I learned a lot in those in those first few months. But re what really drew me to it and what has kept me here four or so years later is just the concept of shared ownership and influence or the kind of collective, the ability to collectively govern a product or data, or or tech in general is was such an exciting concept to me, especially after being very, jaded for, and, disheartened after, you know, the whole kind of Web two, era of Google and Facebook. And, yeah. So that whole that whole premise was was really exciting to me. And then the all of the mess that comes with governance and governance coordination has kept me here because I find it fascinating to be able to work on new human coordination primitives.
Yeah. It's always interesting to see the kind of people that are drawn to the chaos and instilling order in some kind of way. But, yeah, Rafa would also love to kinda hear your origin story of sorts.
So I don't know if this is a well known story, but it is a story I've shared before. There's there's kinda like two important pivot points, I guess, in my career around looking at human coordination. The most recent one was I was working with artisans in the island in Puerto Rico, which is where I'm from originally. And I realized that they were really restricted in terms of the distribution that they had digitally and to the to the entire online economy. And I was trying to think of ways to get them online, but I wanted to do it in a way where the supporting entity organization wasn't necessarily charging them a tax for participating. So there's a lot of conversations that I had with, with the cofounders of of a nonprofit called Obrast del Pais around how we can create, an experience where the artisans themselves can connect to consumers, and they're not necessarily charged a lot because, traditionally, people who sold artisanal crafts would charge upwards of, like, 50% of, type of fee for for any of those sales. And during those conversations, I I was thinking about how can we automate this? How can we create an organization that's sufficiently lean? And that actually, intersected with the rise of DAOs back in 2020 and 2021. But before that, the back when I was 18, the I was working at, my parents wanted, me to work and to learn what working was like. So they got me a minimum wage job with my uncle, and the job was to count screw screws all summer. So it was, my job was to say Exhilarating work. Exhilarating work. I I had to sit down, and I had to count screws and put, I had a barrel of screws that I had to split into little packets of a 100. And I was like, there's no way this is, like, positive ROI for this organization. Like, the this is just, like, excess, like, value just being, like, poured down the drain. At one point, I asked, you know, can I weigh the screws instead of count them? But my uncle being being, you know, playing the role of I had to learn what a minimum wage job was, didn't let me actually count them. And so that that that kinda led to this entire rabbit hole or this turtle question, as one of my friends here in Berlin mentions, of how do humans coordinate. So I ended up working in DAOs, basically trying to both understand how we coordinate and create better a better world for everyone, how businesses actually create value surplus in today's economy, how the Internet impacts that, and most importantly, how those tools and systems can actually be used to create better better environments for the people who contribute to those ecosystems
and better relationships and better power dynamics. Yeah. It's really interesting. And I guess to follow-up then and to think about some of the the research and writing that you've done, and especially where you've talked around, you know, swarms often forming, not because of necessarily strict rules or protocols, but in the kind of absence of things. And people would just kind of find whatever's around them and make it work because they have that desire to coordinate or whatever is that binding energy of the swarm. And so how has that kind of changed your way of thinking about designing governance systems, especially in web three, where there was this such a strong code is law mantra in, you know, the DAO days in 2016?
I can't remember, who wrote about hardness in Ethereum. I'd I have to look it up. But when we think about, like, digital infrastructure, so how do how do people coordinate? Well, people first and foremost coordinate based in some of the environment that they sit in, based on the architecture that surrounds them. In digital environments, that some of that architecture is softer and some of it is harder. On chain being slightly harder, but not necessarily. Right? User interfaces also create, a lot of pressure in terms of what patterns of coordination can exist. And so one of the things that I that I think is really important is it's it's more important to be aware of the water that you're swimming in and what currents exist and what the architecture of the world around you is and how you can influence that. Then try to get the fish or in our case, the crowd or the agents or the people in these digital environments to move in a specific way. And so the design principles that are we bring to kind of the zkSync ecosystem is we're constantly thinking not of trying to convince people to, you know, to participate in a specific way, but how can we create an environment? How can we create the hardness of a specific architecture that produces good outcomes, an infinite game that people want to continue playing and something that creates a sustainable path for the protocol itself? So from the research in online swarms, I guess one of the main learnings is asking, okay, where does your horizon of control sit as an architect for digital spaces? And a lot of that has to do with the user with the user interface. When specifically in protocols, it has to do with the contracts that you're kinda deploying and the affordances of those specific contracts.
That really makes sense. And I guess when thinking about these, you know, the the environment or the the experiences that kinda shape governance overall, you know, Shelby, I wanted to turn to you and ask a question regarding, you know, the governance roast that I know you you had been part of previously and thinking about this element of, you know, the spaces and experiences we can and, you know, could or should be intentionally designing within our space. Whether it's, you know, within the ecosystem that, you know, we're particularly working for and the outcomes of the DAO or whether it's just to kinda set these kind of just broad cultural norms. And, yeah, I'd be interested in, hearing, if you don't mind sharing, a little more about that experience and and what it was like and the role you think that can play for folks in Web three if we start doing things like that a little more systematically.
Yeah. Absolutely. So that governance roast that you're referring to was actually just one event or one part of a, community hub that I helped organize and host at DevCon last year. It was the governance geeks community hub. So shout out to all the governance geeks who are listening, who attended. The purpose of creating spaces or organizing spaces like this Governing Geeks Hub and to organize different sessions and conversations with governance minded folks is really in in my experience over the years and having organized a few different versions of these meetups or spaces, having, like, focused conversations with really high context people on specific governance topics or challenges has been extremely useful. And while it's obviously important to remember that everybody's governance system is different or there's different implications involved in different ecosystems, to be able to come together and share experiences, learn from each other, exchange resources, recommendations, but also just to vent and to have kind of a safe space with other people who you are either working on governance or participating in governance, is very valuable, not only professionally, but also as as a human. So, I really enjoy, helping coordinate these spaces and, not only because it brings a lot of personal value, but I've gotten a lot of feedback that it's it's very useful for for other folks as well, especially so early on in this experiment that we're calling decentralized governance. Even though we've been around, I guess, for a few years now, it's I would still say in its adolescence and, like, mostly experimental phase, and there's still a lot to learn. So having those spaces is is important.
Eugene, were you able to go to the to to the at, yeah, to the roast?
I unfortunately had to miss the roast. I I made the very regrettable decision of, helping co organize or being part of organizing two spaces, so I had to keep running between one and the other. And there was a thing I had to lead at at the, at the grant related one, unfortunately. I was really bummed to have missed that because I know there was a, I think, a dauros that if I'm remembering correctly, Isaac from, from SEALs nine one one and and from shield three. And, I think it was him who organized it previously, and that was another one I had to miss. And just both sounded like such great events because I think that I don't know. It seems like where we've come from with code is law being such a mantra, at least in the earlier days, it's still taking us a while to truly understand that intersection of, you know, the technical protocol level or token mechanic level, and then the soft side and the cultural design that gets put on top of that so that each feeds to the other. It still feels like there's a lot of the space that figures like, oh, we designed the right thing, and then people just fit to that right thing. And it's like, that's a lovely idea, but that's not always necessarily how it plays out. So, yeah, both hearing both of kinda your last answers gets me excited for where we're about to head with the conversation in terms of, you know, unpacking a little more of what y'all have been cooking up at z k sync and really getting at that kind of, maybe circling back to this intersection of, you know, the token mechanic, the fundamental pipelines, the pipes that you're building, so to say, and then, like, the human aspect and just how humans gather around it and how those swarms form and get to work together. I'll pass it off to Jamila to take us to the next part of the conversation.
Thank you so much. I have a quick follow-up. Shelby, can we expect some cough burn event during Argentina DefConnect this year? Let's throw out some alpha.
I will say there are whispers amongst some of the past organizers from the Gov Geeks Hub at DevCon last year who are excited and motivated to do it again. So I
will Fingers crossed. Probably yeah. Confidently
say yes. You you can expect something,
not connect in our bonus hours. If you're part of the group, then you'll know. You know? Yeah. You'll you'll get the invitation.
No. But that's There's no shadowy governance, Cabal. Don't worry about it, you know. Yeah.
You know, just a one reflection, AGM, what you just mentioned and, like, something that I think that came out out of, the conversations from last year and also conversations this year across governance operators is I think that, you know, what's really happened and maybe to set the stage for for where we are today is that the initial model that was ideated from DAOs in, let's say, 2019 with FWB, with Forefront, with CabinDAO, has only recently after four or five years now come to a certain level of maturity, both from kinda like it's operationalized in a sense. You can run a playbook to kind of like launch an on chain organization with, like, token holders and delegates or with, validators or provers or network proof of stake. That playbook has just kind of matured. And I think within that maturity level, we've realized that it that code is law is one side of the spectrum. And but most organizations benefit from what I would say, code and law together for a broader design space. And unfortunately, or fortunately, depending on your point of view, we've we've now been able to reap the consequences of the model. So now we know deep down, especially as governance operators, what the positive and negative consequences of this model is. And we're kinda at an inflection point, which is, you know, where do we where do we go from here? And I'm kinda excited, you know, as we've done some stuff at zkSync, which we'll get into. But I think to set the stage, we are at the point where the first generation or the second generation of DAOs, because the first one was 2017 with the DAO. So second generation has been somewhat matured operationally somewhat, and we've been able to live through the consequences of the design choices back from 2019 and 2020.
To your previous quote that we should be aware of the waters that we're swimming in rather than focusing on getting the fish to move in particular way, what do you think, let's say, the average web three governance contributor awareness of the waters that we're swimming in right now, in your opinion?
I mean, I would say okay. So I'll flip it over to you guys. So right now, if you were if you were to describe Jamilia, like, you know, the main things that kinda define your actions within a governance system, what are what are maybe some of the things that come come to mind to you?
How would you describe the waters that you're swimming that that you're kinda swimming in right now? Well, I don't know, Rafa. Maybe our waters are very different. Maybe we're swimming in completely different streams, you know? What what would be top of mind for you? Well, okay. I think I would say that generally people, very much focused on, let's say, let's use the same allegory, on the little stream, the little river. And very often, we're forgetting that we're all part of the bigger ocean. So that would be my answer. And now back to you, Rafa.
Yeah. So I think I think this is there's a sort of myopia, I think is the word. I've never I don't know if I've ever said that word out loud. But there is this sense of localization that you kinda, like, only know your own kinda, like, stream and your own waters. And very often, like you get this narrow view, like you go to the governance portal, like Agora, Tali, Eragon, and you see that you need to vote and you need to choose yes or no, or maybe you need you need to do that. And you often think that that is the governance system. But there's also, like, an entire other kind of, like, part of governance system where, for example, protocol partners participate in road map development even before there's a vote for a protocol upgrade or, you know. And and that governance system is very, very clear potentially or very explicit for the partner itself, but not necessarily so explicit for the delegates. I think the water that we often miss is the fact of how influenced we are by kind of the ecosystem that we've normalized, like crypto Twitter, for example, exerts a humongous influence in terms of governance processes. Regulatory ambiguity has been something that has significantly shaped a lot of decisions in how we manage governance, has changed the language that we use in documentation. You know, every blog post checked by legal to make sure that you don't step on the how we test by accident because you don't want to like fall into that. I think those are some of the, some of the environmental factors that we need to create more awareness of because they do they do influence what we do on a daily basis. And they often lead to decisions which are often don't necessarily make sense. Like you're like, Oh, why did they post that on Twitter? And it's because, well, it's not really for it's not really for the governance system. They're posting it because crypto Twitter is expecting a post about whatever it is. Why did they word the docs that way? And it's like, well, actually, you know, because they've been reading all the legal documentation and they're trying to comply with a 130 different jurisdictions at exactly the same time. And then you're trying to do your best to, you know, both be accessible and be legally compliant at the same time. But that that's definitely I don't know. Shelby, what what are some that come to mind for you? Yeah. I guess, like, the the thing that's coming to mind for me just listening to you both of you talk is recognizing
that, yes, we are swimming in different streams. Every governance system is governing a different set of things, maybe to different levels or, like, different levels within a silo. So and I feel like the space has kind of fallen into or, like, the DAO world or DAO participants have kind of fallen into, like, a trap of comfort of an assumption of assuming this is how it works in this DAO, and it's kind of how it works in every DAO. But that is and maybe that did work. That assumption did work for the last few years, but that's starting to change. And that's creating additional tension because folks or delegates or other stakeholders and participants are just expecting one thing to be the same or some something to be the same across all DaaS, but every ecosystem has their own reasons for doing things different ways. And, I mean, even with z k sync and the launch of the z k sync govern governance system in September, you know, we we very quickly realized that that was an assumption a lot of folks brought coming to zkSync who have participated in other ecosystems where things are a little different here. So I'm having to kind of mitigate that and adjust, how how we discuss things and, create additional resources and stuff. Yeah. That's, I guess, just the main thing that was coming to mind listening to you guys talk. Yeah. And going back to the point about, like, the current playbook has quite matured.
When we started the design of the z k sync system back in I think, but it started back in October 2023. There are basic assumptions that we tried to go back to the basics or saying, what's the right legal structure? Structure? We ended up with an Austrian association, and we can talk a little bit about that in a second. But what's the relationship between foundation, between labs, between other protocol development organizations? What does a security council really need to be? We have definitions of stage one decentralization. Are those the same definitions that we think that will exist in two years? What are we actually designing for? Are we going to mint the token? You know, we we'll talk also about cap minters. And even it was very difficult to take a step back and think about how to become aware of some of the core assumptions that were kind of default. Like, do you launch with governance on day one? How do you what's the best way to do an airdrop three year into or four years into the airdrop meta when you have industrial level farming, that is basically trying to game your protocol for for multiple years. Right? And so and those questions still come up today. If you were gonna launch, a protocol and and go through the decentralization process right now so you can create a decentralized blockchain organization. You have to also, once again, go back to those basic assumptions and writing down those basic assumptions and being aware of them is it's a hard job and it becomes a harder job the longer that you're in the industry because you just take it for granted.
Yeah. And I think that, prepared out beautifully to just go into our next question on the organizational design. And you guys are doing it quite uniquely compared to other ecosystems. So from the Austrian association that you mentioned, Rafa, to z k governance program systems and borgs, you've created, sort of dual stack system, legally enforceable on chain governance. So it would be great if you guys could walk us through the choice of Austrian association model and how this concept of extraordinary membership fits into the broader idea of reasonable decentralization.
Yeah. So I'll I'll talk a little bit about the overall level, and maybe, Shelby, you can talk a little bit about the delegate relationships with token assembly and and such. At a high level, you know, we had a couple years back, there was kind of the incident where the the voters and the token holders were accused or found as part of an unincorporated kind of partnership. And so we wanted wanted to find a novel type of solution that enabled that that could could launch a token, manage a governance system, but also try to minimize the risks of the participants in that process. And that's how we ended up with the Austrian Association. And that we decoupled basically governance and, token issuance and regulatory alignment from foundation responsibilities of strategic partnerships and other types of ecosystem initiatives. That that was a big part of of the overall strategy. Again, thinking that we wanted to be we wanted zkSync to be able to survive regardless of whatever happened to any of the legal entities that were related to it. The philosophy here was that we were trying really hard to get away from just code and really think about the affordances that different jurisdictions and different legal frameworks provided us. And I think that's really what we've been trying to innovate on where, as you mentioned before, we want we want governance procedures, which are enforceable procedures. And that enforcement can be either via software or via legal relationships, and ideally at the intersection of both of them. And the Austrian Association then became, excellent legal legal structure that then provided, a path for delegates to become what we call extraordinary members. So together, they become the delegates who opt in to mem to that extraordinary membership become the association token assembly. And so they kinda like Sorry. How can they exit? What is the procedure for them just exiting? It's very simple. Just on the governance portal, they can, like, click a button so they can, like, participate or they can re resign. You know, you just click an active or inactive flag. So, Shelby, maybe you can talk a little bit about the some of those rights and responsibilities.
Yeah. So so as Rafa has already kind of previewed here, the Austrian Association model was very attractive for many reasons, but also, in particular for this special type of membership called extraordinary membership, which allows for participants to be able to opt in to becoming a member, which in theory offers then a layer of, liability protection while participating in z k sync. So designing for the issues or frictions that we observed with the Ookidau case and also concerns across the industry with governance participation and uncertain regulatory environments in regards to governance participation, the reason this was chosen was to to try to address that point. Disclaimer, this has not been battle tested. If anybody if anything ever happens, you know, we can't, like, a 100% certain say that not you know, nothing bad will happen, but the the design principle is there and is in place to try to protect, to protect and also incentivize,
governance participation from participants. Thank you so much. And I have a follow-up question here on your ZK governance program system. So if I understand it correctly, this is the framework that introduces legal contracting and accountability for proposal execution. So could you elaborate a little bit more on that and whether you think this kind of opt in legal structure could help DAOs mature. And as you've mentioned, shall we learn from, you know, other examples? Raffi, you mentioned Okeydau, or whether it reintroduces the risk of traditional gatekeeping, so to speak. Mhmm.
That's a that's a good question. So for for people who are listening, what Jamilia is referring to is z k GPS or or this, a governance program system is, it's a Cayman Foundation. And what it allows is that whenever a proposal is approved via the governance system overall, those whoever is participating as part of the SteerCo, as a service provider, has an entity to engage with. So in a lot of on chain organizations, you ask the question, okay, so if a proposal is approved or if a program gets kick started, is there any type of legal accountability with regards to this? And in most cases, the answer is no. You just sent tokens to a multisig and hope that that multisig, like, adheres to the proposal execution. In some more on chain organizations, the the DAO or the on chain organization contracts with, let's say, the foundation. There's other legal structures that exist. In our case, specifically for zkSync, z k GPS is kind of this con this legal counterparty. So whenever a program gets kicked off, you you have a letter of engagement, and you make sure that the people participating don't just have an on chain handshake where there was funds sent to a multisig, but you actually have a legal agreement that says, yes, I'm committing to delivering these services, and the on chain organization may be providing, token supply or specific tokens in exchange for those specific services.
Did you guys have any, sorry, unexpected outcomes or interactions or people not complying with rules? No?
Not so far. I think if anything, everybody has has a sigh of relief because it's far like when you write a proposal, you often don't have all the specific terms that you want in it. Like you're trying to keep the pro bowl. You're optimizing the proposal for readability and accessibility, not for enforcement and for clarity. And so the the response that we've received has been very positive, where whenever a service provider has a letter of engagement, they're like, great. You know, someone wrote down that I will get paid if I do work for this SteerCo. You know? Like, that's awesome. Like, that's that's good. It gives you a sense of security.
Also on the side of delegates or the token assembly, it also adds to the accountability. We'll talk a little bit more about the kind of on chain technical accountability that is kind of baked into our token governance system, I'm sure, at some point during this conversation. But because anybody who would be a signer on a multisig, for example, who is, like, managing a specific token program, if they mint the tokens and run, they could be held legally liable, which gives a a little bit more assurance and and comfort on the token assembly side. Not battle tested. But Not battle tested yet, but in theory. But we're we're you know,
we'll we'll try.
I have a question on, you know, other things that, in your opinion, set z k sinks governance aside from other protocols. Your credo is freedom, prosperity, and I forgot what was the third. Could you remind me?
Freedom, progress, and prosperity.
Right. Thank you so much. And I'm I'm curious about your opinion because it seems like in different ecosystems, more or less, all of the values could be boiled down to decentralization, inclusion of diverse voices, security of the protocol, efficiency in many of them. There was a study published by Medigolf. We mentioned it in other episodes that they analyzed constitutions of different DAOs, and they've highlighted that it seems like decentralization, one of the core values, yet nobody really defined decentralization. Nobody really understood how different communities understand that. So before we dive a bit deeper into, you know, specifics of your governance, Shelby, do you have anything that for you, for example, if someone asked you who is new to governance, to explain in simple terms, what is it unique about what you do at ZKSync that makes you guys just stand out compared to other ex systems?
Yeah. There's a few things that come to mind. I guess the first is really just on chain enforceability and transparency. So all governance at zkSync is is on chain, and is governed fully by the token assembly for protocol upgrades, for token governance, and even for meta governance decisions, as well, which we call GovOps. Governance is all on chain. The the way the governance system is designed is also it fits very is tied very closely to an additional value or maybe kind of, like, catchphrase that is, very popular in the the z k sync ecosystem, which is, don't trust to verify. And you notice that in, the token governance model that has been developed and deployed and, that that we're experimenting with now, to have to be able to programmatically enforce a process rather than having to manually manage it or trust specific parties to have to manage these systems or agreements that they said they would do things a certain way or only spend so much money at a certain time. Like, the the way the system is designed and what makes us unique, and we'll I'm we'll dive into some more details technical details as to why this is, especially in regards to token governance and the KathMinter token mechanic system that is used for token governance, allows for a lot more modularity and trust minimization in how accountability
and process is managed within the zkSync governance system. I was gonna I was gonna say, I think per per your comment on, like, the zk credo
Great credo. It's winner. I'm just I'm always curious to ask, you know, governance people about how they phrase the philosophy, the vision, because it tells a lot about the idea behind the architectural design of governance systems. So, yeah, I'm honestly, the shortest one I've seen so far. Usually, it's like pages and pages of ideology behind.
So I think Which is not better. I I think the core belief is we believe that freedom and within freedom, what I mean is, like, free competition and contribution is really the driver of innovation and progress, which then delivers prosperity to the participants. And I think that those values we take very seriously in terms of how we design the system. We designed a system that permissionlessly people can contribute, protocol upgrades. It doesn't mean that there's going to be a thousand protocol upgrades submitted right now. You know, the protocol is complicated. But for long term sustainability, we what we want is for that openness of participation and variation to be like the path that we're taking. I think that we code is law has a fundamental flaw, which people will exploit the code interpretation for their own personal gain and will try to capture the system. We know that's true. Like, manipulate the rules for their own benefit. And so one of the things that is unique about ZKSync, well, we can argue whether it's unique or not, but we believe in kind of, like, mission centered governance. And that's where the Guardians come into play, which is a council of highly trusted and values centered individuals who can veto proposals in the ecosystem if they're if they're malicious or if they're obviously misaligned and trying to, like, cause harm long term or short term to the to the ecosystem. And The Guardian serve as kind of the central checkpoint. Other ecosystems have a veto, a veto address, or they have a primary, you know, type of role that can only submit proposals. I think that serves essentially the same purpose, which is you're trying to maintain mission alignment in a permissionless system. We took the veto route in terms of the design, and we have on chain enforcement of that privilege and that right. That doesn't mean that that privilege for the for the Guardians can't be revoked, that they there can be a protocol upgrade which removes the Guardians at some point. But the system itself right now includes this entity that steers the orientation. There hasn't been a single veto since we launched, and I don't expect a veto in the near term either. But it does it's really important as a deterrence so that people understand that the mission alignment orientation is something that is taken seriously and every proposal is kind of reviewed, around it. The guardians themselves, they can't submit proposals. The only thing they can do is kinda like, like, like, high judges. They can review something and say, hey, this is actually gonna be back for the ecosystem.
Do you mind sharing a bit on how, the guardians are selected and what are the checks on the guardians?
Yeah. Absolutely. We have a blog post, on the selection criteria that I'll just read read through a couple of them. So steadfast personal visions. So we wanted individuals that had ambitious visions for the crypto industry and today's institutions around transparency, mutual accountability, public responsibility. We wanted people who were active advocates for cypherpunk values, people who had distribution and reach and were recognized voices with in-depth technical knowledge and ideally experienced entrepreneurs, active zkSync builders and partners, and who have an established trust with their with their communities. So the Guardians were initially appointed by the zkSync Association, so the inception, they can be changed with a protocol upgrade. And that's where kind of the check and balance here is basically the is basically that protocol upgrade process where there there is an expectation that Guardians are only going to intervene. But the fact that we have eight means that any individual agenda is not the dominant agenda of the Guardian. So you can have someone who has a specific interpretation of the ZK credo and the ZK Singh vision. That doesn't mean that a specific proposal will be vetoed. You have to have a five out of eight threshold for, for at least five of the Guardians need to say, we believe this is infringing on the Zika Credo vision for for them to be able to take action.
You mentioned ambitious individuals, being part of the Guardians. This reminded me of tweet I saw from Nick Almond, who is doing governance at Solana. And I don't remember the exact quote, but I think it was something like, how does one govern an army of geniuses or something like that. So, it's always a question. How do you facilitate governance in, you know, in the groups or security councils where there's just so many different talented people? And I want to pass my question to Shelby now because I wanted to hear more about this free body, decentralized governance, which from my understanding consists of guardians. Rafa just, gave us an overview of security council and token assembly. So could you walk us through the differentiations, and what do you mean by, like, decentralized, body governance body? How truly decentralized are they in their decision making powers?
Yeah. Happy happy to go over that. So as you mentioned, the zkSync governance system has a three body governance system. So the first body is the token assembly, which is just the term that we use for delegates and token holders who are a part of the governance system. The second body is the Security Council, as Rafa mentioned. And the third is the guardians, how all of those three interact with the governance system. Token assembly votes on all proposals. The guardians are able to veto all proposals. And the security council actually only has final approval power over protocol upgrades. So we actually have three separate governors, which is really cool a really cool design primitive because you're allowed to have unique parameters for each of those governors and those different proposal types based on different needs. So the the security council actually only interacts with the protocol governor, and and only interacts, like, with, for in with the purpose to approve protocol upgrades. Yeah. So the security council and the guardians are are the most, I guess, closed off of the two bodies. They do have both of them do have a requirement or expectation of transparency in any decision that they do make. And the process of approval for protocol upgrades, for example, the, the security council, we see a lot more active because as, as, Rafa mentioned, there haven't been any veto. So the guardians haven't had to share much about, their, their opinions yet. But, so what we do see more often is the security council in the process of approving their protocol that have been approved by the token assembly. They they will share reasoning or information around why, a protocol upgrade is passed, or if they do decide not to execute it, why not? The token assembly, like I said, is made up of all of the delegates and token holders within the z k sync sys ecosystem. That is a anybody who just like in any every other ecosystem, anybody who holds the ZK token is able to delegate that voting power either to themselves or to another delegate. What we've seen is, since since launch, actually, we've had a pretty great spread, I would say, of, in terms of how many folks are meeting proposal, threshold, the kind of diversity in delegates that we're seeing, involved in the governance system and how that's evolved over time has been has been really has been really great to to see. For example, there's the top, like, 20 or 30 ish delegates. There's a really healthy mix of z k chains, different builders in the ecosystem who are contributing to the z k sync protocol or ecosystem, professional delegates, and also other supporters or kind of fans of the z kSync system. So to see that and also to have, I believe it is, we have 28 delegates who currently have a proposal who meet the proposal threshold. So, that means 28 delegates are able to submit proposals, which is a pretty big number, considering how big zkSync is. So so, yeah, that's on on that front, I would say, you know, there's always, like, further decentralization, and there's always the argument of are delegates actually decentralizing because you're centralizing voting power. But in terms of the diversity of delegates who are in that top range and also who are able to meet proposal power, I would say is is pretty diverse to decentralize in in nature.
I think decentralization comes in a variety of different ways. So all the security council members are, independent of each other. There's no, like, there's no entity that has multiple seats. So you have 12 different entity and individuals that are fully unique. The guardians have eight individual participants, and the delegates as well are, like, all independent entities. Most often, they're they're participants of the z k sync ecosystem. And that's, like, that's a that's really good. And obviously, we're a very new ecosystem, so there's work to do. But if we fast forward, you know, what will this look like in, like, five or ten years? Well, the hopefully, like, the delegates will represent z k sync chains, z k sync applications, infrastructure providers, individual builders and entrepreneurs, cypherpunk advocates who are aligned with the z k credo, different developer organizations. And so we should see not just not just the amount of people participating increase overall. Maybe we won't see the number of delegates with proposal power to increase significantly. I mean, you know, having 30 individuals with proposal power is quite a bit, and it needs to say, like, you you still need to make sure that global consensus is is coordinated in some way. But I do think that the diversity of participants is really important. And something that we don't talk about very often, but something that we were very conscious of is that the Security Council, for example, has 12 people and they represent all major jurisdictions legally are around the world in all different time zones. And that's really important. If you really want a 20 fourseven protocol that is capture resistant across a variety of different, like, actors, including state actors who might be might have incentives to kind of manipulate the system, You do need that diversity in terms of jurisdictions, time zones, representation, different entities. It's quite critical. So that's that's a key design principle from our side is, yeah, we want representation and we also want a good balance between between people from all around the world.
Yeah. And I agree with you on decentralization that comes in different forms on your quote. Usually, I'm the first person to say, we shouldn't just divide everything on black and white and say it's either fully decentralized and not decentralized. And here I am asking Shelby a question to which extent your delegates or your governance bodies are decentralized. I know it's always tricky, but to me, it's also interesting how people define, like, decentralization and whether they view it in a similar way, of it being rather a spectrum, or they decide to just, you know, have specific criteria of what defines decentralization for them. So it's always very interesting. And I'm being mindful of time, but I really wanted to ask you guys on your token governance model, capped minters. Shelby, could you maybe quickly give us an overview why did you choose to move away from the concept of minted treasury And, what is a bit more usual that we see in this space? And you moved to mint on demand system, if I can call it this way. So it would be great to hear some of the, maybe, core differences between capped winters and traditional treasuries that we usually see in other ecosystems.
Yeah. I actually will pass this one to Rafa because he was more intimately involved with the design process and decisions on this one. So, Rafa, I'll let let you kick us off.
I'll talk I'll talk maybe I'll I'll talk about the the first piece, and maybe you can talk about the token mechanic, kinda how it's, like, evolved. When we are designing, the token generation event, there was a there was a lot of questions around how do we do this right. And but the the question came up, you know, do we should we have a treasury? Should we mint all the tokens and then distribute them? But what we actually, found out was, I believe it was Gabe Shapiro from MEDALEX who made the recommendation of saying, okay, so why why cap minters? Why not cap minters? Why don't instead of minting them, why don't we give rights? Why don't we govern rights instead of asset transfers? And what this means is that the you you you don't have any pooled funds to begin with, and each airdrop recipient and each token recipient at the token generation event is basically minting the tokens themselves. They have rights for those tokens individually without any sort of pooled funds. And this this comes from the cap minter mechanism. You're distributing rights under cap minter, which means you can mint up to a specific amount, which is the cap. And that means that each person's activity is distinct and not interdependent in terms of the token distributions. This is this is really great. What what I think we didn't know at the time was that this wasn't this wasn't just good for the token generation event, but it was a very effective way to reframe, the the protocol governance of this token itself to focus on basically token rights and token mechanics. And so that vision of the cat vendor kind of, like, began evolving. And maybe, Shelby, you can talk a little bit about, like, how it's moved into a modular kind of framework.
Yeah. Happy to. Before I do that, I just because I'm not a 100% sure we actually defined what a cap mentor is.
That would be great if we can start with the finishing. Yeah. Yeah.
So a cap mentor you can think of a cap cap mentor as just a simple, unique smart contract that enables this just in time minting that we've mentioned a few times now. And in this simple smart contract, there's a few parameters that you can set. The main one being the cap or the limit to the amount of tokens that could be minted within that given contract. Hence, why we call it the capped minter. How it works is that anybody who has, the minting role on that cap minter is able to mint the tokens up to the cat, to is able to mint CK up to the designated cat for that specific cat minter. Now how does that tie into governance is also an important piece to to mention and clarify. So how you can deploy a CatMiner contract. I can deploy one. You could deploy one right now. It wouldn't mean anything. In order for it to be activated, a governance proposal has to be passed that grants the minting rights on that cat minter that will allow the admin, or anybody with the minting role on that cat minter to mint, from that cat minter. So how our governance looks different from other ecosystems is in other ecosystems, for example, when you pass a governance proposal for token governance, our the on chain action is execution of a transfer. The on chain action here is granting the mentor role on a cat mentor or multiple cat mentors depending on the program. So that is kind of like the core and you can think of the cat mentors like the core building block for what this kind of bigger, topic or concept that we're calling token mechanics. So if a catminter is a simple, unique, smart contract, a token mechanic is a combination of additional smart contracts. And those smart smart contracts put together that interact with each other or maybe set specific rules or limitations on, the contracts that they're linked to is what comes together to what we call a a token mechanic. And with these token mechanics, you're able to, really have a lot of modularity in how you design token distribution or allocation within a specific program from a specific cap vendor. How that's evolved over time since launch. So when govern when Zikistan governance launched in September, we had the cat meter.
But September 2024.
September 2024. So we're still not even a one year into the governance system yet. But when we launched in September 2024, we had the cat vendor, and we had this vision of token mechanics and this kind of utopia of automation and programmatic enforcement for, for the deployment of token programs, within the z kSync ecosystem. Over time, we in order to demonstrate what a token mechanic is or what it could look like, we started by speaking with existing teams who are already building token mechanics. This the concept of a token mechanic or, like, a smart contract that executes distributions or actions, autonomous autonomously is obviously not new. And we were able to actions. Autonomous autonomously is obviously not new. And we were able to identify and work with a few different teams to help demonstrate how a cat manager could be hooked up to these existing contracts. What are some examples? Hats protocol, for example. If you want to put eligibility on a cat mentor. So if anybody who has a specific hat, for example, would be able to, mint from a specific hat mentor rather than having, like, a specific minting role of an individual or or a team. The other, like, kind of examples of of types of teams we we were talking to and also having come present delegates to help kind of draw this picture of what token mechanics could look like were a variety of streaming, or, vesting contracts. So Dripps, Sablier, Hedgy, those kind of projects, You could hook a cat mentor up to a distribution contract, a drips contract, a save a Hedgy contract to mint and distribute the tokens in that way. And as we were going through that process, we had the realization of, there it feels like there's still something missing that could make this a lot easier to hook up a cat mentor to these other great existing tools. And also there's tools that don't exist yet that would also be nice for, for us to have. And that's when we started, working on this concept of minter mods or like minter modulators that can be hooked up specifically to, to a cat mentor contract. And the examples of of those that we've been working on are the, rate limiter minter mod, which assigns a limit to how much z k could be minted from a given cat mentor over a certain time period. So imagine you are running a program, a token program, and you have a set of service providers who have to get paid every month. Rather than having a Steerco or a multisig who's managing that program, mint tokens and send it to a service provider every month, that Steerco can grant CapMinter to that service provider with rate limiter on it, and they can pay themselves every month knowing that there's a cap. There's they can only mint up to a certain amount in whatever the agreed amount is for the server that service that's being provided. So that's one example, and that that's, actually one that we're we're you can actually build yourself, right now or it's it's been, audited and deployed. So that's a really exciting example. Another one is an eligibility mod. So I mentioned the hats example, earlier, but the eligibility mod allows you to plug in a little bit easier than it was before. You you can do a HATS contract. You could do other eligibility requirements more specifically. And there's a few others as well. But just to give you guys an idea of where we are today and where we were when we started, it was more like kind of core building block, Cat mentor contract. Here it is. And here's the vision to experimenting with existing tooling, to now building kind of, or helping develop our own, like own cap, additional mintermod contracts to kind of tie all these pieces together. And what we're trying to create here, the outcome of this is to have like a, almost like a, a token mechanics toolkit for people to be able to just look into and take what they need and build together kind of like a Lincoln log or like a Lego set sort of model of a a token mechanic for their token programs.
Before we jump into the wish list of the tooling, that would be great to have. Hopefully, you have time to cover that. It's great that you mentioned the HATS protocol because we're also hoping to have them come to our podcast in one of the upcoming episodes. Before I hand it over to you, Rafa, Shovi, I was just curious on the safeguards. What are their safeguards in place that would prevent the, that would prevent abuse of minting rights, if there are any?
Yeah. Absolutely. So, as I mentioned, a little bit earlier in the conversation, minting rights are granted through governance, so on CapMentor. So like I said, I could deploy a KatMentor contract right now with a cap of a 100,000,000 z k, and it would be meaningless because I don't have the minter I don't have minting rights on or the mentor role has not been granted on that KatMentor. So not in terms of, like, a or, like, restriction, anybody can deploy a Catminter, but only Catminters who are granted the mentor role through governance.
But those rights are being reviewed in this cyclical manner. And sorry for stupid questions like that. But, like, let's say I was a trustworthy agent, and now I'm no longer am. Like, what are the safeguards that prevent those or do those checks? Yep. So so there's two. And and the reason I mentioned,
again, the the granting of minting rights being required in order to mint is that the token assembly can also pass a proposal to revoke those minting rights at any time. So that adds, like, a very legitimate, like, hard coded accountability mechanism for the token assembly to pull the plug essentially on any token any token program rather than say the community maybe, like, being upset and demanding a a proposal to be canceled for whatever reason and maybe passing, like, some sort of vote, but they don't they still are relying on, like, the multisig to send those funds back to a treasury. Or in this case, the tokens aren't minted yet. So the the token is something that can basically pull the plug or cancel, program at any time. And it the second point actually brings us back to z k GPS, which we were talking about earlier, and the legal accountability that is with all of the signers on any given multisig who would be an admin or managing, a cat mentor, a, legal, contract, in place to again, if they mint the tokens and run, they they could be they could get in trouble for that. So those are the two main,
safeguards. Would add also add so the the current version of the capminter also has what we call a pauser role. So most often the way that it's designed is so a token assembly is providing, is delegating rights to mint. So Eugene, Jamilia, you guys have the right to mint up to a 100 tokens, maybe up to 10 z k tokens a month. And your program gets canceled, or you guys decide you wanna go to Bermuda for a bit and use your z k tokens. Very often, there's, what we call security council is responsible for that posit role. So you could have minted 10 or 20 z k, and then maybe you're using the funds not in alignment Mhmm. To the proposal. Well, the security council, in this case, if they had been assigned a posit role, can also pause the cap mentor. So there's different configurations here in terms of security. You can add a rate limiter, which provides one layer of security. You can have posit roles. You can have the token assembly take action. You can have an emergency action, take place by a security council similar to like an incident response for a protocol hack or something like that. So there's a variety of different different layers. The key thing here is that you're managing rights. And what this means is when you manage rights, it gives you more flexibility because the assets are not in a multisig controlled by Eugene and Jamilia. The assets are actually rights inside a contract. And so you can then create controls on those specific rights, which echoes a little bit in terms of what you might do with, like, multisig zodiac modules in Gnosis. For those who are familiar, Gnosis has different modules that you can add different types of controls in terms of the multisig. This is similar, but the controls are upstream in terms of the rights distribution, and therefore tightly integrated into the governance process, not in a separate type of toolkit.
Great. Thank you so much guys for clarification and just detailed examples. One thing before we jump to our fun quiz part, I wanted to ask you on just, like, metrics and performance and how do you guys measure it? Because we saw zkE governance performance overview dashboard, and there are some of the metrics. And as we all know it, who are anyone would know who participates in governance, that there's just so many things, like, outside of on chain trackable activity that goes into the performance or just the feeling or, you know, just so many things that just go beyond past numbers. So my question to you guys, how, first of all, you evaluate zkSync governance performance as of today, summer twenty twenty five? And maybe also, going looking into the future, talking about maybe a wish list of DAO tooling or any things that you don't see quite yet, but in your opinion, that would make your life as governance facilitators easier?
I can start. And, Rafa, you you can you can add on. So, it might sound like a silly one, but given that zkSync governance just launched in September, 2024, one of the metrics that we've measured or considered to be a success metric is, governance validation. The governance system and contracts, as deployed, work as they are meant to, and people are able to pass proposals. And, the security council is able to interact with protocol upgrades, and the guardians are able to execute Avido as we've just verified a few weeks ago with a, with a a kind of test, proposal that we that we ran with with the Guardian. So the governance system has been validated to work as is, and that that's one simple, I guess, success metric that that we've looked at just because we're in this early stage. Another thing that we, have been really happy to see is that the a 100% of standard protocol upgrades have gone through the governance process, since launch. So, on chain protocol governance is also been validated, and it works. And, this was the like, this protocol upgradability or protocol sustainability is one of the primary objectives that we were aiming for this year to have reliable and secure and predictable protocol upgrades for the z kSync governance system after handing over the keys to the token assembly to be and and the the governance system, to to be able to upgrade the z kSync protocol and keep rolling out, cool new features and upgrades. So and then the the other thing that Rafa and I track pretty closely is participation and delegation. As of last month, we were tracking towards around 960,000,000 z k in active voting power. Active voting power. Active voting power is what we, how we define active voting power is any delegate who's participated in two of the last five five votes. And the last time I checked, I think we had around, at least a 100 delegates with over a 100 k, a ZK voting power, who voted in the last two to five votes. So, yeah, having that active participation, and engagement from delegates in the governance system has also been something we track on on on this dashboard. If you if you take a look at it, you'll see there's a ton of metrics, for for delegate metrics. I was surprised to see that it's an average three days that it takes to reach a quorum.
I'm feeling it's quite quite short amount of time considering just other ecosystem examples. What do you think, Rafa?
The main thing that we want is we want protocol upgrades to work seamlessly. Right? And okay. So how do we make that happen? Well, a, you need to be able to hit quorum consistently, and b, you wanna minimize the risk that a valid vote didn't necessarily reach quorum because people forgot to vote. Right? You wanna avoid those those situations. So that's why, Alicia recommended, we start tracking kinda like time to quorum. This time to quorum is really powerful because you can kind of compare it with the total voting window. In our case, the voting periods are seven days. So you want your time to reach quorum to not be six days on average. Right? You want it to be like two to three days, three to four days mat. We're what we're trying to do is we're trying to find ways, trying to identify the frictions that actually lead to that delay in voting process. It should be as easy as possible to to vote, and you should be well educated in each of the proposals as a delegate, by the time you you reach the portal to make a decision on whether to vote or not. So there's a lot of front loading that we're doing. Like, I know there's a proposal coming up very likely next week. So we that we wanna make sure that, the proposal sponsor and the proposal team are posting it on the forum with plenty of time. They're doing the rounds, educating people, answering questions. And everybody is knows when the vote starts and are ready to vote as soon as possible. That's kind of what we're aiming for. Obviously, there's a lot there's no silver bullet. There's simply a list of a thousand small little things that cause, like, delays. And when you solve one at a time, actually, the value the the benefits compound. One little known thing is, you know, if our vote period is seven days, you want to minimize starting a vote on Friday afternoon. And you want to make it because then you lose potentially two days over the weekend. So you want to make sure that the vote starts maybe on Tuesday. So you have momentum in terms of the voting process. So those are there's a lot of it's death by a thousand cuts or time to quorum by a thousand improvements. And that's it's still the first year, but we're hoping we'll get that as seamless as possible. And part of that is, like, voting on mobile, accessibility, education,
simplifying I was about to ask you what's the future of governance in terms of tooling, and if we were to meet up in the same great company a year from now, do you think that governance will evolve in a similar way that, you know, zkSync governance is set up with legal wrappers, opt in membership, enforceable on chain actions? So do you think that would become the norm or you'll see wider divergence on how protocol handle their compliance and liability?
I think that maybe this is a hot take, but I potentially think we're at the highest level of complexity for governance in terms of the story arc of governance processes. I think it's all simplification from here. As, we had the Genius Act pass pass earlier this week, Clarity Act in The US is coming through. There's new definitions that are coming into play. And I I hope that through this process, what we're seeing in terms of macro trend is clarity in terms of what actually constitutes a decentralized system and what constitutes an accountable system, both from legal and on chain perspective. So code and law, you know, or protocol and law or lawful protocols, one might say. Even if they are cross jurisdiction, international mechanisms, we what we should try to do is simplify. So I think we're I'm hoping that even though protocol complexity and power will increase, the governance systems of these protocols will decrease in both risks, decrease in terms of risk with increased security, with increased proper participation for decentralization. I am hoping for further simplification. And I think part of ZKSync will be to pursue further simplification.
Thank you so much. And I wish we could continue just talking and talking, but, mindful of time. Yes, Eugene. Over to you.
Yeah. So just to wrap up this episode, we like doing a little quiz where we'll be asking both of you the same question and ask that each of you please keep your answers to one word. And Shelby, I'll start with you for the first one. How would you describe governance at zkSync in one word?
Technical.
You always put me, put me I know you told me that this question was coming, and I still, like I'm still, like, unprepared for it with some word association. Okay. Z k sync governance is the standard.
K. What do you see as the vibe in DOWs these days? One word.
Frustrated.
Institutionalized. What's and now to switch the order. So Rafa, if you don't mind going first for for the last two, what's an idea that you wish more of those who are building and designing DAOs? What's an idea that you wish they would keep in mind when they sit down to start designing the DAO?
Less is more. Governance.
Or don't innovate.
Governance service minimization. It's one word, Shelby. Hyphenated.
Lot lot of hyphens in that answer. And then the last question for both of you, what is the future of governance in one word?
Regulated. Spearmantle.
Well, yeah, we appreciate you both taking the time. I feel like we easily could have filled another hour in conversation here, but we both appreciate you for taking the time to chat with us today and for all the work that y'all are doing.
Thank you, guys. It was Thank you, guys.
Really enjoyed it.
Thanks for tuning in. The Governance Futures podcast is sponsored by the Scroll Foundation and produced by the governance team at the foundation, Eugene Leventhal and Jamila Kamalova, with editing support from. Any music and photos are tested in the episode description. If you'd like to get in touch, reach out over Twitter at gulf underscore futures or you can email us at governance@scroll.io. Until next time.