Greenlight

What Is Greenlight?

Greenlight is Blockstream's Lightning-as-a-Service platform that provisions and manages Core Lightning (CLN) nodes in the cloud on behalf of end users. Unlike custodial Lightning wallets where a provider holds both the node and the keys, Greenlight splits responsibility: Blockstream operates the node infrastructure (networking, database, backups, watchtowers), while the user's private keys remain exclusively on their device and never touch Blockstream's servers.

The service targets wallet developers and application builders who want to offer Lightning functionality without the complexity of running and maintaining node infrastructure. A Greenlight node can be registered in under one second and spins up in approximately 200 milliseconds, operating on demand and entering sleep mode when not processing payments.

This positions Greenlight between fully custodial solutions (where a provider controls everything) and fully self-hosted setups (where the user manages all infrastructure). The user gets the security of self-custody with the convenience of managed infrastructure.

How It Works

Greenlight's architecture builds on Core Lightning's modular design. In a standard CLN installation, a component called hsmd is the only module that ever touches cryptographic keys. Greenlight extracts this signing module and runs it on the user's device instead of on the server, creating a two-domain control model:

• User domain: controls the signer (holds private keys) and frontend applications
• Blockstream domain: runs the Lightning node, manages databases, backups, channel state, and watchtower services

When the cloud node needs to perform a signing operation (opening a channel, forwarding an HTLC, committing a new state), it sends the request to the signer running on the user's device. The signer validates the request, signs if it passes policy checks, and returns the signature. The node then broadcasts the signed transaction or updates the channel state.

Validating Lightning Signer (VLS)

The critical component that makes this model truly non-custodial is VLS, an open-source Rust library that powers the signer. A naive approach to remote signing would be "blind signing": the device signs whatever the node asks without checking whether the request is legitimate. This is effectively shared custody, because a compromised node with a blind signer can craft malicious transactions to steal funds.

VLS prevents this by independently validating every signing request:

1. It replays Lightning channel state before approving any operation
2. It checks protocol correctness: revoked state detection, HTLC verification, fee validation
3. It enforces customizable security policies on each signature request
4. It rejects any request that violates protocol rules or policy

This means even if Blockstream's infrastructure were fully compromised, an attacker could not steal user funds: the signer on the user's device would reject any malicious signing request. Greenlight reports zero funds lost to node compromise across its user base.

Authentication and Communication

All communication between clients and Greenlight's infrastructure uses gRPC with mutual TLS (mTLS) authentication. Each client receives its own identity consisting of a private key and certificate. The registration flow works as follows:

# Initialize signer with a 32-byte secret seed
signer = Signer(secret=seed, network="bitcoin", identity=tls_identity)

# Register a new node (returns node-specific credentials)
node = scheduler.register(signer)

# Or recover an existing node on a new device
node = scheduler.recover(signer)

# Node is now ready to process Lightning operations
info = node.get_info()

Multiple frontend applications (mobile, browser, desktop) can connect to a single Greenlight node simultaneously, though only one signer can be active at a time: the device holding the keys must be online for the node to process payments.

Developer Integration

Greenlight provides SDKs across multiple languages, making it accessible to most mobile and backend development teams:

• Rust: the primary gl-client crate and glcli command-line tool
• Python: gl-client-py with prebuilt binaries for macOS, Windows, and Linux
• Kotlin: Android integration
• Swift: iOS integration

For testing, the gl-testing library provides a complete mock environment so developers can build and test without hitting the production service. Developer access is managed through the Greenlight Developer Console for self-service certificate management and API key generation.

Breez SDK Integration

The Breez SDK offered a high-level integration layer on top of Greenlight that bundled together the signer, node provisioning, LSP channel management, and submarine swap functionality into a single SDK. This made it possible for wallet developers to integrate Lightning with minimal code. Relai, for instance, used the Breez SDK with Greenlight to onboard over 100,000 users to Lightning.

