Greenlight 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 Blockstream Greenlight product page, the official docs intro/getting-started/security pages, and the main repository README.
- The materials consistently frame Greenlight as hosted, non-custodial Core Lightning infrastructure with an explicit separation between infrastructure operations and key control.
Primary-source snapshots
1) Blockstream product page
- URL: https://blockstream.com/lightning/greenlight/
- Key excerpt:
- The page says keys are stored on the user’s device and never touch Greenlight infrastructure.
- It pitches “Automated NodeOps” on Core Lightning, says developers can integrate Lightning with just a few API calls, and highlights scaling to many users.
- It also says users are not trapped in a “walled garden” and can off-board their Greenlight node to self-hosted infrastructure.
2) Documentation introduction
- URL: https://blockstream.github.io/greenlight/
- Key excerpt:
- The docs intro calls Greenlight a Blockstream service offering hosted, non-custodial Lightning nodes to developers and end users.
- It says Blockstream handles the infrastructure while users remain in control of the keys.
- It also says the service is explicitly not trying to lock users into Blockstream infrastructure and intends to support off-boarding.
3) Getting-started overview
- URL: https://blockstream.github.io/greenlight/getting-started/
- Key excerpt:
- The overview says Greenlight provisions and manages Core Lightning nodes on behalf of users and exposes the Core Lightning gRPC interface “without limitations.”
- It describes two identity types: developer identities for node registration/recovery and device identities for authenticating apps to a specific node.
- It also introduces the signer and scheduler, explaining that nodes are scheduled on demand when clients need to talk to them.
4) Repository README
- URL: https://raw.githubusercontent.com/Blockstream/greenlight/main/README.md
- Key excerpt:
- The README calls Greenlight “your self-sovereign Lightning node in the cloud.”
- It says Greenlight exposes services over gRPC, including a scheduler for account registration/recovery and node scheduling, and a node service for interacting with the Core Lightning instance to send/receive payments and manage channels.
- It explicitly defines remote-control and key-manager application roles, reinforcing the split between interaction and authorization.
- The best-practices section says the 32-byte seed secret must remain on the user device and never be stored on the application server.
- It also documents operational behavior such as idle-node preemption and suggests long-lived gRPC connections to reduce mTLS handshake overhead.
5) Security reference
- URL: https://blockstream.github.io/greenlight/reference/security/
- Key excerpt:
- The security docs say every Greenlight component is identified by an mTLS keypair and the signer additionally has access to the Bitcoin keypair backing node identity and the on-chain wallet.
- They explicitly model an attacker with access to node infrastructure, including a rogue operator, and say the system is designed to prevent such an attacker from moving funds.
- The docs explain that client private keys are generated on the client and never leave it, while the signer independently verifies that pending RPC commands are valid, authenticated, and authorized before signing them.
- They also describe rune-based authorization for more granular command restrictions across different clients.
Working conclusion
Greenlight is best cataloged as a hosted non-custodial Lightning control plane built around Blockstream-managed Core Lightning infrastructure, scheduler-driven node lifecycle, and client-held signing authority. The crucial evidence in this pass was the repeated combination of (1) explicit client-side key custody, (2) a real remote-control plus signer architecture, and (3) on-demand node operations that make Greenlight much more than a generic API wrapper or managed-node host.