Governing Principles (Part II)
Three Things #175: June 22, 2025
Here are three more of the principles that are on my mind as relevant to the design of House of Stake, continuing last week’s list.
Thing #4: Transparency and Accountability
Governance isn’t one size fits all. It needs to be responsive to the situation, and every project needs governance that’s suited to its strengths, its needs, the community, etc. As a result there are very few universal principles in governance.
Among those rare universal principles are transparency and accountability, and they’re extraordinarily important principles in governance. If I had to recommend a general starting point for good governance, I’d recommend starting here. Transparency and accountability are obviously two distinct principles, but they’re closely related and go hand in hand.
Transparency matters because it’s one of the most important bases of legitimacy. It’s critical for stakeholders to be able to see how their governors are behaving. It’s the only way for stakeholders to know that their governors are indeed working on their behalf, rather than, say, lining their own pockets. It’s the best way to keep governors honest. If those in charge know that every decision will be scrutinized by the public, then it becomes much harder to hide corruption and other forms of bad behavior.
Of course transparency isn’t just about what decisions are made. It’s at least as much about how the sausage is made. If only the outcomes of votes and policies are visible, it’s still too easy for bad actors to hide bad behavior. The more of the governance process that’s transparent and publicly visible, the harder it is for politicians, who after all are just flawed human beings, to act in ways that aren’t in the public interest.
In my experience transparency is a bit harder in DAOs than in more formal, default world governance. This is because DAOs often don’t do a good job of defining “formal processes and procedures.” Decision making in DAOs quite often ends up happening behind closed doors, whether in person or, more often, in private chat rooms.
To be clear, policymakers do need private spaces to discuss issues where they can be completely honest with their colleagues. And when there are formally defined processes and procedures, it’s much easier to draw the line between what should and should not be transparent. It’s not possible for everything to be public, because politicians are people and people are entitled to privacy, but all formal processes and procedures should be transparent.
This is one of the downsides to too much transparency: the people making decisions end up not sharing their true thoughts or feelings for fear of being judged too harshly. For this reason, it’s essential for DAOs to carve out a “public sphere” where the actual, formal decision making process can play out in public in a transparent fashion, but also give decisionmakers privacy in other matters.
Accountability is equally important as a governance principle. The basic idea here is that actions have consequences and no one is above the law. There should be an accountability chain for every decision that gets made, and for every dollar that gets spent. When things go wrong, which they inevitably do, it’s absolutely essential that the community know who was responsible for the decision that caused things to go wrong.
It’s important to note that in a mature governance system this isn’t about finger-pointing or recrimination. It’s simply in the name of constant improvement. If we don’t know who’s at fault when things go wrong then we quite literally have no way to improve! By contrast, when there’s a clear person, or group of people, who can be held accountable for a bad decision or bad action, we can all learn from our collective mistakes, put in place safeguards to prevent the same mistake from happening again, and move on with our lives confident in the knowledge that we’re getting better every day. That’s what accountability is all about.
Yes, sometimes accountability involves real sanctions, but more often than not it simply involves the accountable party acknowledging what went wrong and committing to fix it. That’s all it takes. Keep in mind that the accountable party often isn’t even the person who made the mistake. It may be their manager, or their manager’s manager, or even the CEO or the Board. The point is that every decision and every action has a consequence, and there’s an accountable person in the organization who owns that decision.
Accountability is also just about order and structure, and about ensuring forward momentum. A great way to maintain this sort of accountability is to put in place OKRs and review them often. It’s important that everyone see that progress is being made towards goals. Without this sort of structure, it’s all too easy to forget what we’re doing and why, and who owns each task or goal. Every task and every goal needs an owner!
You’d be amazed what a difference good accountability mechanisms make over time, and you’d also be amazed how few organizations are able to put in place functional accountability mechanisms. Like the North Star, this is a great example of uncommon common sense that’s a superpower for teams that are actually able to get it right.
Like transparency, accountability is also a critical building block for legitimacy. If stakeholders can see that even a system’s governors are held accountable for their actions, it goes a long way towards increasing the overall perception of legitimacy in the system.
Thing #5: Keep It Simple
If I learned one lesson from my startup days, it’s to keep things as simple as possible for as long as possible.
There’s always temptation to build the perfect product before launching, and governance is no exception. After all, governance is complex, so can we really do it justice with an overly simple product? Aren’t there lots of different use cases, corner cases, etc. to account for? And we don’t want to be embarrassed by our first product launch.
Actually, to borrow a famous startup refrain, we do want to be embarrassed by our first product launch. If we aren’t embarrassed by the first product, it means we spent too much time on the product. This may seem like second nature to Silicon Valley product types, but the reason is a bit nuanced and it’s not so obvious why this is so important, so it’s worth explaining here.
It’s not because there’s anything wrong with having a nice product. It’s because, when you design, build, and launch a product for the first time, there are countless assumptions baked into your product. That’s literally the definition of design: a bundle of assumptions. You’re making assumptions about who your users are, you’re making assumptions about how they’ll use your product and on which devices and operating systems, you’re making assumptions about their priorities, how they understand the world, and how they want to interact with your product. It’s a long list. Even the best product team in the world can’t design and ship a perfect product the first time.
The basic thing to understand is that you’re going to get a lot of these things wrong, by definition, especially with the first product. Military generals say that no plan of attack survives first contact with the enemy. The same is true of a product. No product plan survives first contact with the market. The plan, and the design, have to evolve in response to these touchpoints. That’s why it’s critical that they happen so early in the product lifecycle, which is why it’s so important that the initial product be as simple as possible. The worst thing you can do is to noodle on something behind closed doors, without letting the world see it or use it—because you’re going to make many wrong assumptions, with no opportunity to correct them. The best thing you can do is iteratively improve your design based on user feedback, a process called design thinking.
In the case of House of Stake, this goes for the product itself (the frontend and the backend), but it also goes for the design of House of Stake and the DAO itself. We made the decision to leave many features out of the initial product release: for instance, we’re supporting only yes/no votes initially, and not more complex vote types (such as multiple choice). As another example, initially all proposals will require a simple approval from any member of the Screening Committee. Over time we may want to add thresholds, multiple signers, a quorum, etc., and also, rather than approving proposals for voting, the Screening Committee will instead be able to fast track proposals (and other proposals will require a supermajority). These are examples of simplifications we chose to speed up the launch of HoS v1.0.
I also think we should also keep the DAO as simple as possible to start. That’s one reason we have only 11 delegates, while some DAOs have hundreds. We’ll discuss proposals on the existing NEAR governance forum, rather than building and launching something new for this purpose. I’m proposing that the scope of HoS start small and expand only gradually over time, as we figure out the processes and build trust with the community. The very first proposals should probably be advisory proposals, rather than those that deploy funds, for this reason. And the last thing that HoS should tackle is trying to change the NEAR protocol itself, which is highly complex. I don’t mind if a lot of HoS governance, such as the working groups, remains informal for now. We should run lots of experiments now, and we can consider formalizing some of them later if they’re working well.
I think it’s essential that we adopt a product-first, keep it simple, MVP-first, experimentation mindset for HoS. The mandate to ship a simple product, then iterate and refine it, will be good for discipline and will demonstrate continual forward progress, and we’re much more likely to arrive at something good if we go about it this way rather than trying to get everything right out of the gate.
Thing #6: Community First (With Guardrails)
We have a difficult balancing act with House of Stake. On the one hand, the entire purpose of the project is to be community driven, community owned and community operated. HoS quite literally exists of, by, and for the NEAR community. It’s meant to decentralize the governance of the protocol away from the NEAR Foundation, to be a community run alternative governance and funding mechanism to the NEAR Foundation, and, over time, to replace more and more of the functions of the NEAR Foundation. For this reason, after HoS is up and running, NF will be quite hands off.
On the other hand, as I say all the time, decentralized, community-driven governance is messy, especially in the beginning. It’ll take HoS time to put in place reasonable operating principles and procedures, to recruit the right people, to build a track record and to build trust with the community. HoS is intended to take custody of not only the original NDC trust, which contains around three million NEAR, but potentially the entire contents of the treasury.near vault which has been accruing 0.5% of inflation for the past three years. This currently contains around 26 million NEAR. That’s a substantial amount of money, and it would be a mistake to immediately hand all of it to an unproven community governance initiative.
Why? One reason is that it would attract the wrong types of people, namely, those who smell money. There are a lot of valuable things that HoS can do before it even disburses a single NEAR token. This includes things like aligning on a North Star, work that’s proceeding right now; drawing up a budget about how HoS intends to deploy capital when the time comes; creating a roadmap, marshalling resources, improving docs, and contributing to marketing, to name but a few. Hopefully, the wrong types of people will be turned off by this sort of activity, so it acts as a sort of filter.
Another reason is focus. HoS can’t do everything, and opening a huge tap of funding will mean being pulled in many different directions by many different groups of stakeholders. That’s something that HoS needs to work towards. It needs to recruit the right people and build operational excellence, and the operational muscle needed to be able to do multiple things well at the same time. It makes sense to start with a very narrow scope, and to do only a few things well. Those first few things shouldn’t cost a ton of money.
This is another way of saying that we should be incremental in everything we do: start with the simplest possible prototype, get it working, and grow from there. With respect specifically to spending money, supporting the ecosystem, investing in projects, etc., the main capability that needs to be developed is accountability, as described above. How do we ensure that we’re not throwing good money at bad people and projects, and that all of the funds being deployed are having a real positive impact on NEAR? That’s a harder problem than it sounds. I know from experience that spending money well is actually quite hard.
So this is yet another balancing act that HoS needs to perfect: ensuring that everything is and remains community first, and yet ensuring that there are guardrails in place that can be gradually dismantled as HoS grows and matures. For now, those guardrails take the form of a. Only custodying the NDC trust assets to start, b. The Screening Committee and Security Council, the latter of which can veto any proposal that seems irresponsible or hasty, and c. Requiring that HoS prove itself and earn the community’s trust before it custodies more treasury assets. As always, I’m totally open to ideas about how we can do this differently, or better.