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 the hosted-Lightning product layer inside a wider Blockstream company shell. The split is the point: Blockstream runs the Core Lightning machinery, while the client-side signer keeps final spend authority. Real backend control plane, still a hosted operator stack and not magic.
• 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

• Broader operator boundary for the release, service, and enterprise packaging shell: blockstream.
• Strongest hosted-Lightning backend peer: phoenixd
• Immediate implementation-family baseline beneath the service: core-lightning

Protocol / company boundary

• Keep this note on the hosted product surface: Greenlight’s signer split, scheduler behavior, gRPC control plane, off-boarding path, and the concrete ways apps inherit a Blockstream-run Lightning backend without handing over spend authority.
• Use blockstream when the sharper question is who operates that hosted fleet, ships the release and support shell, sets service and auth defaults, and packages Greenlight alongside Core Lightning, Jade, and the rest of the wider company stack.
• That split matters because how does Greenlight work as a hosted self-custodial backend? and which company controls the operating and commercial shell around it? are related but not identical questions.

Control surface

• Practical leverage sits in scheduler behavior, client-auth and signer policy, Blockstream-run operating defaults, LSP integration paths, and how real off-boarding is once an app has wrapped itself around Greenlight’s service model.

• The wider reason this note stays separate from the company note is that Greenlight is one hosted service inside a broader Blockstream stack that also includes wallet firmware, consumer wallet defaults, Core Lightning stewardship, and Liquid-adjacent enterprise tooling.

• Read it as hosted self-custodial backend infrastructure over Core Lightning, not as a neutral commodity node host.

• Last reviewed: 2026-08-06 UTC