Mapping the Actors: Builders, Voters, and Guardians

Transcript

SPEAKER_1: Alright, so last time we landed on this idea that structure is not the enemy of decentralization—the absence of structure is. And I've been sitting with that ever since, because it raises an obvious next question: okay, so what does the structure actually look like? Who are the people inside it? SPEAKER_2: That's exactly the right follow-up. And the answer most serious governance frameworks converge on is three distinct roles: Builders, Voters, and Guardians. Each one has a specific lane, and the whole system depends on keeping those lanes separate. SPEAKER_1: Walk me through each one. Starting with Builders—what do they actually do? SPEAKER_2: Builders are the proposers. Developers, core contributors, protocol engineers—they write the code, draft the improvement proposals, and define what changes are technically possible. Their job is creation and specification. What they should not have is unilateral authority to implement those changes. That's the critical boundary. SPEAKER_1: So they can propose but not execute unilaterally. And Voters? SPEAKER_2: Voters are typically token holders. They ratify or reject proposals. But here's where it gets complicated—political scientists have documented for decades that an informed electorate is essential to good democratic practice. Jennifer Hochschild's research at Harvard makes this explicit: citizens need to know who or what they are choosing and why. Token holders voting on a complex protocol upgrade face the same epistemic problem as any voter facing a technical ballot measure. SPEAKER_1: So the assumption that all token holders should have equal voting power on, say, a cryptographic parameter change—that's actually a flawed assumption? SPEAKER_2: Deeply flawed. Hochschild's work shows that as democracies expand the franchise, decision quality can decline because newer participants are less informed. The same dynamic hits DAOs hard. A whale who bought tokens last week has the same formal vote as a developer who's been building the protocol for three years. One-size-fits-all voting collapses the distinction between technical competence and financial stake. SPEAKER_1: That's counterintuitive for anyone who thinks more participation automatically means better governance. So how do you fix it without just handing power back to the developers? SPEAKER_2: That's where Guardians come in. Guardians are security councils, multisig committees, or elected oversight bodies. Their role is not to propose or to vote on routine matters—it's to veto actions that threaten protocol integrity. Think of them as the institutional actors Hochschild describes: structures that substitute for individual voter knowledge to keep the system functional. Madison made a similar argument—filter for the best candidates through institutional design, not by restricting who can vote. SPEAKER_1: So Builders propose, Voters ratify, Guardians protect. That's a clean separation of powers. But how does this actually map onto DAOs today? Is this common? SPEAKER_2: Honestly, it's the exception, not the rule. Most DAOs still conflate these roles. A core developer team that writes proposals also controls the multisig that executes them. That's a single group holding proposer, executor, and guardian power simultaneously—which is exactly the concentration Ostrom warned against in her design principles from last lecture. SPEAKER_1: So what mechanisms actually enforce the boundary between, say, a developer and treasury management? How does a Builder get blocked from just moving funds? SPEAKER_2: The cleanest mechanism is a timelocked multisig controlled by Guardians, not Builders. Any treasury action proposed by developers sits in a queue—say, 48 to 72 hours—during which Guardians can veto. Voters can also signal opposition. The developer never has a direct key to the treasury. The separation is architectural, not just procedural. SPEAKER_1: That's a structural answer. But what about the softer side—how do Voters actually get informed enough to vote well on technical proposals? SPEAKER_2: This is where Hochschild's research on low-information rationality becomes practically useful. Voters don't need to understand every line of code. They can use cue-taking—trusting signals from known experts, similar to how citizens take cues from trusted elites who activate existing predispositions rather than create new ones. A well-designed governance forum surfaces those cues. Delegate systems formalize it: token holders assign their vote to a knowledgeable delegate. SPEAKER_1: So delegation is essentially institutionalizing the cue-taking behavior that already happens informally. SPEAKER_2: Exactly. And John Stuart Mill made this argument in the 19th century—participation itself educates. New voters gain political knowledge through practice. DAOs that run frequent, low-stakes governance votes are building that civic muscle in their communities. The governance process is also the governance education. SPEAKER_1: That's a long game though. What about the immediate risk—role overlap causing a real failure? Is there a concrete example of where blurred roles actually broke something? SPEAKER_2: The 2016 DAO hack is the canonical case, and we touched on it last time. But the role-overlap failure is more recent: several DeFi protocols have seen treasury drains where the same team that proposed a parameter change also held execution keys. No Guardian layer existed to pause the action. The separation wasn't there, so there was no circuit breaker. SPEAKER_1: So for Aziz, or really anyone building a governance framework from scratch, what's the single most important structural decision they make first? SPEAKER_2: Define who cannot do what before defining who can do what. Prohibitions are more durable than permissions. If a Builder cannot touch the treasury, that constraint should be encoded architecturally—not just written in a document. Hochschild's framework reminds us that institutions substitute for individual knowledge. Build the institution so that even an uninformed voter, or an overreaching developer, cannot break the system alone. SPEAKER_1: So for our listener, the core takeaway from this lecture is really about differentiation—not just having roles, but keeping them genuinely separate? SPEAKER_2: Precisely. Functional governance requires differentiating Builders, Voters, and Guardians—and then designing the system so no single group can collapse all three functions into itself. That separation is not bureaucratic overhead. It is the mechanism that prevents any one actor from capturing the protocol. Without it, decentralization is a label, not a reality.