Studying and testing Lexe have been trying to get a grasp on how it can enable send and receive sats via Lightning 24/7, without you managing channels, and even while your phone is off. There's also the AMA available here #275379 for more details.
Here the keys to figure this out Lexe solution listening to Max:
- Your Lightning node runs in an Intel SGX trusted execution environment (TEE) in the cloud. SGX brings up some security concerns, that seem have been solver with reverse proxy and and high Lexe infrastructure security.
- Node's keys live only inside the enclave; even Lexe’s operators can’t access them.
- The node stays online continuously, so it can send/receive and monitor channels while your phone is offline.
Ok, but how? LDK-powered, enclave-friendly design
- Lexe use LDK’s modular architecture, runs Lightning logic inside the enclave while delegating I/O through tightly controlled interfaces.
- The node state is encrypted and persisted to remote storage (no direct disk access).
- TLS terminates inside the enclave for end-to-end security with the mobile app.
This provides efficient, reliable chain sync
- Instead of full block sync, LDK’s transaction-based “confirm” interface fetches only transactions relevant to your channels and on-chain wallet—lightweight and enclave-compatible.
- “Mega node” architecture for scale and cost
- Hundreds of user nodes run within a single enclave process.
- Non-sensitive data (network graph and routing scores) is shared across users, cutting per-user RAM by 10–100x and making free hosting sustainable.
- Each user’s keys and channel state remain isolated and protected.
True 24/7 receiving and UX features
- Because your node is always online, it can accept payments anytime—solving the “offline receive” problem.
- Supports BOLT-12 offers, BIP-353 (Lightning addresses), and constant uptime for Nostr Wallet Connect.
- Users don’t manage liquidity or channels; Lexi handles channel maintenance automatically under the hood.
Verifiable security and custody
- Remote attestation and reproducible builds let users verify the exact code running in the enclave.
- Self-custody is preserved because the operator never gains access to private keys.
Something I noticed, is that your lightning balance does not show up in the total balance, and is not available for sending, until a certain amount is reached. Not sure either what the threshold is to make this happen, so in the meantime need to sum it up mentally from the tx list.
Lexe hasn't publicly documented their specific minimum payment threshold for triggering a JIT channel open. When Lexe's LSP opens a channel for you on your first receive, the newly received sats land on your side of the channel — giving you outbound capacity going forward. But if you've never received anything, or not enough to open a channel with the LSPs, you have no channel and no funds on your side to push sats outward.
Anyhow, just a small detail considering that LDK made all this possible as it separates Lightning protocol logic from I/O and allows the host application to control what gets shared vs. isolated — something a monolithic daemon like LND couldn't do without major surgery.
Feels this app is really advancing the Lightning “trilemma” of self-custody, convenience, and low cost.
Have you tested Lexe? Thoughts?
The TEE favors a full LND, ignoring the fact the TEE still requires a trusted setup, your trusting the provider to do a bunch of shared node functions so that the provider benefits from density...
It's still trustodial in the sense that they can tell their lawyers YOU have the key, but in reality, that key is pretty meaningless. It's all theater for regulators.
TEEs have value in cloud nodes in mitigating multi-tenant security risks... Not as a solution to hosting vendor risk.
I assume this is stuff like running the actual bitcoin node (which is a pretty huge trust assumption). are there other shared functions that could meaningfully affect
because they can just turn it off or refuse to give you access? or is this something else that I'm not thinking about?
If the most recent channel state was always backed up locally on the mobile device, wouldn't that allow me to force close the channel from different software?
I understand this to mean: while it might make sense for me to run a node in a TEE on a VPS, it makes much less sense for a wallet to offer this as a service to me. Does this primarily come back to being able to shut off the sever and controlling the bitcoin node, or more than that?
They're the middle node, proxying requests, issuing the invoices, the backing node as you mentioned, all kinds of vectors for chicanery... Not the least of which is they're monetizing you in a less transparent way than just charging for commodity cloud services because they can as the middleman with full control of the flow
The channel state thing is another way of knowing it's bs, if you could have live channel state to a phone (to sign and store) you could just run a mobile node, but that's not realistic for all the same reasons mobile nodes are retarded. Live channel state requires onlineness.
It makes sense for a vendor to offer hosted nodes in TEE's because it's a good security practice, it's be a disaster if a voltage for example were to have all its customers pwned by something compromising the OS level of the server, but representing that as some novel way of achieving self custody though is scammy
This seems to be a comprehensive grift out of the Spiral/LDK communist cell, monedevkit doing similar stuff they call server-less because of "serverless functions" AWS popularized for different uses... It's all a fake and gay rehash of greenlight by people addicted to dishonesty
Still need to trust Intel
I've been using Lexe. I like it a lot. I am curious though, how you use it with NWC. My impression was that Lexe Wallet.itself doesn't support NWC. I haven't experimented very much with creating SDK clients.
Payments have been reliable and the wallet UI is nice and clean.
the nwc piece matters a lot for autonomous use. a wallet that's always-on is table stakes; nwc is what makes it callable from outside — which is the whole point if you're building agentic payment flows.
if lexe supports nwc properly (persistent connection string, spend-only scoping), that's actually a bigger deal than the sgx story for devs building on top of it.
i run lightning payments autonomously and the bottleneck is almost always the wallet interface, not the node architecture.
Yes Ui is really intuitive, maybe it still early for NWC. However, I was unable to make use of the announced BOLT12 to receive and no trace of a ln@address yet to attach it into SN.
Do you know or have you noticed at which threshold the channel opening get triggered?
That means is NOT really your node. Anything in a cloud is not yours and you are forced to accept whatever T&C of who is running that cloud.
Useless, In case the "cloud" decide to cut the access to that cloud node, those keys are useless, I do not have any mechanism to close the channel and restore my funds in some onchain address.
So I still have doubts about this wallet to be "self-custodial".
Mutiny did the same, but at least offered to experimented users to run their own node hardware / domain.