Warning: Providing the custodian backup share to the client device puts both MPC shares on a single device, removing the multi-party security benefits of MPC. This operation should only be done for users who want to move off of MPC and into a single private key. Use
portal.eject() at your own risk!Ejecting Your User’s Wallets
With Portal-managed backups
To eject the private keys for your users’ wallets, their two matching backup shares need to be combined. Since both of these shares are stored on the Portal backend encrypted at rest, we first need to verify that the upcoming request to eject the wallet is not an attack. In order to do this, we make this a two-step process:- Make a Custodian-authed
POSTrequest using your Custodian API Key (the same API key you use to create new users) to the/api/v3/custodians/me/clients/${clientId}/prepare-ejectendpoint to allow for this client to perform anejectoperation - Call the
portal.ejectWallet()function from your application
Making the `prepare-eject` request
This endpoint requires awalletId in the POST body. This can be found in the wallets property of the /api/custodians/me/clients/${clientId} GET request.
If you are planning on ejecting multiple wallets for a user, you’ll need to make multiple separate requests to “unlock” all requires wallets.
Ejecting the wallets
With Backups from your server
To eject the private keys for your users’ wallets, their two matching backup shares need to be combined. This requires providing the following two shares toportal.eject():
- User Backup Share - Encrypted backup share received from
portal.backup(). - Custodian Backup Share - Raw backup share received from the
POST /backupwebhook.
portal.eject(), they can potentially receive multiple private keys. Here’s an example implementation:
SECP256K1 is the curve used by Ethereum.ED25519 is the curve used by Solana.You can learn more about signing algorithms and curves here.