Detailed Instructions

Define the multisig threshold (M-of-N) based on your protocol's risk tolerance. A common starting point for a 5-signer setup is a 3-of-5 threshold. This requires three confirmations for a transaction, balancing security with operational agility. The signer set should comprise distinct, trusted entities such as core developers, community representatives, and external security experts to avoid single points of failure. Use a deterministic process, like a DAO vote, to finalize the initial signer addresses. Record all public addresses and the chosen threshold in your protocol's public documentation for transparency.

• Sub-step 1: Determine the required signer count (N) and approval threshold (M).
• Sub-step 2: Identify and vet individuals or entities to serve as signers.
• Sub-step 3: Collect and verify the Ethereum addresses (0x...) for each signer.

codeCopy
// Example: Gnosis Safe Factory contract address on Ethereum Mainnet
0xa6b71e26c5e0845f74c812102ca7114b6a896ab2

Tip: Consider implementing a time-lock on the Safe's settings module to prevent rapid, unilateral changes to the signer set.

Detailed Instructions

Deploy a Gnosis Safe (or equivalent audited contract) using its official factory. This ensures you use a standard, non-custodial, and extensively audited smart contract. The deployment transaction will require a single EOA (Externally Owned Account) to initiate, but the resulting Safe address is controlled solely by the defined signer set. During deployment, you must pass the constructor parameters: the list of owner addresses and the threshold. It is critical to verify the factory address on the official Gnosis Safe website to avoid phishing. After deployment, immediately verify the contract code on a block explorer.

• Sub-step 1: Navigate to the official Gnosis Safe interface or use the SDK in a script.
• Sub-step 2: Input the owner addresses and threshold configured in Step 1.
• Sub-step 3: Execute the deployment transaction from a secure EOA and confirm the new Safe address.

javascriptCopy
// Example using Ethers.js and the Safe Factory ABI
const safeFactory = new ethers.Contract(factoryAddress, factoryABI, deployerSigner);
const setupData = safeFactory.interface.encodeFunctionData('createProxyWithNonce', [singletonAddress, initializeData, saltNonce]);
const tx = await safeFactory.createProxyWithNonce(singletonAddress, initializeData, saltNonce);

Tip: Use a deterministic address creation method (CREATE2) via the factory to predict the Safe's address before deployment for planning.

Detailed Instructions

Send an initial amount of the network's native token (e.g., ETH) to the Safe's address to pay for future transaction gas fees. Subsequently, transfer protocol-owned assets (tokens, NFTs, LP positions) to the Safe. Next, configure Safe Modules. The Delay Module adds a mandatory waiting period (e.g., 48 hours) for high-value transactions, allowing time for community scrutiny. The Roles Module can delegate specific permissions (like minting a limited amount of tokens) to a manager address without granting full control. Each module addition is a transaction that requires multisig approval, ensuring the signers collectively authorize new capabilities.

• Sub-step 1: Execute a simple transfer from a protocol treasury EOA to the new Safe address.
• Sub-step 2: Propose and confirm a transaction to enable the Delay Module with a defined time window.
• Sub-step 3: Propose and confirm transactions to transfer core protocol assets to the Safe's custody.

solidityCopy
// Example interface for enabling a module on a Gnosis Safe
interface IGnosisSafe {
    function enableModule(address module) external;
}
// The call data for this transaction must be signed and executed by the Safe itself.

Tip: Start with a conservative delay period (e.g., 7 days) for the most critical functions and adjust based on operational experience.

Detailed Instructions

Implement a clear off-chain workflow for creating and approving transactions. Use a tool like the Gnosis Safe web interface, Safe{Wallet}, or a custom dashboard that integrates the Safe SDK. Each transaction proposal should include a comprehensive description, link to on-chain simulation (e.g., Tenderly), and relevant forum discussion link. Set up on-chain monitoring by adding the Safe as a watched address in services like OpenZeppelin Defender Sentinels, EigenPhi, or Tenderly Alerts. Configure alerts for any transaction creation, approval, or execution. This creates a transparent log and provides early warning for unauthorized proposal attempts.

• Sub-step 1: Designate a primary platform (e.g., Safe{Wallet}) for all signers to use.
• Sub-step 2: Create a template for transaction proposals including rationale and simulation data.
• Sub-step 3: Configure monitoring alerts for all outgoing transactions from the Safe address.

bashCopy
# Example CLI command to propose a transaction using the Safe SDK
safe-cli tx create \
  --to 0xTokenContractAddress \
  --value 0 \
  --data "0xa9059cbb..." \
  --nonce 5 \
  --safe 0xYourSafeAddress

Tip: Enforce a policy where at least one signer runs a local node or uses a verified RPC to independently validate transaction simulations before signing.

Detailed Instructions

