Summary of Lightning Network news for the 1st week of January 2026, as well as late December 2025 (roughly December 15th 2025 to January 4th 2026).

Happy New Year! I hope you had some great time with family and friends (or just by yourself!) and feel ready for a new year of Lightning delicacies. Let's start now with a recap of a few things that caught my attention during the holiday season. As a reminder, this newsletter is non-exhaustive and opinionated, but feel free to poke me if you think I missed something important!

Public Network StatsPublic Network Stats

The Amboss team shared some statistics around the network evolution in 2025. To put it in a nutshell: many small, likely inactive channels were force-closed in the first half of 2025, while node operators leveraged the low on-chain fees environment to open bigger new channels during the second half of the year. This shows the maturation of Lightning with professional actors deploying infrastructure to accommodate even larger payments, leading to a new ATH in terms of public capacity (although this increase is very likely influenced by the decreased BTC/USD price, which compelled operators to increase capacity in order to keep USD-denominated capacity constant).

Verification of Lightning Network Channel Balances with Trusted Execution Environments (TEE)Verification of Lightning Network Channel Balances with Trusted Execution Environments (TEE)

In this paper published in December by Singh, Little, Hayes, Fang, Khanzadeh, Killeen and Abbassi (belonging to a variety of organizations, such as Bitcoin VC Stillmark, LN payment processor IBEX Mercado, Bitcoin proof-of-ownership service Hoseki and Lightning infrastructure provider Lexe) shared a novel mechanism by which a Lightning node operator could attest to its node balances. The goal is for an authorized Verifier to be able to query a proof of the current balance of a Lightning node.

This system would involve 2 main components: a Trusted Execution Environment (TEE), such as Intel SGX, on which the Lightning node (or parts of the Lightning node) runs ; and a TLS attestation scheme (the one suggested is zkTLS). The former would provide proof (an hardware attestation) that the balance was correctly computed by an unmodified version of the Lightning node software, while the latter would certify that the attestation was sent by a specific server at a specific time. However, as such this setup only attests to computation and delivery, which means it would still be possible to issue a fake balance report by feeding the node outdated data. To circumvent this, the paper proposes that the program running inside the enclave could make an additional call to an external provider to check the latest block hash. This external provider could be run by the Verifier itself.

Applications of such a system are typically liquidity marketplaces and credit issuance. In liquidity marketplaces, this would allow the marketplace to "automate the matching of liquidity buyers and sellers with cryptographic assurance of capacity" ; in credit markets this would allow lenders to assess a Lightning node's cash flow and solvency.

Ark As A Channel FactoryArk As A Channel Factory

Rene Pickhardt opened a discussion on Delving Bitcoin around the potential use of Ark for coordinating channel factories.

This builds on prior important work by Pickhardt which showed that payment feasibility on Lightning can be improved only through the addition/displacement of funds into/between channels, which requires an on-chain transaction. This limits Lightning's scaling potential (although we arguably still have a lot of room). A commonly explored idea to mitigate this is the use of channel factories where multiple users can coordinate to perform channel operations (e.g. opening, closing or resizing channels) off-chain. Here, Pickhardt discusses how Ark could be used as such, and compares it to the currently more commonly assumed use case of Ark for payments.

In Ark-based channel factories, each channel would be represented by a vTXO (virtual UTXO), and each round would be an opportunity for users to perform various operations on their Lightning channels inside the Ark. In effect, this would consolidate multiple channel operations into one single on-chain transaction. Such coordination is enabled by the Ark Service Provider (ASP), which commits its own funds in order to ensure each round can settle without all participants being online.

An aspect that crucially distinguishes this channel factory use case from the payments one is that it doesn't require instantaneity (i.e. it's ok if it happens in the next hour instead of right now). Payments on recent versions of the Ark protocol are conducted out-of-round, providing instantaneity whenever the user wants to transact but with the trade-off that until the newly created vTXO is refreshed in a round, the user must trust the ASP not to double spend it^[1]. In the channel factory use case, channel operations are conducted during rounds, meaning settlement is instantaneous. This means Ark could be used to conduct channel operations periodically, while instant payment would be conducted inside Lightning channels (with the instantaneity and trustlessness guarantees that Lightning brings).

Of course, there are still many challenges to overcome. Notably:

• building Lightning channels on top of Ark means such channels inherit the tradeoffs carried by Ark itself, especially when it comes to massive unilateral exit ;
• ASP liquidity requirements are quite significant, and increase as the time between rounds decreases (all things equal otherwise), meaning a trade-off must be struck between the frequency of channel updates (compared to 10 minutes on-chain block time) and the ASP viability^[2] ;
• Lightning's gossip currently requires public channels to be backed by an on-chain UTXO, meaning changes to the LN/gossip protocol would be required to include channels from the factory into the public graph. Interestingly, Gregory Sanders and Vincenzo Palazzo shared their respective work on Ark-based channels and highlighted that they considered them solely in a Lightning Service Provider (LSP) scenario, where only private channels are involved and gossip inclusion is hence out-of-scope^[3].

SweetsSweets

To conclude this issue, here are a few projects and releases I found interesting:

• Miguel Medeiros built a very good-looking dashboard for phoenixd ;
• Zeus v0.12.0 extends the wallet's Nostr Wallet Connect (NWC) capabilities: Zeus can now act as an NWC server that other apps connect to, on top of being an NWC client (since v0.10.0). This release also brings circular rebalancing, and changes the way Zeus generates invoices by default (Zeus used to default to creating "unified" invoices with both a Bolt11 invoice and an on-chain address, and will now only generate Bolt11 unless the user requests otherwise).

That's it for today! Thanks for reading this far and, as always, any feedback is greatly appreciated.

1. See this article for a more in-depth explanation, as well as how users can decide to refresh more or less early depending on their risk aversion. ↩

2. Lightning Node operators probably don't need to perform channel operations every ten minutes, but that's what the main chain currently allows. However, it makes sense that a channel factory settlement period be more than that of the main chain, since it can be considered as a batching mechanism, providing significant fee savings. ↩

3. LSPs are arguably a very good fit for channel factories, since they need to commit funds inside channels they share with their users without an accurate prior estimate of how much the user will use this liquidity. Ark-based factories would allow LSPs to more dynamically resize these channels, thus reducing capital cost (or transferring it to the ASP?). ↩