From fbd65b0823b9b6ef4d5083b0d52187bc0076b4de Mon Sep 17 00:00:00 2001 From: Kelvin Fichter Date: Tue, 12 Aug 2025 12:52:43 -0400 Subject: [PATCH 1/3] feat: liveness module v2 Design document introducing an updated LivenessModule. --- safe-modules/liveness-module-v2.md | 139 +++++++++++++++++++++++++++++ 1 file changed, 139 insertions(+) create mode 100644 safe-modules/liveness-module-v2.md diff --git a/safe-modules/liveness-module-v2.md b/safe-modules/liveness-module-v2.md new file mode 100644 index 00000000..f06491e3 --- /dev/null +++ b/safe-modules/liveness-module-v2.md @@ -0,0 +1,139 @@ + +# LivenessModule V2 + +## Context and Problem Statement + + + +[Safe Accounts](https://safe.global) are configured as a set of owner addresses where some +threshold of addresses can sign and ultimately execute a transaction through the account. We must +solve for two safety cases, first that a threshold of signers do not maliciously execute a +transaction (safety failure) and second that a blocking minority of signers +(`total - threshold + 1`) don't become unable to sign (liveness failure). Either case can be +equally catastrophic but we tend to focus on the safety failure case. Here we attempt to produce a +solution for the liveness failure case that fits within certain constraints. + +We define multisig liveness as the ability for the multisig to reach consensus and execute a +transaction within a bounded amount of time. Note that a multisig does not need to reach consensus +over every possible transaction (because the members have the ability to reject transactions as +needed). We instead say that a multisig is live as long as it is able to reach consensus over a +transaction that states "this multisig is live". + +At a high level, a multisig fails to be live if at least a blocking minority of signers prevents +the multisig from being able to reach consensus. This can happen if signers are honest but unable +to sign (e.g., keys are lost) or if signers are malicious and refuse to sign. We must address both +problems if we want to avoid multisig liveness failures. The existing `LivenessGuard` is +insufficient in this regard because it does not handle malicious signers. + +Any system to address the above must also scale sufficiently such that a signer is not +unnecessarily burdened by the liveness mechanism (this is a product constraint). The +`LivenessGuard` is also insufficient here because it does not scale across multiple chains and it +demands signatures on a regular basis (as opposed to only demanding signatures as needed). + +## Customer Description + + + +The customers for this design doc are any participants in the multisig accounts that would utilize +this module, as well as any 3rd parties who rely on the security properties of these accounts. + +### Customer Reviewers + + + +- Coinbase (potentially impacted 3rd party) +- Uniswap (`LivenessModule` user) +- Optimism Foundation (`LivenessModule` user) + +## Requirements and Constraints + + + +- Solve both the owner liveness and account liveness problems *securely*. +- Keep code as minimal as possible to avoid complex logic in Safe modules. +- Reduce mental overhead for Safe owners and multisig leads. + +## Proposed Solution + + + +We propose the introduction of a new module, `LivenessModuleV2` (name is unimportant) to replace +the existing `LivenessGuard`/`LivenessModule`. `LivenessModuleV2` would employ a challenge/response +mechanism as an alternative to the existing poke mechanism inside of `LivenessGuard`. + +### Singleton + +`LivenessModuleV2` is a singleton that exists at a known address on all chains and has no +constructor parameters. Any Safe on any network can choose to configure the module and then enable +the module within the Safe. + +### Configuration + +A Safe configures the module by setting a challenge period, a challenge bond, and a fallback owner. + +### Challenge Protocol + +Any user may trigger an Account Liveness Challenge by targeting a specific Safe address. In +response to this challenge, a threshold of owners (same threshold as the Safe itself) must sign a +message that confirms the liveness of the safe (e.g., a message over the Safe address and the +current timestamp). If the Safe fails to reach this threshold, all owners are removed from the +account and ownership is transferred to the fallback account. If the Safe successfully reaches the +threshold, the challenge fails and the Safe receives the bond as a reward. + +The Account Liveness Challenge addresses both of the ways in which a Safe can fail to be live. If +sufficiently many honest users cannot sign that the account cannot reach a threshold, the account +falls back to the fallback owner. If sufficiently many users are malicious that the account cannot +reach a threshold, the honest users can refuse to sign and force a fallback. + +## Alternatives Considered + + + +### Owner Liveness Challenge + +We previously considered a model that would allow users to challenge either the entire Safe (as +happens in the Account Liveness Challenge) or an individual owner (i.e., an Owner Liveness +Challenge). An Owner Liveness Challenge would be more similar to the behavior of the existing +`LivenessModule`, where a user could target a specific owner and require that owner respond or be +removed from the Safe. + +The Owner Liveness Challenge faces a number of problems: + +- It creates a second challenge path. +- It only solves the honest user case, whereas the Account Liveness Challenge solves both cases. +- It requires that the Safe configure various new parameters like minimum owner count and threshold + percentage which creates more surface area for potential issues. + +Additionally, in most cases, the Owner Liveness Challenge would be unused because the Safe would +prefer to simply remove an owner that is unable to sign. + +## Risks and Uncertainties + + + +### Fallback Ownership + +Both the existing `LivenessModule` and this updated iteration rely on fallback ownership. In the +case that the challenge fails, ownership of the account must be transferred to some fallback +address. We believe this is acceptable and reasonable. Most multisig accounts can simply name the +Optimism Foundation multisig as a fallback, and the Optimism Foundation multisig can name the +Security Council as a fallback. + +One open question is what the Security Council should set as a fallback. We'd likely want this to +be another multisig operated by an independent and well-trusted entity. + +### Blunt Instrument + +It should be noted that the updated `LivenessModule` is more of a blunt instrument than the +existing module. We no longer have the ability to remove specific owners, we instead trigger a +fallback immediately if a threshold cannot be reached. This is less surgical, but we believe it is +equally effective and ultimately safer/simpler than the existing module because users don't need to +account for as many parameters. From ee75090a48bbda5c4c8ab6aea9b8f85d34caca8b Mon Sep 17 00:00:00 2001 From: alcueca Date: Fri, 22 Aug 2025 07:54:07 +0100 Subject: [PATCH 2/3] comments from design review incorporated --- safe-modules/liveness-module-v2.md | 32 ++++++++++++++++++++++-------- 1 file changed, 24 insertions(+), 8 deletions(-) diff --git a/safe-modules/liveness-module-v2.md b/safe-modules/liveness-module-v2.md index f06491e3..85d871b9 100644 --- a/safe-modules/liveness-module-v2.md +++ b/safe-modules/liveness-module-v2.md @@ -47,7 +47,8 @@ this module, as well as any 3rd parties who rely on the security properties of t - Coinbase (potentially impacted 3rd party) - Uniswap (`LivenessModule` user) -- Optimism Foundation (`LivenessModule` user) +- Security Council (`LivenessModule` user) +- Optimism Foundation ## Requirements and Constraints @@ -72,18 +73,20 @@ mechanism as an alternative to the existing poke mechanism inside of `LivenessGu constructor parameters. Any Safe on any network can choose to configure the module and then enable the module within the Safe. +If possible, this module should be integrated with all other safe modules and guards in a single +contract that is enabled and configured in all Optimism Safes. + ### Configuration -A Safe configures the module by setting a challenge period, a challenge bond, and a fallback owner. +A Safe configures the module by setting a challenge period and a fallback owner. ### Challenge Protocol -Any user may trigger an Account Liveness Challenge by targeting a specific Safe address. In -response to this challenge, a threshold of owners (same threshold as the Safe itself) must sign a -message that confirms the liveness of the safe (e.g., a message over the Safe address and the -current timestamp). If the Safe fails to reach this threshold, all owners are removed from the -account and ownership is transferred to the fallback account. If the Safe successfully reaches the -threshold, the challenge fails and the Safe receives the bond as a reward. +The fallback owner may trigger an Account Liveness Challenge by targeting a specific Safe address. +In response to this challenge, a threshold of owners (same threshold as the Safe itself) must +execute a regular transaction that confirms the liveness of the safe. If the Safe fails to execute +this transaction, all owners are removed from the Safe and ownership is transferred to the fallback +account. If the Safe successfully executes the transaction, the challenge fails and nothing happens. The Account Liveness Challenge addresses both of the ways in which a Safe can fail to be live. If sufficiently many honest users cannot sign that the account cannot reach a threshold, the account @@ -118,6 +121,19 @@ prefer to simply remove an owner that is unable to sign. +### Malicious Fallback +While the fallback owner is chosen as a trusted actor, it can always happen that they are +eventually compromised. In that case, they might issue a liveness challenge and if unnoticed +gain control of the multisig enabling the LivenessModule. + +To mitigate this, we will require monitoring that will alert us of unexpected liveness challenges. + +### Blocking Minority is Below Quorum +If a multisig uses a simple majority or less as quorum this module will be ineffective for the +stated scenario, because malicious actors will reach quorum before the reach a blocking minority. + +Instead of implementing a module that would address this scenario, we accept that this module +is intended for multisigs where the quorum is greater than a simple majority. ### Fallback Ownership From fb92768f45b09b1a986c664ac8e79d9583c0960a Mon Sep 17 00:00:00 2001 From: Maurelian Date: Fri, 5 Sep 2025 08:30:37 -0600 Subject: [PATCH 3/3] Clarify definition of simple majority --- safe-modules/liveness-module-v2.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/safe-modules/liveness-module-v2.md b/safe-modules/liveness-module-v2.md index 85d871b9..6901f505 100644 --- a/safe-modules/liveness-module-v2.md +++ b/safe-modules/liveness-module-v2.md @@ -129,8 +129,7 @@ gain control of the multisig enabling the LivenessModule. To mitigate this, we will require monitoring that will alert us of unexpected liveness challenges. ### Blocking Minority is Below Quorum -If a multisig uses a simple majority or less as quorum this module will be ineffective for the -stated scenario, because malicious actors will reach quorum before the reach a blocking minority. +In order for the module to be effective for the stated scenario, a multisig must require at least a simple majority (defined as `threshold > (total + 1 )/ 2`) as quorum, otherwise malicious actors will reach quorum before reaching a blocking minority. Instead of implementing a module that would address this scenario, we accept that this module is intended for multisigs where the quorum is greater than a simple majority.