Multisig wallets are becoming increasingly popular, with Safe activity on the rise (crossing over $100B in TVL at the time of writing this article) it is important to have a streamlined process surrounding your multisig transactions. Is a simple message in Discord enough to get your multisig signers to spin up a transaction without hesitation? If you are a signer or an owner of a multi-sig wallet, ask yourself these questions:

1. Is there a set of guidelines or rules that are in place about what kind of transactions can even be proposed/signed?
2. Are the signers subject to a set of rules before signing their signature such as using a Hardware wallet or a Wallet Security Extension?
3. Is the Vault, Signer list, and rules maintained properly? 

If you’re not sure, then implementing an SOP (Standard Operating Procedure) for your Multisig vault is probably the best bet to securely move forward. There are all kinds of considerations that go into it, and most of those we’ve baked into the SOP itself. We toss in some optional “advice” as part of the SOP, but of course, you are free to edit this as you choose! Also, we will try to keep this article updated as SAFE releases apps and features within the platform to help technically enforce some of these requirements. This list isn't exhaustive and doesn't take into account some of SAFE's already existing features, but hopefully it will at least get you started!

[Title of the Standard Operating Procedure]

Objective:
{Use this section to spell out your objectives. We’ve included an example here}

The objective of this procedure is to ensure the integrity and legitimacy of transactions through a standardized process of multisig signing, thereby minimizing the risk of unauthorized or erroneous transactions. Some common considerations and setups for multisigs are explained in the official SAFE documentation here. This SOP builds upon these and outlines requirements for signers, transaction processes, and multisig wallet maintenance. 

The Signer

Prerequisites For Multisig Signers:

{These are the rules that every Multisig signer needs to follow to be a signer. Unfortunately, most of these are hard to verify so you’ll just have to get the signer's word for it!}

In order to become a multisig signer, individuals must meet the following requirements:

• Use of a Wallet Security Extension (e.g., Pocket Universe, Mint Defense, Wallet Guard, Fire).
• Utilization of a hardware wallet (e.g., Ledger, Trezor) for signing.
• Implementation of non-SMS 2FA (Time/App Based 2FA like Google Auth or Authy) for {Messaging Platform} Accounts.
• Completion of at least one Boring Security Class 😉

Adding a Signer:

{How Do Signers get added and removed? How are you ensuring new signers follow the rules?}

• Before adding a new signer, the transaction initiator must verify the above prerequisites with the individual and attain board approval.
• All New Signers must be given a copy of this SOP (and sign it, or broadcast a signature attesting to it w/ Etherscan, Signer.is or similar).

The Transaction Process:

{How do transactions get proposed? How do users verify that they know what changes will occur within the wallet as a result of the transaction?}

Transaction Initiation Rules:

• Transactions should only be communicated via the approved {Messaging Platform} with the IDs listed in Appendix B.
• Transactions above the Transaction Thresholds in Appendix A must be confirmed on the secondary {Messaging Platform} in Appendix B and require additional confirmation from [Group or Quorum]
• Signers should be available every [designated time] for signing.
• Certain transactions (e.g. standard compounding functions) don’t require approval. (claim + restake to approved contracts in Appendix A.)
• Transactions must adhere to specified contracts and functions outlined in Appendix A.

Transaction Guidelines:

• Transactions above a certain threshold require confirmation from [Group or Quorum].
• Changes to transaction rules or approved contracts and methods require [Rule or Process].
• Utilization of the 'Transaction Builder' is encouraged to reduce errors and gas costs when multiple actions are needed.

Multisig Vault Review Process:

{How do you deal with inactive signers? How do you update approved contracts or methods? Do you have unnecessary open approvals adding additional risk to your vault?}

Vault Configuration:

• Utilize an m-of-n configuration for multisig signers that ensures speed that utilizes the proper amount of signers (m represents the minimum number of signers needed, and n refers to the number of total signers).
• Create processes to edit the allowed transaction types as needed.
• Maintain a balance between active and emergency signers for operational efficiency and security.

Quarterly Review:

{Conduct a quarterly review to ensure the safety and efficacy of the multisig process. Review approvals, signers, contracts, applications, processes, etc. to reduce permission creep}

• Review signer activities and commitments, and allowed transaction types, functions, and amounts.
• Communicate with emergency signers for continued availability.
• Notify the board if signer thresholds fall below designated levels.
• Potentially run some kind of campaign that introduces a rule-breaking tx request that doesn't follow the SOP and see who signs it, and remind them of why they shouldn't have signed it if they do.

Appendix A - Approved Transactions, Functions, and Amounts

Appendix B - Current Active and Emergency Signers