Raiden Pathfinding Service


A path finding service having a global view on a token network can provide suitable payment paths for Raiden nodes. Raiden nodes can request paths via public endpoints and pay per request. The service will keep its view on the token network updated by listening to blockchain events and a public matrix room where balance proofs and fees are being published. Nodes will publish their current balance proofs and fees in order to advertise their channels to become mediators.

Implementation Process and Assumptions

  • The path finding service will be implemented iteratively adding more complexity on every step.
  • There are three steps planned - (1) Pathfinding Minimal Viable Product, (2) Adding service fees, (3) Handling mediation fees.
  • It should be able to handle a similar amount of active nodes as currently present in Ethereum (~20,000).
  • Nodes are incentivized to publicly report their current balances and fees to “advertise” their channels.
  • Uncooperative nodes are dropped on the Raiden-level protocol, so paths provided by the service can be expected to work most of the time.
  • User experience should be simple and free for sparse users with optional premium fee schedules for heavy users.
  • No guarantees are or can be made about the feasibility of the path with respect to node uptime or neutrality.


A node can request a list of possible paths from start point to endpoint for a given transfer value. The get_paths method implements the canonical Dijkstra algorithm to return a given number of paths for a mediated transfer of a given value. The design regards the Raiden network as an unidirectional weighted graph, where the weights of the edges/channels are the sum of multiple penalty terms:

  • a base weight of 1 per edge, to incentivize short paths
  • a term proportional to the mediations fees for that channel
  • if the edge is included in a route, all following routes will get a penalty if they include the same edge. This increases the diversity of routes and reduces the likelihood that multiple routes fail due to the same problem.

See Routing Preferences for information on how to configure the trade-off between these penalties.

Public Interfaces

The path finding service needs three public interfaces

  • a public endpoint for path requests by Raiden nodes
  • an endpoint to get updates from blockchain events
  • an endpoint to get updates about current balances and fees

Public Endpoints

A path finding service must provide the following endpoints. The interface has to be versioned.

The examples provided for each of the endpoints is for communication with a REST endpoint.

POST api/v1/<token_network_address>/paths

The method will do max_paths iterations of Dijkstras algorithm on the last-known state of the Raiden Network (regarded as directed weighted graph) to return max_paths different paths for a mediated transfer of value.

  • Checks if an edge (i.e. a channel) has capacity > value, else ignores it.
  • Applies on the fly changes to the graph’s weights - depends on DIVERSITY_PEN_DEFAULT from config, to penalize edges which are part of a path that is returned already.

The arguments are POSTed as a JSON object.

Field Name Field Type Description
token_network_address address The token network address for which the paths are requested.
from address The address of the payment initiator.
to address The address of the payment target.
value int The amount of token to be sent.
max_paths int The maximum number of paths returned.
iou object IOU object as described in Communication between client and PFS to pay the service fee
diversity_penalty float (optional) Routing penalty per channel that is reused across multiple different routes returned in the same response.
fee_penalty float (optional) Penalty applied to a channel for requiring 1 RDN as mediation fee.

A list of path objects. A path object consists of the following information:

Field Name Field Type Description
path List[address] An ordered list of the addresses that make up the payment path.
estimated_fee int An estimate of the fees required for that path.
Routing Preferences

The PFS will search for routes that are:

  • short
  • cheap
  • diverse (using different channels for different routes when multiple routes are returned)

Since these goals can be conflicting, a trade-off between them has to be chosen. This is done by assigning a penalty to all undesired properties of a channel, summing up these penalties across all channels used in a route and then choosing the route with the lowest total penalty.

When requesting a route, the calculated penalties depend on the diversity_penalty and fee_penalty parameters. If those parameters are omitted, reasonable defaults are chosen. A diversity_penalty of 5 means that a channel which has already been used in previous route is as bad as adding 5 more channels to the path which have not been used, yet. A fee_penalty of 100 means that spending 1 RDN is as bad as adding 100 more channels to the route (or that spending 0.01 RDN is as bad as adding one more channel).


Each error consists of three parts:

  • errors: a human readable error message
  • error_code: a machine readable identifier for the type of error
  • error_details: additional information on the failure, e.g. values that caused the failure or expected input values (can be empty for some errors)

Please have a look at the full list of errors.

// Request
curl -X POST --header 'Content-Type: application/json' --data '{
    "from": "0xalice",
    "to": "0xbob",
    "value": 45,
    "max_paths": 10
