Swap-in-Potentiam

What Is Swap-in-Potentiam?

Swap-in-potentiam (Latin for "swap in potential") is a protocol that lets a Lightning wallet receive on-chain bitcoin into an address that can later be moved into a Lightning channel cooperatively, without requiring the wallet to be online at the time funds arrive. The protocol was proposed by developers ZmnSCPxj and Jesse Posner in January 2023 and targets a persistent pain point: mobile Lightning wallets that go offline frequently cannot participate in traditional on-chain-to-Lightning swap flows that require both parties to be present.

In a standard submarine swap or channel open, the user must be online to cosign transactions and exchange messages with the swap counterparty or Lightning Service Provider. If the user's phone is off or has no connection, the swap either fails or requires the counterparty to hold funds in limbo. SIP sidesteps this by establishing a reusable on-chain address ahead of time: anyone can send funds to it at any point, and the user and LSP cooperate to move those funds into a channel whenever the user comes back online.

How It Works

SIP relies on a specially constructed Bitcoin script with two spending paths. The user (Alice) and the LSP (Bob) generate this address together before any funds arrive.

1. Alice and Bob create a shared address governed by a script with two conditions: a cooperative path requiring both signatures, and a timeout path that lets Alice spend alone after a specified number of blocks
2. Alice shares this address as her on-chain receive address: anyone (including exchanges, other wallets, or payment senders) can send bitcoin to it at any time
3. When Alice comes online, she and Bob cooperatively sign a transaction that moves the funds from the SIP address into a new or existing Lightning channel via splicing
4. If Bob is unresponsive or goes offline, Alice waits for the timeout to expire and then spends the funds unilaterally to any on-chain address she chooses

The Two Spend Paths

The SIP address script encodes two distinct conditions:

• Cooperative path: Alice and Bob both sign. This is the happy path used to open a channel, splice funds into an existing channel, or send the funds to a new on-chain destination. No timelock is required.
• Timeout path: Alice signs alone after a timelock expires (typically on the order of several months). This is the safety valve: it guarantees Alice can always recover her funds even if Bob disappears entirely.

Using Taproot, these two paths can be encoded efficiently. The cooperative path uses the key path spend (a single aggregated signature), while the timeout path sits in the script path. On-chain, a cooperative spend looks identical to any other Taproot key-path spend, preserving privacy.

Script Structure

The conceptual script behind a SIP address follows this pattern:

# Cooperative path (Taproot key path)
<alice_key + bob_key>  (aggregated via MuSig2)

# Timeout path (Taproot script path)
<alice_key> OP_CHECKSIG
<timeout_blocks> OP_CHECKSEQUENCEVERIFY OP_DROP

The key-path spend uses MuSig2 to aggregate Alice's and Bob's public keys into a single Taproot internal key. The script-path leaf encodes Alice's unilateral spend after the timelock.

Why It Matters for Mobile Wallets

Lightning wallets on mobile devices face a fundamental challenge: the phone is frequently offline, whether because the user closes the app, loses connectivity, or lets the battery die. Traditional methods of moving on-chain funds into Lightning require the user to be present:

• Standard channel opens require both parties to exchange messages and cosign the funding transaction in real time
• Submarine swaps require the user to generate and share a payment hash, then claim the on-chain HTLC before its timeout
• Zero-conf channels let the LSP open a channel instantly, but the user must trust the LSP not to double-spend the unconfirmed funding transaction

SIP eliminates the requirement for the user to be online when funds arrive. An exchange withdrawal, a friend's payment, or a scheduled payout can all land in the SIP address while the wallet is closed. When the user opens the app hours or days later, the wallet detects the confirmed deposit and cooperates with the LSP to move it into a channel.

Zero-Conf Safety

