Trezor Shared Custody Models: Setting Up Escrow Without Trusting a Third Party

A family office has $2 million in cryptocurrency across multiple networks. No single person should have unilateral control, yet the treasury operator, compliance advisor, and chief investment officer all need to approve withdrawals above a certain threshold. A traditional escrow service would hold the keys or have visibility into the accounts—an unacceptable concentration of risk. A multisignature arrangement with independent hardware wallets solves the problem structurally: each signer uses their own device, approval requires a specified quorum, and no single party can move funds alone or see the others’ private keys.

This is not theoretical. Institutional investors, family offices, nonprofits, and business partnerships increasingly use multisignature arrangements to distribute custody responsibility without introducing a trusted intermediary. The mechanism relies on mathematical consensus rather than institutional reputation, meaning that even if one participant is compromised, the remaining signers can still block unwanted transactions. Trezor hardware wallets are designed to participate in these arrangements through self-custodial key management, where each device holds one signing key and the device owner retains permanent control. Setting up a functional multisig system requires understanding key distribution, quorum mechanics, address generation, and the operational discipline needed to execute this model reliably.

Why multisignature differs from standard hardware wallet use

A single-signature hardware wallet concentrates security in one device and one recovery seed. If the seed is backed up securely and the device is not stolen or physically compromised, that model works. The attack surface is limited to direct device access, supply chain compromise, or loss of the recovery seed. Multisignature redistributes that responsibility across multiple independent signers, so the compromise of one device or seed does not immediately threaten the funds.

The trade-off is operational complexity. A single-signature wallet requires one person to manage one recovery seed and one device. A 2-of-3 multisig arrangement requires three people to each manage their own recovery seed and device, coordinate on which transactions to approve, and maintain operational discipline across all participants. The mathematical strength—that an attacker must compromise two devices or seeds simultaneously—comes with the practical burden of distributing authority across multiple parties who may have different security practices, availability constraints, and expectations about decision-making speed.

Trezor supports multisignature arrangements through extended public keys (xpubs), which are cryptographic commitments to a signing key that allow address generation without exposing the private key itself. When setting up a 2-of-3 or 3-of-5 arrangement, each participant creates or imports a wallet on their device, derives the appropriate key material, and shares their xpub with a coordinator. That xpub allows the group to generate shared addresses that require multiple signatures to spend, but no participant ever reveals their private key or recovery seed to anyone else.

The difference from a traditional account or escrow service is decisive. An escrow agent holds keys directly or controls transaction approval. A multisig coordinator sees xpubs and can construct addresses and transactions, but cannot sign them without devices physically present. Private keys remain on the hardware and are never transmitted, shared, or reconstructed.

Structuring a 2-of-3 multisig with Trezor devices

A 2-of-3 arrangement is common for small teams or family treasuries. The interpretation is straightforward: any two signers can approve a transaction, but no single signer can move funds unilaterally. This offers redundancy—if one participant loses their device or becomes unavailable, the other two can still act—while preventing either of the remaining two from proceeding without the third’s consent.

The setup process begins with each participant acquiring an independent Trezor device and creating a recovery seed. That seed is written down and stored offline according to each person’s own security practices. The choice of where to store the seed—a safe deposit box, a home safe, a geographically separated location—is each person’s responsibility. Trezor does not mandate a specific backup method; the point is that the seed remains under each participant’s control and is not stored in a cloud service, email account, or shared location.

Once each device is initialized, each participant derives their extended public key. This is done through Trezor Suite or the Web interface, by navigating to the multisignature setup section and generating the xpub for the appropriate key path. The xpub is a long alphanumeric string that can be safely shared. It represents a commitment to the private key without exposing the private key itself. When an attacker sees an xpub, they cannot derive the corresponding private key or predict future signatures.

The three xpubs are then shared with a coordinator—typically the person responsible for constructing transactions and managing the joint wallet interface. The coordinator imports all three xpubs into a multisig wallet configuration using Trezor Suite or a compatible third-party tool such as Electrum or Sparrow. The software derives the shared addresses that require 2 of 3 signatures, shows the current balance, and provides a transaction template when a withdrawal is needed. When a transaction is ready, the coordinator prepares it and sends it to two of the three signers, either by exporting a file or displaying a QR code that can be scanned.

Each of the two approving signers connects their Trezor device, reviews the transaction details on the device screen, and confirms approval. The device signs internally without ever exposing the private key. The signed transaction is broadcast to the blockchain through the coordinator’s software. The funds have moved without any single person controlling the process unilaterally.

Scaling to 3-of-5 and larger arrangements

