Next Steps for Node Rates

After over a month of feedback from Twitter and in person at the recent BitBlockBoom conference in Dallas, I wanted to put a quick list of actionable items together regarding time value calculations and LNRR (Lightning Network Reference Rate). If you haven’t had the chance yet, please check out my articles “The Time Value of Bitcoin” and “The Bitcoin Risk Spectrum” to catch up on what LNRR is and why bitcoin needs it to achieve reserve currency status.

I’ve had excellent and informative conversations with many bitcoiners that want to see these ideas progress. I am also happy to announce that developers have already started experimenting with calculation methods using their Lightning nodes as a testing ground. I like to remind my audience that I don’t have a coding background, so help from the developer community is essential to further these ideas. We are trying to build bitcoin-native capital markets from first principles, using some examples from traditional finance but mostly originating new capital market theory. Here are possible next steps toward building an on-chain interest rate framework:

1) Decide whether to calculate interest at the individual HTLC level, at the payment channel level, or at the Lightning node level (I tend to favor the node level but the process might be easier at the HTLC level to begin).

2) Start experimenting with calculation methods for individual channels and nodes using different combinations of the three variables (principal, income, and block time).

3) For the principal component, should we calculate bitcoin staked to channels at the start of the contract? An average through time?

4) For the fee component, are we to include the on-chain miner fees paid to open and close payment channels? (I believe we probably shouldn’t, in order to isolate the Lightning Network’s internal economics).

5) For the time component, should we calculate interest one block at a time? The timelock of each HTLC? What about using difficulty adjustment periods of 2,016 blocks because the game theory of bitcoin adjusts every time difficulty adjusts? Or perhaps some arbitrary time horizon? (I’m hesitant to suggest time that isn’t expressed in blocks).

6) Determine other interest rate calculation considerations, such as whether we should calculate in discrete or in continuous terms.

7) ***Determine if these three variables can actually be hashed together to cryptographically prove an interest rate earned.***

8) ***Identify more clearly the exact risks that a Lightning node operator is taking. I received a lot of feedback from Lightning developers on being more explicit about “channel state” risk, specifically the risk of timing the broadcast of an anti-cheat transaction versus action from a malicious counterparty.***

9) Refine my initial theory that Lightning doesn’t have counterparty risk but instead security risk and payment channel management risk. I like the new terms “channel state risk” and “malicious counterparty risk.”

10) Answer some questions about publishing a node’s interest rate, thinking from a privacy perspective. Should the publishing of Lightning realized interest rates be opt-in? (I believe so). If the data is able to be well-anonymized, is opt-in even necessary?

11) Should publishing be opt-in because it will only be used by larger capital providers, those that are hosting Lightning nodes in order to maximize fees due to superior payment channel management techniques? Consumers likely won’t be routing payments and therefore want to calculate interest earned, or will they?

12) Development process: should we try to implement an interest rate framework at the BOLT protocol level? Do we want to build a third layer protocol for the rules of a decentralized capital market? Or should this be carried out at the Lightning wallet provider level by private enterprise?

13) In later stages, we will be thinking about the reference rate, LNRR, which will be a synthesis of individual node rates. LNRR’s construction and calculation should be decentralized and transparent. (That’s why I believe protocol level implementation should be the goal, whether on Lightning/BOLT or a third layer on top of Lightning. A third layer is probably preferable in order to be conservative and not risk breaking anything in BOLT.)

14) More specifics of LNRR and the process of synthesizing nodes’ rates from all over the network can wait until we start experimenting with node level calculations.

Any and all feedback is welcome! Thanks to everybody who has reached out so far and has encouraged this type of experimentation. I look forward to hearing comments and critiques from you all as we progress these ideas forward.

Follow me at

Like what you read? Give Nik Bhatia a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.