Dynamic Mediation Fees in Raiden Explained
Raiden lets users pay anyone in the network by using a path of connected payment channels to mediate the payment. Mediating nodes, which are the nodes between the sender and the receiver on the selected payment path, can earn mediation fees.
The fee model for these kind of mediation fees can be designed in various ways and is usually influenced by a few parameters. Good mediation fee design can incentivize channel balancing and therefore may contribute to the health of a token network. Hence, defining the right mediation fee framework is an important aspect of a well functioning payment channel network.
In this blog post, we’ll have a closer look at how mediation fees are currently being implemented in the Raiden Network, how users can modify them according to their needs and which design criteria were taken into consideration.
Purpose of mediation fees
As outlined above, mediation fees can incentivize users to create and sustain a healthy network by participating in the mediation of transfers. Mediating transfers can allow users to cover (parts of their) cost of participating in the network and possibly even to make a profit.
Mediation fees can be divided up into two main component categories:
- Client specific (local) fee components, e. g. to cover the base cost of operational expenses, the cost of capital for locking tokens as channel deposit, as well as additional fees depending on the respective business model.
- Capacity component: Depending on the capacities of channels and the preferred channel balance distribution (outgoing channel vs. incoming channel), the respective client can incentivize certain mediated transfers over others.
Introducing the Raiden mediation fee framework
With this in mind, we have implemented the following framework for mediation fees:
- Although mediation fees are paid via the (outgoing) channel, over which a mediated payment is sent, fees should not be calculated taking into account the outgoing channel only, but should also consider the channel over which a payment is received (incoming channel).
- Therefore, the mediation fee (MF_total) is modeled as the sum of the contribution from the incoming channel fee (MF_in_channel) and the contribution from the outgoing channel fee (MF_out_channel):
- Each channel fee (MF_in_channel, MF_out_channel) is implemented as the sum of a flat fee, a fee proportional to the transaction size and an imbalance fee, the latter taking into consideration the preferred channel balance:
- The imbalance fee F, determined by the chosen Imbalance Penalty (IP), can be described by the following formula:
The IP is an arbitrarily chosen function that describes how much the mediator would be willing to pay to bring its channel into its most preferred state.
The framework will allow each client to set the constants (const_flat and const_prop) as well as to define the capacity dependent function IP for the incoming as well as outgoing channel according to its needs. Since F can be both positive or negative, it can be used as a tool to incentivize and even subsidize certain payments.
While setting constant parameters requires only single number input, the IP is represented as a set of X and Y values that are linearly interpolated.
Using this format for IP and the approach of deriving the actual values via linear interpolation enables the possibility for a wide range of different functions to be reflected.
In the current model, only mediating nodes can earn mediation fees. The payment initiator and target could theoretically also benefit if their IP was taken into account during routing, however this aspect is skipped for now to avoid additional complexity.
Initial implementation for the imbalance fee
In the initial implementation, the imbalance fee is described as a quadratic function which will favor having each channel in a “centered” state. We believe that this serves as a sensible default for most users and is a good placeholder until a wider variety of strategies is implemented.
As outlined above, the IP function describes how much a node is willing to pay (in absolute values) to move away from an undesirable channel capacity. If a node prefers to have a channel capacity of 5, while the total capacity of that channel is 10 (meaning it could mediate up to 5 tokens in both directions), the IP function might look like this:
When a transfer of three token changes the capacity from 6 to 9, then the imbalance fee will be calculated as
Please note, that instead of the quadratic function, any other function can theoretically be used at the discretion of the mediator without needing to conduct any changes to the protocol.
Configuring mediation fees in the Raiden client
By default all mediation fee components are turned off. They can be set by specifying the respective parameters on the command line (see also raiden-help):
- flat-fee: Flat fee required for every mediation in the smallest unit of the mediated token (e.g. wei for WETH).
- proportional-fee: Mediation fee as ratio of mediated amount in parts-per-million (10^-6).
- max-imbalance-fee: Sets the worst-case imbalance fee in the smallest unit of the mediated token. The max-imbalance-fee specifies the highest point inside the valid range for the quadratic function used for the imbalance penalty.
Setting different fees for different channels is currently not possible without modifying the code, but is fully supported on a protocol level, i.e. currently for one client the same set of parameters is applied for all channels.
Decision rationale behind the chosen mediation fee model
While flat and proportional fees are quite obvious and a commonly used approach to mediation fees, we didn’t just stop there.
The design goal was to use mediation fees as a tool to incentivize transfers that improve the overall network health. This can be achieved by offering lower fees to transfer that balance the involved channels.
To properly account for imbalance in all involved channels, we had to take into account both the incoming and outgoing channel for each mediating node. One node’s incoming channel is another node’s outgoing channel, but the nodes might have a different opinion on what a well-balanced channel is. Hence, relying on the counterparty to balance the channel does not work out in all cases.
We assume, that there is no objective way to say if a channel is balanced or imbalanced: A user who mainly sends payments with his channels and rarely receives might prefer a channel state that increases the capacity in his desired payment direction. Whereas a user running a node to profit as a mediator might prefer channels, that have a similar capacity in both directions. To handle these and other cases, we use the imbalance penalty (IP) function, which describes how much a node is willing to pay to get from the current channel state into their preferred one. For each transfer, we calculate IP(c_after) -IP(c_before) to get the incurred imbalance fee.
In the long run, the imbalance fee can be assumed to be a zero sum game per mediator: Looking at the entirety of payments, the imbalance part of the mediation fee doesn’t raise the overall cost since it, on average, should raise and lower the fees to the same degree. Hence, the sum of all transfers doesn’t get more expensive, nor cheaper through the introduction of the imbalance fee. However, it does change the fee distribution between all transfers, incentivizing transfers that improve the channel state, thus leading to a more preferable channel state on average.
The future of mediation fees
While it’s hard to make predictions, and mediation fees might vary as they depend on the topology and the actual payment routes in the respective networks, we hope that the above outlined mediation fee concept presents a reasonable approach, which can be adapted to specific requirements and changing circumstances.
The field of mediation fee design can be considered as ongoing R&D and we started with the simplest, yet, hopefully, economically sound, model. As always, we are open to talk and curious about integrating other models as they arise.
If you are interested in mediation fee research and different approaches in general, we recommend the following reading material:
- Network Fees in the Lightning Network by Chris Stewart
- Routing Fee Economics in the Lightning Network by BitMex research
Additionally, you can find all information about the Raiden mediation fee model outlined in greater detail in this ADR, or have a look at the code implementation.
We hope you liked this short insight into how the mediation fees will work in the Raiden Network. Which other components of the Raiden 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
Disclaimer: Please note, that even though we do our best to ensure the quality and accuracy of the information provided, this publication may contain views and opinions, errors and omissions for which the content creator(s) and any represented organization cannot be held liable.
The wording and concepts regarding financial terminology (e.g. “payments”, “checks”, “currency”, “transfer” [of value]) are exclusively used in an exemplary way to describe technological principles and do not necessarily conform to the real world or legal equivalents of these terms and concepts.
