Introducing the new Phoenix: a 3rd generation self-custodial Lightning wallet

Published July 11, 2023 (updated December 15, 2023)

TL; DR: Splicing changes the game. Phoenix now manages a single dynamic channel, full control on inbound liquidity, better predictability, trustless swaps. The new fee schedule is detailed here.

Single dynamic channel

When we initially released Phoenix a few years back, we called it a 2nd generation wallet because the introduction of automated channel management was such a huge improvement compared to earlier Lightning wallets.

However, things were still rather primitive under the hood, due to the fact that once a channel has been created it couldn't be altered. This limitation caused a variety of issues:

• Over time, depending on usage patterns, Phoenix could create many channels. Users with dozens of channels are not rare. In the common "stack-only" use case, each incoming transaction (lightning or on-chain) may result in a new channel.
• With inbound liquidity scattered across many channels, it becomes very hard to predict when an incoming payment will trigger the creation of a new channel. It is in fact impossible to predict, since it depends on how the sender decides to split the payment. The unpredictability is frustrating for users, because opening a channel has a cost.
• From the point of view of the wallet provider, each individual channel carries a risk because the channel will need to be closed at some (possibly far away) point in the future at an unknown feerate. This risk isn't compensated over time by compounded revenue for each user, since new channels keep being created. That is why the cost of opening a channel was a minimum of 3000 sat, even if the cost of the funding transaction was 200 sat that day, something that was puzzling for many users.

Leveraging a technology called splicing, the new Phoenix has the possibility to resize channels, making all those issues go away:

• each user has only one channel
• there is no more scattered liquidity or splitting issues
• adding or removing funds to the channel doesn't add future risk and can be priced at current cost: the 1% / 3000 sat fee is replaced by the mining fee for the underlying on-chain transaction.

Another way to look at it is that we are moving from N UTXOs/user to 1 UTXO/user. It is simply the current optimum for self-custody on Bitcoin. Further reducing the on-chain footprint implies sharing UTXOs amongst users, either in a simplistic trusted way (custodial wallets), or by introducing concepts like virtual UTXOs.

We believe that the efficiency gains brought by splicing are so phenomenal that all wallets will eventually implement it. That is why this technological improvement marks the beginning of a new generation of self-custodial wallets.

More predictability and more control

A common feedback that we had with the previous version of Phoenix was that the creation of new channels (and the associated fee) often came up as a surprise for the user.

The new version will not create new channels, instead it will "splice-in" funds to your existing channel, but there is still an on-chain transaction involved. The channel management fee used to be 1 % of the amount received with a min of 3000 sat, now it is just the cost of the mining fee for the splice transaction.

Phoenix is able to accurately predict when an incoming Lightning payment will incur a channel management fee and a note is displayed to the user beforehand:

Users can adjust the maximum fee that they are willing to pay for channel management when receiving payments. If the fee is too high, Phoenix will just wait and retry later (for a swap-in) or reject (for a Lightning payment):

The fee for sending Lightning payments is now shown in advance, and is a fixed 0.4% instead of variable 0.05%-0.5%. This allows the user to validate the fee before making the payment. It also aligns incentives with the wallet provider, which was previously trusted to find the cheapest route. The wallet provider is now incentivized to find the best (reliable, affordable) route within the fee budget.

Trustless swaps

Pretty much all Lightning wallets offer a way to seamlessly send and receive regular bitcoin transactions. However until now this was always done through a swap service that serves as a bridge between on-chain and off-chain.

In the case of Phoenix the swap service was very basic, trusted, and didn't let the user choose the feerate for a swap-out. Other swap services may be trustless (e.g. submarine swaps), but they all lack flexibility.

Swap-out (paying to a bitcoin address)

Splicing makes the distinction between on-chain and off-chain really blurry. Removing funds from a channel (it's called a splice-out), effectively translates to making an on-chain transaction directly from your channel. No swap service is needed and the operation is trustless. Not only can you set your own feerate, you can even bump the fee later to speed up the confirmation, just like with a regular on-chain wallet.

It should be noted that:

• swap services come with the nice property of cutting the link between off-chain and on-chain, whereas splicing-out will reveal your UTXO (again, just like a regular on-chain wallet);
• a splice-out reduces the size of the channel by removing funds from your side, whereas using an external swap service keeps the channel as-is and adds inbound liquidity (simply because your are sending funds over Lightning to the swap service).

This is why, for some transactions you may still prefer going through an external swap service.

Swap-in (sending an on-chain transaction to Phoenix)

In the previous version of Phoenix, the bitcoin address displayed in the Receive tab wasn't controlled by Phoenix but by the swap service, and for every incoming transaction, a new channel was created.

With the new Phoenix, funds stay in control of Phoenix during the process. If there is already a channel, the funds will be spliced in and the capacity of the channel will grow by that amount. Otherwise, a new channel will be created using dual-funding.

Furthermore, Phoenix uses a mechanism inspired by the swap-in-potentiam proposal, which permits zero-conf swaps: as soon as the transaction sending funds to the swap-in address has been confirmed, they will instantly be usable.

Whether it is a splice or a new channel, mining fees are paid by the user, but they can be configured as described in the previous section. Since funds stay in control of Phoenix, the user can choose to set a very low max fee setting, and let the swap pending until the bitcoin mempool gets empty. This makes it possible to deposit funds to Phoenix for less than 500 sat when conditions are optimal, a huge reduction compared to the previous 3000 sat/1%.

Fee comparison

The main change is that the 1% fee on incoming payments has been replaced by a 0.4% fee on outgoing Lightning payments.

This does not mean that incoming payments are free, because mining fees may apply, but when the feerate is low (under 10 sat/byte) it's always cheaper than before, and practically free at 1 sat/byte.

What's next?

• Blinded paths: better privacy for your Lightning payments
• BOLT 12/Offers: static Lightning invoices
• Taproot: cheaper channel management and better on-chain privacy

Update December 15, 2023: the initial version of this post stated that we removed the 1% fee on inbound liquidity. We have since added the option to request inbound liquidity in advance in order to save mining fees for users who are receiving more than spending.