Raiden Network - Fast, cheap, scalable token transfers for Ethereum

  • @raiden-network


    The Raiden Network is an off-chain scaling solution, enabling
    near-instant, low-fee and scalable payments. It’s complementary to the
    Ethereum blockchain and works with any ERC20 compatible token. The
    Raiden project is work in progress. Its goal is to research state channel technology, define protocols and develop reference implementations.


    The Raiden Network is an infrastructure layer on top of the Ethereum
    blockchain. While the basic idea is simple, the underlying protocol is
    quite complex and the implementation non-trivial. Nonetheless the
    technicalities can be abstracted away, such that
    developers can interface with a rather simple API to build
    scalable decentralized applications based on the Raiden.

    What is the Raiden Network?


    The Raiden Network is an off-chain scaling solution for performing ERC20-compliant token transfers on the Ethereum blockchain. It is Ethereum's version of Bitcoin's Lightning Network, enabling near-instant, low-fee, scalable, and privacy-preserving payments.

    The Raiden Network allows secure transfers of tokens between participants without the need for global consensus. This is achieved using digitally signed and hash-locked transfers, called balance proofs, fully collateralized by previously setup on-chain deposits. This concept, illustrated in figure 1, is known as payment channel technology. Payment channels allow for practically unlimited, bidirectional transfers between two participants, as long as the net sum of their transfers does not exceed the deposited tokens. These transfers can be performed instantaneously and without any involvement of the actual blockchain itself, except for an initial one-time on-chain creation and an eventual closing of the channel.

    Figure 1: Simple Bidirectional Payment Channel

    A Raiden balance proof is a binding agreement enforced by the Ethereum blockchain. Digital signatures make sure that neither party can back out of any of the value transfers contained therein, as long as at least one of the participants decides to present it to the blockchain. Since nobody else other than the two participants has access to the tokens deposited in the payment channel's smart contract, a Raiden balance proof is as binding as an on-chain transaction.

    The true strength of Raiden lies in its network protocol. Since opening and closing a payment channel between two peers still requires on-chain transactions, creating channels between all possible peers becomes infeasible. As it turns out, however, you do not need a direct payment channel between a payer and a payee if there exists at least one route through a network of channels that connects the two parties, as shown in figure 2. This network and its associated protocol for routing and interlocking channel transfers is called the Raiden Network.

    Figure 2: Payment Channel Network

    In addition, payment channel transfers, in contrast to on-chain transactions, do not require any fees. Intermediaries within the greater network, however, will want to charge fees on a low percentage basis for providing their own channels to the network, leading to complex routing and a competitive channel fee market. The Raiden protocol aims to facilitate this market by using both protocol-level features and optional auxiliary services.

    Benefits of the Raiden Network

    Any transaction on the Ethereum blockchain comes at a cost depending on the transaction's required computational resources. Accordingly, fees are largely independent of the actual amount of value transferred, be it ERC20 tokens or Ether itself. This makes on-chain transactions best-suited for medium to large value transfers, but less so for transactions on the scale of a few dollars or even fractions of a cent.

    It does not matter whether a transfer is sent in one piece or split over thousands of micropayments. Hardly any transfer is too small to be sent efficiently over the Raiden Network.

    Raiden transfers are also instant, in the sense that as soon as you receive an off-chain Raiden transfer, you can rest assured that the transferred value now belongs to you. In contrast, confirmation of on-chain transfers depends on block time and the time it takes miners to pick your transaction from the pool of pending transactions. Instead of waiting for the next blocks to confirm a transaction, with Raiden transfers you can send, receive, and confirm transfers as fast as sending a chat message over the internet.

    Next to fees, blockchains also have another inherent problem that Raiden helps to solve: scalability. Capacity of most of the current blockchains is capped at a fixed or semi-fixed limit, regardless of the size of the userbase. In stark contrast, capacity of the Raiden Network scales linearly with the number of users, leading to an efficient and future-proof, decentralized transfer network.

    Limitations of the Raiden Network

    The answer to the question of whether you should use a Raiden token transfer rather than an on-chain transaction is actually just this: "why not?". There are, however, use cases where an on-chain transaction is a significantly better choice than a Raiden transfer.

    Raiden transfers require some of your tokens to be locked up in a smart contract for the lifetime of the payment channel. Similarly to only withdrawing small amounts of money from an ATM, you would not want to lock up too much value in a payment channel. Once you withdraw money from an ATM, you cannot use it for anything else, like online payments or wire transfers. Likewise, and since each participant in the network will likely have multiple channels open at the same time, payment channel deposits are expected to be comparatively small, making it difficult to transfer large amounts of tokens over the network of channels.

    Large value transfers should still be performed on the blockchain itself to save the extra cost of channel lifetime management and to avoid the need for routing through mostly inadequately equipped payment channels.

    How it works

    Lifecycle of a Raiden channel

    In order to ensure that participants pay their debts, tokens have to be locked up as security in a smart contract for the lifetime of the payment channel. This deposit ensures that tokens can only be used to send and receive tokens to and from the channel partner until the channel is finally closed by either participant, preventing both from double-spending their tokens to other peers. The process of managing a Raiden channel is shown in figure 3.

    Once a channel is created, participants may issue what can be considered certified checks freely back and forth. Instead of keeping track of all checks, however, each peer only keeps a copy of the latest one. The balance proof contains the final sum of all Raiden transfers sent to a participant up to a certain point, digitally signed by the sender. Since each channel has two participants, it always maintains two of those and together they are essentially the channel's bar tab if you will. Multiple credits are exchanged back and forth, changing the total amount owed between the participants, possibly even rebalancing the channel many times in the process.

    Figure 3: Lifecycle of a Raiden Payment Channel

    Finally, when one party decides to settle the balance on the blockchain, either to claim or pay their outstanding balance, they can close the channel at any time by presenting their balance proof of choice to the smart contract. The other participant -- the one that did not choose to close the channel -- must now present a balance proof of their own or do nothing if they received no transfers. After both parties have submitted their balance proofs, they may now withdraw their deposits. This withdrawal may be triggered by anyone, including addresses other than the two participants.

    If the second participant fails to present their balance proof in time, balances will be distributed according to the closing participant's proof, assuming that the other participant has not received any transfers. This way, Raiden asserts that each payment channel participant always has access to their funds.

    Need for a network

    As mentioned in the introduction, creation and settlement of payment channels have to be performed on the blockchain. Accordingly, it would be unreasonable, infeasible even, to create a new channel per potential target. Instead, Raiden creates a network of channels in which each participant is transitively connected to everybody else through a web of payment channels.

    Let us say Alice wants to send tokens to David, as illustrated in figure 4. She first has to find a route through the network that connects her to David. Then, each participant along that path has to cooperate in order to funnel the payment through the route from Alice to David. Participants lend their own channels to Alice by forwarding the payment to the next hop in the path. A cryptographic hash lock prevents all of these intermediate transfers to be credited until David confirms to Alice that he received the payment. Once Alice decides to unlock the payments, she gives the key to the lock to David. If David now wants to claim the payment without closing the channel, he has to pass the key on to the last mediating peer in the route who in turn needs to pass it on to claim their own payment.

    Figure 4: Multihop Transfer

    Since each participant on that route has an incentive to unlock their incoming payment immediately, the key naturally propagates backward through the channel route, back to Alice. All locked transfers are redeemable on-chain using Alice's secret. It is, however, preferable for the participants to consolidate the locked transfers' values into a standard balance proof. Accordingly, after receiving the secret, each sender of an intermediate transfer signs a new balance proof that includes the locked transfer's value and invalidates the lock itself, cleanly synchronizing the channel state. The multihop transfer is now complete.

    Likely, peers in the network will not provide their channels to be used as intermediaries for free. After all, transfers will cause additional network traffic and imbalances in their payment channels. To that effect, participants in the Raiden network are expected to demand fees to be compensated for lending their channels to the network. These fees may also be used to incentivize rebalancing of unbalanced payment channels, enabling long-lived payment channels.

    Since the resulting fee market will be competitive and actual processing costs will be rather low, fees are expected to be orders of magnitude lower than those of on-chain transactions.


    Since most of the Raiden protocol is performed off-chain, transfers are largely private. Channel balances are hidden from the public until participants settle and withdraw their funds and the net channel balance is revealed. When they do however, channel balances may have already been obfuscated by other intermediary transfers that passed through this and other channels connected to the same nodes, making it extremely difficult to trace back on-chain transactions to off-chain Raiden transfers. Users might even offer paid services to artificially rebalance and obfuscate channel balances in order to increase the level of privacy. On the messaging layer, Raiden will make sure to protect traffic and sensitive data transmitted over the network. The messaging service will hide participants' IP addresses from the public, preventing arbitrary nodes from being subject to DoS attacks. Additionally, pre-computed routes may use an onion routing protocol where intermediary nodes participating in a transfer have no way of knowing the target address of a Raiden transfer. The protocol only reveals the next channel in the route to each participant.

    Raiden Specification


    This document, just like the Raiden protocol is a constant work in progress

    Raiden is a payment network built on top of the ethereum network. The goal of the Raiden project is to provide an easy to use conduit for off-chain payments without the need of trust among the involved parties.

    While there are plans to extend Raiden to generalized state channels and channels with multiple parties, this documentation concerns only off-chain payment channels.

    How does the Raiden Network provide safety without trust?

    To achieve safety, all value transfers done off-chain must be backed up by value stored in the blockchain. Off-chain payments would be susceptible to double spending if that was not the case. The payment channel is represented in the blockchain by a smart contract which:

    • Provides shared rules, agreed up-front by both parties, for the channel’s operation.
    • Holds the token value in escrow to back the off-chain payments.
    • Arbitrates disputes using rules that cannot be abused by one party.

    Given the above properties Raiden can safely do off-chain value transfers, knowing that once a dispute happens the smart contract can be used to settle and withdraw the token.

    The Netting Channel Smart Contract

    The netting channel smart contract is the executable code that contains the shared rules for operating an off-chain payment channel. These rules are implicitly agreed upon by each participant whenever a channel is used. The netting channel allows for:

    • A large number of bidirectional value transfers among the channel participants.
    • Conditional value transfers that have an expiration and predefined rules to withdraw.
    • Rules to determine ordering of transfers.

    Each netting channel backs a bi-directional off-chain payment channel. They deal with a predetermined token and each has its own settlement period configuration. Any of the two participants may deposit any number of times, any amount of the specified token.

    Transfers may be conditionally finalized, meaning that at any given point in time there may be multiple in-flight transfers waiting to be completed. These transfers are represented by lock structures that contain a token amount, expiration, and hashlock. The set of all pending transfers is encoded in a merkle tree and represented in each transfer by its root.

    The channel capacity is equal to the total deposits by both participants. The capacity is both the largest value a transfer may have and the total amount of token in pending transfers. The capacity is divided as available and locked balance to each participant/direction. The available balances vary during the lifetime of the channel depending on the direction and value of the completed transfers. It can be increased either by a participant’s deposit or by a counterparty’s payment. The locked balance depends on the direction and value of the pending locked transfers. It is increased with each locked transfer and decreased when the transfer is finalized, successfully or otherwise.

    A channel’s life cycle

    1. Deployment
    2. Funding / Usage
    3. Close
    4. Settle

    After being deployed the channel may receive multiple deposits from either participant. Once the counterparty acknowledges it, the depositor may do transfers with the available balance.

    Once either party wants to withdraw their tokens or a dispute arises the channel must be closed. After the close function is called the settlement window opens. Within the settlement window both participants must update the counterparty state and withdraw the unlocked locks. A party can not perform a partial withdrawal.

    The updateTransfer() function call receives a signed balance proof which contains an envelope with channel specific data. These are the merkletree roottransferred amount, and a nonce. Since a node can only provide a signed message from the counterparty we know the data wasn’t tampered with and that it is valid. To disincentivize a node from providing an older message, withdraw balances are netted from the transferred amount, a monotonically increasing value. As a consequence there are no negative value transfers and if a participant provides an older message the wrongdoer’s netted balance will end up being smaller.

    Another netting channel operation is the lock withdrawal. It receives an unlock proof composed of the lock data structure, a proof that this lock was contained in the merkle tree and the secret that unlocks it. The channel validates the lock, checks the containment proof by recomputing the merkle tree root and checks the secret. If all checks pass the transferred amount of the counterparty is increased.

    Balance Proofs

    The netting channel requires a balance proof containing the information to properly settle. These are:

    • A nonce
    • The transferred amount
    • The root node of the pending locks merkle tree
    • A signature containing all the above

    For this reason each transfer must be encoded as a balance proof, this follows from the fact that transfer messages change the node balance and must be provable to the netting channel.

    Raiden Transfers

    Transfers in Raiden come in three different flavors.

    Direct Transfers

    A DirectTransfer does not rely on locks to complete. It is automatically completed once the network packet is sent off. Since Raiden runs on top of an asynchronous network that can not guarantee delivery, transfers can not be completed atomically. The main points to consider about direct transfers are the following:

    • The messages are not locked, meaning the envelope transferred_amount is incremented and the message may be used to withdraw the token. This means that a payerpayee to complete the goods transaction.
    • The sender must assume the transfer is completed once the message is sent to the network, there is no workaround. The acknowledgement in this case is only used as a synchronization primitive, the payer will only know about the transfer once the message is received.

    A succesfull direct transfer involves only 2 messages. The direct transfer message and an ACK. For an Alice - Bob example:

    • Alice wants to transfer n tokens to Bob.
    • Alice creates a new transfer with.
      • transferred_amount = current_value + n
      • locksroot = current_locksroot_value
      • nonce = current_value + 1
    • Alice signs the transfer and sends it to Bob and at this point should consider the transfer complete.

    Mediated Transfers

    A MediatedTransferhashlock used to verify the secret that unlocks it, and a lock expiration to determine its validity.

    Mediated transfers have an initiatortarget and a number of hops in between. The number of hops can also be zero as these transfers can also be sent to a direct partner. Assuming N number of hops a mediated transfer will require 6N + 8 messages to complete. These are:

    • N + 1 mediated or refund messages
    • 1 secret request
    • N + 1 secret reveal
    • N + 1 secret
    • 3N + 4 ACK

    For the simplest Alice - Bob example:

    • Alice wants to transfer n tokens to Bob.
    • Alice creates a new transfer with:
      • transferred_amount = current_value
      • lock = Lock(n, hash(secret), expiration)
      • locksroot = updated value containing  the lock
      • nonce = current_value + 1
    • Alice signs the transfer and sends it to Bob.
    • Bob requests the secret that can be used for withdrawing the transfer by sending a SecretRequestRevealSecret to Bob and at this point she must assume the transfer is complete.
    • Bob receives the secret and at this point has effectively secured the transfer of n tokens to his side.
    • Bob sends a secret message back to Alice to inform her that the secret is known and acts as a request for off-chain synchronization.
    • Finally Alice sends a secret message to Bob. This acts also as a synchronization message informing Bob that the lock will be removed from the merkle tree and that the transferred_amount and locksroot values are updated.

    Refund Transfers

    A RefundTransfer is a mediated transfer used in the special circumstance of when a node cannot make forward progress, and a routing backtrack must be done.

    Third parties

    Third parties are required to provide for safe operation. Since a single node cannot be expected to have 100% up-time, third parties are required to operate the netting channels for the period of time the node is offline.

    The purpose of a third party is to update the netting channel during settlement on behalf of a participant. For this reason Raiden must be configured to keep the third party up-to-date with its received transfers, locks, and secrets. If a channel is closed while this node is offline then the third party must be capable of calling updateTransfer/withdraw on its behalf.

    In order to avoid collusion among third parties and the channel counterparty and protect from DoS attacks, a node cannot rely on only a single third party. Given that a node relies on more than one third party, and that these services won’t have 100% uptime, out-of-sync third parties, that not always have the latest known balance proof, must be handled. The smart contract must have logic to totally order a stream of balance proofs from a single participant to do conflict resolution.

    Additional problems can arise with the usage of multiple third parties. Because third parties can easily be impersonated, penalization is not an option for netting channels. If a user is using too many third parties, once a channel is closed there could be a thundering herd problem.

    Mediating Transfers

    Raiden cannot rely on direct channels for most of its operations, especially if the majority of them are for target nodes that will only receive a transfer once. Mediated transfers are a form of value transfer that allows trustless cooperation among Raiden nodes to facilitate movement of value.

    Mediated transfers rely on locks for safety. Locks can be unlocked only by knowledge of the secret behind it. This information is used to determine whether a transfer was complete and is shared among all nodes in a mediation chain. The lock operation allows each participant to safely finalize their transfers without requiring trust.

    For a mediated transfer to work a number of nodes need to collaborate. Which nodes that would be is determined by the path, detailed in the transfer routing section.

    Let’s assume a path of Alice <-> Bob <-> Charlie. Alice does not have a direct channel with Charlie, therefore Alice can either open a new channel or mediate the transfer through other nodes. In our example Bob is a hop to whom Alice has an open channel and is considered good for routing.

    The role of Bob is to mediate the transfer between Alice, the initiator, and Charlie, the target. The number of nodes in a given path may vary but the roles and guarantees work the same way.

    Bob will first receive a mediated transfer t1 from Alice. This transfer is conditionally locked with a secret generated by Alice so it’s on Alice’s hand whether to finalize the transfer or not. The transfer sent by Alice is a valid balance proof, that may be used by Bob on-chain at any time to reclaim the current received amount and if the unlocking secret is learned, to also withdraw the pending transfer t1. Because Bob knows that he may claim the transfer value, and Bob has properly done all the validation checks to guarantee that the balance proof contains the correct transferred amount, the merkle root effectively represents all pending transfers, and Alice does have the available balance to use with the given transfer, Bob can safely forward the transfer.

    Bob will then create a new transfer t2, on the channel Bob <-> Charlie. t2 has its value backed up, since Bob is not the payer, by transfer t1. In the given example Alice is the payer to Bob, and Charlie is the payee to Bob. Note that in the case of an increased number of hops there will be more payer/payee pairs, one for each mediator. The transfer t2 will be another conditionally locked transfer, and the mediator is responsible to use the same lock amount and hashlock for this transfer.

    Once the transfer target has received the mediated transfer it will request from the initiator the secret to unlock the transfer. At this point in time the initiator knows that some node will pay the target. The target informs the initiator about the received lock’s amount, token, and hashlock, so it can be sure that it’s the correct transfer. Now the initiator Alice is at the position of completing the transfer by revealing the secret to Charlie.

    Once the secret is known by the target the payments flow from the back to the front of the payment chain. That means they start at Charlie who will request a withdrawal from Bob, informing Bob about the known secret, allowing Bob to request a withdrawal from Alice.

    Alternative Protocol Implementation

    There is nothing about the way that locks operate that forbids transfer splitting, i.e.: a mediator doesn’t have enough capacity on a channel but it can forward the transfer to two or more channels that on aggregate have the correct amount. Although that scheme is possible, it is not currently considered because of some added complexity. The target node would either need to know the transfer id and amount prior to its start, or it would need to make multiple secret requests to the initiator, as new transfers with the same hashlock arrives, until the correct transfer amount is reached.


    A lock has two parts, an amount used to track how much token is being locked, and rules to define how it may be unlocked. The lock itself is independent from the channel or token associated with it. What binds the lock to a specific channel is the balance proof’s merkle tree.

    Raiden currently relies on hash time locks heavily. They are the essential ingredient for safe trustless mediated transfers. This kind of lock has two additional data attributes, a hash image and a expiration. The lock is unlocked if the preimage of the hash is revealed prior to its expiration. In raiden the preimage is called secret and its hash is called the hashlock. The secret is just 32 bytes of cryptographically secure random data. The hashlock can be the result of any cryptographically secure hash function but Raiden currently relies on the keccak hash function.

    With this lock construct it is possible to:

    • Mediate token transfers, by relying on the same hashlock but different expiration times.
    • Perform token swaps. Two mediated transfers for different tokens are made with the same hashlock and once the secret is revealed we end up having an atomic swap of the tokens.

    Alternative Protocol Implementation

    The preimage could be a hash of another structure, e.g. a written contract. This would bind the action of unlocking a lock release to a document.

    The lock could require two hashlocks to unlock. This construct if used in a proper order, would allow for receipts to be generated.

    The lock could require either of two hashlocks to unlock. This construct allows for safe refunds that don’t need to wait for the lock expiration.

    Safety of Mediated Transfers

    The safety of mediated transfers relies on two rules:

    • For a node to withdraw a lock it must reveal the secret.
    • The mediator must have time to withdraw the payer’s transfer after the payee withdrew the mediator’s transfer.

    The first is trivially achieved by allowing two forms of withdraw. A node may withdraw off-chain by exchanging the secret message and receiving a balance proof or on-chain by revealing the secret.

    The second is the mediator’s responsibility to choose a lock expiration for the payer transfer that in the worst case would allow him enough time to withdraw. The worst case is a withdraw on-chain that requires:

    • Learning about the secret from the payee withdrawal on-chain.
    • Closing the channel.
    • Updating the counter party transfer.
    • Withdrawing the lock on the closed channel.

    The number of blocks for the above is named reveal timeout.

    Alternative Protocol Implementation

    The reveal timeout is large because the blockchain can be congested due to large amount of traffic. This delays the processing of closing/withdraw transactions enough that token loss is possible. At the same time it is impossible to predict how long congestion would last. Ideally the smart contract would be able compute the unlock operations that could have been executed and count lock expiration to the available gas slots of the mined blocks.

    Failed Mediated Transfers

    Failed mediated transfers are defined as transfers for which the initiator does not reveal the secret making it impossible to withdraw the lock. This may happen for two reasons. Either the initiator didn’t receive a SecretRequest, or the initiator discarded the secret to retry the transfer with a different route.

    The initiator might not have received the SecretRequest for yet another set of reasons:

    • Connectivity problems between the initiator and the target.
    • The maximum number of hops was reached, the lock expiration cannot be further decremented so the last node is not willing to make progress.
    • Some byzantine node along the path is not proceeding with the protocol.

    For any of the above scenarios, each hop must hold the lock and wait until it expires before unlocking the token and letting the payer add it back to its available balance.

    Alternative Protocol Implementation

    Use a new lock type that can be withdrawn if any of two secrets is revealed. Each mediator sends the payee transfer with a controlled refund secret. If the next hop cannot proceed with the transfer it sends back a mediated transfer using the same refund hashlock. This allows the mediator controlling the refund secret to release both locks without a risk of double spending.

    Channel Closing and Settlement

    There are multiple reasons for which a channel might need to be closed:

    • The partner node might be misbehaving.
    • The channel owner might want to withdraw its token.
    • The partner node might become unresponsive and an unlocked transfer might be at risk of expiring.

    At any point in time any of the participants may close the smart contract. From the point the channel is closed and onwards transfers can not be done using the channel.

    Once the channel enters the settlement window the partner state can be updated by calling updateTransfer. After the partner state is updated by the participant, locks may be withdrawn. A withdraw checks the lock and updates the partner’s current transferred amount. This is safe since a participant is allowed to provide the partner state only once and neither the transferred amount nor the locksroot will change after that call.

    With third parties the process changes slightly. Since third parties are allowed to call updateTransfer multiple times, the transferred amount and locksroot must be reset each time a new transfer is provided and locks that have been withdrawn must be withdrawn again.

    Alternative Protocol Implementation

    The current implementation has a local unlock, meaning that the same hashlock may be provided multiple times, once for each mediator that is closing the channel. The sprites approach uses a global registry of known secrets and requires the secret to be unlocked only once. This saves the computation of the hash function for each additional withdraw.

    • Nodes don’t need to close the channel to unlock, since the secret can be registered with the secret manager.
    • Nodes doen’t need to care about learning the secret through the blockchain and reapplying it in their own channel.
    • It really simplifies thinking about lock expiration for refunds since the expiration has a fixed lower bound.

    Transfer Routing

    Routing is a hard problem and because of the lack of a global view Raiden has a graph search strategy. The packet routing may be looked at as an A* search, using the sorted path with capacity as an heuristic to do the packet routing.

    Consider the above graph where each graph node represents a raiden node, each edge an existing channel, arrows represent the direction of the transfers, solid lines the current searched space of the graph, dashed lines the rest of the path and the red line an exhausted/closed channel.

    The transfer initiator is A, the transfer target is G. A decides locally the first hop of the path. A’s choice is determined by what it thinks will be the path that can complete the transfer using the shortest path and sending the transfer to the first node in that path.

    B will mediate the transfer and do its own local path routing. It chose C, which in turn chose T. It turns out that both B and C made a suboptimal choice. T was not able to complete the transfer with its channel and will route the transfer through D. This will continue until either the transfer expires or the target is reached. Note that the transfer’s lock expiration is not the same as a protocol level TTL. This behaviour could improve if we add a TTL to protocol messages so that we can inform mediators that a transfer was discarded by the initiator and further tries will be futile.

    Each of these hops forwarded a MediatedTransfer paying fees and sending the transfer value to the next hop to mediate the transfer.

    Alternative Protocol Implementation

    Path finding services: Nodes may choose routing services to update with their current available balance, the routing services will charge a fee to the users to provide routes.

    Onion encryption: To improve anonymity, encryption may be used. The initiator will choose a path that cannot be changed during the transfer and onion encrypt the hops. Garbage of a variable length must be added to the end of the onion encrypted path to hide the path length.

    Merkle Tree

    The merkle tree data blocks are composed of the hashes of the locks. The unique purpose of the merkle tree is to have an O(log N) proof of containment and a constant O(1) storage requirement for the signed messages. The alternative is to have linear space O(n) for the signed messages by having a list of all the pending locks in each message.

    The merkle tree must have a deterministic order, that can be computed by any participant or the channel contract. The leaf nodes are defined to be in lexicographical order of the elements (lock hashes). For the other levels the interior nodes are also computed from the lexicographical order.

    Alternative Protocol Implementation

    Use time order for the leaves and lexicographical for the intermediary nodes. This will greatly improve insertion performance since only the rightmost side of the tree must be recomputed. It may also improve removals since the nodes to the left don’t need to be recomputed.

    Raiden Design Choices

    One Contract per Channel

    At the beginning Raiden was designed with simplicity in mind and the one contract per channel made the code simpler. We have plans to change to a single contract per token.

    Nodes can not Update their Own State

    This greatly reduces the possible interactions with the smart contract and effectively makes cheating impossible. Either party may only provide messages that contain an unforgeable signature.


    With the introduction of third parties this will no longer be true and the design will become more complex.

    Network Protocol Messages Must not have Inherited Trust

    We don’t support informational messages like TransferTimeout, TransferCancelled, nor messages that can lead to change of the channel state without some mechanism backed by the smart contract as this would imply trust between participants and open attack vectors.

    We also don’t support messages from nodes saying that something happened on the blockchain because that is both redundant and imply trust in the message.

    Invalid Messages can Happen

    Raiden is built on top of an asynchronous network and one may not trivially assume that things are globally ordered, so invalid messages cannot be naively assumed as an attack.

    The lack of synchronization messages is a security measure as seen in the above section. As a consequence there are race conditions. For example picture a fresh channel between Alice and Bob.

    • Alice deposits 10.
    • Alice sends a transfer of 5 to Bob.
    • Bob received the transfer, checks if Alice may spend this amount and it fails.
    • Bob polls the blockchain and learns about the ChannelDeposit event.

    This is fixed in the protocol layer with a retry mechanism. It assumes the partner node has a properly working ethereum client and that he is polling for events from the block.

    Hashlocks are not Transfer Identifiers

    Even though hashlocks are unique, this value is not used as an identifier because routing via a specific path may fail. The initiator is at a position where he may choose to discard a path and retry with a different first hop. For this reason hashlocks can change for the same payment and an additional field just for transfer identification is used.


    The Token Launch is Over

    The RDN tokens have now been distributed.


    What are RDN tokens and what can I do with them?

    The Project token (RDN) is a general purpose, decentralised cryptocurrency envisaged to be compatible with and used on the Raiden Network. Upon its generation, the Project Token can be used to create micropayment channels on µRaiden and perform payments over these channels. For more information on the RDN token, review the token contractsthis blogpost.

    What is the initial allocation of RDN tokens?

    A total (fixed) supply of 100,000,000 tokens will be generated which will be allocated as follows:

    • 50% Public auction
    • 34% Retained by brainbot labs Establishment (Raiden project lead)
    • 16% External development fund

    Learn more about the initial allocation of RDN tokens in this blogpost.

    What is the format of this launch?

    The launch will be facilitated via a same price Dutch auction and a fixed percentage of tokens are offered. Read this blogpost for more details.

    Why was the Dutch auction format chosen?

    A Dutch auction should allow everyone to participate without having to rush while offering certainty about the maximum total value of all tokens at the time of a bid. Everyone gets the same price at the end of the auction. Read this blogpost for more details.

    How to participate in the token launch?

    If you don’t meet the KYC threshold, participating in the token launch works by simply sending ETH to the auction address. The address is shown after accepting the Terms and Conditions. Check out the token launch instructions for details.

    Does one need to go through a KYC process?

    Only participants who intend to bid more than 2.5 ETH in total, need to go through the KYC process to get whitelisted. See the KYC FAQ for details.

    Which wallets are supported in the token launch?

    Generally, ERC-20 compliant wallets, which let you keep control over your private key should work. We have tested and successfully participated with the following wallets on the mainnet: Mist, MetaMask, MyEtherWallet, and Parity WebUI as well as the Foundation and the Gnosis multisig-wallets. We cannot, however, guarantee a similar successful result.

    When will I be able to access my tokens?

    You will be able to access your acquired tokens 7-10 days after the token launch has ended. RDN tokens will be credited at the address from which ETH was sent.

    How do I get the RDN Tokens 7-10 days after the end of the auction?

    The RDN Tokens will be distributed to the ETH address you bid with 7-10 days after the end of the auction.

    Can I bid multiple times from the same ETH address?

    Yes. You can bid multiple times from the same ETH address. If the sum of the bids exceeds 2.5 ETH, you will have to complete the KYC check.









  • Raiden Transport Explained

    The Raiden Network relies heavily on nodes being able to exchange messages in a timely manner in order to facilitate token transfers. Hence, the transport of these messages is a crucial component of the Raiden Network.

    In this blog post, we have a closer look at how the message transport currently works in the Raiden Network and which criteria need to be taken into account when choosing the right communication protocol for a payment channel network.

    Transport in Raiden - The Basics

    Token transfers in the Raiden Network are performed via multiple messages which are sent between the nodes. The information contained in a transfer comprises the recipient, the amount and several other pieces of information e.g. the token network, the blockchain and the smart contracts used. Importantly, these messages are signed, such that they can be used to prove balances on the blockchain.

    A single multi-hop transfer requires several messages to be exchanged between nodes

    Desirable properties of a transport layer

    The following non-functional requirements are most important while choosing a communication protocol for Raiden:

    • Accessibility: The protocol should be usable from a wide range of devices and network setups,e.g. being behind a NAT.
    • Scalability: not every node should need to see every message.
    • Speed: latency should be in sub-seconds.
    • Distributed setup: no single point of failure or censorship.

    The efficiency/privacy dilemma

    Currently, a tradeoff between efficiency and privacy (nobody is watching who is receiving and who is sending) in communication protocols is mostly inevitable.

    This dilemma can be described looking at passive protocols: Passive protocols (like @Whisper) feature high privacy by sending all messages encrypted to all nodes without stating who the receiver is. Every node then tries to decrypt the message using its private key. Only the recipient node’s private key will be able decrypt the message. This solution ensures high privacy, however it is not very scalable and has high latency.

    Comparing our initial handcrafted UDP based protocol vs. Matrix protocol

    Up to and including the testnet v0.3.0 release, Raiden used a UDP (User Datagram Protocol) based P2P protocol. With the testnet v0.4.0 Icalo release, we switched to Matrix instead.

    We initially chose UDP because of two big benefits: speed and simplicity. It’s biggest downside, however, is accessibility (NAT traversal issues) and reliability as well as the lack of a discovery protocol which preserves endpoint privacy.

    Due to the above mentioned difficulties, we started to look for alternative communication protocols and for the time being decided for Matrix.

    Introducing Matrix

    What is Matrix?

    “Matrix is an open standard for interoperable, decentralised, real-time communication over IP. It can be used to power Instant Messaging, VoIP/WebRTC signalling, Internet of Things communication — or anywhere you need a standard HTTP API for publishing and subscribing to data whilst tracking the conversation history.” [from]

    If you want to know more about Matrix, have a look at their FAQs or learn how to get started with Matrix.

    Why did we choose Matrix?

    Amongst the wide range of features and functionalities Matrix offers, we especially value the following:

    • Reliability of the transport compared with the former UDP based hotfix: The reliability of transport in Matrix is comparable to TCP. There are no issues with lost messages or retransmissions.
    • Out-of-the-box support for end-to-end encryption.
    • Communication is always initiated from the client to the server (HTTP long polling), which guarantees not running into NAT traversal issues.
    • Federated server set up: Matrix runs on a set of federated servers which allows for a decentralized setup if there are sufficient homeservers participating.
    • Message history: The Matrix server keeps a history of messages sent between peers. Making use of this feature could in theory allow offline messaging as well as other optimizations. This feature is currently not used by the Raiden Network, but could be helpful in the future.
    • Last but not least: Matrix is an open source project, just like we are! :-)

    What changed moving from UDP to Matrix?

    With the UDP transport we used to send binary messages, with Matrix we transitioned to a JSON encoded message format. The JSON format is easier to read and simplifies the debugging of message flows. Communication happens in dedicated channels between the nodes that can reside on multiple Matrix homeservers. This means that a participant’s endpoint is known to his selected homeserver, but kept secret from all other participants of the network.

    Matrix relies on a distributed server infrastructure. Who is running the Matrix servers for the Raiden Network?

    Currently, anyone can run a Matrix server for the Raiden Network. The specifications on how to configure and install the software and host a matrix homeserver can be found in the raiden-transport repository.

    A growing number of community members, projects and companies power the Raiden Network by providing Raiden Matrix homeservers.

    A special thanks goes out to DigitalVirtues, ExchangeUnion, KI decentralized and MyCrypto, who will support the Red Eyes launch of the Raiden Network by running Matrix homeservers for the Raiden Transport.

    How secure is Matrix?

    The communication between the Raiden nodes and the Matrix servers is protected via TLS. Chat rooms in Matrix are by default private and their contents are only visible to users invited to the respective room. Even server operators can’t join rooms they aren’t invited to. Of course a malicious server operator could employ other means to get access to message data. This can be mitigated by end-to-end encryption.

    Matrix supports secure end-to-end encryption using the Olm protocol. Supporting E2E encryption and Onion Routing could be future improvement possibilities which help to increase privacy.

    The future of P2P transports

    As mentioned earlier, there are some tradeoffs to be made when choosing a transport protocol. While Matrix might not be perfect, it’s our choice until P2P transports with better privacy and decentralization properties emerge, which don’t sacrifice our required scalability and latency properties. We will keep on investigating other options, e.g. we are curious how libp2p will evolve.

    With that being said, our transport layer is well decoupled from the core Raiden client so that Raiden might be based on a different transport in future. Currently, we see Matrix being the most viable solution for our needs.

    Special thanks to @ulope and @heikoheiko who have been interviewed for this blog post and Matrix for the support and open conversations!

    We hope you liked this short insight into how the transport layer works in the Raiden Network and are looking forward to sharing more of these deep dives with you in the coming blog posts.

    Which other components of the Raiden Network would you like to learn more about? Let us know by leaving a comment below and we’ll take your topic into account for one of our next blog posts.

    The Raiden Team

  • Raiden Network (RDN) Testing Micropayments

    The Raiden Network (RDN) is testing a micropayments solution called uRaiden on the Ethereum mainnet.

    Importantly, uRaiden could process micropayments in Ethereum-based tokens. Therefore, Uraiden could theoretically process micropayments made with tokens based on the ERC20 protocol. In detail, they design ERC20 protocol tokens for quick conversion into other cryptocurrencies.

    That is big news because most of the blockchain platforms and cryptocurrencies launched over the past two years use the ERC20 protocol. For example, Medium contributor AminCad estimated 91% of the total market cap on coinmarket.cap in January 2018 comprised ERC20 tokens.

    Read full here:

Looks like your connection to Cryptocentral was lost, please wait while we try to reconnect.