I recently read a piece with a provocative title, "The Bullish Case for Bitcoin Custodians", that positioned custodial bitcoin services in a new light. In the piece the authors made the argument that rather than being honeypots for trapping users coins, well-managed custodians can be just one of many tools in the toolkit for new users just starting their bitcoin journeys to self-custody. If you haven't read it as yet I encourage you to check it out. The article made one point that especially stood out to me, which is that custodial wallets if done right should offer a pathway to self-custodial bitcoin for users who are ready to make this leap.

I was also recently in Prague for the BTCPrague conference and was lucky enough to catch a workshop by Jesse from Breez on their new Breez SDK product that builds on top of Blockstream's Greenlight tech. If you haven't heard of these before, the SDK in a nutshell gives you a way to access lightning payments infrastructure without having to give up control of your keys (more here). The keys stay within your custody, but using them is as simple as signing messages against an API without needing to take on any of the heavier tasks that are usually involved with using a lightning node to access the network.

These two separate events got me to thinking about how self-custodial lightning has been evolving, and how the UX of offering custodial services could potentially evolve. Working with the Galoy team that builds the tech for the Blink wallet (formerly Bitcoin Beach Wallet) has also given me some interesting insights into how custodial services are constructed under the hood, what the crucial bits are, and how these services are run in a sustainable way for the operators of these services. It got me thinking about how we could potentially eventually evolve our stack if we wanted to bake the progression from custodial to self-custodial bitcoin right into the centre of our product.

What makes a custodial service

In its simplest form, a custodial service is a set of accounts directed by authenticated users. These accounts have a ledger of transactions associated with them, an accounting balance based on past transactions, and the ability to make requests to a centralized node operator to conduct lightning transactions on their behalf via a connected lightning node. It is important to make this distinction. The ledger of accounts for the user and the lightning node are two entirely separate concerns within this system. The operator is tasked with managing the node and making sure it is funded and operational, and they use the ledger of accounts as an indicator of how much a user should be authorized to request from the operator to be sent based on past receipts.

Under this model, "executing a transaction" involves two major steps:

1. Successfully calling some "sendPayment" or "receivePayment" function that triggers sends/receives over the lightning network via a connected node
2. Updating the user's ledger of accounts on each successful send/receive

The downsides of 3rd-party custody

Under this model, the major issues are that:

• the user has to ask someone's permission to send/receive on their behalf
• the user can't stop the person who controls the node from over-sending funds and breaking the 1:1 backing of bitcoins accounted for on behalf of the user

These two problems stem from the user not having unilateral control over the signing keys that are used to execute transactions on the lightning network. This is "the key" (pun intended) to solving the problem of self-custodial lightning for the user: how do you put keys back in users' hands so that they alone can control movement of their funds?

The UX of Transitioning

The reason that users are encouraged to start with a custodial service stem from the difficulty and personal responsibility that usually comes with managing one's own keys. If a custodial service is done right, it would serve as training wheels for teaching about all the elements of bitcoin that fall outside of key management. This would include things like:

• understanding denominations and exchange rates, and potentially softening this learning through things like stablesats
• understanding the process of sending and receiving transactions using things like lightning invoices and other bitcoin/lightning protocol mechanisms
• understanding their own instrinsic reasons for why they would even want to use bitcoin in the first place, and providing a light-touch pathway to this understanding

Once a user is comfortable with this, the best transition to self-custody would ideally look like isolating the process of guiding users to generating and storing their own keys, but keeping everything else about the experience of using bitcoin the same. It is on this front that custodial solutions are well positioned to serve as a sherpa on the pathway to self-custodial bitcoin.

If done right, a custodian can simply swap in the generation/storage of keys in-app, but still remain integrated enough that everything else about the user experience stays the same, and this is where the potential of something like the Breez SDK comes in!

A practical example: Blink

To illustrate this better it would be helpful to get into some of the nuts and bolts of how wallets and transactions work in a custodial service. This is specific to Blink, but generalizations can be made to other custodial systems as well (e.g. LNBits, LndHub etc.).

Current setup

The Blink mobile wallet works as follows:

1. Users create accounts and receive an authentication token
They automatically receive two new "wallets" with each account, a BTC denominated wallet and a (stablesats-)USD wallet. These wallets don't have unique keys or anything attached to them, and are simply an entity in a database against which transactions can be made.

