A multisignature wallet requires a specified number of authorised signatures to approve spending or another action. A two-of-three policy, for example, accepts any two of three designated signers. Such a policy can support shared custody, organisational approval, or recovery. With a threshold greater than one, a single key cannot authorise spending.1

Bitcoin scriptsReport an errorSuggest an improvement

BIP 11, assigned in October 2011, specified a standard form for M-of-N-signature Bitcoin transactions. Its motivating examples included wallet protection services and escrow. A threshold below the full number of keys permits some signers to be unavailable; requiring every signer offers no such tolerance.1

BIP 16 introduced pay-to-script-hash, which lets a sender pay to a hash of spending conditions rather than supplying the full conditions when making the payment. The redeemer provides the script and evidence needed to satisfy it. P2SH can represent multisignature conditions, but is a general script mechanism rather than a synonym for multisig.2

Coordinating signatures also requires a way to exchange transaction information. BIP 174 defines the Partially Signed Bitcoin Transaction format, or PSBT. It carries the information needed by signers and can combine partial signatures across software or devices, including offline signers. A PSBT coordinates authorisation; it does not remove the need to inspect the proposed transaction.3

Contract accountsReport an errorSuggest an improvement

An Ethereum smart-contract wallet can maintain an owner list and enforce a signature threshold in code. Safe's documented design supports changing both owners and the threshold through authorised operations. The account itself is a contract, so its authority is determined by its code and configuration rather than a single account private key.4

Additional execution paths can modify the security model. Safe modules, for example, can authorise actions under their own rules after being enabled. Safe warns that a malicious module can take over an account. Evaluating the displayed owner threshold alone is therefore insufficient for an account with enabled extensions.5

Failure modesReport an errorSuggest an improvement

Multiple approvals protect against some individual-key failures, but cannot establish that the approved action is desirable. Investigator Sygnia's account of the February 2025 Bybit incident describes injected JavaScript manipulating a transaction during signing, leading to a malicious replacement of the wallet's implementation. Its investigators found the injected resources on all three signers' hosts.6

The incident illustrates the distinction between independent keys and independent checks. Signers who all rely on the same misleading interface can approve the same harmful instruction. Wallet security consequently depends on what each signer verifies as well as how many signatures the contract or script requires.6

See alsoReport an errorSuggest an improvement

ReferencesReport an errorSuggest an improvement

  1. ^ a b Andresen, G. (2011). BIP 11: M-of-N Standard Transactions. https://bips.dev/11/ 

  2. ^ Andresen, G. (2012). BIP 16: Pay to Script Hash. https://bips.dev/16/ 

  3. ^ Chow, A. (2017). BIP 174: Partially Signed Bitcoin Transaction Format. https://bips.dev/174/ 

  4. ^ Safe documentation. Smart Account Concepts. https://docs.safe.global/advanced/smart-account-concepts 

  5. ^ Safe documentation. Safe Modules. https://docs.safe.global/advanced/smart-account-modules 

  6. ^ a b Sygnia. Sygnia’s Investigation into the Bybit Hack: What We Know So Far. https://www.sygnia.co/blog/sygnia-investigation-bybit-hack/