// Result for success
    "result": [
        "path": ["0xalice", "0xcharlie", "0xbob"],
        "path": ["0xalice", "0xeve", "0xdave", "0xbob"]
// Wrong IOU signature
    'errors': 'The signature did not match the signed content',
    'error_code': 2001,
// Missing `amount` in IOU
    'errors': 'Request parameter failed validation. See `error_details`.',
    'error_code': 2000,
    'error_details': {'iou': {'amount': ['Missing data for required field.']}}

GET api/v1/info

Request price and path information on how and how much to pay the service for additional path requests. The service is paid in RDN tokens, so they payer might need to open an additional channel in the RDN token network.


A JSON object with at least the following properties:

Field Name Field Type Description
price_info int Amount of RDN per request expected by the PFS
network_info.chain_id int The chain ID for the network this PFS works on

chain ID:

// Request
curl -X GET --data '{
    "rdn_source_addressfrom": "0xrdn_alice",
}'  api/v1/info

// Result for success
    "price_info": 0,
    "network_info": {
        "chain_id": 3,
        "registry_address": "0x4a6E1fe3dB979e600712E269b26207c49FEe116E"
    "version": "0.0.1",

GET api/v1/<token_network_address>/payment/iou

Request the last IOU used by sender to pay the PFS. This IOU can be used by the client to generate the next IOU to pay the PFS by increasing the amount and updating the signature.

Field Name Field Type Description
sender address Sender of the payment (Ethereum address of client)
receiver address Receiver of the payment (Ethereum address of PFS)
timestamp string Current UTC date and time in ISO 8601 format (e.g. 2019-02-25T12:53:16Z)
signature bytes Signature over the other three arguments [1]

The signature is calculated by

                  sha3_keccak("\x19Ethereum Signed Message:\n[LENGTH]"
                              || sender || receiver || timestamp ))

A JSON object with a single property:

Field Name Field Type Description
last_iou object IOU object as described in Communication between client and PFS

Network Topology Updates

The creation of new token networks can be followed by listening for: - TokenNetworkCreated events on the TokenNetworksRegistry contract.

To learn about updates of the network topology of a token network the PFS must listen for the following events:

  • ChannelOpenened: Update the network to include the new channel
  • ChannelClosed: Remove the channel from the network

Additionally it must listen to the ChannelNewDeposit event in order to learn about new deposits.

Balance and Fee Updates (Graph Weights)

Updates for channel balances and fees are published over a public matrix room. Path finding services can pick these balance proofs from there and update the topology represented internally. The Raiden nodes that want to earn fees mediating payments would be incentivized to publish their balance proofs in order to provide a path.

Balance Update

Balance Updates are messages that the Raiden client broadcasts to Pathfinding Services in order to let them know about updated channel balances.

Field Name Field Type Description
chain_id uint256 Chain identifier as defined in EIP155
token_network_identifier address Address of the TokenNetwork contract
channel_identifier uint256 Channel identifier inside the TokenNetwork contract
updating_participant address Channel participant who sends the balance update
other_participant address Channel participant who doesn’t send the balance update
updating_nonce uint256 Strictly monotonic value used to order transfers. The nonce starts at 1
other_nonce uint256 Strictly monotonic value used to order transfers. The nonce starts at 1
updating_capacity uint256 Available capacity for the participant sending the update
other_capacity uint256 Available capacity for the participant not sending the update
reveal_timeout uint256 Reveal timeout of this channel
signature bytes Elliptic Curve 256k1 signature on the above data


The signature of the message is calculated by:

ecdsa_recoverable(privkey, sha3_keccak(chain_id || token_network_address || channel_identifier || updating_participant || other_participant || updating_nonce || other_nonce || updating_capacity || other_capacity || reveal_timeout))

All of this fields are required. The Pathfinding Service MUST perform verification of these data, namely channel existence. A Pathfinding service SHOULD accept the message if and only if the sender of the message is same as the sender address recovered from the signature.

Future Work

The methods will be rate-limited in a configurable way. If the rate limit is exceeded, clients can be required to pay the path-finding service with RDN tokens via the Raiden Network. The required path for this payment will be provided by the service for free. This enables a simple user experience for light users without the need for additional on-chain transactions for channel creations or payments, while at the same time monetizing extensive use of the API.