Lexe primary sources — 2026-05-02

Project status in this pass

• No canonical standalone whitepaper or litepaper surfaced.
• The clearest current source of truth is the official homepage, wallet docs overview, “How Lexe Works” and pricing pages, developer docs, the public monorepo README, the sidecar README, and the public SECURITY.md.
• The materials consistently frame Lexe as a hosted-but-noncustodial Lightning wallet and node platform built around secure enclaves, reproducible builds, remote attestation, and developer integration surfaces.

Primary-source snapshots

1) Homepage

• URL: https://www.lexe.app/
• Key excerpt:
  • The homepage calls Lexe a next-generation Lightning stack with “self-custodial, always-online nodes in secure hardware.”
  • It says Lexe keeps nodes online for free, supports 24/7 settlement even when the phone is offline, and positions the product as both end-user wallet infrastructure and a developer integration surface.
  • It also claims keys are managed inside secure hardware that Lexe cannot access and points users to the public security model and open-source monorepo.

2) Wallet docs overview

• URL: https://docs.lexe.app/
• Key excerpt:
  • The wallet docs overview calls Lexe a “next-generation self-custodial Lightning wallet with free node hosting and reliable 24/7 payments.”
  • It distinguishes between wallet/product docs and separate developer docs at docs.lexe.tech.

3) How Lexe Works

• URL: https://docs.lexe.app/how-lexe-works/
• Key excerpt:
  • This page says Lexe addresses the reliability-versus-self-custody tradeoff by running the user’s Lightning node on Lexe’s servers while keeping the user’s private keys inside secure enclaves.
  • It highlights three verification layers: open-source code, reproducible builds, and remote attestation before the phone shares keys with the enclave.
  • It also says users retain unilateral recovery and can close channels plus move funds even if Lexe disappears, using encrypted backup data stored in the user’s own Google account and an open-source recovery tool.

4) Fees and pricing

• URL: https://docs.lexe.app/fees-and-pricing/
• Key excerpt:
  • The pricing page says node hosting is free, with percentage-based payment routing/receiving fees.
  • It explains Lexe’s LSP role, inbound liquidity allocation, and the automatic opening of inbound/JIT channels when incoming payments require more capacity.
  • Future pricing is tied to actual liquidity usage and on-chain costs rather than a recurring infrastructure subscription.

5) Developer docs overview

• URL: https://docs.lexe.tech/
• Key excerpt:
  • The developer docs say Lexe supports a CLI plus Python, Rust, and Sidecar SDKs.
  • The docs frame Lexe as an integration surface for Lightning payments and payouts, not just a consumer wallet.

6) Sidecar docs / sidecar README

• URLs:
  • https://docs.lexe.tech/sidecar/
  • https://raw.githubusercontent.com/lexe-app/lexe-sidecar-sdk/master/README.md
• Key excerpt:
  • The sidecar materials say lexe-sidecar runs a local webserver on http://localhost:5393 and proxies REST requests to the user’s Lexe node.
  • Example endpoints include node_info, create_invoice, pay_invoice, and payment lookup routes.
  • The README says apps in any language can control a self-custodial, always-online Lexe node this way, and documents both app-linked client credentials and root-seed-based auth.

7) Python SDK quickstart

• URL: https://docs.lexe.tech/python/quickstart/
• Key excerpt:
  • The quickstart says backend developers can create a root seed, sign up a user, provision the node, and then manage invoices and Lightning payments programmatically.
  • It explicitly says each user gets a self-custodial Lightning node running in a secure enclave.

8) Public monorepo README

• URL: https://raw.githubusercontent.com/lexe-app/lexe-public/master/README.md
• Key excerpt:
  • The README describes Lexe as a “managed, non-custodial Lightning node and wallet based on Intel SGX.”
  • It identifies major components including an LDK-based Lightning node, BDK wallet support, Fortanix EDP integration, SGX remote-attestation code, and reproducible build tooling.
  • It also documents how users can independently reproduce the user-node enclave build and verify the enclave measurement used in production.

9) SECURITY.md

• URL: https://raw.githubusercontent.com/lexe-app/lexe-public/master/SECURITY.md
• Key excerpt:
  • The security model explicitly considers rogue employees with cloud and software-signing access, not just ordinary remote attackers.
  • It says code integrity is enforced through reproducible builds and remote attestation, with the attestation quote embedded in the TLS certificate used before secret provisioning.
  • It explains how the root seed is provisioned into the enclave, sealed to CPU/measurement-specific hardware, and protected behind authenticated reverse-proxy access plus inner and outer TLS layers.

Working conclusion

Lexe is best cataloged as secure-enclave-hosted, non-custodial Lightning wallet and node infrastructure with both consumer and developer-facing control planes. The decisive evidence in this pass was the repeated combination of (1) always-online cloud-hosted user nodes, (2) enclave-based key isolation backed by reproducible builds and remote attestation, (3) unilateral recovery outside Lexe’s cooperation, and (4) real SDK/CLI/sidecar surfaces that let apps treat Lexe as programmable Lightning infrastructure rather than only a mobile wallet.