#04 Path to Progressive Decentralization: Transferring power from authority to community

#04 Path to Progressive Decentralization: Transferring power from authority to community

What is progressive decentralization

It is the concept that a project initially starts with centralized control in the hands of the founding team and gradually, in its journey of growth, relinquishes control to the community and moves towards decentralization.

Why is it necessary

The idea is quite simple: we must let go of the idea of decentralizing everything instantly, and instead think about how can we make new technology more intuitive and increase its adoption.

In the 0 to 1 journey of any project/startup, it is required to have an opinionated visionary approach to drive the team forward, avoid friction to onboard customers, do multiple iterations and establish a product market fit. To achieve the PMF the team needs a focused but open directive which is difficult to achieve if there are more brains driving it.

However, as the idea grows and more and more people buy into the vision, it makes sense to relinquish control gradually to the users, builders, stakeholders so as to not act in one’s selfish interest alone and thus, do more public good.

Decentralization can be valuable…

Decentralization is the transfer of control and decision-making from a centralized entity — a specific individual, organization, or group — to a distributed network. This can apply to many elements of a business, including content creation, organizational governance and processes, and even the tech stack.

Decentralization is often functional. For example, an organization might aggregate opinions from a decentralized network of individuals. Indeed, value creation in web3 is in large part about using shared ownership to incentivize participation and engagement from many people at once. 

In other contexts, decentralization can provide security — for instance against censorship (although for this to work, it’s important to structure governance correctly). And separately, web3 platforms seeking to make use of their own digital assets also need to decentralize for regulatory reasons.

… but decentralization isn’t easy.

While decentralization can be valuable for a business — necessary, even — it can be difficult to start out that way. Many pressures push toward centralization in the short run even for companies that are committed to decentralization in the long run.

Think of the challenge, for instance, of initiating a product or conducting the type of quick iteration required to get to product-market fit without a core central team or a centralized process for decision-making. Furthermore, decentralization in web3 also typically comes with an expectation of composability, which introduces the risk that someone else might “fork” your product before you achieve scale. And relying on decentralized governance or other forms of crowdsourced input without the properly designed support structures — including those that drive engagement — can potentially expose a platform to risks of fraud or payola.

These forces encourage centralization early on. But it’s important to ensure that they don’t lead to design decisions that make future decentralization even harder. That is, even if there are good reasons to be more centralized early on, you should design for future decentralization.

Progressive decentralization

Here is some guidance to help you actively plan for future decentralization.

In Web3, crypto innovators have to be able to do two things:

  • Build something people want and find product-market fit.
  • Decentralize governance and turn ownership and control over to the community.

These are two fairly difficult issues to work out. There are a lot of failed projects that tried to tackle both of these issues at the same time — trying to find product-market fit while decentralizing their governance — and this led to new and unexpected problems.

Decentralized autonomous organizations (DAOs) are a perfect example of decentralized governance, and they move slowly. There are a lot of arguments. Nobody’s really taking control or being decisive, and therefore they lose a lot of the advantages of being a startup.


1. Core team. Hire people who are able to set up their work so that it might be possible for external members to take over some of the responsibilities — for example, a community manager who designs the community in a way that allows members to start to self-manage and self-govern. Additionally, invest in upskilling your team with an eye toward decentralization as a long-term target, and of the new technologies and best practices that support those efforts.

2. External contributors. The further you slide toward fully decentralized, the more your community gets involved in how the product evolves and is governed. Calibrating based on how decentralized you want to be, you’ll want to build in a participatory way and cultivate the community that’s going to take part in building on top of shared infrastructure, contributing content, and/or governing the system. And it’s not just about inviting community participation — you have to design the organization in a way that enables people to contribute and rewards them for doing so. This means building robust feedback and engagement channels, together with the accompanying structures and processes.

On the reward side, meanwhile, introducing reward points or digital tokens to track and reward community contributions can help incentivize community activity. For example, you might start off by engaging external developers to test out your core infrastructure — perhaps by allocating rewards to developers who kick-start activity by building on top of the protocol.

3. The technology stack. The stack can be architected in a modular way that allows you to swap in decentralized versions of the centralized services that you start out with — for example, by starting out storing content on AWS and over time transitioning to decentralized storage services, such as Arweave or IPFS.

4. Finance. You should plan for decentralization both in terms of how you fund the business initially and the ways you allocate resources internally and externally. In particular, you should structure finances in a resilient way that can sustain the organization without central control — for instance, consider how the investors you are bringing on would react to an exit to community control (which we might call a “decentralexit,” perhaps), and think through regular allocations to a community treasury.

5. Internal processes. It’s important to invest the time upfront to think through what might be needed for you to decentralize parts of your operations and business processes — for example, you might need rich documentation that allows community members to understand precedent or context for specific decisions for governance.

Once that product-market fit has been found, they can start building a community around that product and running it more like an open source project. They can, for example, put bounties for people to build out certain features, community management work, and operations work.

Several systems need to be put into place at this point, and processes need to be built that can facilitate people contributing to the new platform. You have to create new ways of incentivizing these contributions. And they must be sustainable so your project doesn’t flame out or lose direction the minute your direct leadership is moved over. 

But once these things are in place, then you can turn ownership and control of your project to the community.

To view or add a comment, sign in

More articles by Hamdi KÜÇÜK

Insights from the community

Others also viewed

Explore topics