[Source](https://jessewalden.com/progressive-decentralization-a-playbook-for-building-crypto-applications/)
# A Playbook for Building Crypto Applications
Crypto founders have a unique challenge in front of them. In addition to building a product that people want, they also need to consider how that product can successfully run in a decentralized manner — that is, as a protocol owned and operated by a community of users.
This is a difficult challenge because much of what it takes to build a successful product at the outset — product leadership, rapid iteration, a managed go-to-market — complicates the path to community ownership and regulatory compliance, which guarantee long-term health.
I've talked to a number of crypto founders working to resolve this tension. Here I'll propose a three-step process that may serve as a guide for how to do it, by way of progressive decentralization — a process in which founding teams relinquish control by degrees, over time. Doing so step-by-step allows teams to focus and creates a path toward regulatory compliance, including issuing tokens that hopefully will not run afoul of securities regulations.
Keep in mind that this process is intended for certain crypto startups building __applications__ on smart contract platforms. It's less useful for blockchain computing platforms themselves, which require sufficient decentralization from inception in order to be useful.
Given the still-uncertain regulatory framework around community-owned networks, the final stages of this playbook are only pointing toward potential solutions rather than identifying proven winning strategies. Think of it as a possible path.
## The Three Components of Crypto Success
First, I'll posit that any successful application running on a blockchain computer will feature these three components:
1. Product/market fit
1. Community participation
1. Sufficient decentralization (community ownership)
The need for [product/market fit](https://pmarchive.com/guide_to_startups_part4.html) is obvious. Without a product people want, there are no users, no business, and it will be difficult to sustain a community for long. Community participation and decentralized control are less applicable to traditional startups, but are crucial for crypto startups. Why are they so important?
The answer is that [community participation and control](https://www.wired.com/story/how-blockchain-can-wrest-the-internet-from-corporations/) results in limited platform risk — the risk that the rules of a platform will change against the will of its users. Web 2.0 platforms have demonstrated the potential for this kind of misalignment, for example by killing innovative app ecosystems built on their APIs, or by profiting at the expense of users' privacy or wellbeing. In contrast, user-owned networks can benefit from a [cooperative economic model](https://jessewalden.com/past-present-future-from-co-ops-to-cryptonetworks/) that helps ensure crypto services remain better aligned with their users, even as they scale.
Another important reason for achieving decentralized community control is regulatory compliance**.** Crypto tokens that facilitate economic alignment can be deemed securities under the [Howey Test](https://a16z.com/2018/05/04/considerations-for-regulating-cryptonetworks/), a regulatory framework used by the SEC. Managing a distribution of securities to a large community of users can be challenging and expensive for a startup to manage — even Airbnb and Uber [haven't figured out how to do it](https://www.pillsburylaw.com/en/news-and-insights/rule-701-revision-uber-airbnb.html). But analysis of recent SEC commentary and enforcement actions suggests that true decentralization may enable a startup's token to transmute from a security to a non-security if the team is able to sufficiently decentralize operations, eliminating information asymmetry or dependency on the efforts of the founding team to create value. One key test for whether an investment might be deemed a security is whether investors are relying on the efforts of others with the expectation of profits.
As Scott Kupor, managing partner at Andreessen Horowitz, [has previously written](https://a16z.com/2019/10/22/mutability-sec-recent-cases/):
> In the pre-network stage, tokens will generally be characterized as securities in light of the 'reliance on the efforts of others' prong of the Howey Test. However, post-network launch — provided that the network is sufficiently decentralized — the nature of the token can change from security to non-security, owing to the fact that the holder of the token is no longer relying on the efforts of others."
So, with these reasons for decentralization in mind, let's walk through a framework for tackling it as a process, with the goal of building a sustainable, compliant and community-owned product.
## Objective 1: Product/Market Fit
The earliest stage of building a crypto application requires all the ingredients of a normal startup: a great team, lean development, tight execution, and quick learning. During this phase, the only thing that matters is product/market fit. To move fast toward finding it, it's important to avoid design by committee (or community!) A product needs opinionated leadership to test hypotheses and update assumptions quickly. In practice, this could mean admin privileges on smart contracts, which allow for rapid iteration and product management — including upgrades, shutdown, or quick parameter setting.
At this stage, there should be no pretense of decentralization — a core team is driving all product decisions by necessity, in the interest of finding product/market fit. Launching a token at this stage is not advisable because it could trip compliance wires. Dependence on the core team's efforts is one way a token might be deemed a security under the Howey Test, and thinking about this is a distraction from product development.
The idea of a core team controlling all aspects of a project may ruffle the feathers of some early users, but founders shouldn't be wary of this. If users are complaining about the control you've got, that's actually a good problem to have! It means someone cares about what you've built. That said, it's important to communicate clearly about where control exists. Faking autonomy is a quick way to undermine trust, whereas transparency is a way to build it.
### Objective 2: Community Participation
At early signs of product traction — a growing user base, developer ecosystem and network effects — it's time to start devoting more cycles to fostering harmony between passive users, more-active contributors and the core team.
To start, founders might invest more heavily in best practices for running the product like an open source project: invest in good documentation; develop openly; offer bounties, grants or other incentives for third-party development; hire community leaders to help steward open development; and introduce[rough consensus](https://tools.ietf.org/html/rfc7282) on decision making.
Going further, it may make sense to start eliminating platform risk through imposed technical constraints. For example, in Compound v2.2,[upgrades take effect 48 hours after they are pushed](https://medium.com/compound-finance/upgrading-compound-governance-c56b55a2996c), allowing time for users to exit the protocol, or review and voice dissent. Urbit practices "Kelvin versioning," in which version numbers count __downwards__ to 0, at which point no more updates are to be made.
For the core team, relinquishing control comes with an opportunity to begin transferring responsibility to the community. But as you go about engaging community members, it's important to revisit incentives. Why will community members contribute to the product on an ongoing basis?
**Incentives (Fees)**
An economic incentive is one way to engender community contribution. But where do the economics come from? A pragmatic and familiar business model for crypto services is a fee-per-call, similar to an API micro-service like Twilio or Stripe. Distributing this fee stream to active contributors can align the community around the project's success.
That said, fees don't always make sense at the outset of a project. Given that crypto services are open source, it may be better to introduce fees only once there are [strong network effects](https://a16z.com/2018/12/13/16-metrics-network-effects/), resulting in defensibility through switching costs.
[Uniswap](http://uniswap.exchange/), a decentralized exchange, is an example of how a crypto application with a fee can be protected by the power of its network effects. In Uniswap, the more users that contribute liquidity to an exchange pair, the better the pricing for traders. In order to provide the same pricing in a fee-free fork, you'd need to coordinate all the liquidity providers and third-party services integrated with the original to start using said fork. The cost of coordinating all that is a switching cost. While such switching costs are lower in crypto where data is open, they still do exist. In crypto, however, protocols must remain [minimally extractive](https://www.placeholder.vc/blog/2019/10/6/protocols-as-minimally-extractive-coordinators) (in other words, they cover relevant costs rather than seek to maximize profit) in order to incentivize community contribution.
**Distribution (Tokens)**
Tokens are an instrument for effectively distributing the fundamental value of a project, including a fee stream. While token distribution can incent participation and help build defensibility, it's important to consider how to construct a distribution that is both fair and effective.
Many ICOs and airdrops were suboptimal in that they invited unengaged communities and regulatory scrutiny. Crypto applications that focus on product/market fit have an opportunity to do better, by distributing tokens to an already active user base.
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 through testnet programs where independent community members can register to participate in operating a node. A promissory and managed token distribution to users that contribute valuable work can help eliminate community dependency on the effort of founding teams.
Next, teams need to plan how remaining tokens will be distributed to participants, both fairly for past contributions, and effectively as a future incentive for ongoing participation**.** The distribution design needs to consider the core team that built the product, as well as the users that make it useful. Getting this right is hard, and will always be specific to the application in question, but some common questions to think through are:
* What percentage of tokens should be allocated to the initial team and cap table?
* How will you reward different types of contributors to the product or service, historically and in the future?
* How will technology leadership be rewarded going forward?
Answering these requires analysis of community behavior, modeling of rational outcomes and workshopping proposals with community members.
## Objective 3: Sufficient Decentralization
If you're a crypto founder and are ready for this stage, that means you have achieved early product/market fit, built a robust community capable of successfully maintaining the application, and mapped out a model that properly incentivizes sustainable operations.
Now for the last and final step on the journey to sufficient decentralization: a widespread token distribution.
In practice, I imagine teams will "[exit to the community](https://hackernoon.com/startups-need-a-new-option-exit-to-community-ig12v2z73)" by airdropping tokens to users and contributors based on the plan mapped out in the prior objective. This would happen the moment a smart contract is triggered to mint and distribute tokens. Optimally, once this function is triggered a number of things will have happened:
* The core team will have ceded majority ownership of the application (fees and control) and mitigated platform risk by ensuring the product is community-owned and operated.
* The token may have transmuted to a non-security, given that the service is now sufficiently decentralized — that is, independent of the efforts of a single entity that might have asymmetric information.
* The company is sustainable, having retained enough tokens to benefit from fees and growth.
* User-owners realize increasing returns to scale, as the cooperative economics of the service allow for better alignment and growing value (as defined by users rather than shareholders.)
The spirit of this objective is to mark a specific moment where a crypto product company completes its journey from traditional product team to sustainable community-owned-and-operated network. (Conducting a token distribution always requires careful legal review, and there is little precedent for what I'm describing, so please consult a lawyer first!)
## How to Avoid Getting Stuck
A lot of teams have gotten stuck by tackling these objectives in the wrong order, "faking" decentralization, or by trying to do everything at once.
For instance, app teams that pursue community ownership first (starting with a wide token distribution) risk engendering a community of speculators, rather than real users. Without a working product, ownership is worthless, and the community won't stick. Many teams that have done this are unable to back into product/market fit, and as a result have a hard time kickstarting meaningful community participation.
Another sequencing risk is jumping straight from early signs of product/market fit to decentralized community ownership (skipping objective 2, community participation.) Failing to formalize __real__ community participation can land projects in an uncanny valley of decentralization theater. A symptom of being caught here is an apathetic community with low participation rates, and a heavy dependency on founding teams. In this situation, formalizing control (e.g. through delegation) may be a better path to building trust, whereas hiding under the pretense of decentralization is a quick way to undermine it.
Another way to get stuck is to aim to do all three things at once. Lack of focus is the death of most startups, and the same is true for crypto applications. Each of these objectives overlap and needs to be considered holistically, as part of an idea maze, but execution needs to be sequenced and prioritized, not attempted at once.
Finally, it's worth noting that even if you do the steps in order, once you flip the switch to full community ownership, you're in fairly uncharted territory in terms of governing the application. Scaling effective community decision-making is challenging, but if internet communities can accomplish feats like Wikipedia, I'm optimistic that experimentation and skin-in-the-game (via valuable ownership) can lead to cooperative decision-making at unprecedented scale.
So far, we have yet to see a crypto application execute each of the objectives sequentially, but the most promising project teams I've spoken with have been navigating their way through this playbook. Through those conversations, I've come to believe that progressive decentralization offers teams the most auspicious path to finding product/market fit, financial sustainability, a participatory community and regulatory compliance — in that order.