A 3-of-5 multisig requires three signers out of five to approve each transaction. This model is appropriate for larger organizations or situations where availability matters more than strict consensus. If one or two participants are unavailable due to illness, travel, or turnover, the remaining three can still act. The flip side is that no individual has a veto: if three of the five agree, the funds move regardless of the dissent from the other two.

The setup procedure is identical in structure to 2-of-3, but scales to more participants. Each of the five people creates or imports a Trezor device, derives their xpub, and shares it with the coordinator. The coordinator combines all five xpubs into a 3-of-5 configuration and derives the shared addresses. When a transaction requires approval, the coordinator sends it to three signers, and once three have confirmed, the transaction broadcasts.

Larger multisigs introduce new operational considerations. With five signers, reaching consensus may be slower because scheduling three people to review and approve a transaction can require more coordination. The identity and availability of each signer becomes critical information that must be managed—who holds key one, key two, key three, and where do they live or work? If the coordinator loses that information, they may construct a transaction and not know how to reach enough signers quickly. Documentation and a clear operational manual therefore become essential.

The number of signers also affects security in subtle ways. A 3-of-5 arrangement tolerates compromise of two keys, which is better security than 2-of-3 tolerates one. However, it also means that an attacker needs to compromise three different devices or seed backups to unilaterally steal funds. Depending on the physical security and backup practices of the participants, that might be easier or harder in practice. A 2-of-3 in which all seeds are stored with equivalent precautions may actually be stronger than a 3-of-5 in which some participants keep their seed on a desk.

Distributing keys and maintaining the wallet backup

The most critical operational task in a multisig arrangement is ensuring that each participant’s recovery seed is backed up securely and that the multisig wallet configuration itself can be recovered if needed. Recovery seeds are individual to each device and should never be shared. Each participant is responsible for their own backup.

The multisig wallet configuration—the combination of xpubs and the rule set—should be documented and stored in a way that any participant or a designated successor could recover it without relying on the coordinator. That documentation should include the xpub of each signer in a clearly labeled format, the derivation path used (typically m/45h/0h/0h for multisig), the quorum rule (2-of-3 or 3-of-5), and instructions for importing the configuration into compatible software if needed.

A practical approach is to create a document that each signer receives. It lists all five xpubs, explains how to verify them (for example, by checking against the signed message from each participant), and provides step-by-step instructions for reconstructing the multisig wallet in Trezor Suite, Electrum, or another tool. This document can be stored openly because it contains no private keys—only the public commitments that are necessary to reconstruct the shared addresses.

The distinction between the recovery seed and the wallet configuration is important. The seed allows someone with a Trezor device to recover the private key and recreate the xpub. The wallet configuration allows someone with all xpubs to recreate the shared addresses and see the balance, but not to sign transactions. Together, they form the complete backup, but neither one alone is sufficient to steal funds or reconstruct the wallet unilaterally. This separation is a feature, not a limitation: it means that losing the configuration document does not expose anyone’s private key.

Transaction approval workflow and device verification

When a withdrawal is ready, the coordinator constructs a transaction showing the destination address, amount, and network fee. Modern non-custodial wallet software such as Trezor Suite displays a transaction preview before sending it to signers, allowing the coordinator to verify the details themselves before asking others to sign. This reduces the risk that a compromised coordinator can silently alter a transaction between creating it and requesting approval.

Once two or three signers have been identified, the coordinator exports the unsigned transaction or displays a QR code representing the transaction data. Each signer, in turn, connects their Trezor device and reviews the transaction details on the hardware device screen. This is a critical control point: the signer sees the destination address, amount, and fee on the device itself, not on the computer screen, which could be compromised. If the details match the instruction they received from the coordinator, they approve. If something looks wrong, they reject.

The security of this step depends on the signer actually reading and understanding the device display. An attacker who has compromised the coordinator’s computer can change the address shown on screen, but cannot change what the Trezor displays—that comes directly from the device’s internal verification of the transaction. If a signer blindly approves without reading the address, that protection is lost. Operational discipline is therefore a requirement, not an optional extra.

Once two signers have approved, the transaction is broadcast. The blockchain confirms it, and the funds have moved. There is no undo and no recovery, so the approval process must include a final sanity check. Some organizations require a delay between approval and broadcast, allowing signers to cancel if they notice an error. Others require email confirmation of each approval before the next step. These are additional procedural controls that vary by organization and risk tolerance.

Recovery scenarios and key rotation

A multisig arrangement that lacks a documented recovery plan is incomplete. Practical scenarios to plan for include: one signer loses their device and recovery seed, one signer becomes unavailable (death, departure, incapacity), the coordinator loses the wallet configuration, a participant suspects their device was compromised, or the team decides to add or remove signers.

