Core Tensions
Three Things #187: September 21, 2025
There is tension in all things: the yin and the yang, the masculine and the feminine, opposing forces pulling in opposite directions. Tension is healthy and natural. It’s a source of information. Just as there are healthy and unhealthy forms of conflict, there are also healthy and unhealthy forms of tension.
Here are a few points of tension I see in House of Stake at the moment, most of them quite healthy!
Thing #1: Centralization 🌐
Let’s start with the obvious. Progressive decentralization is one of my personal design principles and operating goals for House of Stake. In a nutshell, the governance of NEAR up to this point has been pretty centralized around the NEAR Foundation, a few other core “nodes”, and a small number of people. That’s totally normal and desirable early in the lifecycle of a product, project, or ecosystem. The goal is to decentralize power and decision making away from just this set of stakeholders. But doing so will be a gradual process. That’s also normal, natural, and healthy.
Centralization and decentralization each have advantages and disadvantages, and transitioning to a more decentralized power structure will involve tradeoffs. The obvious benefit to centralization is efficiency. Decisions can be made very quickly and easily in a centralized fashion. By contrast, deciding anything in a decentralized fashion takes forever and isn’t guaranteed to ever resolve in a desirable outcome, as anyone can attest who has polled the room on what to order for lunch.
Centralization is efficient. There’s a large and growing list of demands on the time and attention of the House of Stake core team. Every day, community members express their desire for us to get such and such a thing done, or to weigh in on such and such a thing. The easy path is to just do all of these things ourselves, in a centralized fashion. If that seems counterintuitive, what I mean is that the easy thing is to keep everyone happy. And the easy way to keep everyone happy is to do what they ask or expect of you: quickly, unilaterally, centrally.
But there are a few problems with this approach. The first is that it doesn’t scale. There are only a handful of people on the core team, we only have so many hours each week, and there’s a set of expectations and deliverables (on the part of the NEAR Foundation) that we have to prioritize, which doesn’t always line up with the community’s expectations. If, instead of focusing on these core deliverables, we do whatever the community asks us to do on any given day or week, we won’t ever make progress on the core deliverables. And if we fail to do that, the project will fail. (Incidentally, this is also why it’s so essential to agree and have buy in on the core deliverables. More on this later.)
The second problem is that it’s, well, centralized and uninteresting. It’s how companies and existing human institutions do things. We’re here to do something bigger, bolder, and much harder. Simply doing everything ourselves doesn’t move us any closer to our high level goals.
The third problem is that it doesn’t develop any capacity on the part of the community or ecosystem. Sure, we could grow the core team, hire more people, take on additional responsibility and funding, etc., but then we would end up reinventing the NEAR Foundation under a new name. Again, that’s not the point. It’s not what we’re here for. The point is for the community to step up and take on more and more of the work of governance, and all that it entails, including the operational burden.
So there’s tension pulling us in both directions: centralization, in the name of efficiency and expediency, keeping people happy, and just getting things done; and decentralization, in the name of capacity building and moving towards our real, long-term goals. It’s our job to skate between these two extremes. There’s plenty of things that we can, must, and will do in a centralized fashion, at least for now: hiring and product are two good examples (more on product below). And there are things that could be done in a decentralized way, but still probably make sense for us to do in a centralized way, such as managing the budget.
But a lot of things fall somewhere in between, including policy documents, e.g., Code of Conduct and Conflict of Interest, and a compensation plan. While, in general, I’d like for the community to step up and own the process of developing these, in general that hasn’t worked very well so far. We could deliver minimum viable policies by decree, and let the community iterate and improve upon them in the future. Indeed, we may have to do this in order to get the pieces in place in time to get things up and running, get proposals passing, etc.
I think that’s okay in the short term, as long as these documents are straightforward, reasonable, and can be amended later, and as long as we continue capacity building on the part of the DAO.
Thing #2: Product 📦
I’ve written a few times about the importance of product, and about how difficult it can be to sell infrastructure as a product, in the context of Ethereum, Spacemesh, and Urbit. NEAR faces this same challenge, and the good news is that the decision makers at NEAR are well aware of this. They’re aware of the importance of having one or more killer products, with product market fit, to the health and success of the broader ecosystem and of the economics of NEAR. NEAR Foundation and NEAR AI have recently adopted a more product-focused stance, with a greater focus on a smaller number of products.
This begs the question, what does this mean for House of Stake? What role, if any, does HoS have to play in this product strategy? And how can a product strategy help HoS avoid some of the more common failure modes of DAOs?
One of the most common failure modes I’ve seen in DAOs is something I like to call decentralization theater, where a DAO spends a great deal of time and money figuring out how to govern, while in practice never actually governing anything. There are multiple reasons for this, including bikeshedding (i.e., everyone has an opinion about the most trivial things, but no one weighs in on the really important things) and putting the governance cart before the product horse (i.e., building governance before there’s a mature product to govern). This forces DAOs to do governance for the sake of governance, which never ends well.
A product focus should be able to help us avoid at least the second cause of decentralization theater, i.e., having nothing to govern. So it’s reassuring to know that NEAR has such a product focus. And, indeed, NEAR has at least one product, NEAR Intents, that’s fairly mature and well on its way to finding product market fit. So I don’t think it’s too early to think about decentralized governance at NEAR.
Another relevant question is, how does HoS help with product?
The most obvious answer is to help build AI governance tooling, i.e., to focus on governance by AI. This is because HoS will itself be a user of this tooling, so it could iterate quickly and dogfood the tooling. I think AI governance tools will be increasingly important, and that they can be built in such a way that other projects can also use these tools. We’ve spoken to a number of teams that are experimenting with this tooling right now, but no one has yet built anything mature and standards haven’t yet emerged. It’s also extremely synergistic with the other AI infrastructure and tools that NEAR AI is building, and indeed AI governance tools can be built on NEAR AI infrastructure, offering a first customer and use case.
Another opportunity for HoS is to contribute to governing the AI tools that NEAR AI is developing and bringing to market: governance of AI. These tools include infrastructure for DCML (decentralized confidential machine learning), custom models, and sample applications including a chat bot built on this verifiable, confidential infrastructure. HoS could play a role in, say, prioritizing product features, or governing the data that’s used to train the model.
The tension here is that DAOs tend to be bad at product. This is because product is hard, and requires making hard decisions including saying no to most things (features, customers, opportunities, events, partnerships, etc.). A successful product strategy typically requires a single visionary and a small, aligned team that can ruthlessly prioritize and say no. In other words, it requires a highly centralized approach. Product typically cannot be built by committee, which is why a DAO is typically bad at product. A DAO is definitionally the opposite of a single visionary.
So, while it seems at first glance like HoS has a lot to contribute to NEAR and NEAR AI’s product strategy, I’m struggling to see exactly what that role is. And while a product-focused strategy might be a good way for HoS to avoid governance theater, by focusing on concrete deliverables, it’s unclear that those concrete deliverables should actually be product related. It probably makes more sense for HoS to focus on the things it was originally intended to do: namely, tokenomics/cryptoeconomic governance, and, to some extent, technical governance, in addition to broader goals such as legitimacy and ecosystem health.
This doesn’t mean that HoS won’t still rely on AI governance tooling. In fact, it may be the case that the role of HoS is, in fact, to be the customer of such tooling, designed and built by our team at NEAR Foundation or another ecosystem partner. And HoS probably has a role to play in setting standards. We’re still figuring this out, and as always we’re open to suggestions.
Thing #3: Speed 💨
We made the decision to soft launch House of Stake last month, despite not being completely ready. In the event, mistakes were made, and the soft launch wasn’t a complete success. We pushed Agora, the team building the House of Stake governance site, outside their comfort zone a little bit and asked them to launch before they were 100% ready.
But I stand by this decision. When launching any product, it’s essential to keep things as barebones as possible and to get a minimally viable version of your product into your customers’ hands as soon as possible. Everything before this moment is pure speculation. Once your product is live, even in alpha form, you can stop speculating about how users are going to use it, and instead observe what they actually do. We learned a lot from the initial alpha launch. We identified and fixed a number of bugs and other issues.
This launch is emblematic of one of the challenges, and core tensions, in House of Stake—and, for that matter, in any product team. HoS is a DAO, and a DAO may not feel like a product, but I prefer to think of HoS as a product (which is why we have a kanban). Every product team struggles with the question of when to launch and of how much to attempt to do, and to perfect, before launch. I wrote about this tension in the lead up to the Spacemesh launch in 2023.
To be clear, there are still a lot of missing parts in HoS. We have drafts of some of the core policy documents and charters that we need, but none have been finalized or ratified yet, and they’re in various states of completion and maturity. We don’t even have a “proposal charter” that outlines the process by which proposals get passed, which is of course a hard requirement before we can begin passing proposals. We haven’t finalized the scope or mandate for HoS, we haven’t figured out our budget or how to spend the treasury, etc. We’re close to having these things, but we’re not quite there yet.
One option is to button up all of these things before attempting to launch HoS. That might seem like the conscientious, responsible thing to do. But there’s an alternative: to attempt to get the thing off the ground in the incomplete, imperfect, jury-rigged, scotch-tape-and-rubber-bands state that it’s in today. That’s risky, but it still feels like the right decision, for the same reason that doing an early alpha launch was the right decision. We shouldn’t be noodling on this thing ourselves, in private. We should be building it together, in public. We need a minimum viable set of infrastructure—including the smart contracts, the frontend, and some very basic charter documents—and we’ll figure out the rest together.
At the same time, we don’t want to overly rush things. It’s a balancing act. We rushed things a little bit too much with the alpha launch, which is why we’re now taking our time to get the beta launch right. I wrote a few years ago about my writing style, which is very similar, and which works very well for me. First, get a rough draft out. Don’t worry at all about things like grammar, diction, or even how good the writing is. The key thing is to just get it all down in raw form. Then, iterate from there. The important thing is to get the first draft out. Then you can take your time to improve things iteratively. I think we should do the same thing with HoS. (Note: one important exception here is security. There’s no cutting corners when it comes to security, even in the first release. That’s why we’re working with the best auditors in the world, we’ve done multiple audits of code and process, etc.)
There’s been some criticism that things aren’t moving as quickly as people would like. That’s perfectly okay, and this criticism doesn’t bother me. There’s some truth there, and some things should and could be happening faster than they have been. As a team, we’re working across vast distances and timezones that are very far apart, which isn’t helping. The team is still new, but we’re starting to gel and operate like a functional team. Things are already beginning to speed up, as we build trust as a team, get to know one another, and figure out how to communicate and how to work together. This process will continue, and things will continue to speed up.
In general, though, these things take time. Good things take time! Rome wasn’t built in a day. We’ll get early, alpha releases of things out as soon as possible, when possible, and be as iterative as possible. But we’re attempting to do something complex and difficult, and high stakes, and it won’t happen overnight. Be patient, and have faith. We’re moving in the right direction, and we’re off to a good start.