# Multisig SOP ## Abstract This document outlines Multisig Standard Operation Practises (SOP). ## Safe Multisig - Must be verified after deployment to ensure it is the actual Safe multisig contract and that it does not include any shadow signers. - There is always a possibility, for example, that a frontend was compromised and a malicious contract ended up being deployed. As such, verification of the contract itself is of high importance. ## Signers - Must use a reasonably secure hardware wallet (e.g., Ledger Flex or Trezor Safe 5), purchased directly from the manufactorer. - This acts as an extra layer of defense in case your computer is compromised. - Must use an unique address generated on the hardware wallet for each multisig. - To ensure they do not sign anything meant for another multisig. - Must not use the address for anything but interacting with the multisig. - To ensure that the address is not compromised. - Must never reveal they are a signer. - To reduce the risk of virtual of physical attacks. - Must never store the seed phrase in digital form, but rather have secure physical backups which should be stored at a secure location different from where the hardware wallet is kept (e.g., a safe deposit box). - To ensure ability to restore the hardware wallet in case of hardware failure. - Should use a dedicated device with a secure OS (e.g., Tails or Qubes) which is only booted up to verify and sign transactions. Must use full disk encryption. Must not be used for generic browsing, messaging, email, social networking, etc. This device must only be used for connecting to the multisig interface, verify the transaction, sign the transaction, then shut down. - Significantly reduces the risk of an attacker gaining control of the system. - Must keep the OS up-to-date with security patches. - Reduces the attack vector. - Must use a read-only OS such as Tails with persistent storage running from an encrypted external USB device such as Kingston IronKey Keypad 200, if no dedicated signing machine is used. - By booting into an OS on a hardware encrypted USB device, an attacker is less likely to obtain control of the OS used to sign. - Must use Signal, with a [PIN](https://support.signal.org/hc/en-us/articles/360007059792-Signal-PIN) set, or other end to end encryption communication system, for coordination and receiving transactions to sign. - Ensures end-to-end encryption, which telegram or discord does not have for groups. - Must be able to recognize phishing, social engineering, and be aware of sophisticated attacks, including but not limited to: Deepfakes (audio, video), Malware that can modify what you see, fake UIs through supply chain attacks, etc. and Hidden code and backdoors in deployed smart contracts - Common attack vectors across the ecosystem. - Must verify that the partly-signed transaction was generated willfully by the intended holder of the first signature's key. - Verify that the transaction is reasonable. If unreasonable or a new type of transaction, it might have been created under duress. - Must notify the coordinator immediately over the secure communication channel if the key is lost or leaked, to allow for swift key rotation. - Ensures the security of the multisig. - Must sign an onchain message to confirm ownership during key rotation, and attend a video call with the coordinator or someone delegated by the coordinator to confirm. - In order to avoid adding the wrong address, or that the multisig owner's secure communication has been compromised. - Must be part of quarterly signing rehearsals in the event that the multisig is used less frequently than that. - This ensures that knowledge stays fresh. - Must be ready to review and approve a transaction within 48 hours of any request. - Must be ready to review and approve a transaction within 24 hours, in case of an emergency. - Must notify the coordinator if you're unavailable to sign transactions for a period of time. ## Verification Steps - Check transaction meaning and intent - Do I understand what this transaction does and how it does it? - Are all the addresses known and verified? - Is this transaction expected? Did the coordinator confirm it on a trusted channel? - Decode and verify transaction calldata, double check that Safe and the wallet you're using to interact with your hardware wallet matches. - For contract interactions, are the parameters correct? You must decode and verify these. - Simulate the transaction - Use the Tenderly or another simulation tool to verify that the transaction does not revert and returns the expected end state. - Generate safe hashes - Use [safe-tx-hashes](https://github.com/pcaversaccio/safe-tx-hashes-util) to generate "domain hash", "message hash", and "safe transaction hash". Verify the output, and watch out for any warnings! - Verify To - Is the To address correct? - Verify Value - Is it the expected value to be sent? - Verify call-type ("Call") - Should normally be Call (0). **Must Not** sign an untrusted DelegateCall (1) as this could give complete control of the multisig to an attacker. - Verify transaction details on the wallet UI - Verify that all fields shown on your wallet match the values shown on the Safe UI. - Check that nonce matches. - Check that operation is set to 0 (i.e. call). - Verify Nonce - Avoid sigining messages with excessively high nonces. Signatures with high nonces will remain valid until natural Safe activity bumps the nonce. - Verify Operation - Should be 0 (call). - Verify safeTxGas, baseGas, gasPrice, gasToken, refundReceiver. - Must be 0. - Verify that safeTxHash, Domain hash, Message hash match the hashes from safe-tx-hashes. - Must match. - Use a newer model hardware wallet with EIP712 support and verify the above details on the wallet. - Must match with what's expected. - Do not use blind signing on your hardware wallet. - Blind signing poses a significant risk. - On your hardware wallet, make sure that Domain hash and Message hash match the hashes generated by safe-tx-hash. - Must match. - Only when you have verified everything, and you are certain that everything checks out, Sign the transaction. ## Monitoring - Each multisig must have monitoring setup, with alerts being sent to dedicated communication channels. - Safe Configuration Change proposals with information about proposed changes (Critical). - Configuration, management, modules and other changes. - Safe Proposal, with detailed information about the proposal (Medium). - Safe Executions (Info). ## Resources - https://help.safe.global/en/articles/276343-how-to-perform-basic-transactions-checks-on-safe-wallet - https://help.safe.global/en/articles/276344-how-to-verify-safe-wallet-transactions-on-a-hardware-wallet - https://github.com/pcaversaccio/safe-tx-hashes-util