The Breez SDK Greenlight integration has since been deprecated in favor of newer SDK approaches, though the underlying Greenlight platform and its native SDKs remain actively maintained.

Comparison to Other Lightning Models

Greenlight occupies a specific point on the Lightning custody spectrum. Understanding where it sits relative to alternatives helps clarify its tradeoffs:

Compared to custodial Lightning Service Providers, Greenlight eliminates the single point of failure where a provider compromise means lost funds. Compared to self-hosted nodes (running LND or CLN on your own hardware), Greenlight eliminates the DevOps burden of keeping a node online, updated, and backed up.

For a deeper comparison of Lightning infrastructure approaches, see the Lightning Service Providers guide and the mobile wallet architecture overview.

Use Cases

Wallet Applications

The primary use case for Greenlight is powering non-custodial Lightning wallets. Instead of asking users to run their own node or trusting a custodian with their funds, wallet developers can provision a Greenlight node for each user. The wallet app runs the VLS signer locally, and users get the UX of a simple mobile wallet with the security guarantees of self-custody. Blockstream Green uses Greenlight for its own Lightning functionality.

Fintech and Payment Integration

Businesses that want to accept or send Lightning payments without operating node infrastructure can use Greenlight as their backend. The gRPC API integrates into existing payment stacks, and the on-demand node model means businesses only consume resources when actively processing transactions. The free tier supports up to 1,000 nodes, with enterprise plans available for larger deployments.

Rapid Prototyping

Developers building on Lightning can use Greenlight to skip the infrastructure setup phase entirely. A node registers in under a second, and the testing library provides a mock environment for development. This lowers the barrier to experimenting with Lightning features like keysend payments, BOLT12 offers, or hodl invoices.

Why It Matters

One of the biggest barriers to Lightning adoption is the operational complexity of running a node. Users must keep hardware online 24/7, manage channel liquidity, handle backups, and stay current with software updates. This complexity pushes most users toward custodial solutions, which defeats one of Bitcoin's core value propositions: self-custody.

Greenlight addresses this by decoupling key custody from node operations. Users who lack the technical ability or desire to run infrastructure can still hold their own keys and maintain sovereign control of their funds. For the broader Bitcoin ecosystem, this expands the set of users who can participate in Lightning non-custodially.

Layer 2 solutions like Greenlight, Lightning, and Spark each take different approaches to making Bitcoin more usable at scale. Greenlight focuses on reducing the infrastructure barrier for Lightning specifically, while Spark provides an entirely new layer with native self-custody and stablecoin support built in. Both reflect the same principle: users should not have to sacrifice custody for convenience.

Risks and Considerations

Privacy Tradeoffs

Because Blockstream operates the node, they have visibility into transaction metadata: invoices, payment amounts, channel counterparties, and routing information. This is a meaningful tradeoff compared to running your own node where no third party sees your activity. Blockstream has acknowledged this and has been working on encrypting invoice details and routing payments as onions to reduce their visibility, but users should understand that Greenlight is not equivalent to a self-hosted node in terms of privacy.

Signer Availability

The user's device must be online and running the signer for the node to process payments. If the phone is off, in airplane mode, or the app is killed by the OS, the node cannot sign transactions. This creates a tension between the security model (keys on device) and the always-on nature of Lightning nodes. Incoming payments, channel state updates, and force-close responses all require the signer.

Vendor Dependency

While Greenlight supports offboarding (users can export their node and migrate to self-hosted CLN infrastructure), active use depends on Blockstream's infrastructure being available. If Blockstream discontinues the service or experiences prolonged outages, users need a migration path. The fact that Greenlight nodes run standard Core Lightning makes this migration technically straightforward, but it still represents a dependency.

Not for Routing Nodes

Greenlight is designed for endpoint and wallet nodes, not for routing node operators. Users who want to earn routing fees or provide inbound liquidity to the network should run their own dedicated node infrastructure instead.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.