In the world of consumer blockchain, there are two common models for blockchain key management: user custody (or self custody) and application custody.
User custody is considered the default and best option by the Web3 community. The user keeps their own key(s) on a device in their control (typically a laptop or phone), and access to that key is managed by software called “a wallet”. Applications that provide blockchain services to the user make requests to the wallet, and the wallet examines and presents the request to the user for approval before executing. This has the advantage of being self-sovereign and it gives the user absolute control over their assets, while providing them full protection from lost assets due to failed or attacked service providers.
For users new to Web3, setting up self-custody is confusing and creates friction. The user is expected to install and configure their wallet software before they have even used the application that requires it. If you’ve been in the Web3 space for a while, you might not remember the confusion of being asked to remember twelve random words and then authorizing “full access to all websites” to a bit of software you’ve never heard of before. This is even worse on mobile, where users are accustomed to getting started without any kind of account creation (especially not one that requires a second application to be installed!). Dapper Wallet and others have done their best to streamline this process, but data shows that it’s still a major drop-off point for user onboarding.
In a desire to remove this friction, a large number of application developers are providing custody for their users. “App custody” gives users a very natural, Web2-style onboarding experience, and allows the application vendor to sell their digital products and services using traditional payment methods (e.g. credit card on web or native in-app purchases on mobile). This approach is especially attractive for mobile and for companies that already have a customer base with account login (like Netflix or Spotify).
App custody has another benefit: the application doesn’t need to pester the user for permission via the wallet. The app software can manage the contents of the account they created for the user directly. For example, if a user buys an on-chain item using in-app purchases (IAP) in a mobile game, they don’t want to have to jump back to their wallet to approve every interaction with that item.
As valuable as app custody is in creating a great on-boarding experience and streamlining interactions with games and other application services, it causes each application to be an isolated island. The power of blockchain assets is that users can take them out of the experience that originally created them and use them in other compatible apps, like peer-to-peer trading marketplaces, or in new products that extend existing experiences.
One way of trying to bridge this gap is to ask users to start with app custody, and when they’re experienced enough in the Web3 ecosystem to get themselves a self-custody wallet, they can transfer their assets out of the app-managed account into their private wallet.
This introduces its own difficulties. The world inside the app (the app-custody account) and the world outside the app (the user-custody account) are disconnected. The app world doesn’t see – and can’t even request access to – the assets in the user-custody account. And the user can’t use the world of Web3 applications without removing them from the app-custody account, where they are presumably quite useful! And worst of all, if an app provider shuts down the user can lose all assets in the app-custody account, with no possibility of recovery.
Fortunately, there’s an approach that gives us the best of both worlds.
By using account abstraction – specifically, account delegation – one blockchain account (the “child account”) can delegate control to another account (the “parent account”). The child account can be accessed using cryptographic keys, as per usual, but the owner of the parent account can directly access the assets of the child, as well. Critically, the account granting the delegation (the “child”) must explicitly provide this access, and can revoke this access at any time for any reason.
This connection lets us create a hybrid of app custody and self custody that provides the full benefits of both. A new user, without a self-custody account, can sign up for a new account without having any wallet software. But when they are ready for self custody, they can delegate control of the app-custody account to their self-custody account. Using their own keys, on their own devices, they can access all of the assets in both accounts, while still allowing the application to manage the assets in the child account without having to bring up the wallet software.
Since this delegation relationship is tracked on-chain, the application can see the connection to the parent account, and can see the assets in that account and other children accounts associated with it. It can request temporary access to those assets from the wallet software (using a standard transaction-signing request), or even propose moving those assets into the app-custody account to allow for continuous access.
To learn more about account abstraction and Hybrid Custody on Flow, visit http://flow.com/hybrid-custody.
