user : Getting key stakeholders in your ecosystem (e.g. builders, users, partners) to participate, rather than professional or random delegates/token holders. assistant : ### What evidence or examples demonstrate this is a real problem? This could include failed proposals, low participation rates, specific incidents, data you've observed, or patterns you've noticed across projects. user : Ideally, those who have the most skin in the game should be participating in governance. Skin in the game includes both token ownership, but also if you are building something on the protocol being governed. In almost all major DAO ecosystems, there are at least 2-5 professional delegates in the top 10. These teams typically do not hold any tokens, and are not actually building in/using the protocol/tech being built in the ecosystem. In other words - those with no skin in the game hold a lot of voting power in most DAOs. They also often don't require the technical expertise needed to assess technical proposals/protocol upgrades. Another issue is that a lot of projects building in an ecosystem (e.g. chains) don't have the time/desire to participate in governance, even though they are typically the once who are most impacted by governance outcomes - especially in regards to protocol upgrades. I have personally done governance onboarding research in the ZKsync ecosystem with different chains or apps building on ZKsync, and most folks are heads down busy working on their project and had not thought about how governance decisions can impact their own chains/work. I also found a big hurdle was just getting a Delegate profile set up/deciding who on their team should be responsible for it. This group requires a custom onboarding for each case to get them both set up and participating. Another pattern noticed is that many token holders often do not understand/care about the actual protocol project that they have decided to buy a governance token for - the main concern is price. Similar to professional delegates, many token holders often do not not have the technical expertise to be able to assess technical proposals, nor do they understand how much certain things cost (especially in regards to security e.g. security audits, bounty programs, etc.). Most folks tend to assess proposals only from the perspective of token price impact, which often leads to misalignment with the reality & needs of the ecosystem to achieve the strategy & mission. assistant : Would you like to share another governance problem, or should we move on to exploring solutions and who's working on them? user : Move on assistant : ### What approaches, tools, or mechanisms could address the governance problems we've discussed? Share any potential solutions you're aware of or have considered - these could be technical tools, process innovations, research directions, or organizational approaches. user : - Customized onboarding strategies for specific builders / partners you want to have participating in governance. e.g. custom onboarding docs outlining support with setting up delegate profiles, help source voting power if possible) - Design airdrops to target partners & builders in ecosystem to help seed voting power for these groups in your governance system. - Delegate tagging system on governance interface: e.g. ZKsync has a tagging system that tags all Chains, Apps, Technical Partners, Security Council members & Guardians. There is also an "active" tag to see who is actively participating in governance and which profiles are "dead". This helps token holder looking to delegate their voting power better easily identify a) key participants in the governance system and b) who is actively participating. - Delegation pool programs: Allocate a portion of treasury to a delegation pool program that delegates X amount of voting power to each e.g. Chain (or other key participants) building in the ecosystem. assistant : ### Which teams, projects, or researchers do you know are actively working on these solutions or related governance innovations? This helps us map who's contributing to solving these challenges. user : ZKsync has a custom delegate tagging system, and has experimented with customized governance onboarding strategies for specific builders & partners in their ecosystem. I believe OBOL also has some sort of tagging system. Uniswap did the Treasury Delegation program a few years ago that delegated up to 10 million UNI (approx. $100M+) from its treasury to "underrepresented" delegates. Airdrops have started to become more strategic over time to target more specific groups within an ecosystem. Celestia's modular ecosystem onboarding is probably the best example that I am aware of. Their airdrop targeted targeting developers and Ethereum researchers github commits to ensure tokens ended up in the hands of people who understood the technology and would build apps on top of it - rather than random token farmers. This could be adapted to target specific chains or projects building on your protocl, which also acts as a strong incentive mechanism for teams to build in your ecosystem. assistant : Would you like to share more solutions or identify additional actors working in this space, or should we move to wrapping up? user : move on assistant : ### Thank you for mapping governance challenges and solutions Here's a summary of your contributions: **Problems Identified:** - Getting key stakeholders in your ecosystem (builders, users, partners) to participate in governance, rather than professional or random delegates/token holders **Evidence Provided:** - Professional delegates (2-5 in top 10 of most major DAOs) hold significant voting power despite having no skin in the game and often lacking technical expertise to assess proposals - Builders/chains in ecosystems are too busy to participate in governance, even though they're most impacted by decisions - require custom onboarding to get set up and understand relevance - Many token holders don't understand or care about the protocol itself, focus primarily on price impact, and lack technical expertise to assess proposals or understand ecosystem costs/needs **Solutions & Approaches:** - Customized onboarding strategies for specific builders/partners (custom docs, delegate profile setup support, help sourcing voting power) - Strategic airdrop design targeting partners & builders to seed voting power - Delegate tagging systems on governance interfaces (identifying chains, apps, technical partners, active vs. inactive delegates) - Delegation pool programs allocating treasury funds to delegate voting power to key ecosystem participants **Active Contributors:** - ZKsync: Custom delegate tagging system, customized governance onboarding experiments - OBOL: Tagging system implementation - Uniswap: Treasury Delegation program (delegated up to 10M UNI to underrepresented delegates) - Celestia: Strategic airdrop targeting developers and Ethereum researchers via GitHub commits Does this summary capture your main points accurately, or would you like to clarify or add anything? user : Is it too late to submit another problem? assistant : Not at all! We can absolutely go back to problem mapping. What governance challenge would you like to explore? user : Delegates and token holders have gotten into a habit of assuming governance works the same / is used for the same thing in every ecosystem. This often leads to frustration and eventually apathy of many participants assistant : ### What evidence or examples demonstrate this is a real problem? This could include failed proposals, low participation rates, specific incidents, data you've observed, or patterns you've noticed across projects. user : Governance suface area is unique in every ecosystem. First, it comes down to what you are governing. Typically, governance is used to govern 1 or a combination of three things: treasury, protocol, "meta-governance"/social decision. Depending on what you govern usually significantly impacts governance design & tooling. The next layer of governance surface area is exactly how much governance touches of each of those 3 silos i.e. what level of detail does governance get to make decisions on. For example, voting on the logo color is different than electing a team/council member who gets to make those kinds of decisions. Most projects do not communicate the exact governance surface area clearly enough in documentation. And while governance does/has worked the same for many ecosystems over the past 5-6 years, each ecosystem has their own unique set of values, goals and priorities that delegates unfortunately do not always understand or attempt to figure out before participating / making demands in an ecosystem. Another consideration is the phase a project is in at any given time. e.g. if your protocol has sufficient revenue they can by all means play around with grant programs, but if you are pre-revenue and there are critical priorities that need the support of governance programs, those should be prioritized. Many delegates & token holders don't quite understand that, as many are wanting/expecting programs that benefit them first. When ZKsync governance launched in September 2024, many delegates who participate in other ecosystems showed up with a set of assumptions & proposal ideas that they are used to / have seen in other ecosystems - especially in regards to token governance / program ideas (e.g. grants, delegate incentives). The governance team stayed strong in sticking to the priorities that were ratified by the community via governance vote for year 1 which were 1) protocol security 2) chain incentives 3) app incentives. This didn't include/leave space for the typical programs people were expecting, but it was necessary to stay on track with strategy and priorities, also considering the developmental stage the project was at at the time (pre-revenue/PMF). assistant : Would you like to share another governance problem, or should we move on to exploring solutions for this one and the earlier problem? user : Solutions assistant : ### What approaches, tools, or mechanisms could address the governance problems we've discussed? Share any potential solutions you're aware of or have considered - these could be technical tools, process innovations, research directions, or organizational approaches. user : All projects could benefit from trying to be more transparent about their true governance surface area. Going beyond explaining what your governance governs, they need to better explain to what extent does governance touch each of the silos it governs. This can be reflected in better docs, clearer language, better diagrams etc.) Delegate onboarding programs/tests could be useful to ensure delegates understand exactly what your governance governs, understand priorities and strategy. This could be an annual test - making sure folks are up to date as these things evolve within an ecosystem over time. Another good way to get folks to pay attention is to get them involved in the priority/strategy decision-making process. This could be something like the Scroll's co-creation sprint project, that brings core team members/builders together with the community to help agree on annual priorities / strategy. assistant : ### Which teams, projects, or researchers do you know are actively working on these solutions or related governance innovations? This helps us map who's contributing to solving these challenges. user : Scroll probably was the best example of delegate onboarding programs and the co-creation sprints. In regards to a good description of governance surface area, most projects have clear descriptions of what they govern (e.g. treasury, protocol, meta-gov" but they don't do a good job of explaining the depth of gov surface area for each of the things being governed. I actually think the clearest model that almost existed was Eigen Layer's council model. Governance elected the councils, but the councils decided everything else. The surface area was simple and at the highest level, with clear accountability mechanisms to keep councils in check. I also can imagine that some teams keep governance surface area a bit more ambiguous due to legal/regulatory concerns, but that may change soon too. assistant : Would you like to share more solutions or identify additional actors working in this space, or should we move to wrapping up? user : wrap up assistant : ### Thank you for mapping governance challenges and solutions Here's a summary of your contributions: **Problems Identified:** 1. Getting key stakeholders in your ecosystem (builders, users, partners) to participate in governance, rather than professional or random delegates/token holders 2. Delegates and token holders assume governance works the same/is used for the same thing in every ecosystem, leading to frustration and apathy **Evidence Provided:** *Problem 1:* - Professional delegates (2-5 in top 10 of most major DAOs) hold significant voting power despite having no skin in the game and often lacking technical expertise to assess proposals - Builders/chains in ecosystems are too busy to participate in governance, even though they're most impacted by decisions - require custom onboarding to get set up and understand relevance - Many token holders don't understand or care about the protocol itself, focus primarily on price impact, and lack technical expertise to assess proposals or understand ecosystem costs/needs *Problem 2:* - Governance surface area is unique in every ecosystem (what you govern: treasury, protocol, meta-governance; and to what depth), but most projects don't communicate this clearly enough - Delegates arrive with assumptions from other ecosystems and push for programs/proposals that may not align with current priorities or developmental stage - ZKsync example: Delegates expected typical programs (grants, delegate incentives) but governance stayed focused on ratified year 1 priorities (protocol security, chain incentives, app incentives) appropriate for pre-revenue stage **Solutions & Approaches:** *For Problem 1:* - Customized onboarding strategies for specific builders/partners (custom docs, delegate profile setup support, help sourcing voting power) - Strategic airdrop design targeting partners & builders to seed voting power - Delegate tagging systems on governance interfaces (identifying chains, apps, technical partners, active vs. inactive delegates) - Delegation pool programs allocating treasury funds to delegate voting power to key ecosystem participants *For Problem 2:* - Better transparency about governance surface area (clearer docs, language, diagrams explaining not just what governance governs but to what extent/depth) - Delegate onboarding programs/tests to ensure understanding of governance scope, priorities, and strategy - potentially annual to keep folks updated - Involve community in priority/strategy decision-making processes (like co-creation sprints) **Active Contributors:** - **ZKsync**: Custom delegate tagging system, customized governance onboarding experiments - **OBOL**: Tagging system implementation - **Uniswap**: Treasury Delegation program (delegated up to 10M UNI to underrepresented delegates) - **Celestia**: Strategic airdrop targeting developers and Ethereum researchers via GitHub commits - **Scroll**: Delegate onboarding programs and co-creation sprints bringing core team/builders together with community for annual priorities/strategy - **Eigen Layer**: Council model with clear governance surface area (governance elects councils, councils decide everything else) with accountability mechanisms Does this summary capture your main points accurately, or would you like to clarify or add anything? user : Done assistant : Thank you for participating in phase 1 of gov/acc research, Participant 15! Your insights on stakeholder participation challenges and the governance surface area problem will be valuable contributions to building the research roadmap. These will be synthesized with other participants' input to inform the visualization and workshop at EthCC.