← Back to Leaderboard Analysis Dashboard

📄 DAO Function Guidelines (aka The Pizza Framework)

1 chunks  ·  Format: markdown

Priorities Extracted from This Source

#1 Decentralizing core operations by adding multiple external contributor teams
#2 Reducing single points of failure in core development
#3 Reducing concentration of power and unilateral control
#4 Avoiding DAO execution for functions poorly suited to DAOs
#5 Using DAOs for functions aligned with DAO strengths
#6 Empowering community members to execute parts of core-team responsibilities
#7 Establishing neutral or loosely affiliated governance bodies
#8 Supporting autonomous DAO operations and infrastructure

Document Content

Full text from all 1 processed chunks:

Chunk 0
🍕 ### There are two ways to decentralize existing, centralized operations: #### Let’s say we have a pizza with 8 slices #### We can create 16 slices, by adding another pizza! (Adding multiple external contributors to reduce dependencies on core team ) It can make sense to decentralize in this way when: The point of decentralization is to reduce a single point of failure (only one core development team). “Adding more pizzas” reduces the risk of this failure by creating redundancy. You will want to facilitate collaboration in these instances. Classic example: It is unusual to decentralize the core operations of the original core development team; instead, Core Developer Programs reduce dependancy on the original core team by allowing additional developer teams to contribute to the core protocol. This type of decentralization is usually addressed earlier in the decentralization process. The point of decentralization is to reduce the concentration of power or eliminate unilateral control. “Adding more pizzas” can create competition, providing a check on the dominant or incumbent decision maker. Classic example: A group of core developers becomes to power, exercising outsized control in the development of the protocol. A competing or alternative group of core developers can provide a check on the power of the incumbent core developer program. This type of decentralization is usually addressed later in the decentralization process. It can also make sense to decentralize this way when the function does not lend itself well to DAO execution: Based on our research, DAOs have not historically been good at: Designing Design by committee is sub-optimal; product design, creating brand assets, developing roadmaps, etc. are all convex decisions meaning decentralizing the process of making these decision can “easily lead to confusion and low-quality compromises.” [Vitalik](https://vitalik.eth.limo/general/2022/09/20/daos.html) However, the DAO should serve as an input into the creation of these things! Incubating DAOs have not generally been successfuly at incubation, although many DAOs have employed this strategy Incubation is an incredibly high touch process, to which DAOs are not usually well suited. Developing repeatable playbooks may also be overly prescriptive in a quickly evolving DAO landscape Bootstrapping is a variation of incubation that is usually handled by a Foundation given the challenges cited above Negotiating or licensing DAO partnerships have historically been challenged. DAO-to-DAO contracts, token swaps, and DAO licensing processes have all had limited success DAO negotiations can suffer from too many counterparties It is very difficult to enforce accountability for agreements made with DAOs Based on the above, the below functions may best decentralize by adding multiple external teams rather than dissolving the operations of any one team into the DAO: Core Development Metagovernance Strategy Business Development Marketing #### Or, we can cut up the existing pizza into 8 more slices, totalling 16 slices (Empower the community to execute elements of work that would otherwise be the core team’s responsibility) 🍕 🍕 🍕 🍕 🍕 It makes sense to decentralize this way when a function would benefit from being run by a group of third party, neutral, or loosely affiliated individuals Classic example: Security Councils, Developer Advisory Boards that are not affiliated with the Core Dev Program, etc. It makes sense to decentralize this way when the function is a core competency of DAOs Based on our research, DAOs can be good at: Sourcing (product ideas, feature requests, user feedback, BD inbound processing, etc.) Educating (new users, governance participants, and/or developers) Amplifying The DAO’s focus should be on amplifying established brand assets and core messaging rather than creating these things This may include running a community or DAO specific twitter account or hosting community events relating specifically to the DAO Scaling or parallelizing execution of non-core work Targeting new or underserved markets where the community has a strong presence (local events, translation services) Executing work core teams otherwise wouldn’t have the capacity to (numbaNERDs, grant recipient marketing, etc.) Providing important ancillary services that don’t require a high degree of core team oversight such as user support and governance facilitation The decentralization and development of alternative front-ends (More relevant to application layer DAOs) Maintaining autonomous operations Facilitating autonomous product maintenance Allocating capital to support sustainability Managing DAO communication platform(s) Running the voting process end-to-end from submission votes to on-chain execution of proposals Managing accounting, payroll, and payments infrastructure for DAO contributors Managing non-trademarked assets
← Back to Leaderboard   Review & Rate →