MetricsDAO was a crypto analytics DAO that provided educational materials and connected crypto protocols with onchain data analysts. I joined in early 2022, brought in to help with governance, and stayed through the end of the organization.
Where We Started
When I first got to MetricsDAO, governance was having growing pains. The DAO already had a legal entity and a set of bylaws drafted with outside counsel during its incorporation. The problem was the governance structure those documents described was built around a token that hadn’t launched and had no firm timeline. In reality, decision making was being done through Discord messages and voting with emojis. It worked at the beginning, but was starting to show its weaknesses as the DAO grew and started to do more. There wasn’t much structure, and what existed wasn’t written down.
Minimal Viable Governance
The first thing I did when I started was work with other members to establish a constitution. This was a governing document that laid out decision making procedures before a token was released. The structure was built around contributors organized into pods, with elected pod leaders making up a Governing Council that served as the ratifying body. We wanted to keep the founders of the DAO as part of the structure, but realized that many of them had other responsibilities. To keep them involved, we also created a Genesis Council, made up of the organization’s founding members, who held an advisory role and retained their voting power. Seasons operated on fiscal quarters with two-week off-seasons built in for reflection and amendments.
Since the DAO was still young, the proposal process was built to be relatively lightweight to allow decisions to be made quickly. We used an optimistic voting system, meaning proposals would automatically pass unless enough people actively voted against them. It didn’t make sense to make everyone get involved with every decision, but it was also important that contributors could have a meaningful way to disagree with any direction the org was going. The constitution was ratified through an onchain Snapshot vote, starting a public record of governance for the DAO.
The Next Step
About a year in, with a better read on how the DAO was operating, I designed a new governance system in collaboration with other contributors and with review from outside legal counsel. It was encoded into a new set of bylaws. This new system was built around a longstanding goal from the DAO to become increasingly decentralized. However, we had seen other scenarios where decentralizing in a way that wasn’t well planned resulted in a functioning organization becoming too chaotic to operate efficiently. As new contributors join, shared context becomes more diffused, and existing initiatives need to spend resources integrating the new members. The core problem we needed to solve was: how do you expand who has a say in an organization without destabilizing the people doing the work?
The original constitution had contributors and governors as distinct classes, which made sense operationally but created friction in governance. More importantly, it meant decisions were all made by a small internal group. The analysts and broader community that MetricsDAO existed to serve had no formal voice in decisions that sometimes affected them.
The new system introduced two membership classes. Core Contributors were the people running day-to-day operations, while Stewards were a new class. Stewards were meant to be analysts and community members who weren’t doing internal work in the organization but had a stake in how the DAO operated. MetricsDAO existed as a bridge between analysts and other entities in the system. Core Contributors were the structural supports of the bridge. But the bridge exists for the traffic on it, the analysts themselves. The kinds of decisions each group should weigh in on aren’t always the same, and having two distinct classes allowed governance participation to be scoped to what was actually being decided.
The expansion of the Steward class happened through a relatively informal onboarding process. Prospective Stewards applied through a dedicated channel with a short pitch, and needed seven affirmative votes from existing members to be brought in. With the size of the group at the time it was enough to show trust in an individual without requiring everyone to be able to vouch for them. The expectation wasn’t to recruit entirely new members directly into the Steward role, it was to formalize the participation of people already adjacent to the community, analysts and regular contributors who had already demonstrated they cared. The Core Contributor group would keep operations stable while that expansion happened gradually.
Our proposal process also changed slightly. The original version used a binary Yes and No voting system. It was functional but it lacked the depth needed to signal opinions around complex proposals. We replaced the binary with four options:
- Yes
- No
- Abstain
- No with Veto
Abstaining needed to exist as the organization grew, as people would be exposed to more decision making that was outside their domain, and while we wanted to encourage participation, we didn’t want people to feel forced into taking a position they weren’t comfortable with. A No with Veto vote expressed a different signal than a regular No vote. A normal No vote was intended to mean that while the current iteration of the proposal wasn’t acceptable, the voter would be willing to consider a reworked version. A No with Veto vote signaled that someone thought an idea was fundamentally flawed, and that no revisions would be enough to change their mind. If a proposal gathered enough Vetos, spending more effort on iterating would be wasted.
The membership structure and voting design were both aimed at a longer-term goal that we referred to as governance ossification, governance structures robust enough to need less and less reinvention over time. Complex governance processes only make participation harder, and that becomes even worse when they’re always changing. The concept draws from writing on governance minimization in crypto, the argument that dependable systems tend to govern less over time which reduces potential attack surfaces and the overhead that governance itself creates. Applied to a small DAO, governance that needs to redesign itself every few months is fragile. The right moment to stabilize looks different for every organization, but designing toward it from the start is different from stumbling into constant reinvention.
Below, you can read the generalized framework developed for small organizations looking to decentralize, as well as the actual legal bylaws we implemented.