Cowrie Research

lexe

5 min read

Lexe

  • Name: Lexe
  • URL: https://www.lexe.app/
  • Category: hosted self-custodial Lightning backend / secure-enclave wallet-node infrastructure / developer SDK stack
  • Tags: bitcoin-ecosystem
  • Summary: Lexe is the serious hosted-self-custody Lightning backend in this branch. The point is the tradeoff: always-on cloud nodes, SGX attestation before key provisioning, reproducible builds, and a recovery path if Lexe disappears. Strong trust-minimizing engineering, still a hosted operator stack and not magic. Keep this note on the product and architecture surface; the named operator boundary around hosted nodes, LSP policy, metadata visibility, fee-setting, and the privacy / support shell now lives separately in lexe.
  • 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

  • Company boundary for hosted-node operation, LSP policy, metadata visibility, fee-setting, and the wider privacy / support shell: lexe.
  • Closest hosted-but-self-custodial Lightning backend comparison: greenlight
  • Self-hosted counterpoint for operators who want the packaged backend without enclave-hosted infrastructure: phoenixd

Protocol / company boundary

  • Keep this note on the product and architecture surface: secure enclaves, remote attestation, unilateral recovery, sidecar and SDK workflow, and the way Lexe packages always-online self-custodial Lightning access for users and developers.
  • Use lexe when the useful question is who hosts the nodes, runs the LSP path, sets routing and liquidity economics, collects operational metadata, and controls the release / docs / privacy shell around that stack.
  • That split matters because how does Lexe's enclave-based Lightning stack work? and which operator controls the easiest hosted path around that stack? are related but not identical questions.

Control surface

  • Practical leverage sits in SGX trust and attestation assumptions, SDK and sidecar defaults, recovery-data workflow, hosted liquidity policy, and how much the payment path still depends on Lexe-operated infrastructure staying honest and online.

  • Keep the company shell visible too: lexe is where hosted node admission, LSP economics, metadata and log retention, and the privacy / support perimeter become the main analytical object.

  • Read it as trust-minimized hosted backend infrastructure, not as a neutral node host or wallet primitive.

  • Last reviewed: 2026-08-10 UTC

Graph View

Backlinks