As protocols develop toward decentralization, governance typically evolves in three phases over time: a protostructure, a superstructure, and finally, a hyperstructure. Most protocols in this space start with the intention of becoming decentralized and gradually do so over time, moving from a concentrated group of stakeholders to an open community governance process.
At the start of any protocol, an individual or group creates an open rail for some purpose that will eventually be governed by a commons. This first stage is what I would call a protostructure.
A protostructure consists of a protocol in development with an implied direction and the eventual goal of having a group of decentralized stakeholders determine its future direction. The protocol’s intention and usage are strictly defined, and a roadmap of the elements required for launch is set.
To call a project in a protostructure phase "centralized" as an insult is ridiculous, as it isn’t even mature enough to be scrutinized against a set of criteria to consider it decentralized. In this stage, the team's actions are positive-sum, lifting all boats towards the same goal in a category. It is only competitive on narrative in this stage, but not on intention or outcomes.
We've entered the superstructure phase once a protocol is launched and teams can use it as a common rail for their projects.
A superstructure can be defined in several different ways. One standard definition comes from large ships, where the superstructure sits upon the ship’s hull and exists as a lightweight extension above the main deck. The core foundation of the ship remains the hull, but the superstructure houses crew members, additional operations, and more.
One additional definition of it in a web3 context comes from a16z’s differentiation of layer 1s (L1) and layer 2s (L2) that settle to layer 1s. In their view, the L1 is the foundation or hull, while the L2 is the superstructure where participants “live and work”; conducting business and settling down to a foundation.
The Marxist theoretical definition of the superstructure encapsulates all things outside the means and relations of production. In this case, the base holds the means and relations of production (the protocol’s operational foundation), and the superstructure becomes anything related to or influential to production, such as ideology (incentive governance and protocol directional influence).
This phase begins with a project's launch and tokenization, which becomes a means to govern the protocol.
Projects can now build permissionlessly on top of the protocol and use it for critical processes. The protocol's usage introduces new efficiencies or value creation, and creates new modes of operation that weren’t originally possible with other centralized solutions.
We’ve reached a point where the core team can’t change the protocol on a whim, so it becomes safer to build upon or begin to be involved in steering any changes. Governance moves from centralized to semi-centralized during the superstructure phase.
In the superstructure phase, the core protocol acts as the base or foundation of the superstructure. On top of that, we now have data coming from the usage of the protocol that will influence its direction. We've also now introduced systems indirectly related to the protocol’s core function, such as creating community engagement programs or encouraging projects to build on the protocol, which are all steered by governance. These incentive programs directly impact the base protocol, as the incentive typically comes in the form of the governing asset.
Many projects in web3 are currently in this phase with backstops for centralized teams to prevent hostile takeovers and builders being involved in core protocol governance. During this phase, there are still typically checks on ‘total decentralization,’ as an originating team may still have veto power or slight majority control over decisions to prevent attacks. Additionally, issues can quickly be remedied if the protocol halts for any reason or bug.
Actions taken by actors in this phase are typically mixed, as some might now wish to steer protocol governance to their ends rather than for the common good.
Finally, after the superstructure phase, we reach the hyperstructure phase once we've hit a point of total decentralization.
Originally coined by Zora founder Jacob Horne, a hyperstructure is defined by a protocol finally being in a completely permissionless, unstoppable state. The protocol is completely neutral, free from all foundational influence, and creates positive incentives for anyone using it. We’ve reached fully open governance.
Making changes to the protocol is effectively beyond the control of the original team and is completely based on the whims of asset holders. There is no backstop that anyone can use to halt the protocol, nor is there a body of trusted individuals that can override any decisions. If there is a contentious change to the protocol, participants must fork it and rebuild consensus around their own version of it.
One example of preventing attacks in a fully decentralized system comes from a recent governance initiative in the ENS ecosystem. To thwart potential governance attacks, large delegates of ENS recently coordinated to create a new delegate called veto.ens.eth. This new delegate enables a pool of existing delegates to easily veto proposals collectively (it can only vote no) if there is an attempted governance attack.
If the protocol breaks, it is up to the decentralized group of stakeholders to fix it. To reach this phase, a protocol needs to be completely battle-tested, as there aren’t any more training wheels preventing things from going awry.
The protocol must provide as much value as possible to stakeholders building on it, or it will completely fall apart. If it fails to do so, another protocol that may respond quicker to market demands will be able to subsume any meaningful activity completely.
Every action and decision pertaining to the protocol’s governance must be completely optimized both for the survival of the protocol and its victory against all other competition. In my opinion, this phase turns the protocol into a machine playing a zero-sum game.
If it’s a liquidity protocol, then it must amass all available liquidity.
If it's a decentralized name system, then it must be the dominating namespace.
If it’s a marketplace, then it must command all transactional activity.
If it seeks attention, it must command every last drop.
At this point, the protocol is self-serving and benefits everyone who builds on it.
