Cryptoeconomics for the Long-Term: Founder Lockups and Second ICOs — Part II

This article is the second part of my short series on long-term cryptoeconomic incentives. In the first part, I discussed how the current models of founder lockups and fundraising are broken, and how they can lead to misaligned incentives, pump and dumps, and consensual exit-scams, as well as how projects might attempt to fundraise post-ICO. In this article, I will focus on potential solutions to help solve these problems. Once again, thanks go to Michael Longoria and Kevin Xu for sharing their thoughts and experience here.

If you have not yet read the first part, I suggest you do so before reading this one. Part I can be found here.


A Better Way Forward

In Part I, I established multiple problems with current cryptoeconomic models and approaches to founder lockups and fundraising. Now, I will explore several potential solutions to these problems, how they would work, and how they will improve upon the status quo.

Revising Cryptoeconomic Models: Milestone-Based Lockups

This first revision is focused on improving and properly aligning founder incentives so that token-releases occur alongside positive company milestones. This can be done by enforcing a robust structure for token-releases based on project goals. Defining clear and executable goals is essential for any successful company, and helps to give meaning and direction for day-to-day work. While some goals can be flexible, ultimately, having a clear outline for success is a great way to ensure that everyone is aware of and agrees on the vision and direction of a project.

A Helpful Guide

This leads to a robust milestone-based token-unlock model, where a founder’s tokens become unlocked X amount of time after reaching important project milestones (could be immediately, 1 year, 4 years, etc…). Until reaching the milestone, the funds are held in a smart contract ruled by an oracle, or in some similar form of escrow. This forces the team to define precisely what success looks like for their project over time.

For example, consider two different (contrived) milestone-based founder release schedules, and how differently they portray the project’s priorities and goals:

  • 10% on testnet launch with the promised features, 10% on reaching 1000 unique users, 10% on team growth to 10 people, 10% on reaching 10000 users, 25% on mainnet launch, 15% on signing 5 institutional partners, 10% for launching a mobile app and adding additional features and functionalities, and the final 10% for establishing a full decentralized governance ecosystem. All tokens from hitting milestones will be unlocked 2 years after the milestone is hit.
  • 20% on 20000 Telegram users, 20% on Crypto influencer endorsement, 20% on mainnet launch, 20% on masternode implementation, and 20% on major exchange listing.

Obviously real unlock schedules may not be this pronounced, but as you can see from this simple example, it becomes far easier to understand a project’s development trajectory by examining how the founding team chooses to set their milestones. By participating in the project’s ecosystem, you also have more complete information regarding the project’s aspirations, and how each goal will impact the founder’s bottom-line. Rather than merely being a roadmap, this enables founders to put their money where their meaningful development is.

The final challenge is figuring out how to determine when these goals are met. Rather than being a simple lever that a founder could pull, in the ideal scenario, this would be decided through a community-driven oracle or some form of project governance. This brings us to the next improvement, which focuses on governance, as well as deciding key factors such as the founder token unlocks discussed here.

Revising Cryptoeconomic Models: Decentralized Chairman of the Board

Developing robust governance structures are essential for ensuring the long-term development of any project remains committed to its success. Because nearly every project’s tokens do not represent fractional ownership in the company, unlike the traditional startup model, the founders are traditionally less beholden to shareholder and equity-holder interests. In order to maintain a similar level of checks and balances as the traditional startup model, it is abundantly necessary to create models for decentralized governance of projects.

Ensuring Users Like This Guy Don’t Wield Absolute Power is Just as Important as Removing Centralized BoDs (OK, I also really just wanted to use this picture.)

Voting and governance has received extensive attention and scholarly writing by several leaders in the space. Vitalik takes a pessimistic view of on-chain governance as being both exploitable and plutocratic (models of one token = one vote give disproportionate power to the top holders of any currency), as does Vlad Zamfir in his article Against On-Chain Governance. Fred Ehrsam takes a more optimistic view and outlines many of the existing models in this excellent article as well.

The governance debate focuses on distributing power and influence, as well as limiting the power of malicious actors to influence voting-driven decision-making. I plan to write more extensively on this in the future, as I believe it is a fascinating discussion which is essential for the long-term success of companies and project communities. In this article, I will focus on one piece of my proposal, which is the idea of creating a decentralized Board of Directors.

Rather than taking the perspective of giving absolute power to the voting community, I believe that a hybrid model will prove far more fruitful. Imagine we create a governance system where the founders control less than half of the decision-making power, while the community controls over half. Now, a consensus must be reached among several founders alongside the community. In the event of the founders wishing to seize power over a decision, they will still lack the majority or supermajority necessary to achieve control. Regardless of how the exact governance model is structured, creating a decentralized version of a Board of Directors will be a helpful step toward ensuring these balances of power remain in place while allowing those who are more knowledgable or have more at stake to have their voices heard.

We can apply this same structure to milestone-based founder token unlocks, where a board can vote on whether a particular milestone has been reached. In addition to serving as an oracle for the smart-contract or escrow, this vote would also signal confidence and support for the project. It would be a signal suggesting that voters believe that funding the project and development team will increase the long-term value of their holdings by more than the value of tokens released. For additional reading on this approach to founder unlocks and governance, Matthew Di Ferrante wrote an excellent post on Responsible Token Sales in July 2017 which remains poignant today. Vitalik’s endorsement of the game-theoretic approach to the design outlined in the above article further adds weight to the importance of reconsidering our current model of token unlocking and governance.

By implementing this “DBoD” we can provide a way for blockchains to function as corporate entities while providing substantial voice and power to meaningful stakeholders without falling victim to “Rule of the Mob” problems.

Revising Cryptoeconomic Models: Equity and Dividend Tokens

The third and final improvement which follows from the conclusions reached above concerns the process of raising additional funds after burning through earlier funds. As discussed above, without the ability to offer additional tokens for sale, companies will need to seek alternative ways of fundraising. By introducing security tokens, promising projects can offer investors a share of their revenue and future successes while raising funds to continue work.

No article is complete without a Dilbert cartoon

These tokens can represent a piece of the value created by the network, a piece of the company’s revenues enabled by the network, or a form of tokenized equity in the company itself. Regardless of their precise implementation (and different models will make sense for different projects), the introduction of this type of token will open the door for numerous new developments, incentive structures, and governance models.

In theory, only companies with a genuinely promising future will succeed at raising funds in this manner — since the securities will provide a future share of revenues or represent ownership of the company or network, conceivably only projects whose future is bright enough to support their raise will be able to successfully sell their security tokens. This provides a further market-validation mechanism as projects begin to mature and achieve their long-term goals.

The eventuality of adding security token can and should be considered even in current token-design and regulatory considerations, as it will be far easier to implement if the necessary infrastructure is already in place. The addition of a security token will lead to a symbiotic two-token model, where incentives and additional layers of flexibility can be baked into the ecosystem. For an existing example of this approach, one need not look further than Sia’s two-token Siafund model. DASH’s community-driven development fund and masternode model is also worth consideration as a sustainable long-term approach. I believe this will become commonplace, and will serve as a much-needed source of supplemental income for companies still in the growth and development phases. By building with this possibility in mind, projects can bolster their token ecosystems, and leave doors open to future fundraising options.

Conclusion

There are several glaring problems with the current fundraising and founder lockup models, and as we begin thinking about building long-term ecosystems which are sustainable, it is vital that projects and investors begin to think about opportunities for improvement. The problems and solutions outlined here are focused around aligning incentives, fundraising, and protecting all parties from malicious outcomes. By considering these possibilities long in advance, we can prepare ourselves (and our projects) for these eventual outcomes long before they become a reality — and plan accordingly.