Cowrie Research

lexe

4 min read

Lexe

  • Name: Lexe
  • URL: https://www.lexe.app/
  • Category: hosted non-custodial Lightning wallet infrastructure / secure-enclave self-custody platform / developer-facing wallet-node SDK / Bitcoin Lightning payments control plane
  • Tags: bitcoin-ecosystem
  • Summary: Lexe is best understood as a hosted-but-noncustodial Lightning wallet and wallet-node control plane rather than a normal mobile wallet, simple managed-node host, or custodial payments API. Its official materials consistently describe an always-online user Lightning node running on Lexe’s cloud infrastructure inside Intel SGX secure enclaves, with open-source code, reproducible node builds, remote attestation before key provisioning, and unilateral recovery if Lexe disappears. The clearest categorization clue is that Lexe combines verifiable hardware-isolated key custody with app-facing SDKs, a local HTTP sidecar, and CLI flows that let developers and end users control self-custodial Lightning nodes without having to operate their own servers.
  • What it does:
    • Hosts a user’s Bitcoin-and-Lightning node in the cloud so it can receive and settle payments 24/7 even when the phone is offline
    • Uses secure enclaves for key handling and publishes open-source code plus reproducible builds so users can verify the node software Lexe runs
    • Performs remote attestation before provisioning secrets into the enclave and documents unilateral recovery using encrypted Google Drive backup data and an open-source recovery tool
    • Exposes developer integration surfaces through CLI, Python SDK, Rust SDK, and a Sidecar SDK that runs a local webserver proxying REST requests to the user’s Lexe node
    • Supports both app-linked client credentials and backend-managed root-seed flows, including programmatic wallet signup and provisioning from the Python SDK
    • Packages Lightning routing, inbound liquidity, JIT-style inbound channels, and 24/7 node hosting into one consumer-plus-developer operating layer
  • Key claims:
    • The homepage calls Lexe a “self-custodial, always-online” Bitcoin and Lightning wallet with free node hosting, 24/7 settlement, “infinite inbound liquidity,” open-source and reproducible node code, and keys managed inside secure hardware that Lexe cannot access
    • The wallet docs overview calls Lexe a “next-generation self-custodial Lightning wallet with free node hosting and reliable 24/7 payments” and points users to separate wallet and developer documentation portals
    • The “How Lexe Works” page says Lexe solves the reliability-versus-self-custody tradeoff by running the user’s Lightning node on Lexe’s servers while keeping private keys inside secure enclaves, with open-source code, reproducible builds, and remote attestation built into the mobile app before key sharing
    • That same page says users can recover funds even if Lexe shuts down by decrypting independently stored recovery data, closing channels on-chain, and moving Bitcoin elsewhere
    • The fees page says node hosting is free, routing/receiving fees are percentage based, and Lexe’s LSP allocates inbound liquidity and opens inbound channels when needed, with future liquidity/channel pricing tied to actual liquidity usage and on-chain costs
    • The developer docs overview says Lexe offers a CLI plus Python, Rust, and Sidecar SDKs for integrating Lightning payments and payouts into applications
    • The Sidecar docs and README say the lexe-sidecar binary runs a local webserver on http://localhost:5393 and lets apps in any language control a self-custodial, always-online Lexe node through REST endpoints like create_invoice, pay_invoice, and node_info
    • The Python quickstart says backend developers can generate root seeds, sign up users, provision enclaved nodes, and manage invoices/payments programmatically, framing each user as getting a self-custodial Lightning node running in a secure enclave
    • The public monorepo README describes Lexe as a “managed, non-custodial Lightning node and wallet based on Intel SGX,” identifies LDK-, BDK-, and Fortanix-based components, and highlights SGX remote attestation plus reproducible node builds
    • The SECURITY.md file explicitly models rogue employees and other attackers, says the user node build is reproducible, says remote attestation is embedded in the TLS certificate before secret provisioning, and says sealed root seeds plus inner/outer TLS and reverse-proxy auth protect user-node access
  • Whitepaper: No canonical standalone Lexe whitepaper or litepaper surfaced in this pass. The clearest current source of truth was the official homepage, wallet docs, developer docs, public monorepo README, and SECURITY.md; see ../whitepapers/lexe-primary-sources-2026-05-02.md.
  • Sources:

Internal linkages

  • Closest hosted-but-self-custodial Lightning backend comparison: greenlight
  • Self-hosted counterpoint for operators who want the packaged backend without enclave-hosted infrastructure: phoenixd

Governance / control risk

  • Practical leverage accumulates around enclave trust and attestation assumptions, SDK and sidecar defaults, recovery-data workflow, hosted liquidity policy, and how much of the user experience depends on Lexe-operated infrastructure staying honest and available.

  • Last reviewed: 2026-05-26 UTC

Graph View

Backlinks