How it works

⚡ Lightning

Lightning fees are calculated using the following method:

The result is the average fee to travel through a route on the Lightning Network.

Fees on Lightning are computed differently from on-chain fees.
One of the primary differences is that the transaction size (in bytes transmitted through the network) is irrelevant.

They are composed of two components:

In addition, these fees are charged once per hop through a route, so the more hops a payment goes through, the more fees will be charged. Each intermediate node is free to choose its own fee policy.

Question: will I be charged the exact amount that is displayed on this website?
The answer is: it depends. The fees displayed on this website are averages of all public routes, for 1 hop. If your payment goes through just 1 hop, on a very average and typical route, it should be approximately the same amount. Although we can't predict how far you are from each destination you want to pay, so the more hops, the more fees.
Also, if you are connected to an expensive routing node, you might pay above-than-average rates.

Question: I have a direct channel to the payment recipient, what fees am I going to pay?
One word: ZERO :)
Direct payments do not incur any fee.


🔗 On-chain

Here is a quick summary of the method used to compute estimates. The algorithm uses a simplified model taking into account 3 factors:

Current weight of transactions in the mempool
Speed at which new weight is entering the mempool
Randomness in block production intervals

Unlike some other fee estimation algorithms, it doesn't look at the previous mined blocks at all. Instead, it looks at the factors that are going to drive the production of the next blocks: the mempool, the speed of increase of the mempool and the probability at which it is being drained.

Its goal is to give reasonable estimates given the presently known mempool dynamics, while avoiding overestimation.

Inputs

The mempool is categorized into "fee buckets". A bucket represents data about all transactions with a fee greater than or equal to some amount (in sat/vbyte).

Each bucket contains 2 numeric values:

For simplicity, transactions are not looked at individually. Focus is on the weight, like a fluid flowing from bucket to bucket.

Computations

For each target interval (30 mins, 1 hour, 2 hours etc...), we're trying to find the cheapest fee rate that is likely to become fully cleared (0 WU) with a given probability.

The probability is defined by the "confidence" setting on the website. Current values are:

Now let's simulate what's going to happen during each timespan lasting minutes:

The cheapest bucket whose final_weight is ≤ 0 is going to be the one selected as the estimate.

Small correction

Because the window used to sample the flow of transactions increases proportionally to each target interval, it sometimes gives incoherent results with estimates that decrease then increase as the window gets larger (if there was significant variations in the flow of transactions during this time).

Since this makes no sense (if a low fee gets you confirmed faster, then there is no need to increase the fee to target a longer window), so for each estimate we take the minimum value of all estimates at windows shorter or equal.


Icons by FontAwesome (cc-by-4.0)