This new approach leverages a channel opening flow rather than the traditional onchain-to-offchain swap, aligning with the principles set forth by LSPS0, albeit as an extension that is yet to be discussed with the LSPS standards group. Central to this mechanism is the use of public keys known between transacting parties, where Alice knows a public key controlled by Bob for initiating transactions. This setup facilitates the creation of a watch-only onchain wallet by Alice using BIP32 HD derivation, negating the need for a swap address.

In implementing swap-in-potentiam, all inputs to the funding transaction must originate from addresses with the same Lightning Service Provider (LSP) as Bob, though Alice's keys can differ. This requirement stems from the desire to avoid using Partially Signed Bitcoin Transactions (PSBT) since the current sub-protocol lacks support for MuSig2, opting instead for a bespoke format that communicates the inputs and order of outputs. Despite this, PSBT remains utilized for general onchain-to-onchain transactions, enabling swap-in-potentiam wallets to implement PayJoin. There is hope that future adaptations will incorporate MuSig2 support within PSBT, but until then, a specific 2-of-2 tapleaf path exists to facilitate transactions without MuSig2.

The essence of swap-in-potentiam lies in its ability to transform an onchain address into one that can be spent in the Lightning Network after achieving a minimum confirmation depth, without necessitating additional waiting periods for moving funds from onchain to offchain. This process allows for a unique transaction method where a third party, potentially unaware of the beneficiary's identity, can fund the swap-in-potentiam address. This funding action inadvertently opens a channel, akin to a non-Lightning channel open, through a modified Spilman channel mechanism, utilizing OP_CLTV/OP_CSV. Unlike traditional Lightning Network channel openings that require active participation from both parties to exchange initial signatures, the swap-in-potentiam channel can be opened unilaterally or even by a third party, thereby streamlining the transaction process. The only requisite is onchain confirmation, which occurs between the third-party funder and Alice, eliminating the need for any intermediary waiting period between Alice and Bob.