Governing Principles
Three Things #174: June 15, 2025
DAOs are obviously messy and difficult, and as I’ve said publicly a number of times, I remain quite skeptical about decentralized governance because so few DAOs are functional and so many end in disaster. One question I get asked quite often in the context of my work on House of Stake is, what did they get wrong that I think we’re doing better at HoS? In other words, what are the guiding principles behind the design of HoS?
I want to share a little bit of my personal governance and DAO design philosophy that’s guiding my own thinking about House of Stake. Here are a few of those principles, in no particular order. There are more, and I intend to write more on this topic in the coming days.
To state the obvious, I’m just one person involved in designing, building, and operating House of Stake. The idea was originally Illia’s vision, and that vision guided the complete proposal that Gauntlet produced before I even got involved. So this is just my personal philosophy, and the the personal principles that I bring to the table in my role as HoS Steward and liaison with the NEAR Foundation.
Thing #1: North Star ✨
If there’s one thing I’ve learned about governance over the years, it’s that it’s essential to figure out what you’re governing and how you intend to govern it before you actually try to do any governing. I’ve seen countless DAOs get lost in what I like to call “governance theater,” where they debate these basic, foundational questions in a process of endless bikeshedding, rather than getting any real work done or creating any real value (i.e., rather than actually governing anything).
In other words, there are certain basic principles that everyone needs to agree on before the actual work commences. You’d be shocked how many projects skip this most basic, most fundamental, most important step. Everyone gets excited about governance, people form working groups and start writing proposals and spending money, and then after a while, inevitably chaos reigns supreme and people start asking, why are we here in the first place? What’s this all about? Without having done this work upfront, it’s hard to answer these questions.
There’s no single, simple word for what this step entails. Partly, it’s agreeing on a shared set of values and a value system (the things we all believe), a mission (the animating force, what gets us out of bed in the morning and makes us want to work on this together), and a vision (a shared future definition of success). Sometimes this will involve things like a constitution (a document that outlines basic law, i.e., rules and procedures), a set of principles (like values, but less abstract and more actionable), or a code of conduct. I like to refer to this entire package collectively as the North Star.
Why does the North Star matter? Because it’s the thing that keeps everyone focused and rowing in the same direction, to borrow a favorite corporate metaphor. Most importantly, it’s the thing we use to make decisions, and it’s the thing we turn to when times get hard, which they inevitably will.
Lots of decisions in governance can be made using common sense, maybe most of them. But not all of them. There will inevitably be gray areas, and decisions which aren’t so obvious. There will be decisions that benefit one group of stakeholders more than another. The hardest are decisions where shared values come into conflict.
For instance, imagine a hypothetical organization with core values that include integrity and compassion, and imagine that the organization’s management has made the difficult decision to fire an employee. Integrity may dictate that it happen quickly (rather than pretending that the employee is still doing a good job), whereas compassion may dictate waiting (e.g., due to the employee’s personal circumstances). These sorts of impossible decisions happen all the time in business, in big ways and in small, and only a clear value system—not only what things we value, but also their priority and how they all fit together—and a clear mission (read: that which serves the mission is correct) allow these difficult decisions to be made confidently.
While I was active in Ethereum governance, I saw clearly that Ethereum lacked a North Star. While some of Ethereum’s shared values were clear, things like decentralization, privacy, and censorship resistance, these are quite abstract and it wasn’t at all clear how to translate these into a practical governance system. I even convened a congress to try to articulate a clearer North Star for Ethereum, but after an entire day of debating, the best we could come up with was, “keep adding blocks to the chain” (true story!).
As a core developer, this made it very difficult to decide on anything but the most routine technical decisions. It’s a big reason that contentious governance proposals keep coming up again and again, because Ethereum doesn’t have a clear North Star, or a constitution and operating principles and procedures that would allow bad ideas to be shut down once and for all. Ethereum doesn’t have a clear mission or vision, beyond something hand-wavy like “unstoppable applications” or a “decentralized world computer.” What do these mean in practice, and how do we use them to help make decision? To be useful, a mission and vision have to be clear, achievable, and immediately actionable.
The second reason the North Star is important, as mentioned, is that we turn to it when things get hard. When things are easy it’s easy to forget the North Star. Everyone is excited and energetic and happy to contribute. But there are always long, slow, hard periods of time when work feels like a slog. The North Star, and in particular the mission and vision, are what keep us going during dark, hard times. This is why it’s so important that they be truly inspirational, and that the people signing up to work on the project are truly inspired and energized by these ideas. In many ways, a well-crafted mission and vision are a superpower for an organization and a team that can articulate them clearly, and they’re the hallmark of nearly every successful project. They’re an excellent example of uncommon common sense.
The point is to not put the governance cart before the North Star horse. As a starting point for House of Stake, and in parallel to developing the platform itself, we’re actively discussing the North Star for both NEAR and for House of Stake (they are, by definition, aligned, since HoS is NEAR’s governance mechanism). I’m sure we’ll have progress to report on this front soon.
Thing #2: Progressive Decentralization 🌀
There are two schools of thought when it comes to decentralization. The first is that decentralization is black or white, like pregnancy: you can’t be partially pregnant, it’s all or nothing. This is the way that Bitcoiners and other decentralization maximalists feel about the subject. If a project isn’t maximally, meaningfully decentralized, then by the time it figures this out it’ll already be too late.
In some respects I agree with this way of thinking, and it makes a lot of sense for a project like Bitcoin that’s trying to be sovereign money that competes with fiat money. There’s a realistic chance that a state actor, or many state actors, might someday try to attack Bitcoin, so it needs maximal, sovereign-grade decentralization and censorship resistance. But I don’t think this makes sense for all projects. In particular, decentralization may work for base layer infrastructure that’s relatively straightforward, like Bitcoin, but it tends to be terrible for products because design by committee pretty much always results in worse outcomes than design by a small team of focused, motivated experts.
What about DAOs? They probably fall somewhere in between. They’re not building products, not exactly, but nor are they building infrastructure like Bitcoin. In the case of House of Stake, and more generally DAOs that govern layer one protocols like NEAR, the DAO needs to do many things. It needs to be in touch with the broader ecosystem, with the needs, desires, and preferences of an extraordinarily broad array of stakeholders. It needs to be able to make decisions effectively and efficiently on proposals covering a broad array of topics, some technical, some social. It needs to flexibly and dynamically adapt to the changing needs of the platform and community as these evolve over time.
Importantly, a DAO like House of Stake doesn’t spring into existence out of nowhere. There are probably a tiny number of successful projects that were governed by DAOs from the very beginning, but it’s incredibly rare because it’s incredibly difficult for the reasons I just mentioned: typically, DAOs can’t move fast enough or make good enough product decisions, especially at the earliest stages of a project when these decisions are the most critical. Instead, projects tend to be governed in a more centralized fashion in the beginning. Which brings us to the second, and I believe more useful, school of thought around decentralization. Rather than trying to achieve perfect decentralization out of the gate, it’s rather a goal to strive for over the long term.
In other words, decentralization is a journey, not a destination. In this respect it’s like other lofty values and goals: peace, prosperity, privacy, democracy. We may never quite get there, but it’s nevertheless a goal worth aspiring to.
I’ve been upfront about the parts of House of Stake that are centralized (for now). HoS was conceived of by Illia, NEAR’s cofounder and the CEO of the NEAR Foundation. The project is being executed by NF, and to date is entirely funded by NF. Substantial agency and authority has been placed in the hands of the initial set of delegates, none of whom is a NF employee, and the delegates are off to an excellent start gathering information and preparing to make decisions. However, there are a number of safeguards in place, such as a Screening Committee, and a Security Council, composed of folks from NF, NEAR One, and other aligned, trusted, professional actors like Gauntlet. The Screening Committee hand picked the initial set of delegates.
You may look at this arrangement, throw your hands in the air, shout bloody murder, claim that it’s centralized and that NF is corrupt, yadda yadda—goodness knows we get plenty of this sort of noise in the community. Or you could zoom out and try to see the broader perspective. While HoS is far from perfect, it’s a major, bold step in the direction of decentralization for NEAR Protocol, as its governance has historically always been fairly centralized. And it will become more decentralized over time.
This process will continue. The scope of HoS governance should probably be pretty narrow to start, since it’s a novel mechanism that needs to find its footing and build trust, both with the community and with the Foundation. The Security Council will make sure that the first few proposals are reasonable, are properly vetting funds recipients, aren’t committing too much funding too early, etc. This is very much by design. Like any process, as HoS matures, it’ll naturally gain trust, and Lindy, and its scope and remit will grow. The goal is for it to someday replace the Foundation entirely.
But we have to start with baby steps. And all of this is still an experiment. I think we’ve done a pretty good job with the initial setup. For instance, we’ve picked an excellent initial set of delegates, and we have an excellent set of partners. The HoS design is sound, and mature, and robust, strongly informed by mistakes that other DAOs have made. HoS has a great chance of success. But only time will tell how it plays out. Decentralized governance is never simple, and it’s always messy. If we got big things wrong, we’ll find out soon enough, then we’ll either fix the problems, or if necessary we’ll tear it down and try again—that’s another way in which we’re leaning into progressive decentralization. In the meantime we need to be patient, have faith, and give the project a chance.
Thing #3: Rough Consensus 🈴
Ethereum governance doesn’t use voting. This confuses a lot of people. Voting is a simple, familiar, effective mechanism. Why not use it to make decisions?
Well, let’s question those all-too-common assumptions. First of all, is voting simple? Let’s take a closer look. For one thing, there are many kinds of voting systems. The form of voting that most people are familiar with is called “First past the post,” which means that everyone votes only for their favorite candidate, and the one with the most votes wins. But there’s strong evidence that other systems, most notably ranked choice voting (RCV), is a better system in that it produces outcomes that are more in line with voter preference and selects for candidates with a broader base of support. So voting isn’t so simple after all.
Is it effective? Well, if you define effective as producing outcomes that are in line with voter preference, we just showed that the most common and familiar form of voting actually isn’t very effective. In fact, if you take the time to understand ideas like social choice theory, preference aggregation and Arrow’s Theorem, you’ll quickly realize that voting is anything but simple and that it’s actually not an especially effective way of aggregating the preferences of a group.
There are a lot of reasons. In addition to the challenges highlighted by Arrow’s Theorem, there’s also preference falsification and the unfortunate, frustrating fact that people tend to vote more for social reasons, and more to align with the social expectations of the people around them, than for rational reasons such as choosing the objectively “best” candidate. (If it isn’t already obvious, this is how we end up with leaders like Donald Trump.)
Those are among the reasons Ethereum chose not to use voting. So what’s the alternative? One powerful alternative is known as rough consensus. The holy scripture of rough consensus is RFC-7282 from the IETF, the Internet Engineering Task Force, an international body that’s responsible for producing and maintaining Internet protocols and global standards that Internet-connected devices around the world all comply with. Famous examples of IETF protocols are DNS and TCP/IP, which undergirds the whole Internet; POP3, IMAP, and SMTP, which govern email; and SSH and TLS/SSL, which are used to make secure connections to remote systems. In other words, rough consensus is literally the governance primitive that’s used to this date to govern the entire architecture of the modern Internet.
I encourage you to read the RFC to get a better understanding of how rough consensus works and why it was chosen as the basic governance primitive for IETF as well as Ethereum, but the rough idea is that it’s optimized for one thing: to ensure that all dissenting voices are heard. In particular, it’s not designed to make sure that everyone has a say in every decision, because, as it turns out, that’s not a very effective way to make at least some kinds of decisions.
It works like this: The person in charge of a particular working group (the chairperson) shares a proposal from someone in the group. The discussion begins, and anyone who has an objection to the proposal can air the objection to the group. Each objection is discussed and addressed, one by one, until none are left. As the discussion nears the end of the allotted time, the chair of the session will ask if anyone has any burning, “over my dead body” objections, and it’s in the chair’s discretion when to close discussion on the grounds that all legitimate objections have been raised. When and if there are no more objections, which in some cases will take several iterations of a proposal over several sessions, the proposal is considered to have passed and moves to the implementation phase.
Note that rough consensus isn’t foolproof. In particular, it’s not very good at handling proposals that are especially controversial. Without strong governance rules and procedures, participants can abuse the system through denial of service attacks: i.e., repeatedly bringing up a proposal, again and again, since there’s no hard “rejection” mechanism. I wrote recently about how some of these failure modes presented themselves in Ethereum governance.
To be clear, the initial design for House of Stake involves token locking, delegation, and, indeed, voting. Voting is a good place to start because it’s simple and familiar, and it probably does make sense for certain kinds of decisions, but maybe not for all of them. Time will tell. In particular, HoS won’t be making technical decisions about the NEAR protocol anytime soon, but eventually it might be, and rough consensus might be a better choice for that.
And perhaps some public goods funding could also flow through such a mechanism. I could see a hybrid mechanism working well: delegates propose and approve a budget via a vote, and then a portion of that budget could be allocated using rough consensus. This is just an idea. It’s up to the delegates and the other HoS stakeholders to adopt it, or not. My purpose here is to point out that there are alternatives to voting that can be quite effective, and that voting isn’t the only governance mechanism at our disposal.