As protocol developers, we often overlook simple ways to accrue value, and instead bake complexity and friction into our designs in order to serve our token overlords. Technology users demand frictionless experiences, yet in order to stay consistent with jurisdictional laws and regulations, we build “mechanics” that prove beyond a doubt the token is a technology and not a security. To be fair, tokens are a wonderful tool for coordinating protocol actors. They are also a wonderful tool for sustainably funding open protocols.
In this blog, I attempt to untangle a simpler model for open protocol token economies. I do this by exploring the needs, stakeholders, objectives, and risks of open protocols.
Using attributes to define an open protocol, we can say it has: (1) a roadmap that is ostensibly set by a community of developers; (2) developers that contribute code, tools, and applications without asking for permission; and, (3) a leadership team that is accountable to community stakeholders.
Examples of open protocols are Linux, Python, MLS, Ethereum, and ENS. Technically, Linux and Python are open source software standards; however, the coordination requirements are similar to open protocols.
There are two fundamental needs of an open protocol:
A way for stakeholders to efficiently set the roadmap (i.e., governance framework)
Sustainable funding for completing the roadmap (e.g., a token, a business model, or charitable contributions)
In addition to core protocol developers, principal and agent protocol administrators, who have limited authorization from the community to perform authorized tasks, are necessary to fulfill the protocol roadmap.
Principals: Protocol oversight leadership that is empowered by the community to select agents and propose high level financial decisions
Agents: Protocol leaders that are empowered by their principals to make short-term and long-term operating decisions, including nurturing the developer core
Core developers: The primary developers employed to build core products
Optional
Principals, agents, and core developers are responsible for execution, while the community dictates roadmap and authorized task selection.
Above all, the protocol must deliver value for developers and users.
A protocol must also find sustainable funding for upgrades.
For blockchain protocols, the roadmap can be sustainably funded using a protocol-owned treasury that captures recurring revenue from real business models, such as spam fees, account abstraction bundler earnings, L2 rollup sequencer earnings, chain integration earnings, risk arbitrage, etc., as well as token investment earnings. This last bit makes obvious the need for the community to drive value to the protocol token. Thankfully, coordinating governance of the roadmap is crucial to protocol success, and tokens are a wonderful coordination tool.
The protocol must remain permissionless. Client applications will inevitably use the protocol to operate in a way that runs counter to various legal jurisdictions. In order to protect the protocol from unbearable regulatory burden, Miles Jennings at a16z provides a view on a protocol DAO structure that is capable of discarding protocol earnings sourced from client applications failing to follow their local laws. However, this would place a high operational burden on the DAO, and only time will tell if DAOs will achieve this level of sophistication.
In web3, a protocol that helps developers solve real user problems should implement a strong business model. The business model allows the protocol to capture recurring revenue for the treasury. This satisfies one of the basic needs of the open protocol, the ability to fund the roadmap, without having to rely on external donors. This is novel for open protocols.
A protocol that is effectively capturing value requires skilled leaders to ensure the protocol can deliver more than an $ETH of value in the future from one $ETH of value captured today. This growth is demanded by the community, and good money and effort should be paid by the community to attract the best leadership possible.
An efficient coordination mechanism is needed for the community to elect protocol leadership. We should expect leader election to be contentious--there is a lot at stake. Protocol tokens are an excellent coordination tool, and in this case should be used to (1) incentivize the community to participate, and (2) represent eligibility to participate.
A starting place for protocol leadership elections using tokens is staked delegation. Community members delegate their vote to a protocol leader on the ballet by staking in the voting contract. Elections can be continuous, as they are in most DAOs today, or a vote can be held every six months.
Blockchain allows for open protocols to implement a business model that can capture enough value to sustain itself into the future. This is a novel feature of open protocols, and demands novel legislation and regulatory oversight. Tokens are a wonderful coordination tool, but fear of regulation has caused us to perform design backflips to ensure these coordination tools are seen as technology instead of shares in a business. This is a losing product strategy. As open protocol designers we should stop designing mechanisms for the sake of the token, and focus on solving problems for developers and users.
Growing protocol value is only one mandate for leadership. The open protocol exists to serve the community. Its value capture should be reinvested into the shared mission of the ecosystem. Leadership must be the best representation of the ecosystem’s shared mission and values. After all, a shared and enduring mission and value-set is the sole reason for the open protocol’s existence.