Verifying Multisig Transactions

Authored by:

engn33r

Piña

Coinspect

Isaac Patka

SEAL | Shield3

Geoffrey Arone

Shield3

Louis Marquenet

Opsek

Pablo Sabbatella

SEAL | Opsek

Dickson Wu

SEAL

Auditware

Auditware

The security of a multisig wallet relies on each signer independently verifying what they are signing. A compromised web interface could present a legitimate-looking transaction while tricking a hardware wallet into signing a malicious one.

The verification process is divided into two distinct phases: signing the off-chain message and executing the on-chain transaction.

Key Definitions (EVM)

• Domain Hash: EIP-712 domain separator, unique to each Safe. Ensures signatures cannot be replayed on other networks or Safes.
• Message Hash: Raw hash of transaction parameters. This appears on your hardware wallet.
• SafeTxHash: Combined hash of domain + message hash. Used for nested Safe approvals.

Phase 1: Signing the Off-Chain Message

When you are the first signer or are adding your signature to a transaction that has not yet met its threshold, you are not sending an on-chain transaction. Instead, you are signing a structured, off-chain message that conforms to the EIP-712 standard.

Goal: To confirm that the cryptographic hash displayed on your hardware wallet exactly matches the hash of the transaction you intend to approve.

Process

1. Initiate Signing: Start the signing process in the multisig wallet's web interface.
2. Verify on Hardware Wallet: Your hardware wallet will display an EIP-712 hash for you to sign.
3. Compute Hash: Use an independent, local tool to re-calculate the expected hash from the transaction's parameters (nonce, to, value, data, etc.). For a list of recommended options, see the Transaction Verification Tools section.
4. Compare Hashes: Compare the SafeTxHash generated by the local tool with the hash displayed on your hardware wallet's screen. They must match perfectly.
   • All signers must verify transaction data on at least two independent devices
   • All signers must verify transaction data through at least two separate communication channels
5. Simulate Transaction: At least 2 signers must use transaction simulation tools to verify transaction effects. Simulation testing output should be shared with and reviewed by all signers before signing.
   • Warning: Simulations can be spoofed - always apply critical thinking and good judgement during transaction reviews since a simulation can display one thing and then do something else entirely when actually executed on chain
6. Sign: If the hashes match and simulation results are verified, you can confidently sign the message on your hardware wallet. This confirms you are approving the correct transaction, even if the web UI has been compromised.

Phase 2: Executing the On-Chain Transaction

Once a transaction has the required M-of-N signatures, it can be executed. This involves submitting a final on-chain transaction that calls the execTransaction function on the multisig contract, passing in all the previously signed data.

Goal: To confirm that the on-chain transaction being sent correctly encapsulates the multisig transaction you and other signers approved.

Process

1. Initiate Execution: In the multisig interface, start the execution of the fully signed transaction.
2. Verify Calldata: Your hardware wallet will prompt you to sign a new on-chain transaction. It will display the raw transaction data (calldata), which should show a call to the execTransaction function.
3. Decode and Compare: Use a calldata decoder (e.g.,calldata.swiss-knife.xyz) to parse the data shown on your hardware wallet.
4. Confirm Parameters: Carefully check the decoded parameters within the execTransaction call, especially the internal destination address (to), value, and data payload. Ensure they match the original, intended transaction.
5. Sign and Broadcast: If the calldata is correct, sign the transaction on your hardware wallet to broadcast it to the network.

Operational Best Practices

⚠️ Beware of DELEGATECALL: In a smart contract multisig transaction, an operation: 1 (DELEGATECALL) is dangerous if the target contract is not explicitly known and trusted. This opcode gives another contract full control over your wallet's context and storage.

• Transaction Simulation: Before signing, use a simulator like Tenderly or Alchemy to preview the transaction's outcome. This helps confirm that it will not revert and will result in the expected state changes.
• Hardware Wallet Standard: All multisig signers should use hardware wallets to protect their keys from online threats. Data shown in a browser extension wallet should be treated with the same skepticism as data in the web UI.
• Secure signing environment: Use a dedicated, air-gapped, or hardened device. Avoid primary work laptops.
• Alternative Frontends: To further reduce reliance on a single public UI, consider using an alternative or self-hosted multisig interface.
• Separate browser/profile for signing: Use a dedicated browser or browser profile when interacting with signing UIs to reduce cross-extension/session risk.
• Require a "how to check" guide: Every transaction should include explicit verification instructions for signers.
• Verify addresses and amounts via independent sources: Do not rely solely on messages from co-signers.
• Check transactions in the queue: If unclear what a transaction does and why, do not sign; ask for explanation.
• Communicate status: After review, state whether a transaction is ready to execute and confirm after signing ("checked, signed, X more required").
• Last signer executes: If executable immediately, the last signer should execute; otherwise coordinate clearly.
• Re-verify before execution: Treat execution as a fresh signing event and re-check parameters.
• Use checksummed addresses: Always use checksummed format to prevent copy/paste or case errors.

Simulation notes with timelocks

When using a timelock, simulations may show the staging event rather than actual execution. Inspect the staged payload and verify cancellation/execution roles and parameters before proceeding.