Greenlight

• Name: Greenlight
• URL: https://blockstream.com/lightning/greenlight/
• Category: hosted non-custodial Lightning node infrastructure / Lightning-as-a-service / Core Lightning control plane / developer-facing wallet-node backend
• Tags: bitcoin-ecosystem
• Summary: Greenlight is best understood as a hosted-but-noncustodial Lightning control plane rather than a custodial wallet, simple payments API, or ordinary managed-node host. Its official materials describe Blockstream-operated Core Lightning infrastructure where the platform handles node scheduling, uptime, and operational hosting while user keys stay on the client side and apps interact with their nodes through gRPC, language bindings, and a signer model. The strongest categorization clue is the deliberate split between infrastructure management and key control: Greenlight provisions nodes on demand, but the client or signer retains the secrets needed to authorize fund movement, and users can eventually off-board their node to self-hosted infrastructure.
• What it does:
  • Lets developers provision hosted Lightning nodes for end users without running their own node fleet
  • Uses Core Lightning under the hood while exposing node control over gRPC plus protocol buffers and language bindings
  • Separates node scheduling/control from key management so apps can act as remote controls, key managers, or both
  • Uses mTLS identities, signer checks, and rune-based authorization concepts to authenticate clients and prevent infrastructure-side fund movement without client approval
  • Starts nodes on demand through a scheduler and can preempt idle nodes to conserve infrastructure resources
  • Supports custom liquidity-service-provider integration and explicitly allows users to off-board to self-hosted infrastructure rather than remaining in a closed platform
• Key claims:
  • Blockstream’s product page says keys stay on the user’s device and never touch Greenlight infrastructure, emphasizes automated NodeOps on Core Lightning, and positions Greenlight as a way to integrate Lightning with “just a few API calls”
  • The same page says users are not locked into the service and can “seamlessly off-board” their node to self-hosted infrastructure, which is a key clue that Greenlight is meant as hosted infrastructure rather than a custody moat
  • The documentation introduction calls Greenlight a Blockstream service offering “hosted, non-custodial, Lightning Network nodes” where Blockstream handles infrastructure while the user controls the keys
  • The getting-started docs say Greenlight provisions and manages Core Lightning nodes on behalf of users, exposes the Core Lightning gRPC interface without limitations, and uses a scheduler to start nodes on demand when clients need them
  • The repository README describes Greenlight as a “self-sovereign Lightning node in the cloud” and says it exposes scheduler and node services over gRPC so apps can register/recover accounts, schedule nodes, and interact with the running Core Lightning instance to send/receive payments and manage channels/liquidity
  • The same README explicitly defines two application roles: a remote-control role for interacting with the node and a key-manager role that holds the secrets needed to authorize actions
  • The security docs say each component has its own mTLS identity, private client keys are generated locally and never leave the client, and the signer independently checks that requests match authenticated client commands before signing them
  • Those security docs also say the design assumes even a rogue Greenlight operator or compromised node infrastructure should not be able to move funds without satisfying signer-level authorization checks
• Whitepaper: No canonical standalone Greenlight whitepaper or litepaper surfaced in this pass. The clearest current source of truth was the Blockstream product page, the official Greenlight docs, the repository README, and the security reference; see ../whitepapers/greenlight-primary-sources-2026-05-02.md.
• Sources:
  • https://blockstream.com/lightning/greenlight/
  • https://blockstream.github.io/greenlight/
  • https://blockstream.github.io/greenlight/getting-started/
  • https://blockstream.github.io/greenlight/reference/security/
  • https://raw.githubusercontent.com/Blockstream/greenlight/main/README.md

Internal linkages

• Closest hosted-but-self-custodial Lightning backend comparison: lexe
• Immediate implementation-family baseline beneath the service: core-lightning
• Self-hosted contrast for operators who want the packaged backend without Blockstream-run infrastructure: phoenixd

Governance / control risk

• Practical leverage accumulates around scheduler behavior, client-auth and signer policy, Blockstream-run operational defaults, LSP integration paths, and how easy off-boarding really is when an app has built itself around Greenlight’s service model.

• Last reviewed: 2026-05-26 UTC