lexe-company-primary-sources-2026-08-10

Lexe company-boundary primary sources — 2026-08-10

Why this addendum exists

• The older lexe-primary-sources-2026-05-02.md note already captured the product and architecture story.
• This addendum is narrower: it isolates the operator / company boundary around Lexe where hosted node infrastructure, LSP policy, fee setting, metadata visibility, credential issuance, and the privacy / support shell become the practical control surface.
• No separate legal-entity string was obvious in the materials surfaced during this pass, but the named operator behind lexe.app, docs.lexe.app, docs.lexe.tech, and the lexe-app GitHub organization is still a useful company-layer boundary for analysis.

Primary-source snapshots

1) Homepage

• URL: https://www.lexe.app/
• Key excerpt:
  • The homepage markets Lexe as self-custodial, always-online nodes in secure hardware and says Lexe keeps the node online for free while charging routing / receiving fees.
  • It also says the node runs in secure hardware that Lexe cannot access and points users to the public security model.
  • This is the clearest first-party statement that Lexe is not merely wallet software; it is a hosted operator shell around the wallet and node lifecycle.

2) How Lexe Works

• URL: https://docs.lexe.app/how-lexe-works/
• Key excerpt:
  • The docs say the user’s Lightning node runs on Lexe’s servers in the cloud, always available to receive payments even when the phone is off.
  • They also say Lexe maintains the infrastructure while the enclave is the user’s sovereign domain, making the operator-versus-custody split explicit.
  • The page highlights remote attestation before key sharing plus unilateral recovery if Lexe disappears, which matters because the trust-minimizing posture is itself part of Lexe’s hosted operating model.

3) Fees and pricing

• URL: https://docs.lexe.app/fees-and-pricing/
• Key excerpt:
  • The pricing page says Lexe hosts the node for free, charges routing and receiving fees, and may change rates in the future.
  • It explicitly says the user’s node connects to the Lightning Network through Lexe’s LSP.
  • It also says Lexe allocates inbound liquidity, opens JIT / inbound channels when needed, fronts on-chain channel-opening costs, and later recovers those costs through channel and liquidity fees.
  • This is strong evidence that a named operator is making economic, routing, and liquidity-policy decisions above the nominally self-custodial wallet.

4) Privacy policy

• URL: https://www.lexe.app/privacy-policy
• Key excerpt:
  • The privacy policy says account operation stores randomly generated authentication tokens, public keys, push notification tokens, and other technical material needed for service operation.
  • It says the backend stores limited payment metadata such as payment id and creation date, and that on-chain receives expose the Bitcoin txid.
  • It says Lexe collects node logs for diagnosis and performance work, observes Lightning payment value via the fees it charges, receives anonymized short route prefixes plus success/fail status, and may store or share data for legal, fraud, security, or technical reasons.
  • This is the clearest first-party statement that the operator boundary still matters even when keys remain outside Lexe’s reach.

5) 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 the main operator-facing components: enclave builds, attestation verification, reverse proxying, and the broader hosted node stack.

6) SECURITY.md

• URL: https://raw.githubusercontent.com/lexe-app/lexe-public/master/SECURITY.md
• Key excerpt:
  • SECURITY.md explicitly models rogue employees with cloud and software-signing access.
  • It says attestation quotes are embedded in the TLS certificate used before secret provisioning and describes the reverse-proxy and mutually authenticated access layers around the user node.
  • That makes the company boundary useful because release provenance, infrastructure honesty, and operator access controls are part of the product’s real security assumptions.

Working conclusion

Lexe deserves a separate company / operator note because the meaningful control surface is not just secure-enclave Lightning exists. It is that one named operator hosts the enclaved nodes, runs the LSP, sets fees and liquidity policy, collects limited metadata and logs, issues app/backend credentials, and controls the release, documentation, privacy, and support shell around a trust-minimizing but still centrally operated stack.