Governance tokens are an exciting innovation for the open source community. In the past, open source projects relied solely on self-funding, donations, or corporate sponsorships. But with governance tokens, communities can give economic and governance rights to users and contributors in the form of tokens, turning them into direct stakeholders of the network. This not only defends against identical forks but also provides sustainable economics to maintain and expand the project.

This scheme works particularly well for projects with a clear and profitable definition of "network effect." In Proof of Stake protocols, for example, capital dedication in the form of staking and node formation contributes directly to network security. For Dapps, which are the main source of usage and revenue for base layer ecosystems, hosting protocols that offer greater security are preferred. Accumulated security cannot be easily emulated, and it makes sense to provide both governance and economic rights to token holders in this context, discouraging them from moving to identical forks. The same logic could be applied to liquidity. While anyone could copy Uniswap's open source swap contracts, it is difficult to attract its level of liquidity, a crucial element to an AMM's user experience.

The limitation of fungible governance token dynamics

However, the same logic may not be applicable for the long tail of open source projects. Projects with a narrower target audience or focusing on specific verticals of tooling, developer infrastructure, etc. struggle to define a profitable network effect. Existing token dynamics could be detrimental to these projects since they may not be able to generate enough excitement or seamlessly integrate tokens into their user experience. As there are limited alternatives, these projects either have to depend on ecosystem/Gitcoin grants, or goodwill of developers for maintenance and expansion. Special purpose AMMs and NFT marketplaces pitching for support in the Gitcoin Grants program, which is intended for building and sustaining digital public goods, illustrate such difficulties.

This is a problem since the compatibility with the current fungible token dynamics does not necessarily reflect the holistic value of the project. There are open source projects which have the potential to become valuable building blocks, but are not pursued due to the aforementioned incompatibility. Web3 is still in the nascent stage of finding sectors where blockchain enabled benefits provide competitive advantage to Web2 counterparts, and open source enabled interoperability and composability are undoubtedly the best ingredients as they bring exponential progress. To enhance this flywheel momentum, we need more diverse options for the long tail of open source projects to create sustainable economics and governance.

To address this issue, I propose a potential alternative: a Soulbound Token based decentralized governance structure with governance and economic rights expressed as variables. In the following sections, I will provide a general overview of a preliminary model that, with sufficient discourse, could open up a broader design space for open source builders.

Potential alternative: a Soulbound Token based decentralized governance

The concept of integrating governance and economic rights as variables within SBTs can offer an alternative approach to decentralized governance. Economic and governance rights could be represented as separate variables containing numeric values, enabling limitless customizability according to how the community defines the supply and distribution policies.

Governance and economic rights, or ‘Clout’ can be expressed as follows (any better term than "Clout" is always welcome - suggestions included ‘Merits’, or plain old ‘Rights’):

Clout Specs

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

• A variable within an extension of Soulbound tokens (i.e. ERC-5192 or equivalent) to express governance or economic rights

• Within a user’s SBT representing the membership of a community, Governance Clout and Economic Clout shall be separate variables, each showing a numeric value of the accumulated rights

• Clout shall be flexible, capable of having floors and ceilings, being incremented and decremented (i.e. earned or lost), delegated and undelegated, etc. according to how it is set forth by the community

• Many experiments in the DAO governance space (Linda’s excellent post), such as governance councils, Lido’s veto rights for stETH holders (i.e. economic Clout), etc. may all be smoothly integrated into Clout based governance

• Weight of Clout may be determined by the common pro-rata basis, or any other effective schemes

• Ground rules that require general consensus from the community, such as, how to determine Clout distribution policies, etc. should be stipulated via strong community consensus (i.e. Community Constitution)

As shown in the specs, the significant advantage of this model is that the project does not need to implement a perfect policy set from day one. As long as there are appropriate prerequisites for constitutional amendments to genuinely reflect the community's sentiment, the project team and community can experiment with policies to optimize incentive and decision-making schemes for their overall benefit. With this flexibility, projects will be able to leverage the takeaways from the exciting experiments on DAO governance occurring in the space to build an effective customized governance model.

