On February 14, 2024, Fireblocks announced Multi-Device Sync for its Non-Custodial Wallet-as-a-Service platform, solving one of the most persistent pain points in Web3 user experience — accessing a single self-custody wallet across multiple devices without compromising security. For developers building crypto applications and advanced users managing portfolios across phones, tablets, and desktops, this represents a significant leap forward in how self-custodial wallets operate. This tutorial walks you through the technical architecture, implementation steps, and security considerations of multi-device wallet synchronization.
The Objective
The goal is straightforward but technically demanding: enable a user to access the same self-custodial wallet — with the same addresses and private key material — from up to 11 different devices without ever storing private keys on a centralized server. The challenge is that true self-custody requires private keys to remain on the user’s device. Moving keys between devices typically means either exporting seed phrases (security risk) or using a centralized key management system (not true self-custody).
Fireblocks solves this using Multi-Party Computation (MPC) cryptography. Instead of a single private key stored in one place, the key is split into multiple shares distributed across devices. No single device ever holds the complete key, and transactions require cooperation between multiple key shares to sign.
Prerequisites
Before implementing Multi-Device Sync, ensure you have the following: a Fireblocks developer sandbox account, familiarity with the Fireblocks Non-Custodial Wallet SDK, iOS or Android development environments set up with Xcode or Android Studio, Node.js 18+ for backend integration, and a basic understanding of MPC cryptography concepts. You will also need at least two test devices — the primary device where the wallet was originally created and a secondary device you want to sync.
From a user perspective, Bitcoin currently trades at approximately $51,826 and Ethereum at $2,777. With significant assets at stake, implementing proper multi-device wallet security is not just a convenience feature — it is essential infrastructure for any serious crypto application.
Step-by-Step Walkthrough
Step 1: Initialize the primary wallet. When a user creates a wallet on their primary device, the Fireblocks SDK generates key shares using MPC-TSS (Threshold Signature Scheme). One share stays on the device, encrypted with the user’s biometric or PIN authentication. Another share is held by the Fireblocks co-signer service. The combination of these shares enables transaction signing without either party holding the complete private key.
Step 2: Generate a sync request. When the user wants to add a second device, the primary device generates a sync request containing an encrypted payload. This payload is encoded into a QR code that the secondary device scans. The QR code contains no private key material — only a session identifier and a public key for establishing an encrypted communication channel between the devices.
Step 3: Authenticate on the secondary device. After scanning the QR code, the secondary device must complete authentication. Developers can configure multiple authentication methods: a passphrase, a PIN code, biometric verification (fingerprint or Face ID), or two-factor authentication via SMS or authenticator app. This step ensures that even if someone gains physical access to the primary device, they cannot add unauthorized devices.
Step 4: Key share derivation. Once authenticated, the secondary device generates its own key share through a secure MPC protocol with the Fireblocks co-signer. This new share is mathematically linked to the original wallet — both shares can participate in signing transactions for the same addresses. The primary device’s key share remains unchanged throughout this process.
Step 5: Verify synchronization. Test the setup by signing a transaction from each device independently. Both should generate valid signatures for the same wallet address. Verify that the address matches the original wallet and that the transaction appears in the mempool when broadcast. If any step fails, the devices are not properly synced and the process should be restarted.
Troubleshooting
QR code scan fails: Ensure both devices are on the same network and that the sync request has not expired (default timeout is 5 minutes). Check camera permissions on the scanning device. If using a web SDK, ensure the browser supports WebRTC for peer-to-peer communication.
Authentication loop: If the secondary device repeatedly asks for authentication without completing sync, clear the local cache on both devices and regenerate the QR code. This typically resolves state synchronization issues in the MPC protocol.
Transaction signing fails on secondary device: Verify that the key share on the secondary device was properly derived. Check the Fireblocks console for error logs — failed key derivation usually indicates a network interruption during the MPC ceremony. Remove the secondary device and re-sync.
Device limit reached: The system supports up to 10 additional devices per wallet (11 total including the primary). If you hit the limit, you must remove an existing device before adding a new one. Device removal revokes the key share on that device, preventing it from signing future transactions.
Mastering the Skill
Once you have basic multi-device sync working, explore advanced configurations. Implement custom authentication flows that require multiple devices to co-sign transactions above a certain threshold — effectively creating your own multi-signature wallet with MPC under the hood. Set up automated key rotation schedules that periodically refresh key shares without changing wallet addresses, providing forward-looking security against key compromise. Consider integrating hardware security modules (HSMs) on the backend to add an additional layer of protection for the co-signer service. The Fireblocks WaaS platform provides the cryptographic primitives — how you compose them into a security architecture is where the real engineering challenge lies.
Disclaimer: This article is for informational purposes only and does not constitute financial or security advice. Always conduct your own research before implementing wallet solutions.
WaaS without centralized key storage has been the holy grail since 2019. fireblocks actually shipping it is a milestone
guardian recovery assumes your friends actually keep their devices online. mine would lose theirs at a bar week one lol
guardian recovery is cute until you ask 3 friends to install an app and keep it running for 2 years straight. seed phrases suck but at least they dont ghost you
11 devices synced without storing keys on a central server is actually impressive. been waiting for someone to solve this properly
11 devices is the theoretical max. practical limit is more like 4-5 before key fragment latency gets annoying
threshold_boy 4-5 devices is plenty for most users. phone, laptop, tablet, work machine. 11 is overkill and probably hurts UX with sync latency. the sweet spot matters more than the max
agreed, but the real question is how they handle key recovery if you lose your primary device. the article glosses over that part
the recovery flow uses social recovery with guardian devices. lose your primary and 2 of 3 guardians can reassemble. not perfect but better than seed phrases
^ key recovery is the elephant in the room. lose your primary device and the recovery flow better be bulletproof or its all over
device_sync key recovery is the hard problem nobody talks about until they lose a device. the guardian approach works but what happens when guardians go offline? need a fallback that doesnt involve seed phrases
recovery_node_ guardians going offline is the real edge case. Fireblocks uses MPC threshold so you need a quorum of device shares. lose enough devices and the fallback is still a seed phrase whether they advertise it or not
self-custody across 11 devices without central key storage. MPC threshold cryptography is finally getting user-friendly
the real test is latency on transaction signing across devices. if it takes 30 seconds to approve a swap nobody will use it
Anika B. signing latency on MPC across 4 devices is around 2-3 seconds in practice. the 11 device max is a spec sheet number nobody will actually use. 3-4 devices covers 99% of real workflows