Lightning Gateway

What Is a Lightning Gateway?

A Lightning gateway is a service that connects protocols operating outside the Lightning Network to Lightning's payment infrastructure. It allows users of systems like Fedimint federations, Cashu mints, or Spark to pay Lightning invoices and receive Lightning payments without directly operating a Lightning node or managing payment channels.

The gateway operator runs a Lightning node with sufficient channel liquidity. When a user wants to send a Lightning payment, the gateway pays the invoice on their behalf and receives protocol-native assets (such as ecash tokens or virtual UTXOs) in return. When a user wants to receive a Lightning payment, the gateway accepts the incoming HTLC on its Lightning node and credits the user within their native protocol.

This pattern emerged from the Fedimint project, which formalized the gateway role as a distinct component in its architecture. The concept has since been adopted and adapted by other Bitcoin Layer 2 protocols, each implementing the gateway pattern with different trust assumptions and security guarantees.

How It Works

A Lightning gateway maintains liquidity on two sides: Lightning channel capacity for interacting with the broader network, and protocol-native balances for settling with users inside the connected system. The gateway earns fees for bridging between these two worlds.

Outgoing Payments (User Pays a Lightning Invoice)

When a user inside a gateway-connected protocol wants to pay a Lightning invoice, the flow typically follows this pattern:

1. The user locks protocol-native funds in a conditional contract (enforced by federation consensus, mint rules, or atomic swap logic)
2. The user sends the Lightning invoice to the gateway
3. The gateway pays the invoice through its Lightning node, obtaining the payment preimage
4. The gateway presents the preimage as proof of payment and claims the locked funds
5. If the gateway fails to pay before a timeout, the user's funds unlock automatically

Incoming Payments (User Receives a Lightning Payment)

Receiving Lightning payments through a gateway reverses the flow:

1. The user generates a payment hash and shares it with the gateway
2. The gateway creates a hold invoice on its Lightning node using this hash
3. When a payment arrives, the gateway acquires the preimage from the user's protocol (purchasing it from the federation or retrieving it from the user)
4. The gateway settles the Lightning HTLC using the preimage and credits the user with protocol-native funds

Liquidity Management

Gateway operators must manage three distinct liquidity layers:

• On-chain Bitcoin for opening and closing Lightning channels
• Inbound and outbound Lightning channel capacity for routing payments
• Protocol-native balances (ecash tokens per federation, mint balances) for settling with users

A gateway cannot process incoming payments for a federation if it lacks sufficient ecash balance in that federation, even if it has ample Lightning liquidity. This three-layer balancing act is one of the operational challenges that distinguishes gateways from standard routing nodes.

Implementations

Fedimint Lightning Gateway

Fedimint provides the most well-documented gateway implementation. The gateway daemon (gatewayd) is a specialized Fedimint client paired with a Lightning node. It exposes a REST API that Fedimint clients use to request payment routing.

Fedimint's current protocol (LNv2) supports both LND and LDK as Lightning backends. A recent integration of LDK Node directly into gatewayd simplified deployment from two separate daemons to a single process. Gateway operators configure four fee parameters per federation:

# Fedimint gateway fee configuration
lightning_base_fee_msats: 1000    # Fixed base fee per payment
lightning_fee_ppm: 1000           # Proportional fee (parts per million)
transaction_base_fee_msats: 500   # Base fee for protocol-side settlement
transaction_fee_ppm: 500          # Proportional protocol-side fee

Under LNv2, federation guardians must explicitly register gateways before they become discoverable to users. Multiple independent gateways can serve a single federation, creating competition on fees and reliability. Gateways are untrusted entities separate from federation guardians: users rely on reputation and the timeout-based refund mechanism for protection.

Cashu Mint as Gateway

In Cashu, the mint itself acts as the Lightning gateway. Unlike Fedimint's separation between federation guardians and gateway operators, Cashu combines both roles in a single operator. The mint runs a Lightning node and handles two operations:

