Progressive De/Centralization: A Playbook for Building Decentralized Applications
Preface
For the past year, I had the pleasure to work with many DAOs, from large social DAOs to leading DeFi projects and public good visionaries. Many founders and contributors have run into tremendous headwinds while trying to build the best product and simultaneously dealing with governance overhead. In this piece, I refine and collect thoughts together to form a playbook for building the best crypto product.
This playbook is focused specifically on applications that live on blockchains. These include but are not limited to DeFi projects (Uniswap, Aave, Maker), social primitives (Lens, Safe, Farcaster), and on-chain games (Dark Forest, Lattice). This playbook does not apply to centralized exchanges (Binance, Coinbase, FTX), social collectives (FWB, FF), Layer 1/2s, or off-chain games.
Summary
Since 2020, the concept of progressive decentralization has become more popular in the crypto industry. However, questions have arisen regarding its effectiveness. For instance, early product-market fit (PMF) metrics have been inflated due to farmers expecting future airdrops, while governance activities have not shown a convincing ability to scale to more contributors. The SEC has also been scrutinizing DAOs with large token holder counts, exposing the facade behind progressive decentralization. Additionally, many scammers and grifters have used this concept as an excuse to rug projects.
To address these challenges, I will introduce the Progressive De/Centralization Playbook, a series of steps that builders can take to achieve decentralization while not *directly violating* regulatory requirements:
The first step is to build a protocol and product, allowing contributors to provide input without a formal structure or legal barriers.
Next, the protocol development process should be formalized, and ownership transferred to the protocol foundation.
Meanwhile, product development should be centralized and structured as a traditional company.
Optionally, a token can be launched to govern the protocol development process, but not the product.
This approach (at a high level) will maintain decentralization and product agility while ensuring regulatory compliance. This playbook would be most helpful to founders who have not spent a large amount of time following different governance activities/dramas.
If you're interested in learning more about the thought process and reasoning behind this design, I will be sharing my insights in a series of future articles. Stay tuned.