Multisig requires several keys to authorise spending. Security depends on the threshold, independent holders and policy backups as well as the private keys.
Threshold and availability
Keys are not the whole wallet
Amount, fee and change
Interpret a 2-of-3 quorum
In a hypothetical 2-of-3 policy, two keys can spend. One unavailable key is tolerable; losing two may lock funds, while compromising two may enable theft. A threshold does not distinguish colocated devices from truly independent holders. Consider fire, theft, human error and simultaneous absence before choosing locations.
Back up the policy
A Bitcoin descriptor can describe public keys, derivation paths, scripts and rules used to recognise wallet outputs. Individual seed backups may not easily reconstruct the collective wallet alone. Keep the exact policy and recovery instructions compatible with your tools. Extended public keys cannot sign, but disclosure can reveal wallet activity.
Verify each proposed spend
A PSBT carries a partially signed transaction and information needed for signing. Each participant should verify recipient, amount, fee and change on a trusted display. Multiple signatures do not help when everyone blindly approves the same misleading proposal. The coordinator should not be the only place that holds the policy or verifies details.
Practise with an absent signer
Start with a small test wallet. Receive limited funds, make a normal spend and then simulate one signer’s absence using remaining keys and the backed-up policy. Verify software compatibility and participants’ understanding. Untested backups may be incomplete; keep exercises separate from primary funds.
Distinguish scripts from contracts
Bitcoin script policies and smart-contract collective accounts do not share every property. For contract accounts, inspect modules, owners, thresholds, upgrade mechanisms and network. Message signatures may have application-specific consequences. Read the chosen system’s documentation: the word multisig guarantees neither harmless modules nor automatic recovery.
Prepare policy changes
Changing a Bitcoin policy generally means moving outputs to a new policy. Contract accounts may update owners or thresholds through different procedures. Document proposal, independent review, refusal handling and unavailable signers. During incidents, verify the replacement address and retain needed backups before rotating.
Scenarios and model limits
| Situation | Interpretation |
|---|---|
| 2-of-3: one unavailable key | Remaining keys and policy can enable spending. |
| 2-of-3: two lost keys | Threshold not met; funds may be locked. |
| 2-of-3: two compromised keys | An attacker may meet the spending threshold. |
Frequently asked questions
Are two devices automatically safe?
No. Shared location, seed or operator can create a common failure point.
Is a PSBT itself an authorisation?
No. It transports transaction data; required signatures and transaction validity still matter.
Should public keys be protected?
They cannot sign, but may reveal wallet activity. Limit disclosure and retain policy backups.
Verifiable sources
Bitcoin Developer Guide — Wallets- Bitcoin BIP 174 — Partially signed transactions
- Bitcoin Core — Output descriptors
- Safe — Smart account architecture
Independent educational content reviewed against primary documentation. No personalized recommendation or promise of returns. Updated October 3, 2026
