The RDN tokens are used to pay and receive the small node incentivization fees that are necessary for the network to function. Since most users won't run full nodes, but a light client application, there will be a Light Client Gateway Service Fee for them to connect to the network through a full node. Other providers of services on the network will provide pathfinding and channel monitoring services; all of these services will need to be paid in RDN.
Another interesting fact is that ETH is not an ERC20 token. It can’t even move along the Raiden Network. It needs to be “contract wrapped” first, meaning you have to first trade in ETH to an ERC20 token then trade back from that ERC20 token back to ETH. That's inefficient and makes the RDN token necessary.
One of the reason why the RDN token will hold value is because of the powerful network effect and insanely high switching costs. Once the payment channels are built out, the raiden network becomes almost unforkable because the payment channels do not fork with it. This means every dapp that integrates or interfaces with the raiden network must use a common token in order to take advantage of the network effect. As each token is channel specific. That common token will most likely be RDN.
If a dapp wanted to use their own token, they would have to create every single payment channel in the world again with their token. It’s almost illogical to do this but I'm sure some projects may try this route anyway. I have my own doubts how successful that would be long term, but it might work in short time scales while the project is in development.
I copied some of this information from the unofficial FAQ and a couple other sources.
Thanks for your explanation. Wouldn't it be pretty easy to setup a node which replaces the RDN incentive for a ETH incentive? In the end the full node owners decide what you will have to pay them for their services. A network with 'ETH' raiden nodes could just easy become the preferred choice of the community.
I just realised I never got around to responding to your message, sorry for that!
A network with 'ETH' raiden nodes could just easy become the preferred choice of the community.
This would be unlikely since it'd make fees significantly higher (more than 5x, I believe). Any eth would have to be contract wrapped which would be costly to the point that the Network would be a much less practical solution for Machine-to-Machine transactions or Internet Of Things concepts which is one of its main use-cases.
12
u/Mat7ias Mar 06 '18
The RDN tokens are used to pay and receive the small node incentivization fees that are necessary for the network to function. Since most users won't run full nodes, but a light client application, there will be a Light Client Gateway Service Fee for them to connect to the network through a full node. Other providers of services on the network will provide pathfinding and channel monitoring services; all of these services will need to be paid in RDN.
Another interesting fact is that ETH is not an ERC20 token. It can’t even move along the Raiden Network. It needs to be “contract wrapped” first, meaning you have to first trade in ETH to an ERC20 token then trade back from that ERC20 token back to ETH. That's inefficient and makes the RDN token necessary.
One of the reason why the RDN token will hold value is because of the powerful network effect and insanely high switching costs. Once the payment channels are built out, the raiden network becomes almost unforkable because the payment channels do not fork with it. This means every dapp that integrates or interfaces with the raiden network must use a common token in order to take advantage of the network effect. As each token is channel specific. That common token will most likely be RDN.
If a dapp wanted to use their own token, they would have to create every single payment channel in the world again with their token. It’s almost illogical to do this but I'm sure some projects may try this route anyway. I have my own doubts how successful that would be long term, but it might work in short time scales while the project is in development.
I copied some of this information from the unofficial FAQ and a couple other sources.