The Raiden Network Token Model
TL;DR: This post elaborates on the goals and utility of a future RDN token. We have been working hard to balance the interests of all stakeholders and to come up with a sustainable model that provides value for the community for and even beyond the Raiden sub-ecosystem. Skip to the FAQ at the bottom as a shortcut.
The scope of the Raiden Network project is to build an open source protocol and a reference implementation of a decentralized system, which enables scalable, low latency, low cost transfers of ERC20 tokens.
In order for payment channel networks to provide their utility, cooperation of many actors in a decentralized network of off-chain services is required. Crypto-economically secured systems depend on means to represent and exchange value to set the correct incentives for the involved actors. The RDN token is envisaged to be the default currency to be used between these services and their clients in the Raiden Network.
Design Goals of the Raiden Network Token
At the core, the system is a protocol, which should have no mandatory fees to avoid any hesitation when considering usage of the protocol. Payment channel networks will have strong network effects and switching costs are high. We want to avoid a token model which would exploit this, i.e. there should be no rent seeking monopoly. The protocol and the emerging network should be open for innovation and not mirror the walled garden model of silicon valley platforms such as Facebook
A RDN token should align the incentives of all stakeholders in the system in a way that there are no incentives to fork the protocol. This results in the requirements that the token model should not degrade usability, should not hinder adoption and not introduce additional gas cost for standard operations. The token should instead improve the quality and innovation of the overall system.
A crowdsale of RDN tokens hopes to raise the required funds to develop the project to a stage of maturity which can support major adoption. Retained tokens are also envisaged to be used to reward and sponsor 3rd party open-source projects which build additional tools, libraries and applications.
Stakeholders in the System
Let’s take a look at the stakeholders of the system and their possible incentives.
Users (light clients)
Regular users access the system by using a light client (e.g. a JS library used in a Dapp). Their minimal expectation is that the system is secure and using it comes as a worriless experience. They do not want to pay unnecessary fees. If there are fees, they want to see competition to bring the fees down or get better service. Users do not want to be locked in with a rent seeking network. Furthermore, users prefer open access to the network and innovation based on its utility over a monopolistic monetization by a small group of owners.
Full Node Operators
Other than light clients, full nodes open multiple channels and therefore create the backbone of the network. Full nodes may advertise a set of services which are especially useful to light clients. Running a full node requires installing the Raiden software, running an Ethereum node, properly securing the system and maintaining a high uptime if providing services to other parties. As all of this comes with a cost, full node operators want to have means to get compensated for the services they provide. They compete on the dimensions of service quality and fee schedule. They need to cooperate with other services to deliver theirs. Also, with them playing a crucial role in the system, they want to have a vote in protocol upgrades.
Provided services can be:
Light Client Gateway Service
Light clients rely on a full node to connect to the network and send and receive tokens.
Channel Monitoring Service
When nodes go offline (planned or unexpected), they can not monitor their channels anymore. Participants stand to lose part of, or their entire deposit if they do not monitor the channel. Therefore, channel monitoring and disputing wrong states can be delegated to multiple non-trusted third parties which need to be incentivised to provide the service.
Pathfinding Service
The Raiden Network is conceived to be structured such that nodes can find a path of payment channels with sufficient capacity by recursively querying nodes along the Kademlia-like structured graph of payment channels. This process involves a rather high number of messages which can add significant latency. Alternatively paths can be quickly discovered by querying a pathfinding service which has a map with the current capacity of a certain neighbourhood of the payment channel network. The pathfinding services need to cooperate (which involves payments) with those pathfinding services of other neighbourhoods to provide their service.
3rd party application builders
There are many applications that could be built on top of the Raiden Network, leveraging on the low fee and latency properties. Developers of 3rd party applications should not be distracted from using the network by inbuilt fees at the core, which would lower their competitive edge. For the auxiliary services they want to see good quality at low cost or have the option to provide these services themselves and free for their users. Application builders take some risk when deciding to base their application on the network and want to benefit from the added value they bring to it. In order to protect their technology investment, they want to have a vote in protocol upgrades.
Developers
Developers want to get rewarded for their work and the maintenance of the protocol and reference implementation, as well as the coordination and organisation of deployments. Next to the core of the protocol, 3rd party developers will create a multitude of complementary software and services, such as alternative clients, wallet integrations, interoperability with other blockchain systems, developer libraries for various platforms etc. There should be means to support their contributions with a reward that is strongly correlated to the value they added. Developers are aligned in their interest to bring adoption to the system as they share the investment of efforts in the same subset of the Ethereum ecosystem. Being the experts, they should have a vote in protocol upgrades.
Utility of the Token
While the Raiden Network protocol does not enforce mandatory fees at its core, the system can provide a better user experience if auxiliary services provided by full nodes are used. Having a common token for the remuneration of these services is important. Acceptance of a common currency allows the services to cooperate efficiently, allows users to use their channels with service providers for multiple token networks and enables availability of services for token networks which are not widely accepted for payments.
In future versions of the Raiden Network the token might also be used to govern protocol upgrades or act as stake in a generalized state channel technology.
Conclusion
Alignment of incentives
From a user perspective, the RDN token model is designed to allow for competition and innovation of auxiliary services on an open platform. This will allow for better services and lower fees over time. Also users do not sign up for a platform where they’d help to create a monopoly based on the emergent network effects.
Providers of auxiliary services are given the means to monetize on the platform by taking RDN token based fees, thereby strengthening the value of the token. This is aligned with their requirement, that the system is well governed and has the resources to be further developed and maintained in the long run.
Creators of applications on top of the Raiden Network have no incentive to spawn their own competing network, as there are no unnecessary fees, their users would have to bear.
The developers of the protocol and reference client implementation are properly funded and development grants can be given to a broad range of groups aiming to add value to the system. This allows to progress and maintain the technology based on its overall success without having any developer bias towards a specific service or application on top.
FAQ:
Q: Is the token needed to use the Raiden Network?
A: No, it is not necessary at the core protocol level. Opening or closing payment channels, joining the network, sending transfers does not involve RDN at the protocol level. The user experience (i.e. less software to install and operate, higher probability of fast and successful transfers) can be increased though when paying small fees for auxiliary helper services in RDN tokens.
Q: How does the token have value?
A: The token has value if the auxiliary services in the system are remunerated in RDN tokens and users who do not run the full set of services therefore stock the token. The RDN token has a fixed supply and scarcity of a currency usually gives it value proportional to its usage.
Q: What prevents an auxiliary service from accepting payments in tokens other than RDN?
A: Nothing, a service could do this. But, as services and users need to cooperate, the system is most efficient though if a single currency is used. E.g. pathfinding involves a recursive chain of api calls and it would be quite inefficient if currencies need to be exchanged in between.
Q: Why not use the token that’s transferred in the payment channel as the currency?
A: Because the token might simply have no value to the service providers (e.g. think IOUs in a local community currency).
Q: Doesn’t the token add unnecessary friction over using ETH?
A: As the software can automatically acquire RDN tokens, the mental burden for a user is low. Cost wise, roughly 100k additional gas is necessary to initially exchange some ETH for RDN using a DEX, which currently costs ~$0.15. We consider this to be neglectable friction compared to the benefits of being able to do low cost transfers on a payment channel network maintained by an ecosystem of well incentivised developers, projects and services.
Q: Couldn’t the token be forked out?
A: Yes, every open source blockchain based system can be forked at any time. Therefore it is important, that incentives are aligned such that this is rather unlikely.
Q: Why not use ETH?
A: The Raiden Network is not your average DApp. It is a complex technology that involves tremendous engineering efforts before its release and if successful, will require ongoing maintenance and improvements of the protocol and implementations. Also bootstrapping the network will depend on more than some developers delivering software. It will also rely on the interlocking efforts of dedicatedly incentivised 3rd party developers, non developers and projects building applications on top, constituting a healthy ecosystem of aligned builders, evangelists and users.
We sincerely believe that a properly funded and incentivised organisation is better positioned to deliver and drive adoption, than a development team living off donations. In the past, open source projects have been suffering from a constant lack of funding, incentives and subsequently bad management and progress. Blockchains have opened a way to allow for sustainable funding of open source protocols and we consider this to be also the right approach for the Raiden Network.
While the Raiden Network is deeply rooted in the Ethereum ecosystem, it is not funded by the Ethereum Foundation nor is it part of their roadmap. The project is instead run by brainbot labs, a for-profit company aiming to drive adoption of public blockchain systems. And that is probably good, as we think that an independent and well run Raiden project will turn out to be more beneficial to the value of the Ethereum ecosystem than a half hearted donation based approach.
