Lexe: 4th Gen Lightning Infrastructure

Bitcoin Magazine Print Edition

By Max Fang

This article was printed in the 2025 Lightning Issue of Bitcoin Magazine.

The Lightning Network has been in production since 2018—seven years. Lightning has all the properties we want for Bitcoin payments: instant settlement, low fees, self-custodial. Many Bitcoiners who followed Lightning since the early days would have predicted that in 2025, Lightning adoption would be a lot larger than it is. So why hasn't it taken off?

As a refresher, the Lightning Network is a layer-2 on top of Bitcoin which allows for instant, low-fee Bitcoin payments while remaining self-custodial at all times. The core innovation of the Lightning protocol is the payment channel, which allows the vast majority of transactions between participants to be made off-chain, meaning they don't need to be included in the Bitcoin blockchain. Participants in the Lightning Network must run a Lightning node and open channels with other users in order to send and receive payments.

The first three generations of Lightning

To better understand where Lightning stands today, we must recall the history of Lightning and examine how Lightning usage has changed over time.

The first generation of Lightning was based on self-hosting Lightning nodes at home. The earliest users of LND or core-lightning had to run their Lightning nodes via the command line. Lightning users would run a Bitcoin Core or btcd full node, then run lnd or lightningd on top, using the Bitcoin full node as the source of blockchain data. This meant Lightning was only available to technical users, so people worked to make this process easier. Early efforts include Pierre Rochard's node launcher, which could run a Lightning node on a desktop computer in one click, and Jack Mallers' Zap desktop wallet. In 2020, Umbrel built an operating system for Raspberry Pis which included Bitcoin Core and LND by default, so anyone could run a Bitcoin and Lightning node at home with zero configuration, minimal technical skill, and about \$300 in hardware investment. Enthusiasts willing to put in the time and money to run Lightning nodes at home greatly contributed to the early growth of the Lightning Network.

The second generation of Lightning moved to mobile wallets with LSPs. Self-hosting a Lightning node at home still required users to manage their channels with other Lightning nodes. Getting inbound liquidity—capacity for receiving payments—was especially difficult. Wallets like Breez and Phoenix saw the shortcomings of the home-hosting approach and pioneered the LSP model, where Lightning Service Providers would serve as the primary channel counterparty for end users running Lightning nodes on their mobile phones and act as the gateway to the broader Lightning Network. This was a critical breakthrough, as users didn't have to do any Lightning configuration themselves, and acquiring inbound liquidity was as simple as tapping a few buttons within the app. Lightning looked promising—it was fast, cheap, and easy to use. Mobile Lightning wallets allowed Lightning to reach over 100,000 end users.

The third generation of Lightning products were custodial. People started using Lightning for payments in earnest—both online and in person. With innovations such as the Lightning Address, receivers could post a string which resembles an email—for example, satoshin@gmx.com—and senders could pay to the Lightning Address, as long as the sender's wallet supported it. Receivers quickly discovered, however, that they would miss payments whenever their Lightning wallet app wasn't open and running in the foreground of their phone. Breez and Phoenix tried to work around this by using push notifications to wake the mobile Lightning nodes in order to receive payments, which helped, but payments were still unreliable: they would fail if the user's phone was in power-saving mode, had bad reception, or was off the grid. The offline receive problem became a major UX hurdle.

As a result, many users who needed to receive payments 24/7—for example, those accepting Zaps on Nostr or receiving donations for open-source Bitcoin work—started switching to custodial alternatives. Products like Strike and Wallet of Satoshi accepted payments for users around the clock to their company Lightning node and simply updated internal ledgers to track each user's balance. Products like Voltage and Alby Hub offered node hosting services for a fixed monthly cost—but user keys would live in memory on company servers, meaning any server administrator could run a single command (sudo /proc/<pid>/mem) to gain access to their users' keys.

These products were a step forward from a UX perspective—uptime was reliable and payments could be made to the custodial provider at any time. But this was also a step backwards—users had to sacrifice their self-sovereignty in exchange for a better UX. Only a small minority of people—those willing to invest in home server hardware and time to manage channels and liquidity—would go back to the first-generation approach: self-custodial Lightning nodes hosted at home.

Lexe's approach: The 4th generation of Lightning?

Lexe takes a new approach to Lightning that promises to fix the technical problems holding Lightning back from broader adoption. Like first-generation Lightning, Lexe is self-custodial. Like second-generation Lightning, Lexe provides an LSP and spares users from configuring their node or managing channels and liquidity. Like third-generation Lightning, Lexe users can receive payments 24/7. Sounds great—but how?

The key innovation: Lexe runs Lightning nodes on behalf of users inside hardware enclaves in the cloud. Programs inside secure enclaves are isolated from the rest of the system's hardware and software, including the rest of the CPU, the operating system, and server administrators. This means Lexe can run users' Lightning nodes without access to the users' keys, because the keys are protected by the enclave's isolation guarantees. Lexe users can use an app on their phone to securely control their Lexe node in the cloud.

How is Lexe self-custodial?

There are a few questions about how Lexe is actually self-custodial. For instance, how do we know that Lexe's node software doesn't have any backdoors that would allow Lexe to extract users' keys? To address this, Lexe's node software is open-source and published on GitHub. If Lexe tried to slip in a backdoor, it could be exposed by code review.

Once we establish that the node's source code is secure, how do we know that the binary running inside the enclave was compiled from that source? Lexe's node binary has a reproducible build: anyone can clone Lexe's repository, compile the source locally, and compare the resulting binary to the published node binary to verify they match.

Lastly, how do we know the enclave is running the verified node binary? This is done through remote attestation, where the enclave produces a hardware-backed proof that it's running a particular program. A key fused into the CPU, inaccessible to server administrators, signs this proof. The proof is transmitted to the end user, and the user's mobile client verifies it before sharing sensitive information—such as the user's root seed—over an end-to-end encrypted channel that terminates inside the enclave.

Lexe gives Lightning a chance

The result is a self-custodial, always-online Lightning node and wallet where users can send and receive payments 24/7. Lexe hosts users' nodes for free, so the only costs for Lexe users are Lightning routing fees and payments for inbound liquidity. With Lexe's wallet, we have a Lightning product that can compete with custodial providers on both UX and cost, while adhering to the Bitcoin ethos of preserving self-custody.

We return once again to the question: "Why hasn't Lightning taken off yet, in 2025?" Lexe's thesis is that Lightning has never had a fair chance. Whether it's the hassle of running your own node, the offline receive problem, or the loss of self-sovereignty, Lightning users have always had to give something up to access the payment network that promised to bring Bitcoin to the masses. With Lexe's approach, Lightning now has a chance: no more major technical roadblocks to providing a seamless UX. If more companies develop similar innovations or build on Lexe itself, our collective efforts could help establish Lightning as the primary payment rail for a hyperbitcoinized future.