Summary of Lightning Network news for the 2nd and 3rd week of January 2026 (January 5th 2026 to January 18th 2026).

Welcome to your "weekly" recap of the latest technical news in the Lightning ecosystem. Now, before you ask: no, you didn’t miss the last issue, I did. Let’s say that between work and personal matters, time fell short last week, and so I decided to postpone Latest Strikes to the next week (now!), covering the last 2 weeks.

Wallets & ToolsWallets & Tools

Machankura Self-Custodial AppMachankura Self-Custodial App

On January 3rd, Machankura released a build of their new self-custodial wallet to people in the Google Play waiting list. The team had announced this new app back in November 2025, giving more details into the tech stack it uses:

• Acinq’s lightning-kmp implementation (the same one that runs in Phoenix wallets) ;
• Lightning Service Provider (LSP) support.

A few things remain unclear (for instance, who will act as a LSP in the wallet) but it’s really great to see the Machankura team add a real self-custodial Lightning solution on top of their well-established custodial solution. The two seem highly complementary, with the custodial solution tailored for no-internet (GSM-only) feature phone usage leveraging the USSD protocol ; while the new self-custodial app can serve user with smartphones and reliable internet access.

TunnelSats v3TunnelSats v3

TunnelSats released the v3 of their Lightning node VPS service. The idea is to enable Lightning node operators to more easily expose their node to clearnet without revealing their IP address or having to open ports on their router. With the v3, TunnelSats users can now enjoy:

• a management API for automation,
• Nostr Wallet Connect for automatic renewal payment,
• new, enhanced scripts for installing and managing your VPN tunnel.

Another thing I really like about TunnelSats is how they openly provide the scripts for you to run on your node, instead of black-boxing them behind an interface. This way, users can audit and understand what’s happening, and it can even help them create their DIY solution if they want to take a leap at managing their own VPN server.

PolarPolar

The v4.0.0 release of regtest Lightning Network tool Polar was a huge one, bringing:

• LLMs agents control over local regtest network through the Polar MCP, enabling agents to manage the topology of networks, as well as payments ;
• support for automated simulations of realistic payment activity through the integration of the SimLN tool ;
• improved performance on ARM64 chips ;
• and the usual update to available nodes.

X Announcement

Implementations & SpecImplementations & Spec

Core Lightning ReleaseCore Lightning Release

Core Lightning v25.12.1 was released, notably continuing the integration of mnemonic-based (12 words) seeds into the implementation’s tooling. As a reminder, as of v25.12 new Core Lightning nodes are created using a 12 words seed phrase.

Accountability in EclairAccountability in Eclair

Eclair implemented accountability signal, replacing the previous endorsement mechanism as a mitigation against channel jamming.

Channel jamming is a problem that has been identified for quite a long time (see for example our early coverage on the matter here and there), where an attacker could at virtually no cost jam Lightning channels, i.e. block channels so that no payments can go through while the attack is ongoing. Such an attack is achieved by sending payments through the target channel(s) with no intention of ever settling them. There are 2 (porous) categories of jamming attacks:

• quick jamming, where the attacker sends a lot of payments through channels in order to exhaust the max limit of 483[1] simultaneous in-flight HTLCs in a channel ;
• slow jamming, where the attacker exhausts the liquidity of a channel by sending one or multiple payments that mobilize this liquidity and letting them expire, thus blocking the liquidity and rendering in usable for the processing of other payments until the expiration of the fake payments.

Jamming is fought through the combination of 3 mechanisms:

• a local reputation system, maintained by each node on its neighbors, keeping track of how well they behaved in the past (quick settlement, etc.) ;
• a signaling mechanism to "coordinate" reputation across the network (more on that later) ;
• the compartmentation of a channel’s liquidity into different buckets that can be used (or not) depending on the current liquidity congestion, received signal, and downstream node reputation.

Previous jamming mitigation mechanisms used an endorsement signal where a node extending an HTLC could signal to the next node whether they’re ready to have their reputation impacted by the behavior of the HTLC. Endorsed HTLCs coming from a peer with a good reputation would be allowed into the "protected" bucket, while others could only use resources (liquidity and HTLC slot) from the general bucket. The signal would propagate across a payment route: the sender would endorse the HTLC if they expect the payment to succeed quickly (i.e. they hold the final recipient and all the intermediate routing nodes to be honest actors), and each node along the way would endorse their forwarded HTLC if and only if the incoming HTLC was endorsed and the incoming peer has a good reputation.

However, some limitations were found in the context of a "attackathon", leading to the replacement of the endorsement signal with an accountability signal. Accountability goes the other way around: when offering an HTLC, the incoming peer flips the accountable flag to signal to the downstream forwarding node that their reputation will be affected by how quick this HTLC settles (ie, they will be held accountable). A node (Alice) would typically flip the accountable flag when forwarding the HTLC requires them to use resources outside of the general cluster, thus indicating to the next forwarding node (Bob) that their (Alice’s) resources are constrained (which might indicate an ongoing jamming attempt) and that they (Bob) should behave, or else risk their reputation being degraded. A node receiving an HTLC with the accountable flag enabled (such as Bob in our example) has incentives to give special treatment to this HTLC, provided the incoming node has a good reputation, thus extending it resources outside of the generic cluster and marking their own forwarded HTLC as accountable.

Channel (un)jamming is a fascinating topic, and I plan on releasing a more in depth article on its history, going into more technical details around the endorsement abandoned mechanism and the new accountability solution. I’ll link to it in an upcoming issue when it’s ready.

See also: Optech’s coverage in the newsletter and podcast.

ResearchResearch

Pickhardt PaperPickhardt Paper

Rene Pickhardt published a paper formalizing his work. I plan on doing a full article diving deeper in the paper, but the cusp of it is:

• given the network topology and channel depletion over time, some payments (and gradually more and more of them) become infeasible, and enabling them requires adjusting liquidity in channels through on-chain transactions (opening/closing channels, splicing, etc.) ;
• the need to come back on-chain puts a lower bond on Lightning’s transactional throughput ;
• channel factories would allow Lightning operators to alleviate channel operations costs and increase their frequency, lifting up this lower bond.

Thank you for your work Rene, enjoy your sabbatical!

See also: this StackerNews post giving a summary of the paper.

---

That’s it for this week! I hope you found this issue informative and, as always, please share any feedback you may have in the comments. See you next week!

This is a hard limit that rooter in rules limiting the size of on-chain Bitcoin transactions. In practice, Lightning implementations may default to using lower bonds.↩