Policies regarding SBT supply caps and Clout distribution should start from the consensus on the ideal state of the project’s decentralization. For now, I believe that the holders of these SBTs will be categorized into contributors (e.g. in the form of capital, dev, community building, etc.) and clients. Therefore, determining the optimal composition of these two types will be the main consideration for the policy sets. For instance, if a team wants to start with a manageable group of prospective contributors, they could initially set the total supply of contributor SBTs at a 1 to x ratio of their personnel count. As more contributors join the community, peer-review will be more actively available, and the project could suggest a governance proposal to extend the number of contributor SBTs when the community is deemed ready. If necessary, client SBTs could also have a similar cap to ensure that the product scales at a manageable pace, although I believe this will be less relevant considering the common difficulty of acquiring clients.

With the general policy on SBT supply caps ready, projects could figure out the corresponding Clout distribution mechanisms to effectively onboard the different types of community participants. Clout distribution will be directly relevant to the dilution of the members’ governance and economic rights, so the process should involve careful consideration of the direction and pace of decentralization. This will greatly vary according to project characteristics, and I will try to provide more color below.

Let’s see how the Clout model could work with a simplified example.

Illustrative example

A project team has developed a smart contract that charges a 1% fee for its great functionality. They have set both their Governance Clout, Economic Clout variables as 100 since they believe that such a level of granularity is sufficient for their project. Although the overall Clout weight is capped at 20%, the team is exempted from this ceiling in the early stages to ensure quick execution. For decentralization, such an exception persists until team Clout is diluted down to sub-20%, and from then on the team could also earn and lose Clout under the 20% ceiling. The project stipulated that the proceeds will be distributed to all relevant stakeholders at the end of every two epochs.

To incentivize its client base, the project sets a high Clout distribution policy for early users, providing 10% of the ETH amount as Economic Clout, with Governance Clout designated as 50% of Economic Clout for balanced representation. Client’s Governance Clout, Economic Clout variables are capped at 7 and 15, respectively, to prevent disproportionate distributions. Thanks to the team's hard work, the project was able to attract its first client in the 1st epoch. Let’s also assume that the client has enough conviction to transact 100 ETH every epoch through the project's smart contract.

Upon hearing the exciting news, our good friend Alice becomes interested in the project and seeks ways to contribute by reviewing the codebase. While reviewing, she identifies an opportunity to significantly optimize gas usage and proposes the change via Github. The team agrees to merge her proposition, and the community policy grants her 5 Governance Clout and Economic Clout for her contribution. At the end of the 2nd epoch, the accrued balance is distributed according to the pro-rata economic rights of the community members.

Fast forward, and it is the 11th epoch. The project was able to acquire 2 more clients with its Clout incentive model, and those two clients have also transacted enough volume to reach maximum Clout level. Alice is a major contributor to the project with many valuable commits, and she onboarded a fellow 10x engineer Bob, who also became a crucial part of the community. In this situation, Figure 5 shows the pro-rata weights of each stakeholder on a governance agenda. Although the team still has more than 60% of voting power, their weight has been significantly diluted and it will be important to incorporate the stakeholders’ viewpoints since further dilution will gradually lead to the loss of majority.

There are countless ways to expand this basic model to further enhance sustainability. Projects could introduce additional policies on incrementation/decrementation according to the types of activity they want to promote. For instance, client Clout could decrement or diminish once they cease being a revenue source for the project. To prevent Clients being misrepresented due to their relatively low Governance Clout ceiling, the project could also introduce veto rights for Economic Clout holders on matters directly relevant to revenue distribution rights (i.e. Lido’s dual governance). Moreover, to prevent Alice and Bob from becoming an idle free-rider, projects could stipulate that the Economic Clout, Governance Clout decrement after a certain period of non-contribution.

Major benefits

I would like to highlight three major benefits of this model, apart from its flexibility illustrated above. With SBT based governance, projects can form 1) sustainable runway structures while achieving progressive decentralization, 2) effective mechanisms to bootstrap and protect network effects, and also 3) integrate seamless user experience to their product.

For sustainable project runway and progressive decentralization

