tl;dr - Super proposes a new way of paying an L1 address from a lightning balance where you turn your channel partner into your swap provider, without diminishing your channel balance.

Splices vs swapsSplices vs swaps

First, this is a nice description of splicing:

Splices allow two channel users to cooperatively sign a transaction that consumes their channel as an input and has two outputs: the first sends the intended amount to the sender’s intended destination, and the second returns the change to the channel, where it is divided up again via presigned transactions. In a splice, neither channel user loses their balance, except in the sense that the sender loses the amount he or she sent, plus mining fees.

Then a description of swapping:

Swaps allow a channel user to route an LN payment to a third party “swap provider,” whose business is to pay L1 addresses in return for LN payments. Swap providers typically charge a service fee to cover the cost of L1 mining fees and to make a profit, and they also often leverage smart contracts to assure LN users that they won’t get short-changed during the swap. Some (including me) even say that a swap provider who doesn’t use such a smart contract as an assurance to their users isn’t “really” a swap provider.

The downside of splicingThe downside of splicing

Super goes on to explain one reason why splicing is not as useful as swapping (sending sats to a third party who will turn them into an onchain output for a fee):

I think swaps are usually better than splices. An initial clue in support of this intuition comes in the form of channel capacity. Suppose a channel has two users, and each puts 50k sats in the channel. Its total capacity is 100k sats (the sum of each user’s balance) and thus that is the maximum balance either user can have in that channel, without doing an L1 transaction to change it (a “splice-in”). If a user opts to send 10k sats out of the channel via a splice, not only does the user’s balance fall by 10k sats, but the total capacity of the channel also falls by 10k sats. Consequently, for both users, their maximum potential balance in that channel is lower than it was before. This is particularly painful when you recall that many wallets have their users “pay” for the capacity that goes into their channel. Every time such users do a splice, the capacity that they paid for goes down, and many users “feel” this loss every time.

In a swap, that doesn’t happen. Routed payments change a user’s balance, but not their channel’s capacity. If a user has 50k sats in a 100k sat channel, and they send someone 10k sats, their “balance” falls to 40k, but the channel capacity stays at 100k sats, because their channel counterparty’s balance “rises” by 10k sats. (That counterparty also “loses” 10k sats in other channels, in a chain of inter-channel payments that terminates with the final recipient.)

Connector outputsConnector outputs

A connector output is a bitcoin utxo, typically small (e.g. a segwit output at the 294 sat dust limit qualifies), which allows users to conditionally “revoke” presigned bitcoin transactions. They require a setup procedure, which consists of adding the connector output to a bitcoin transaction as one of its inputs, and then signing it. This procedure creates a presigned transaction that can be revoked in the following manner: if anyone “spends” the connector output, one or more of the signatures in the presigned transaction become “revoked,” or invalidated, because a bitcoin signature is invalid if it signs a transaction with an input that has already been spent

Connector outputs are a small, extra output you stick in a pre-signed transaction so that you can invalidate the pre-signed transaction by spending the connector output.

Connector swapsConnector swaps

Now, imagine you had a channel that was set up with connector outputs. Whichever of the channel partners who wants to spend to an onchain address creates two psbts spending the amount they want to spend from the channel: one spends the sats to the onchain destination the other allows the channel partner to sweep the sats after a timelock expires.

Finally, the actual swap takes place: the channel partners sign an onchain transaction that uses the one of the channel partner's utxos (independent from their lightning channel) to pay the destination and refill the channel's capacity to the level it was already at. Then the person who wanted to do the swap in the first place transfers an equal number of sats to their partner's side of the channel.

That is probably not the most helpful explanation, but I really had to think it thorugh a few times when I read Super's explanation and I'm hoping that it simplifies things a little. If it didn't, here is Super's full explanation of the protocol:

Once a connector output exists, an LN user with connector aware software can use it in a swap in the following manner: suppose two users of a channel, Alice and Bob, have a balance of 50k sats apiece (so the total capacity of their channel is 100k sats), and Alice wants to send 20k sats to an arbitrary L1 btc address. I will henceforth call this address “the destination.” Alice should first create an off-chain utxo in the Alice <--> Bob channel worth 20k sats, plus a service fee for Bob, which covers the cost of an L1 transaction, and allows him to make a profit.

This off-chain utxo should be “recoverable” by Alice if and only if her connector output exists. This is achieved by making the off-chain utxo a 2 of 2 output between Alice and Bob, similar to the channel itself, and having both sign a transaction that consumes the ~20k sats and the connector as inputs, and creates one output: it restores the ~20k sats to Alice. Thus, if the connector output doesn’t exist, both signatures are invalid, and Alice can’t recover her ~20k sats. A second transaction, signed by Alice and Bob, allows Bob to take the ~20k sats after a timelock expires (e.g. 10 blocks), without consuming the connector – so, if it ceases to exist, Bob’s path is unaffected.

Once both transactions are signed, Alice gives Bob a final signature: one that is valid for an L1 transaction – “the payment transaction” – with the following properties. (1) It consumes one or more of Bob’s utxos (he gets to pick what ones to use) (2) it consumes the connector output (3) it pays 20k sats to the destination (4) it creates a “replacement” connector output with the same value and the same script as the current one (5) it sends any of Bob’s change anywhere Bob likes. Bob signs and broadcasts the payment transaction, and once it confirms, Bob knows he is guaranteed to get the off-chain ~20k sat output if he broadcasts the latest state of the Alice <--> Bob channel. But that’s the sad path.

The happy path is: the payment transaction confirms, whereupon Alice and Bob cooperatively resolve the utxo off-chain, pushing 20k sats from Alice’s side of the channel to Bob’s side in the process, plus his service fee. If the L1 tx does not confirm (e.g. maybe Bob decided not to broadcast it), Alice can unilaterally recover her ~20k sats by closing her channel and sweeping the ~20k sat utxo. If Bob’s L1 tx confirms but Alice refuses to pay him off-chain, Bob can close the channel in its latest state, wait for the timelock to expire, and then sweep the ~20k sat utxo.

What's cool about this is that you can use a channel partner as a swap partner without having to trust them. The channel partner can make the swap from one of their other utxos and you can send them the sats on lightning. Theoretically, this should be a lower fee way to do this than involving a third party for the swap service or diminishing your channel capacity.