I have been working on managing digital assets across multiple blockchains. Currently, I’m dealing with Bitcoin, Ethereum, and a few others, and I’ve noticed that as I expand the number of chains, managing all the wallet integrations is becoming a bit of a challenge.
I have a few questions regarding the best practices for integrating wallets efficiently when working with multi-chain assets:
Wallet Management Across Chains: Is there an easy way to manage wallets for different blockchains within the Fireblocks platform? For example, should I be setting up separate wallets for each chain, or is there a more streamlined way to handle everything in one place?
Security Considerations: With multiple wallets on different chains, what are the key security practices I should be following? Are there specific settings in Fireblocks that I should enable to enhance security for multi-chain operations?
Automation and Efficiency: Are there any automation features available in Fireblocks that could help reduce the manual work involved in managing transactions across multiple chains? If so, how can I set them up?
General Recommendations: For those who are managing assets across multiple blockchains, do you have any general tips or recommendations to make this process smoother?
Hey @jivijet278! Yoji from the Fireblocks team here.
Great questions! I want to take a moment to break down the Fireblocks workspace structure before we fully dive in. Fireblocks has a general structure for how it “organizes” your assets: a workspace can hold vaults, which in turn can hold a single asset wallet per asset/protocol. Certain assets may also support creating additional deposit addresses or memo tags to track deposits. This is an important structure, as while there is one set of two “master” private keys (EdDSA and ECCDSA) that is used when generating keys for the workspace, each vault derives its own set of private keys to generate the private/public key pairs for each asset wallet in the workspace.
This “segregated” vault structure means each vault’s blockchain addresses will be unique to that vault, which is desirable in case you have end users who will make crypto deposits and each user can be assigned a single vault with unique addresses to deposit to. Then, if needed, you can sweep deposited funds to a single “omnibus” wallet, which would centralize funds from different wallets to be processed as needed (additional “central” wallets you can consider would be a withdrawal vault with minimal funds or a DeFi wallet for on-chain work). This type of architecture allows you to track individual deposits through user vaults, and at the same time simplifying account management by having them centralized in an omnibus vault for treasury/investment management.
Generally, we recommend a “Sweep-to-Omnibus” architecture for users building retail wallet services, token projects, and for some treasury management use cases. I’d be happy to dive deeper with you on this if you can clarify your specific use case.
Now, diving into your questions:
Wallet Management Across Chains: As explained above, this will greatly depend on your use case. Nonetheless, it’s recommended to segregate vaults by their use case regardless of if users have individual vaults. For example, in the Sweep-to-Omnibus architecture, it’s still recommended to have a separate DeFi vault only holding the immediately needed funds (to protect against, for example, smart contract risk due to open balance approvals or interactions with malicious dApps). This will also help you manage your assets across chains as funds can be centralized according to their use cases.
Security Considerations: I would recommend setting strict Transaction Authorization Policy (TAP) rules to ensure strict controls over where your assets move, who is allowed to move them, and if any secondary checks should be made. Additionally, if you’re frequently bridging assets/interacting with dApps, I would create an specific vault account for these operations. You can then add more targeted TAP rules for this vault, like the dApps it’s allowed to interact with or the amounts that can be transferred out at a time/over a time period. Additionally, you can set an “Approval Cap” to limit the amount dApps are allowed to send approval requests for, so no open “max value”-style approvals are made.
Automation and Efficiency: Certainly! We have the “Payments Engine,” which allows you to create automated flows, like initiating payouts to different wallets, moving assets to exchanges, performing conversions. We also have an Automation engine on the roadmap (ETA Q4 '24) that will give you functionality to perform different actions like transfers, sweeps, top-ups, conversions, and triggering payment flows based on time, value, or deposit-based triggers. Of course, you are always welcome to build your own automations via our API.
General Recommendations: It’s difficult to make general recommendations without understanding your specific use case(s), if you’d like to elaborate I’d be happy to provide some more specific recommendations!
