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