Getting to Sufficient Decentralization: Progressive Decentralization, Airdrops, and Transfer-Restricted Tokens
Sufficient decentralization can be a great way to launch a token that is not a security, but it doesn’t happen overnight. The journey to sufficient decentralization is an incremental process, not a flip of the switch.
That journey is commonly referred to as “progressive decentralization.” Jesse Walden wrote an excellent playbook on progressive decentralization for crypto companies that lays out the process in more detail. In this post, I will give a high-level overview of Jesse’s work and cover the pros & cons of this approach, as well as cover other options for decentralization.
The progressive decentralization playbook
How can a project evolve from a fully centralized core team with an idea–to a sufficiently decentralized successful product and organization in the market?
The playbook lists three sequential steps:
- Find product-market fit (Early Stage)
- Grow community participation (Growth Stage)
- Achieve sufficient decentralization (Later Stage)
Once step 3 is achieved, the playbook advises that the community can launch a freely tradable token without risk of that token being deemed a security (see here for our post on sufficient decentralization and tokens from a regulatory lens). We also suggest below that a project can launch a token with transfer restrictions during steps 1 (Early Stage) or more likely step 2 (Growth Stage), and then remove those transfer restrictions during step 3 (Later Stage — Sufficient Decentralization).
The Catch-22 of launching a token using the progressive decentralization playbook
Decentralizing progressively has a lot of advantages. It allows the centralized team to get product feedback quickly and to act on it unilaterally, while allowing the community’s role and responsibility to grow incrementally until they are able to take on full control.
Unfortunately, progressive decentralization can create a Catch-22 when it comes to tokens. Because the product-market fit stage comes before a project is able to widely launch a freely tradable token (i.e. more than simply token rights, or subject to lock-ups or transfer restrictions).[1] As a result, it can be difficult for the token — an ostensibly core part of the product — to be included in the product-market fit discovery process. The result is often to launch a token later on, after the community has taken control, and after the product is mostly formed. This approach runs the risk of the token not being as core to the product as it could, or should have been.
On the flip side, launching a token that can be bought and sold on an exchange too early in the project’s life cycle can also pose an issue. Freely tradable tokens can obfuscate whether their truly is product-market fit, or whether individuals are only engaging and using the product as a way to earn tokens that they can immediately sell (ideally for a profit).
Token distribution — current challenges with airdrops
Under a progressive decentralization playbook, once product-market fit is found, and once the team decentralizes, it is common for a token to be launched with some portion of the token allocation distributed to prior users, via airdrops.
Airdrops are well intentioned and customary. This distribution approach also has the significant advantage of arguably not being the issuance of a security (i.e. investment contract), although there are other factors to consider as well (see here).
The goal of airdrops is to reward early users of your platform. Typically, power users who participate during the Early Stage and Growth Stage are rewarded with airdropped tokens after the token launches in the “Later Stage” (i.e. once sufficient decentralization is reached).
But having users work now in the hopes of tokens later is imperfect at best, as your community members don’t know how many tokens they will be receiving, if any. Also, by delaying the token launch so significantly, projects miss out on many of the benefits that tokens can provide including creating robust reward programs and providing their community with greater utility. The risk is that your best, early users may churn. Some come early for the product, are not sufficiently incentivized to remain loyal, and leave.
Additionally, airdrops also are easy to scam, by generating a large number of fictitious transactions in multiple wallets in order to “farm” more airdrops.
Basically airdrops in the Later Stage of a product life cycle are a regulatorily safer but otherwise suboptimal solution.
Launching a transfer restricted token (TRT) earlier in a product’s life cycle
One solution that projects can utilize to access the benefits of tokens earlier on in their product development, while keeping in mind regulatory risk and issues posed with Later Stage airdrops, is to launch a token that includes certain transfer restrictions during the Early Stage or Growth Stage of the product.
Unsure what a transfer restricted token is or how it works? Check out our post on that here.
This approach allows projects to use tokens to bootstrap network effects, supporting the achievement of business objectives (customer acquisition, retention, engagement) while still accounting for token regulatory concerns (since the token cannot be bought or sold on an exchange).[2] Furthermore, TRTs have the advantage of being able to be issued to users in real time (or close to it), thereby serving as a better incentive and reward mechanism since users understand what they can expect.
TRTs will, by definition, not have extrinsic monetary value since they cannot be bought and sold, but they will have intrinsic value within the brand’s ecosystem through various utilities made available by the project (e.g. access to exclusive offerings, the ability to buy brand items using the token as the payment mechanism, the ability to vote on brand decisions using the token for governance, etc). As a tool for brands to wield, tokens allow these businesses to set reward rates relative to the value it brings to the business, for example: signing up for the platform may earn 10 TRTs, while referring a new user may earn 50 TRTs.
We will dive into the various use cases and their advantages of TRTs for a project looking for project-market fit in a future post. But the TL;DR is: because rewards in the form of TRTs can be deposited in a user’s wallet in real time, the project can use them as an acquisition tool, engagement tool, retention tool and a feedback mechanism.
In summary, progressive decentralization is an incremental journey on the path to sufficient decentralization. To maintain compliance with regulations, projects may elect to hold off on launching a freely tradable token until they are sufficiently decentralized, or they may launch a token sooner and apply certain transfer restrictions to the token (which may be removed later on if desired). Ultimately, whichever path is chosen is a business decision that requires significant regulatory input.
Disclaimer: This post is meant for education purposes only, and is not meant as a substitute for legal advice.
Enjoying this content? Follow Co:Create on Twitter for more.
[1] At least according to the Playbook, token launches should be limited to the growth phase. “To start, teams might test a distribution with a managed and permissioned group of community members. A number of teams have elected to do this by allocating a slice of future tokens to early “power” contributors, for example…”. It is possible this advice will still resonates two years later. However, I would argue that, given the current regulatory environment (for example, the recent LBRY decision) may make this stance more difficult. Additionally, as discussed below, I believe there is a business advantage in being able to get tokens into any user’s hands, not just power users, active discord members, etc.
[2] We will discuss in future blog posts, but in order to obtain the highest level of regulatory clarity, a token should follow the path that the SEC has laid out in several no-action letters, including IMVU and Pocketful of Quarters. Some of the relevant facts included in those letters is that the tokens are transfer restricted and — importantly — have uncapped supplies. We will discuss all the details, including uncapped supplies in future posts.