SIP also improves the trust model for instant channel operations. Because the LSP cosigns the SIP address, it knows that no one can double-spend funds sitting in that address without its cooperation. This means the LSP can safely credit the user with channel capacity the moment a deposit to a SIP address is seen in the mempool, without waiting for confirmations. The LSP accepts zero-conf risk only from addresses it co-controls, not from arbitrary external transactions.

Comparison to Other Approaches

Several techniques exist for bridging on-chain bitcoin into Lightning. SIP fills a gap that other methods leave open.

SIP is often used in combination with splicing: the deposit goes to a SIP address, and when the user comes online, the funds are spliced into the existing channel in a single transaction.

Real-World Adoption

The most prominent implementation of swap-in-potentiam is in Phoenix Wallet, built by ACINQ. Phoenix uses a variant called "swaproot" that combines SIP with Taproot to create swap-in addresses indistinguishable from regular Taproot payments. Phoenix manages a single dynamic channel that is resized through splicing, and SIP addresses serve as the on-chain deposit mechanism.

In Phoenix's implementation, deposits that are not swapped into a channel within approximately four months can be recovered by the user through the timeout path. The wallet provides a built-in interface for spending expired swap-in deposits.

The protocol is also relevant to the broader Lightning ecosystem. The Spark network and other Layer 2 solutions address similar challenges around receiving funds while offline through different architectural approaches, such as async payments and virtual UTXOs that eliminate the need for channel management entirely.

Use Cases

Exchange Withdrawals to Lightning

A user sets their SIP address as the withdrawal destination on an exchange. The exchange sends bitcoin on-chain. Hours later, the user opens their Lightning wallet, and the funds are automatically moved into their channel. No coordination between the exchange and the user's LSP is needed.

Recurring On-chain Deposits

Because SIP addresses are reusable (unlike standard Lightning invoices), they work well for recurring deposits. A mining pool payout, a DCA service, or a payroll system can send to the same address repeatedly. Each deposit accumulates in the SIP address and can be swept into the channel when the user comes online.

Receiving While Offline

A merchant running a mobile Lightning wallet can share their SIP address for on-chain payments. Even if the merchant's phone is off, funds arrive safely in the SIP address. When the merchant reopens the app, the wallet and LSP cooperatively move deposits into the channel, making them available for Lightning payments.

Risks and Considerations

Timeout Window Trade-off

The timeout period creates a tension. A longer timeout gives the user more time to come online and cooperate with the LSP, but it also means funds are locked in the shared address for longer. A shorter timeout lets the user recover funds faster if the LSP disappears, but creates urgency to come online before the timeout expires. Phoenix's implementation uses a timeout of approximately four months, which balances convenience against the risk of the LSP going offline.

Address Reuse Privacy

While SIP addresses are designed to be reusable, reusing any Bitcoin address creates address reuse privacy concerns. Multiple deposits to the same address are trivially linkable on-chain. Implementations like Phoenix mitigate this by rotating SIP addresses using output descriptors, generating fresh addresses from the same underlying key relationship.

LSP Dependency

During the cooperative period (before timeout), funds in a SIP address require the LSP's cooperation to move. If the LSP goes offline, the user must wait for the full timeout before spending unilaterally. This is safer than trusting the LSP with custody (the LSP can never steal funds), but it means the user's on-chain liquidity is temporarily less accessible than in a standard single-sig wallet.

Confirmation Requirements

While the LSP can accept zero-conf deposits from SIP addresses it co-controls, external deposits to the SIP address from unknown sources may still need confirmations before the LSP credits channel capacity. The zero-conf benefit applies specifically because the LSP is a cosigner on the address, not because of any inherent property of the deposit transaction.

Related Concepts

SIP intersects with several other Lightning and Bitcoin scaling techniques. For deeper exploration, see:

• Submarine Swaps Explained for the HTLC-based alternative to SIP
• Splicing Lightning Channels for how funds move from SIP addresses into channels
• Async and Offline Lightning Payments for the broader challenge of receiving Lightning payments while offline
• Lightning Service Providers for the LSP's role in SIP and channel management

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.