SCID Alias (Short Channel ID Alias)

What Is an SCID Alias?

A Short Channel ID (SCID) alias is a locally assigned, arbitrary identifier that a Lightning node uses in place of the real Short Channel ID for a given channel. The real SCID encodes the exact on-chain location of the channel's funding transaction: its block height, transaction index within that block, and output index. Revealing this information lets anyone look up the funding UTXO on a block explorer, exposing channel capacity, funding addresses, and potentially the identities behind the channel.

An SCID alias breaks that link. Instead of encoding on-chain coordinates, the alias is an arbitrary 64-bit value that means nothing outside the two peers who negotiated it. When a node uses an alias in route hints or forwarding, external observers cannot determine which on-chain output funds the channel.

The feature was introduced through BOLTs PR #910, merged in May 2022. It adds the option_scid_alias feature (bits 46/47 in BOLT 9) alongside the separate option_zeroconf feature, though the two are closely related in practice.

How It Works

To understand SCID aliases, it helps to first understand the standard Short Channel ID format and why it creates a privacy problem.

The Standard SCID Format

A standard Short Channel ID is a 64-bit integer that encodes three values from the funding transaction:

• Block height (3 bytes, 24 bits): which block confirmed the funding transaction
• Transaction index (3 bytes, 24 bits): the position of the transaction within that block
• Output index (2 bytes, 16 bits): which output in the transaction is the funding output

The human-readable format uses the notation BLOCKxTXxOUTPUT. For example, 1440743x38x0 refers to block 1,440,743, transaction 38, output 0. This format is defined in BOLT 7 and used throughout the gossip protocol for channel identification.

// SCID bit layout (64 bits total)
// [  block_height  |  tx_index  |  output_index  ]
// [   24 bits      |  24 bits   |    16 bits      ]

// Example: 1440743x38x0
// block_height  = 1440743 (0x15FBE7)
// tx_index      = 38      (0x000026)
// output_index  = 0       (0x0000)
// Encoded: 0x15FBE70000260000

The problem is clear: anyone who sees an SCID in a BOLT 11 invoice route hint, a channel_update message, or an HTLC forwarding instruction can look up the exact funding UTXO. This reveals capacity, on-chain addresses, and timing information that can be used for chain analysis.

Alias Negotiation

SCID aliases are exchanged during channel establishment. When both peers support the feature, the flow works as follows:

1. Both nodes advertise option_scid_alias support in their init messages
2. During channel opening, option_scid_alias can be included in the channel_type TLV to enforce alias-only mode
3. In the channel_ready message (formerly funding_locked), each peer includes an alias SCID in a TLV field
4. Each node must recognize incoming HTLCs that reference the alias it sent to its peer
5. If alias-only mode was negotiated, the real SCID must never appear in route hints, invoices, or forwarding

Each side of the channel can send a different alias, and aliases are scoped to a single peer relationship. A node must not reuse the same alias across different channels.

Alias-Only Mode

When option_scid_alias is negotiated as a channel_type bit (rather than just an init feature), the channel operates in alias-only mode. In this mode:

• The real SCID must never be placed in route hints within invoices
• The node must not forward HTLCs that arrive referencing the real SCID for that channel
• Only the alias may be used when constructing onion payloads that reference this channel

Without alias-only mode, aliases are a best-effort privacy improvement. The node may still accept HTLCs referencing the real SCID, and the real SCID could still appear in gossip. The channel type enforcement makes the privacy guarantee strict.

Use Cases

Privacy for Private Channels

Private channels are not announced to the network through gossip, but they still have real SCIDs derived from their funding transactions. When a node includes a private channel in a BOLT 11 route hint, the real SCID appears in the invoice. Anyone who intercepts or receives the invoice can decode the SCID and look up the funding output.

SCID aliases solve this by placing the alias in route hints instead of the real SCID. The receiving node maps the alias back to the correct channel internally, but external observers see only an opaque identifier. This significantly improves private channel privacy.

Enabling Zero-Conf Channels

Zero-conf channels allow nodes to begin routing payments before the funding transaction has confirmed on-chain. The challenge: a real SCID requires a confirmed block height, transaction index, and output index. Until the funding transaction is mined, none of these values exist.

SCID aliases provide the solution. When a zero-conf channel is opened, the peers exchange alias SCIDs immediately. These aliases serve as the channel identifier for routing until the funding transaction confirms and a real SCID becomes available. In practice, zero-conf channels almost always use alias-only mode, keeping the alias even after confirmation.

This is why option_scid_alias and option_zeroconf were introduced in the same specification update: zero-conf channels fundamentally depend on aliases to function. Lightning Service Providers (LSPs) that offer just-in-time channels rely on this combination to provide instant inbound liquidity.

Protecting Public Channel Metadata

Even public channels that are announced through gossip can benefit from SCID aliases in certain contexts. When a node constructs a blinded path or provides route hints for receiving payments, using an alias instead of the real SCID prevents the payer from learning the exact on-chain details of the last-hop channel.

Implementation Support

All major Lightning implementations support SCID aliases:

• LND: supports option_scid_alias and zero-conf channels. When opening channels, the --scid_alias flag enables alias negotiation.
• Core Lightning (CLN): supports alias SCIDs with configuration options for alias-only mode.
• Eclair: includes full support for alias negotiation and channel type enforcement.
• LDK: provides alias support at the library level, enabling wallet developers to build alias-aware applications.

For a deeper comparison of implementation differences, see the research article on Lightning implementation comparison.

Risks and Considerations

Not a Complete Privacy Solution

SCID aliases hide the funding transaction from route hints and forwarding, but they do not make a channel invisible. If the channel is public, its real SCID is still broadcast through gossip and recorded by network observers. Aliases primarily protect private channels and specific payment contexts where the real SCID would otherwise be leaked.

For stronger privacy, aliases work best in combination with other techniques like blinded paths and onion routing, which hide additional information about the payment path.

Routing Complexity

When alias-only mode is enforced, senders must know the alias to route through that channel. For private channels, this means the alias must be communicated via route hints. If a node enforces alias-only but the sender tries to use the real SCID, the HTLC will be rejected. This can cause routing failures if software does not properly handle alias-only channels.

Alias Collision

Since aliases are arbitrary 64-bit values, there is a theoretical possibility of collision where two channels on the same node share the same alias. Implementations must ensure aliases are unique per node. In practice, the 64-bit space is large enough that random collisions are astronomically unlikely, but implementations should still check for uniqueness.

Ecosystem Compatibility

While all major implementations now support SCID aliases, older nodes and wallets may not understand them. A channel opened with alias-only mode requires both peers to support the feature. Routing through nodes that do not recognize alias SCIDs in forwarding instructions will fail. As adoption has matured since the 2022 specification merge, compatibility issues have become increasingly rare.

SCID Aliases and Layer 2 Privacy

SCID aliases represent a broader trend in Lightning protocol development: reducing the on-chain footprint of payment channels. By decoupling channel identifiers from funding transactions, the protocol moves toward a model where off-chain activity reveals less about on-chain state. This aligns with the privacy goals of simple Taproot channels, which use Taproot to make channel opens indistinguishable from regular transactions on-chain.

Layer 2 protocols like Spark take this further by eliminating channels entirely. Instead of managing channel state and identifiers, Spark uses a statechain-based architecture where users hold virtual UTXOs without needing to open, manage, or close channels. This removes the SCID privacy problem at the architectural level, since there are no channel funding transactions to leak.

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.