Embedded wallets reside in a Fireblocks workspace that includes custodial Vault Accounts assigned to the customer. Each embedded wallet has its separate keys. Also, the workspace includes one master key to serve the customer’s vault accounts (not connected to the end user wallets). Fireblocks embedded wallets use a 2-of-2 MPC signature scheme. One key share resides in an Intel SGX-enabled server managed by Fireblocks, and the other resides on the end user’s device.

​

Structure

The Fireblocks workspace can include an unlimited number of embedded wallets and an unlimited number of wallet accounts inside each embedded wallet. Each wallet account can hold as many asset wallets as you need. However, you can only have one type of wallet asset per wallet account. You can also use our non-custodial embedded wallets in parallel with self-custodial wallets. One workspace can support both structures.

​

Secret key management and wallet derivation

The derivation for non-custodial embedded wallets is almost the same as for self-custodial wallets. Each asset in an embedded wallet is derived according to the following structure: m/purpose/coinType/account/change/index, where:

• m is the master private key
• purpose is the derivation standard (BIP-44 in our example)
• coinType is the unique identifier of an asset (0 for BTC, 60 for ETH, etc.)
• account is the vault account ID
• change is always 0
• index is the address index (always 0 except for UTXO-based assets)

For Non-Custodial Wallets, Bitcoin wallets can only have one deposit address per account, unlike self-custodial wallets which can have more than one. This means that for any account, the derivation path for the BTC asset in it will always be m/44/0/accountId/0/0.

​

Unsure about which custody model is best for you?

Read our Guide to Digital Asset Wallets and Service Providers for insights into evaluating digital asset wallets and service providers for your business.