Why we Launch a Crypto Network Without a Token (for now!)

Centrifuge OS enables a new generation of applications for the financial supply chain. It allows any business to transact with their counterparties while maintaining ownership of their resulting data, including company details, business relationships, and most importantly, subsequent transactions like purchase orders or invoices.

Participants can privately and securely exchange financial documents — such as invoices, orders, or others — while having public verifiability of said data. The network relies on a public blockchain (Ethereum) to guarantee the unalterability of the private data, verification of the network participants based on public encryption keys, and most importantly the tokenization of privately exchanged assets. One important example of that is the tokenization of unpaid invoices to enable invoice-based financing.

In short:

Centrifuge OS is a decentralized, peer-to-peer, crypto network that builds on public blockchain infrastructure.
Centrifuge System Overview

We are launching the publicly usable Ethereum mainnet version soon. Contrary to other crypto networks, we decided to launch without a token. In this post, we want to share our design approach and the reasoning behind launching our network, initially, without a token and token-specific features. We also discuss our plans for introducing a token-driven incentive model at a later point.

Why Have a Token?

Many decentralized networks that are being built today use one (or multiple) tokens to support the network. Here are some possible reasons for having a token as part of a decentralized network.

Fee/Unit of Usage

The token allows users to pay service providers (e.g. miners) for the services they provide within the network. Note that, usually, the entity that “uses a service” transfers the token to someone who “provides a service” within the network. In some networks, these tokens also become a currency for general value exchange between users.

Incentivization for Participation

Giving out or rewarding tokens to network participants to incentivize them to use the new network. There is a possibility of pairing the incentivization with other uses of the token. E.g., giving out higher rewards for providing a service to the network to those users who join early (e.g., higher mining rewards for earlier blocks).

Staking

Users or service providers have to lock up tokens to access features of a network. Often service providers have to stake a number of tokens to provide a service to the network. They have to stake to perform work. That’s also called a “work token.”. In other cases, users have to stake tokens to access the basic feature set of the network or community.

Securing a Network

A subset of staking where the ones who provide the service (e.g., mining, storing, transcoding, computing,…) have to put up a security deposit in the form of tokens. Usually, there are network rules that slash this security deposit in the case of misbehavior. The potential of losing the valuable stake incentivizes good behavior of the service providers and secures the network.

Governance

Holders of the token can influence the parameters and direction of a network. Examples are on-chain votes for protocol upgrades or voting to release funds for specific purposes (e.g., grants). This is called a “governance token” or “power token.”

Why Wait to Introduce a Token?

Our vision is that someday, every business uses Centrifuge OS to participate in the decentralized economy. At that point, we believe, the network that powers Centrifuge OS requires a token-based incentive model to function well and provide maximum value for its users and service providers. The path towards our vision is long. When building, designing, and launching different parts of Centrifuge, we aim to make the best decisions possible, at the right time, to progress on this path. In the case of introducing a token, this means that we will postpone token-specific features in favor of other priorities.

Reducing Complexity

Let’s face it: Creating new products or even whole new categories of products is hard. Finding users for those products is also hard. When designing a new product (especially decentralized, trustless systems) more complexity means less flexibility for the product and future iterations. It also brings a higher possibility of people attacking the system for financial gains — purely to extract token-based value.

Unless a product fundamentally requires a token to function from day 0, having a token adds complexity. We think that keeping things as simple as possible is a wise design choice even if this means postponing specific token-enabled features to a later release.

Uncertainty * Uncertainty = …

Building software products always come with uncertainty. Lots of testing is done before launch. Use-cases are explored. There are closed-alpha and open-beta periods. Whatever you do, the age-old axiom holds:

“No product vision survives the first contact with real-world usage.” — said someone who built and launched products before

We have an idea what the Centrifuge network will be used for. We supported early users to build on top of the protocol. But we don’t know for sure which other use-cases will appear and become important over the coming months. Adding a token into the mix adds another layer of uncertainty. Is the token reward schedule designed correctly? Does the governance mechanism take every possible situation into account? Are the usage-fees going to be what we predicted ahead of time? Are our smart contracts coded correctly to support the different token uses (See “Complexity” above)? Is the allocation of funds for incentivizing the network compared to rewarding network operators adequate? Is the token going to be subject to speculation? How would speculation influence network mechanics? Could the whole network be laid to waste by any of those factors?

Providing Value to Centrifuge OS Users

Our primary goal for Centrifuge is to be a system that users want to use because of its functionality. The system itself needs to provide real value to the users. The token can be a mechanism to support the system overall or enable specific (decentralized) features. Having a token is not the prime objective of our project. The prime aim is to deliver a foundation for a new generation of business-to-business applications in the financial supply chain. If the first version of Centrifuge makes a step towards that objective without a token, then we want to go that route.

Developers and partners build on Centrifuge OS because they gain inherent value from the system.

Users use the products built on Centrifuge OS because they gain value from those products.

The token is there to support those goals. The token is not the starting point but the result.

No Token at Launch

We decided to launch the initial version of Centrifuge OS without a token. We want to support real-world usage as early as possible. That is possible without a token being part of the initial protocol. We made the conscious decision to postpone token-specific features until a later point. Among the postponed features are allowing delegation of peer-to-peer document signatures, decentralized & trustless data retention and validation, scalability, and decentralized protocol governance. These decisions mean that we will deliver portions of our vision in a later phase. It also means we will see real-world use earlier and can develop the next version with more certainty while being free from a token-specific feature lock-in right now.

While launching now, we are still actively developing our token model and are designing and prototyping the token-enabled features already. Centrifuge’s token economy, once launched, will enable a whole new set of use-cases for Centrifuge OS.

Introducing a token to the network at a later stage will come with other challenges — users might have to hold multiple tokens, where before they only held ETH. Features that were “free” before might have a nominal fee attached to them. Users might have to stake tokens to access new features. How will those factors influence the usage of Centrifuge? We are keeping all that mind, and we think launching earlier, (in-)validating assumptions earlier, and supporting real-world transactions and use-cases sooner will allow us to design the token economy and the next iteration of the protocol with more certainty. In the end, we prefer a working system that provides value early on. From there we will add, improve, and evolve our thinking and approach.

Join our journey by following us here on Medium or at Twitter. If you are interested in using or building on Centrifuge, join our Community Slack, read our documentation, or send a note to hello@centrifuge.io. While we are not actively hiring right now, we are also always open to talk to exceptional people who want to support us and the team! We love to hear from you!