Design a Multi-Sig Vault Protocol

Problem statement

Design a multi-sig vault protocol that lets a defined group of signers collectively control digital assets. Funds may only move when a configurable threshold of keys (for example 2-of-3, 3-of-5, or 4-of-7) authorize the same exact transaction. The system must create proposed transactions, collect partial authorizations, aggregate or verify them against the threshold, broadcast only valid fully-authorized transactions, and let owners change the signer set and threshold through an equally protected governance flow.

This is not a single-user wallet. A vault is a financial consensus object: multiple humans, possibly in different organizations, time zones, and trust domains, must agree on the exact bytes of a movement before it becomes irreversible. The product must therefore combine three disciplines that rarely live together: cryptographic threshold policy, transaction lifecycle orchestration, and institutional-grade key custody.

Why the problem is distinctive

A payments app can roll back a mistake. A blockchain transaction cannot. Once a fully-signed transaction is broadcast and confirmed, the movement is final. The design therefore separates proposal authorization from execution finality. Proposal authorization is a reversible, eventually-consistent workflow: created, confirmed, revoked, expired, executed. Execution finality is an invariant: the network accepts only one exact transaction payload whose authorizations satisfy the current threshold policy at execution time.

The second distinction is that the signers themselves are part of the threat model. Unlike a web service where the database trusts the application, a vault must assume that some signers may be malicious, coerced, offline, or holding compromised keys. The protocol must tolerate up to threshold-minus-one compromised keys without asset loss, and it must survive signer unavailability without a centralized override.

Public operating baseline

Public evidence establishes that this category is operationally central to crypto. Safe's deployed contracts report over 100 billion dollars in cumulative secured assets and the Safe smart accounts are the most deployed smart-account contracts on Ethereum, used by DAOs such as Uniswap, Aave, and thousands of treasuries. Fireblocks states it has supported trillions of dollars in transfer value for over two thousand institutions, and its MPC custody design publishes the use of key shares split by ECDSA threshold signing. BitGo reports securing over eighty billion dollars in assets under custody at various public snapshots and pioneered on-chain 2-of-3 multisig for exchange reserves in 2014. These are cited company figures for context, not the targets of our design.

For capacity planning this answer assumes a mature protocol layer: 250,000 deployed vaults, 40,000 active vaults per day, 180,000 proposals per day, and a five-times event peak around governance votes and market volatility. Unless a number is tied to a public source, it is a stated design assumption.

The four architectural planes

1. Policy plane: the threshold definition, signer set, spending limits, time locks, and module permissions. This is the constitution of the vault.
2. Transaction plane: proposal creation, payload normalization, confirmation collection, execution, and index state.
3. Custody plane: key generation, share storage, signing ceremonies, hardware and cloud protection of every signer identity.
4. Operations plane: off-chain indexing, notifications, simulation, audit, support, and recovery.

A strong interview answer keeps these planes separate. It allows the transaction plane to degrade without weakening the policy plane, and it lets the operations plane observe everything without ever gaining the ability to forge an authorization.