---
# System prepended metadata

title: Multisig Best Practices

---

---
title: Multisig Best Practices
version: 2023.05.29
author: Sam Bacha, et al.
---

# Multisig Best Practices

> v2024.07

> **Action Items**
    > Local Machine conformance enforcement
    > Dry run practices
    > Hardware safeguards

## Abstract

This appendix summarizes the best practices for the use of a 2-of-3 multi-signature wallet where the authority to execute a transaction requires a consensus of two individuals in possession of two of the wallet’s three private keys.

0. A wallet is successful if the owner can use it but an adversary can't.

1. The private keys must be stored or held separately, and each must be respectively access-limited to separate individuals.

2. Multiple keys should not be stored with the same custodian. For example, if the keys are physically held in the custody of a third party (e.g., a bank), then no more than one key can be custodied in that bank. Doing so would violate best practice #1.

3. The second signatory (a.k.a. the co-signer) must refer to a policy established beforehand specifying the conditions for approving the transaction before signing it with their key.

4. The co-signer should verify that the half-signed transaction was generated willfully by the intended holder of the first signature’s key.

### MultiSig Optimal Creation

We use the wallet configuration wizard defined in this paper: "On Cryptocurrency Wallet Design
by Ittay Eyal" https://eprint.iacr.org/2021/1522.pdf

Frontend located here: https://crypto-wallet-designer.github.io/crypto-key-calculator/

This tool computes the success rate of a crypto wallet based on the fault probabilities of its keys.

## Policy for Transaction Validation

Best practice #3 prevents the co-signer from becoming merely a “deputy” acting on behalf
of the first (forfeiting the decision responsibility back to the first signer, and defeating the security model). If the co-signer refuses to approve the transaction for any reason, then the due-diligence conditions for approval may be unclear. That is why a policy for validating the transaction is needed. Example verification policy rules may include:

- A predetermined protocol for being asked to cosign (e.g., a half-signed transaction
will be accepted only via an approved channel).

- An allowlist of specific actions that can be performed by the wallet.

- A threshold for the number of transactions that can be executed on a given day,
week, etc.

Best practice #4 mitigates the risk of a single stolen key. In a hypothetical example, an
attacker somehow acquires the unlocked Ledger Nano of one of the signatories.

### Duress / Safeword 

A voice call from the co-signer to the initiating signatory to confirm the transaction will reveal that the key has been stolen and that the transaction should not be co-signed. If under an active threat of violence, a “duress code” (code word, phrase, or other system agreed upon in
advance) can be used as a covert way for one signatory to alert the other signers of an issue.

#### Warrant Cannary

Usage of Warrant Cannary is advised for escliated policy identification for duress levels.


## Operational Safeguards 

> Note that each multi-signature wallet used by the team should be treated independently of
the others. Thus, each wallet should have its own policies for transaction validity and
storage.


## Citations

> MultiSig Contract
> Eyal, Ittay. “On Cryptocurrency Wallet Design,” 2021. Cryptology ePrint Archive. https://eprint.iacr.org/2021/1522.
