Add official timelock guard functionality to Gnosis Safe

[jesusholoo]

Feature Request: Timelock Guard for Gnosis Safe

Summary

Recent incidents (e.g. the Bybit attack) have shown that high-value multisigs can be compromised when signers unknowingly approve malicious transactions due to altered or misleading UIs. In that case, a modified Gnosis Safe UI caused signers to approve a transaction they did not fully understand.

This class of attacks could be significantly mitigated by introducing a timelock guard for Gnosis Safe, enforcing a mandatory delay between transaction approval and execution. Even if it's couple hours, it's enough for having external actors review the transactions, detect the attack and be able to cancel those transactions.

---

Context / Motivation

The attack vector relies on two key properties of Safe transactions:

1. Transactions are executed immediately after reaching the threshold.
2. The UI is a critical trust component, and signers may approve transactions without fully verifying calldata.

A timelock guard would:

• Force a waiting period before execution
• Allow anyone to inspect the full transaction during the delay
• Enable cancellation if unexpected behavior is detected

This pattern is already widely used in governance and upgradeability systems (e.g. Safe → OpenZeppelin Timelock → Target contract), but today it requires external infrastructure and contracts.

Embedding this logic directly as a Safe Guard would make it significantly easier to adopt for high-value multisigs.

---

Proposed Solution

Implement a Timelock Guard for Gnosis Safe with behavior inspired by OpenZeppelin TimelockController.

Key properties:

• ⏱ Mandatory execution delay

  • All Safe transactions must be scheduled first
  • Execution is only allowed after delay has elapsed

• 🔄 Updatable delay

  • Delay changes must themselves go through the timelock
  • Similar semantics to OZ’s updateDelay

• 📦 Full transaction visibility

  • The guard must receive all tx parameters, emit and event, and compute the txHash:

    • to
    • value
    • data
    • operation
    • ...

  • This makes off-chain verification and monitoring trivial

• ❌ Transaction cancellation

  • Scheduled transactions can be canceled before execution

---

Related Work

There is an existing implementation in Safenet:

• https://github.com/safe-fndn/safenet/blob/main/contracts/src/SafenetGuard.sol

However, a new implementation could improve usability and security by:

• Following OpenZeppelin timelock patterns more closely
• Supporting delay updates
• Supporting cancellation
• Storing the full transaction payload
• Being designed for direct UI integration

---

UI / UX Considerations

To maximize safety and adoption, this guard should be integrated into the Gnosis Safe UI

Additional Context

This guard would be especially valuable for:

• Protocol treasuries
• Foundation multisigs
• Upgrades
• High-value operational wallets

Given the increasing sophistication of UI-based and social-engineering attacks, enforcing time as a security primitive seems like a necessary evolution for Safe.

Please let me know if there are any existing efforts or ongoing work in this direction that I may have missed. I’m a smart contract developer, and if this feature is considered a good fit, I’d be happy to help or implement it.

Implementation details:

We could verify the same N/M signatures inside the guard when scheduling the transactions (also checking that the nonce is greater than the current multisig one...), making this N/M scheme the only authorization method for scheduling.

This way, the multisig actors only need to sign one transaction. Then, an executor can then schedule the transaction and later execute it, reusing the same signatures. This makes the process of sign the transaction friction-less to the timelock