Common flows to create self-custodial user wallets include:
  • Creating wallets with a user owner. This configures wallets such that users are the only entity that can update policies, update owners, add signers, and export the wallet. If you create wallets via one of Privy’s client-side SDKs, your app’s wallets are automatically created with user owners.
  • Creating wallets with a 1-of-n key quorum, where one element of the key quorum is the user. This gives users full permissions over their wallet, while enabling other parties to easily update wallets (e.g. policies and signers) and take actions with them.
You can extend self-custodial user wallets to support various use cases, as outlined below.

​
Enabling offline actions

Many apps want to configure user wallets such that apps can take certain actions with these wallets, even when the user is offline. This includes use cases like limit orders, agentic trading on behalf of users (e.g. with a Telegram bot), or portfolio rebalancing. For offline actions, Privy generally recommends:
1

Create a wallet with a user owner

To ensure the wallet can only be updated by the user, create the wallet with a user owner. If you use one of Privy’s client-side SDKs to create wallets, wallets are created with a user owner by default.
2

Add an authorization key as an additional signer

Next, add an authorization key controlled by your server as an additional signer on the wallet. You can also configure the additional signer to have a specific set of policies associated with it, restricting the actions it can take. You can do this via one of Privy’s client-side SDKs or REST API
3

Execute scoped transactions with your additional signer

Your additional signer can now execute actions, such as signing messages or sending transactions, subject to its policies. These actions can occur while the user is offline.

​
Enabling wallet updates from the server

Many apps want the server to be able to update a wallet, such as updating the policies or signers associated with a wallet, even when the user is offline. For server-side wallet updates, Privy generally recommends:
1

Create a wallet with a 1-of-k key quorum

Create your wallet with a 1-of-k key quorum, whose elements include at least a user owner and an authorization key controlled by your server. You can do this via Privy’s REST API.
2

Add an authorization key as an additional signer

Next, add an authorization key controlled by your server as an additional signer on the wallet. You can also configure the additional signer to have a specific set of policies associated with it, restricting the actions it can take. You can do this via one of Privy’s client-side SDKs or REST API
3

Update the wallet with your authorization key

As a satisfying member of the key quorum that owns the wallet, your server’s authorization key can unilaterally update the policies and additional signers assigned to the wallet. This enables your app to update wallet configurations, even when users are offline.

​
Sending transactions from your server

Many apps would like users to explicitly authorize transactions, but to send transaction requests from their server for increased reliability, retries, and various other use cases. To send transactions from your server by default:
1

Create wallets with a user owner

To ensure the wallet can only be controlled by the user, create the wallet with a user owner. If you use one of Privy’s client-side SDKs to create wallets, wallets are created with a user owner by default.
2

Request a signature over your transaction request

Construct your transaction request and use Privy’s client-side SDKs’ methods to have the user sign the transaction request.
3

Execute the transaction request from your server

Send your user’s authorization signature from your client to your server, and send your transaction request with the user’s signature to Privy’s API.

​
Requiring users and servers to approve transactions

Many apps want to require both users and servers to approve transactions. This can be used to enhance the security of your application; for example, by requiring the server to approve transactions, compromise of a user’s account cannot be used to unilaterally take action with the user’s wallet. To enable a configuration where both users and servers must approve transactions, Privy recommends the following:
1

Create a wallet with a m-of-k key quorum, with m ≥ 2

Create your wallet with a m-of-k key quorum with m ≥ 2, whose elements include at least a user owner and an authorization key controlled by your server. You can do this via Privy’s REST API.
2

Have users and server(s) both sign transaction requests

Next, construct your transaction request and have users and servers sign the transaction request.
3

Execute your transaction request with the user and server signature

Next, construct your transaction request and have users and servers sign the transaction request.

​
Exporting wallets from the server

Many apps want the server to to have the ability to export the private key for a user’s wallet. This can be used to self-host a recovery site where users can export their private key outside of your core application. To enable this, Privy generally recommends:
1

Create a wallet with a 1-of-k key quorum

Create your wallet with a 1-of-k key quorum, whose elements include at least a user owner and an authorization key controlled by your server. You can do this via Privy’s REST API.
2

Export the wallet from your server

As a satisfying member of the key quorum that owns the wallet, your server’s authorization key can unilaterally export the wallet. Follow this guide to export the private key for your user’s wallet from the server.