This model offers a more sustainable approach to obtain project runway and progressive decentralization without the controversies associated with the prevalent governance token schemes. With the existing solution, decentralization is achieved through token emissions, where the ‘insiders’ retain dominance in governance for faster execution in the initial stages. As time passes, insiders sell their stakes either to secure project runway or take profit while more tokens are distributed to the community, gradually leading to decentralization. This has aroused negative community sentiment because such selling activities are often perceived as a bearish sign by the community, despite the fact that it is inevitable to some extent.

The proposed model provides a smoother solution, allowing early realization of profits while offering a range of levers such as Clout floors/ceilings, incrementation/decrementation, etc. to facilitate progressive decentralization. Accumulated profits could be more directly distributed to stakeholders without the necessity to use or reserve those proceeds to accrue value to a fungible token. This goes well with the general pace of project development since expenses will be limited in the early stages of the project, and even a relatively small profit will be a valuable source of extending runway.

Also, by granularly defining the distribution policy of each Clout, projects could optimize the direction and pace of diluting their governance. In the above sample, for instance, the project could heighten the distribution and ceiling amount for users/clients if further reflecting their opinion in governance is healthy for the network. Moreover, the community could enhance the Clout ceiling of the team (e.g. 20% > 30%) if it believes that the team should have elongated leadership in project execution. Although this model mitigates the necessity of exclusive fundraising, early investors could be rewarded with augmented economic rights with reasonable governance Clout ceilings to reflect their contribution, and etc.

For bootstrapping and protecting network effects

As shown in the sample, projects can still bake in bootstrapping mechanisms that reward early users to kickstart product awareness and revenue flow. Providing enhanced economic and governance Clout for early adoption not only acts as a practical discount on product fees but also grants early clients with more exposure to the upside of the product. When the project acquires more clients/users, early comers will have accumulated more rights to the proceeds and governance of the network. Such anticipation will be a powerful tool to retain clients/users, ultimately serving as a moat for the project’s network effect.

For seamless user experience

Projects are no longer obliged to create artificial ramps to reduce token velocity, which is the case with existing fungible token dynamics commonly entailing token gated access to core services or benefits. When you think of the diversity of frameworks and libraries that make Web2 development so much easier, it is difficult to imagine all Web3 building blocks with such token dynamics.

Auto-compounding programs are a good example. The feature is a valuable addition to most protocols with staking rewards, but requires extensive maintenance and security checks since it involves delicate permissions from the users. Although it has an intuitive fee based business model, it is difficult to structure fungible token dynamics since the margins are not sufficient to create enough hype. Also, creating token gated access for users and integrators directly degrades user/developer experience. With this model, these teams could focus on providing the most optimized solution for their target user-base along with healthy bootstrapping schemes and runway, without sacrificing user/developer experience.

Conclusion

As this is effectively the first draft, there are obviously many remaining issues. For one, we have to tread carefully with SEC’s regulations. Although this model intends to circumvent the Howey Test by making these rights non-transferrable via SBTs (referring to SEC’s framework), legal counsel and further fine tuning are certainly necessary to avoid being categorized as a security. Also, the specific implementation of ERC-5192 should be carefully considered to incorporate the flexible composition of Economic Clout and Governance Clout. It is great to see similar efforts in progress, such as, EIP-4974 with its Ratings, since they highlight the limitations of the existing ‘asset-centric’ model. But, there is no directly applicable implementation yet, which I am willing to pursue once this model is more crystalized.

The current proposition is mostly hypothetical and hopefully, I will be able to write separate series on the different aspects of this model by gathering case studies of projects that have implemented similar logic to certain verticals. To further develop this model, or even modify it completely, I would love to gather feedback from those who have considered ideating or implementing an alternative to fungible governance tokens. With enough traction, I am thinking of organizing working groups to create templates for major organization/service types to mitigate the model’s complexity.

It might take some time for a viable alternative to be thoroughly formulated, but there certainly should be more options for the long tail of open source projects to apply sustainable governance and economic dynamics. Please feel free to DM me (Twitter - @0xwhykay) with any questions or feedback!

Thank you Ryan & PiSofa (@CyberConnect), Flam & Heimdall (@0xCitadel), Griffin & Michael (@Phi_labs - Archway), and Nathan & Subin (@Hashed) for reviewing and providing incredible feedback on this post!