The DAO conversation almost exclusively revolves around governance. The entire space effectively speaks of them equivocally. One cause for this is that pooling money pre-product (community-first) makes the collective management of those funds an immediate need. Then after people realize the overhead of collective decision-making, they try to implement delegation; this further entrenches the conversation on the topic of governance and nothing else.
Centering DAOs on governance is a mistake and a recipe for failure. The problems caused by starting in this way are evident once you realize that governance and automation are inversely correlated. We must decide (governance) because we have yet to set it through predefined rules (automation). Unscoped governance is a poison to DAO effectiveness and a force multiplier of coordination.
The strength of DAOs is coordination, not governance. DAOs can be decentralized economic game engines and create order from chaos if appropriately structured. They are the gamification of companies. We can advance this idea by building with coordination at the center and only adding governance as needed. This kind of DAO game design is an application of the Protocol-first DAO Strategy and what the Polygon DoD team is pressing into as we try to bring a greater variety of organizations on-chain.
To make a case for these claims, I'll posit four principles, then demonstrate the consequences of applying those principles to everyday DAO activities. They're as follows.
DAOs must structure as multiplayer games to achieve maximum coordination effectiveness. They must source resources from anyone and be able to provide those resources to anyone. Platform business models are the only structure that supports this. Pipeline businesses rely on trade secrets, IP, or private resources to function and are incompatible with decentralization. Explicitly state the sides of the game and understand what will attract each player to come.
Incentivizing and rewarding activity is a significant malpractice in DAOs. Paying people for participation or merely voting misses the point. We need good decisions, not just decisions. Decisions and activities that produce value can be structured to distribute shared rewards to the driving participants. Web3 is uniquely suited to this pattern of shared ownership, and neglecting it negates a core value proposition of DAOs.
DAO coordination games should incentivize their continued playing and not require any player's perpetual involvement. Organizational autonomy means building self-perpetuation and self-propagation into the game. On-chain organizations are a form of digital life. They should sustain their own life and encourage beneficial replication. We can pursue this self-preservation by creating graduated contribution rewards and encouraging on-protocol game replication.
Remember, we are turning coordination up by turning governance down. One way to do this is through parametrization. This parameterization can be as simple as proposal templates or as strict as contract parameters, changeable through governance. We can't eliminate governance, but we should pursue a balance that harnesses the advantages of automation and programmability.
These principles are neither exhaustive nor absolute, but they're enough to test our thesis. Let's now apply them to everyday DAO activities and see what happens.
Education is a core component of any DAO initiative. How DAOs typically go about this critical activity? Founding members either drive the whole thing or spend the treasury paying contributors. This approach is neither decentralized nor sustainable. Consider the following education game.
In this model, you can see students, a teacher, and a protocol, mediating payments and distributing token rewards. The first order of business is to create the multiplayer setup. We do this by allowing teachers to charge a fee. We no longer have to provide or pay for those services by doing so.
Next, we take a fee at the DAO treasury and underlying protocol level to address sustainability and issue token rewards in exchange for successful engagements. This pattern follows the second principle of rewarding outcomes, not activity. Teachers get paid when the DAO makes money and distributes tokens only when participants create value. These tokens could be transferable (currency) or nontransferable (reputation).
We can incentivize the game's ongoing play in two ways. We can allow students to apply to be teachers after reaching a reputation threshold and by diluting players who stop playing. We could even visualize this with a dynamic NFT showing each player ranking on a curve scoped to each "university" instance.
We have reduced and focused governance without eliminating it by starting with the game. We have laid a foundation of sustainability and coordination upon which we can build a community. There's a treasury, but spending it can be tightly constrained, such as only using it to purchase relevant services and tools for contributors. Let's look at another example.
Investment DAOs are a hugely popular use case for DAOs. They are, in fact, the first use case. How do we determine the success of a grant DAO? Often the touted metric is the number of funds distributed. A more helpful success metric could be the ROI derived from the appreciation of the underlying cap table. How could this be made into a game?
We turn this into a game by creating a prediction market from our fund. Players get presented with early-stage startups and must predict how each project will perform over a specified timeframe, and projects with majority support get funded.
In a standard investment DAO setup, there is no incentive for voting against a proposal with majority support. In this scenario, you are because the game will reward you with greater governance power for voting against funded projects that don't perform.
Notice as well that non-voters get diluted in this setup. This feature targets free riders and coheres with our self-perpetuation principle. We have turned our investment DAO into a game where even the cynics are incentivized to play.
Lastly, consider how combining different game elements can make even more complex interactions. You can mix and match components to design or redesign compartmentally. We can onboard new members through a cohort-based auction, then upskill participants through the education game before finishing the season with the investment game to determine who takes the remaining pot.
There also doesn't need to be one single game of the DAO. You can have many games and games within games. What we want is an ecosystem of operational primitives. There doesn't have to be permission around adopting these games, either. One guild could operate on one game mechanic while another employs another.
All these are examples and ways of thinking, not blueprints. My ultimate goal is to stimulate the reader's imagination with the types of things we could build if we do so with coordination in the center. Does any of this sound like the typical DAO conversation? I don't believe it does, but it can.
"Most people in DAOs don't even know what game they are playing.." - Pet3rpan
The DAO conversation needs to change if we care about community, sustainability, or the frequent exploitation of enthusiastic contributors. It's not just about improving what we're doing now; it's about unlocking new possibilities.
By centering on coordination, we re-enter the token engineering domain and gain its modeling and simulation methods. We reap the rewards of compounding returns by designing testable and reusable game elements. We gain a new level of operational visibility because we can create real-time dashboards on Dune Analytics showing the state of organizations.
This approach isn’t utterly novel, but it's far from normative. Let's change that. The Polygon DoD team is working to connect ecosystem builders to create a playbook for the next generation of decentralized organizations. In it, we’ll examine how to utilize and configure current DAO organizational legos to achieve the mechanics described above. Reach out! Let's build the future together!
Big shout out to CuriousRabbit, who helped me proofread this post and design and refine the machinations models. Another big shout out to the Machinations team for creating such an incredible tool and modeling language. We’re barely scratching the surface of what's possible and what's coming.