2. Users conduct authenticated actions via an API
Users can now use their token through the app to make requests against the Blink backend using a graphql API. The requests are automatically assigned to the requesting user's account, and they can be sent in any number of ways. Most users will be making these requests and will see the results of these requests via pre-programmed flows wrapped in a mobile wallet UI.

3. The backend receives requests and executes them accordingly
For a custodial lightning application requests usually fall into 2 broad categories:
- requests for lightning transactions over the network
- requests for details about their account, balances and transactions made
The backend server executes these requests on behalf of users and the server is the entity that holds control of keys for moving funds. It is also in charge of reading from and making changes to internal databases to reflect the latest state of user account and balances.

Architecture of self-custody

To appreciate the changes that would occur as users transition to self-custodym, it would be helpful to understand the new architecture that would facilitate this shift.

The Breez SDK is simply a way to communicate with independent "Greenlight" lightning nodes hosted in the backend. Under this setup, the original custodian would still setup and manage the lightning infrastructure on users' behalves and would be paid for this activity. The thing that would change is that instead of the user asking the custodian to direct funds, they would make these requests using signed messages to their own nodes in the cloud managed by the original custodian. It is important to udnerstand that the original custodian no longer has any control of funds in these new nodes since they don't have the keys.

The nature of the work of the custodian would shift more to the role of being an LSP and less about controlling and directing user funds.

Making the transition

If Blink wanted to offer a new separate self-custody option, the actions outlined before would change to facilitate users being able to control their own funds.

1. Users create an account and receive keys and a node
The user would first call directly to Greenlight via the Breez SDK to generate new keys and be mapped to a node. The user would then call the Blink API with the details of this new node and the Blink backend would register this node as a new wallet against the user account.

2. Users execute signed actions directly against the Breez SDK node
The user would use signed messages to direct fund movement against their Greenlight node. Again, these calls are made directly to the node and simply facilitated by someone like Blink. Blink would never control actual fund movement.

3. The backend receives requests and records them accordingly
The backend would still be aware of the transactions being conducted by users even though they have no control. This is because under the current configuration, Greenlight nodes construct routes in the backend where Blink would have some visibility of transactions. In this case though this is maybe a positive since the backend can then provide a unified transaction view to the end user through the same original API.
Note: Future designs and improvements will likely improve the privacy of this step without compromising the end experience for the user, but these are still under development.

Tradeoffs

The positives of this new setup come with some unavoidable drawbacks for now.

The positive elements are that:

• the UX of sending/receiving stays the same
• the balance and list of transactions would also stay the same since they are being recorded in the same backend ledgers
• users now have unilateral control of their funds

The biggest tradeoff with this approach is privacy. With this approach, to keep that familiar user experience and to avoid having to manage their own infrastructure the user necessarily has to share all transaction activity with the custodian. This step is simply moving from "no control + no privacy" to "self-control + no privacy".

We should discount this shift though as it isn't a trivial step. A big part of managing one's own funds is learning how to work with public-private key-pairs and this approach very cleanly isolates that transition.

Once the user is comfortable with this they can then easily move to more privacy-respecting alternatives and more complex setups that would require additional effort/learning from the user, but all in their own time and at their own pace.

The Custodian's Perspective

For the custodian, building in this sort of transition process could also be in their business/sustainability interests. Running custodial systems come with significant challenges and costs. These would include things like:

• the technical & security overhead that comes with managing other people's funds
• compliance & kyc requirements and the need to segment users by jursidiction

By incorporating a self-custodial transition into a custodial system, operators can mitigate some of these risks while still benefiting from revenues from activities like liquidity management, routing and infrastructure management. It also provides the opportunity for operators to be good bitcoin citizens and encourage bitcoin best-practices among their user-base.

The actual decision to go down this route would of course be dependent on many other factors, so don't expect your favourite custodians to all start integrating the Breez SDK tomorrow. The key though would be to continue working things like LSP business models, and to keep evolving the eco-system such that it becomes more and more attractive for businesses to want to go down this road instead of leaning into becoming bigger and bigger banks. It'll come down to incentives.

It's positive though that developments in the space even allow for new user experience pathways like this. It's in the spirit of a sentiment shared by Andreas Antonopoulos in one of his earlier talks where he spoke about how bitcoin eventually scales. In his words, we win once "bitcoin can continue to fail to scale, gracefully, for decades to come".