Skip to main content
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.ejectPrivateKeys() at your own risk!

Ejecting Methods

You can eject wallets using either Portal-Managed Backups or Self-Managed Backups depending on your implementation.

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: Implementation Requirements
  1. Make a Custodian-authed PATCH request using your Custodian API Key (the same API key you use to create new users) to the /custodians/me/clients/{clientId}/enable-eject endpoint to allow for this client to perform an eject operation
  2. Call the portal.ejectPrivateKeys() function from your client application with the appropriate backup method

Step 1: Enable the Eject Operation

This request must be made from your backend. The Custodian API Key is a server-side secret and must never be embedded in your Flutter app — doing so exposes the key to every user of the app and lets them eject any other wallet on your custodian.
Make a custodian-authenticated PATCH request using your Custodian API Key to authorize the ejection. Send a JSON body with the walletId and an ejectableUntil timestamp at least one minute in the future:
The walletId can be found in the wallets property of portal.getClient() (clientInfo.wallets[*].id).
If you are planning on ejecting multiple wallets for a user, you’ll need to make multiple separate requests to “unlock” all required wallets.

Step 2: Eject the Wallet

After preparation, call the ejectPrivateKeys() method with the appropriate backup method that was originally used to secure the wallet:
Those functions will:
  • Retrieve and combine shares from Portal’s server
  • Perform the cryptographic operations to construct the private keys
  • Return the private keys as a string that can be imported into other wallet managers

Self-Managed Backup (from your server)

When using Self-Managed Backups, you store the backup shares in your own infrastructure. To eject a wallet, you’ll need to provide both backup shares to the portal.ejectPrivateKeys() function.
  • Client Backup Share - Encrypted backup share received from portal.backupWallet() (the cipherText).
  • Custodian Backup Share - Raw backup share received from the POST /backup webhook.
Implementation Requirements
  1. Retrieve the encrypted client backup share from your storage
  2. Retrieve the raw custodian backup share(s) from your storage
  3. Call the eject function with both shares
Example Implementation:

Cryptographic Curves

Portal supports multiple blockchain networks that use different cryptographic curves:
  • SECP256K1: Used by Ethereum and most EVM-compatible blockchains
  • ED25519: Used by Solana and several other blockchains
You can learn more about signing algorithms and curves here.
When ejecting wallets, make sure to provide the appropriate backup shares for each curve your application supports.

Security Considerations

After ejecting private keys:
  1. Store them securely - Never share or expose your private keys
  2. Consider the wallet compromised - The MPC security model no longer applies
  3. Create a new wallet if needed - For continued use with Portal, create a new MPC wallet

Use Cases

Private key ejection should only be used in specific scenarios:
  1. Migration - Moving to a different wallet provider
  2. Advanced users - Who need direct access for specific operations
  3. Compliance - Regulatory requirements that mandate key access
And that’s it! Now your users can obtain a private key to import their wallet into another wallet manager. Related Documentation