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

# Multisig Best Practices

> Contract Source Link: <TODO></TODO>

> **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.

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.

## 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
>