If one signer loses their device and recovery seed, that person can create a new Trezor device, generate a new xpub, and the remaining signers can migrate the funds to a new multisig address that incorporates the new xpub. This requires the non-affected signers to approve a transaction moving all funds to the new configuration. The old signer is replaced without exposing the funds during the transition.

If one signer becomes unavailable but the recovery seed is accessible, a designated successor can import the seed into a new device and take over that signer’s role. Alternatively, the remaining signers can vote to remove that key from the arrangement by migrating to a new multisig address.

Replacing a signer in a 3-of-5 arrangement is simpler than in a 2-of-3 because the remaining four signers can still act—they approve a transaction to a new multisig address that includes the new signer’s xpub and excludes the old one. In a 2-of-3, if one signer is unavailable, the remaining two must cooperate to migrate. This is why some organizations prefer 2-of-3 for maximum security against single compromise, while others prefer 3-of-5 for better operational resilience.

Planned key rotation—replacing a signer’s device or xpub on a schedule, even if nothing has gone wrong—is possible but requires the same migration process. Some organizations rotate keys annually; others only when needed. The trade-off is between reducing the window of exposure if a key has been compromised without the owner’s knowledge, and the operational complexity of coordinating migrations.

Choosing the right coordinator software and avoiding pitfalls

Trezor Suite is the official software and offers native multisig support, but it is not the only option. Electrum, Sparrow Wallet, and other multi-crypto wallet applications also support Trezor multisig arrangements. The choice affects usability, available features, and where the coordinator and signers interact.

Trezor Suite is browser-based and can be accessed through a web interface or downloaded as a desktop application. The web version eliminates installation complexity but relies on browser security. The desktop version is more isolated but requires installation and updates. Electrum is a desktop application with a long history and strong multisig support, especially for Bitcoin. Sparrow Wallet is newer and focuses on privacy and control. All three support similar multisig models: the coordinator constructs and broadcasts transactions, and signers approve them by connecting their devices.

The key pitfall is mixing coordinator and signer software in ways that create compatibility issues. If the coordinator uses Electrum to construct a transaction, but a signer tries to approve it in Trezor Suite, the transaction format may not transfer cleanly. Testing the workflow with a small test transaction before moving real funds is essential. That test should include constructing a transaction with the actual coordinator software, exporting it, importing it to each signer’s software, and confirming that the signer can review and approve the same transaction.

Another common mistake is storing the xpubs or configuration document insecurely. Because xpubs can be derived from public information, it might seem harmless to email them or store them in a cloud service. In practice, a synchronized list of all five xpubs in an email account is a treasure map for an attacker. If they compromise the email account and then compromise one device or seed, they know exactly what address to monitor and can track the full balance without needing to compromise additional devices. Treat the configuration document as sensitive even though it contains no private keys.

Implementing multisig within institutional or family frameworks

A family office or institutional implementation should combine hardware security with governance procedures. The hardware—independent self-custodial wallet devices with offline keys—provides the technical barrier. The governance—a decision-making process, approval authority, and documentation—provides the operational control.

A sample framework for a family office might specify that the chief financial officer, one family member, and an external advisor each hold a signing key. Any two can move funds, but no individual can act alone. The procedures would include: a written request from an authorized person, review of the destination address and amount by the coordinator, email confirmation from two signers, a 24-hour delay before broadcast, and a requirement that all three participants receive a notification of the transaction before settlement. This layering of controls reduces the risk that an attacker who compromises one device or email account can steal funds undetected.

For a nonprofit with a board of directors, a 4-of-7 arrangement might be appropriate—any four of seven board members can approve, but a minority cannot. The process might include a written board resolution authorizing the transaction, verification of the address by a second board member, and approval by four signers within a specified timeframe. The recovery procedures would specify that if a board member departs, a successor is named within a defined process.

The coordinator role should be clearly assigned and potentially rotated. If the same person is always the coordinator, they become a central point of failure—an attacker who compromises that person’s computer can modify transactions between creation and approval. Rotating the coordinator, or requiring two coordinators to sign off on each other’s work, mitigates that risk. Some organizations use a separate device or machine solely for coordination, never for approval, to reduce the attack surface.

Documentation is critical because turnover is inevitable. If the original participants leave, their successors must understand the system. A multisig wallet that works perfectly as long as the founders are available, but becomes incomprehensible after they depart, is a failure. Every wallet backup procedure, recovery process, and approval workflow should be documented in a way that a person with reasonable technical competence could follow a year later, even if none of the original architects are available.