Signer rotation is critical for long-term security. Draft and ratify a policy for periodic review and replacement of signers (e.g., annually). The process to add/remove a signer is a transaction that itself requires the current multisig threshold, ensuring no single signer can alter the group unilaterally. Establish emergency procedures for scenarios like a signer losing access or a detected compromise. This may involve a pre-defined, time-locked transaction to a fallback Safe controlled by a completely different set of entities. All procedures should be documented in a publicly accessible emergency response plan, separate from the main multisig.

• Sub-step 1: Schedule a quarterly review of the signer set's activity and security posture.
• Sub-step 2: Draft, propose, and approve a transaction to update signers when necessary.
• Sub-step 3: Deploy and fund a separate emergency fallback Safe with a distinct signer set.

solidityCopy
// Example: Function signature for swapping a signer via the Safe contract
// This requires a previously approved transaction to `execTransaction`
function swapOwner(address prevOwner, address oldOwner, address newOwner) public;

Tip: Use the Safe's Guard feature to impose additional constraints, like blocking transactions to non-whitelisted addresses, as a final security layer.

Detailed Instructions

Define the signing threshold (M-of-N) and the specific roles of each signer. This policy should be formally documented off-chain, detailing the types of transactions allowed, spending limits, and emergency procedures.

• Sub-step 1: Determine the number of signers (N) and the required approvals (M). For a treasury, a common configuration is 3-of-5.
• Sub-step 2: Assign clear roles (e.g., Technical Lead, Community Lead, Auditor) to each signer's key.
• Sub-step 3: Document the exact process for proposing, reviewing, and executing a transaction, including required off-chain communication channels.

Tip: Use a tool like Safe{Wallet} to easily configure these parameters during wallet creation. The policy is a living document and should be reviewed quarterly.

Detailed Instructions

Never store signer private keys on internet-connected devices. Each signer must use a dedicated hardware wallet (e.g., Ledger, Trezor) for their role in the multisig.

• Sub-step 1: Purchase new hardware wallets from the official manufacturer for each signer.
• Sub-step 2: Initialize each device, generating a new seed phrase in a physically secure, private location.
• Sub-step 3: Connect each hardware wallet to a clean, dedicated machine (never the daily-use computer) to link it to the multisig wallet interface (like the Safe app).

javascriptCopy
// Example: Connecting a hardware signer via ethers.js (conceptual)
const provider = new ethers.providers.JsonRpcProvider(RPC_URL);
const ledgerSigner = new ethers.providers.LedgerSigner(provider, "hid", "m/44'/60'/0'/0/0");
// The signer object is used to propose/confirm transactions via the Safe SDK.

Tip: The seed phrases for these hardware wallets must be stored in secure, geographically distributed locations, such as bank safety deposit boxes.

Detailed Instructions

Every transaction proposal must undergo a standardized review by multiple signers to catch errors or malicious payloads.

• Sub-step 1: The proposer shares the raw transaction data (to, value, calldata) in a designated channel, including a link to the verified contract on a block explorer like Etherscan.
• Sub-step 2: At least one other signer independently simulates the transaction using a tool like Tenderly to verify the expected state changes and lack of reentrancy.
• Sub-step 3: Reviewers manually verify the recipient address, the function selector (e.g., 0xa9059cbb for transfer), and the encoded parameters against the original proposal document.

Tip: For complex contract interactions, require a diff check between the current live contract and the one the transaction interacts with to detect upgrades or malicious deployments.

Detailed Instructions

Configure the multisig wallet to enforce a timelock delay for transactions above a certain value or for critical functions like changing signers.

• Sub-step 1: When creating the Safe, enable the Timelock module. Set a delay period (e.g., 48-72 hours) for transactions over a defined threshold (e.g., >100 ETH).
• Sub-step 2: Once a transaction reaches the signature threshold, it enters the timelock period. This is visible on-chain.
• Sub-step 3: Use this window as a final safety net. The community and other signers can monitor the pending transaction and raise an alarm if it appears fraudulent, allowing time to execute a cancel transaction if the signer set is still secure.

solidityCopy
// Example: A simplified timelock check in a module
require(block.timestamp >= queue[txHash].eta, "Timelock::executeTransaction: Transaction not ready.");
require(block.timestamp <= queue[txHash].eta + GRACE_PERIOD, "Timelock::executeTransaction: Transaction stale.");

Tip: Combine this with a public monitoring bot that alerts a Discord channel when a timelocked transaction is queued.

Detailed Instructions

Periodically rotate signer keys and conduct fire drills to ensure the process works under pressure.

• Sub-step 1: Schedule a quarterly review. If a signer leaves the project, use the multisig to remove their address and add a new signer's hardware wallet address in a single, well-reviewed transaction.
• Sub-step 2: Once per year, perform a recovery drill. Simulate a scenario where a signer's key is compromised: the remaining signers must use the multisig to remove the compromised address before the attacker can act.
• Sub-step 3: Test the execution of a batched transaction that performs multiple actions (e.g., collect fees, swap tokens, send to treasury) to ensure complex operational workflows are familiar.

Tip: Document the outcomes of every drill and rotation. Update the signing policy based on lessons learned to continuously improve the security posture.