Global Bit Vision / Knowledge library · Security · 2 min read
Count independent decisions
A multisignature arrangement requires a configured number of authorized signers for specified actions. A two-of-three policy, for example, allows any two participating signers to satisfy the threshold. It can reduce reliance on one key while allowing operation after one signer becomes unavailable.
The protection depends on independent control. Three keys stored on one compromised computer are not equivalent to three people reviewing transactions on separate devices. The diagram’s signer count matters less than the number of genuinely independent failures required to authorize a bad action.
A hypothetical treasury payment
A small organization uses three signers and requires two approvals. A preparer creates a supplier payment. The first signer checks the invoice and destination through a known supplier channel. The second independently inspects network, amount, recipient, and decoded transaction details before signing.
If both simply trust the same compromised dashboard, two signatures can approve one shared mistake. Independent review means using separate evidence for critical facts, not merely clicking the same confirmation on two devices. For a new recipient, an out-of-band verification procedure can matter more than another approval screen.
Now suppose one signer loses a device. The remaining two may be able to replace that owner according to the account rules. They should act through the documented recovery procedure, verify the new address, and preserve an audit trail. Recovery authority is itself sensitive and deserves the same review as spending.
Inspect paths beyond the threshold
Smart-contract accounts can support modules, guards, delegated permissions, and fallback handlers. Some modules authorize activity through a path different from ordinary owner-threshold signing. The account’s full permission model therefore includes enabled extensions, not only the owners listed on the main screen.
A higher threshold also increases availability requirements. A three-of-three policy stops if one signer is unavailable. Choose a policy that reflects travel, illness, employment changes, and emergency needs. Test whether the organization can operate safely during a realistic absence instead of maximizing the number in isolation.
For Bitcoin multisignature arrangements, backup may require policy and public-key information in addition to individual secrets. For contract accounts, network and deployed configuration matter. Recovery documentation must match the actual technology rather than applying a generic “save the seed” instruction everywhere.
Operational checklist
- Separate signer devices, backups, and critical verification channels.
- Document the owner set, threshold, network, and extension permissions.
- Independently verify new recipients and unusual transaction types.
- Practice signer replacement and loss scenarios with a limited-value setup.
- Review permissions after personnel changes or software upgrades.
Keep a transaction log describing who prepared, checked, and approved each important action. It should contain identifiers and rationale without exposing secret material. This makes later incident review possible and encourages signers to exercise judgment rather than serve as ceremonial approvers.
Frequently asked questions
Does two-of-three mean all three must sign first?
No. Any valid combination satisfying the configured threshold can authorize the relevant action, subject to the specific account rules.
Can multisig stop every malicious transaction?
No. Enough compromised or mistaken signers can approve one. Extensions and other privileged paths may also introduce separate authority.