• Minting (deposit via Lightning): the user pays a Lightning invoice issued by the mint, and the mint issues blind-signed ecash tokens of equivalent value
• Melting (withdrawal via Lightning): the user submits ecash proofs plus a Lightning invoice, the mint burns the tokens and pays the invoice, returning any fee overage as change tokens

Inter-mint payments route over Lightning, enabling interoperability between separate Cashu mints. However, the single-operator model means users fully trust the mint with their deposited funds.

Spark's SSP Model

Spark takes a different approach to Lightning interoperability. Rather than relying on trusted gateways, Spark uses its Service Providers (SSPs) to route Lightning payments with atomic swap guarantees.

For outgoing payments:

1. The user instructs the SSP to pay a Lightning invoice, conditionally transferring Spark leaves as payment
2. The Settlement Engine (SE) locks the transfer on the user's leaves until a timeout
3. The SSP pays the Lightning invoice through its Lightning node
4. The SSP delivers proof of payment to the SE, which finalizes the leaf transfer atomically
5. If the timeout expires without proof, the SE unlocks the user's leaves with no loss

This design means neither the SSP nor the user can steal funds: the atomic swap construction ensures that payment and proof of payment are cryptographically linked. The trust assumption is distributed across SE operators (1-of-n or minority-of-n), a stronger guarantee than single-operator gateways.

Gateway vs. LSP vs. Submarine Swap

Lightning gateways are often confused with LSPs and submarine swap providers. While all three facilitate Lightning payments for end users, they operate at different layers:

A key distinction: LSPs are peers on the Lightning Network graph, while gateways are intermediaries between two distinct systems. An LSP helps you use Lightning directly; a gateway lets you interact with Lightning from outside it.

Use Cases

• Federated ecash payments: members of a Fedimint federation can pay any Lightning invoice or receive payments from anyone on the Lightning Network, gaining privacy benefits of ecash with Lightning's reach
• Cross-protocol interoperability: users on different Layer 2 systems can transact with each other by routing through Lightning as a common settlement layer, with gateways on each side
• Mobile-friendly payments: protocols like Spark and Fedimint use gateways to provide Lightning access to mobile users who cannot run full nodes or manage channel state
• Offline receive: Spark's SSP model allows users to receive Lightning payments while offline, with the SSP holding the payment conditionally until the recipient comes online
• Privacy-preserving payments: ecash-based systems gain transaction privacy within the protocol while using gateways to connect to the broader Lightning economy

Risks and Considerations

Gateway Liveness

If a gateway goes offline, users lose Lightning access until it returns or they switch to another gateway. Funds held within the protocol (ecash in a federation, leaves in Spark) remain safe, but pending Lightning payments may fail or time out. Protocols that support multiple competing gateways (like Fedimint) mitigate this through redundancy.

Custodial Risk Spectrum

Gateway trust models vary significantly:

• Cashu mints: fully custodial to a single operator, who controls all deposited funds
• Fedimint gateways: the gateway itself is not custodial (funds are held by the federation), but the gateway could fail to complete a payment after accepting locked ecash; timeout refunds and multi-gateway competition provide protection
• Spark SSPs: non-custodial by design, with atomic swap guarantees ensuring neither party can steal funds; trust is distributed across SE operators

Liquidity Constraints

Gateways face more complex liquidity challenges than standard Lightning nodes. They must balance Lightning channel capacity, on-chain reserves for channel management, and protocol-native balances simultaneously. An imbalance on any layer can block payments in one direction even when other layers have surplus capacity.

Payment Completion Risk

A gateway could accept locked protocol-native funds but fail (or refuse) to complete the Lightning payment. Well-designed protocols protect against this with timeout-based refunds: if the gateway does not present proof of payment within a defined window, the user's funds unlock automatically. However, the user loses time and the payment must be retried through another gateway or at a later time.

Fee Overhead

Gateway payments incur fees on both sides: Lightning routing fees for the network hop, plus the gateway's own service fee for bridging between protocols. This double fee layer can make gateway-routed payments more expensive than native Lightning payments, particularly for small amounts.

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.