DeputyPauseModule
Table of Contents
- Status
- Overview
- Context
- Upgradeability
- Assumptions
- aSCP-001: Pause authorization process is well-defined
- aSCP-002: Pause authorization process is robust
- aSCP-003: Pause authorization process is fast
- aDPM-001: Contract is configured correctly
- aDPM-002: Deputy key is not compromised
- aDPM-003: Deputy key is not deleted
- aDPM-004: Ethereum will not censor transactions for extended periods of time
- aDPM-005: OpenZeppelin ECDSA and EIP712 contracts are free of critical bugs
- aDPM-006: Safe contracts are free of critical bugs
- aDPM-008: Deputy key is capable of creating signatures
- System Invariants
- Component Invariants
- iDPM-001: Only the Deputy may act through the module
- iDPM-002: Deputy must only be able to trigger the pause
- iDPM-003: Deputy must always be able to act through the module
- iDPM-004: Deputy authorizations must not be replayable
- iDPM-005: Foundation Safe must be able to change the Deputy account easily
- Impact
- Mitigations
- Implementation Spec
Status
Proposed
Overview
The DeputyPauseModule
is a Safe Module designed to be installed into the Security
Council Guardian Safe that allows a dedicated Deputy address to create an ECDSA signature that
authorizes the execution of the Pause Mechanism. The
DeputyPauseModule
assumes that the Security Council Guardian Safe is the Guardian
that is permitted to act within the SuperchainConfig.
Context
Additional context and motivation for this component can be found in the corresponding design document.
Upgradeability
The DeputyPauseModule
is not expected to change frequently and is therefore not a proxied
contract. The DeputyPauseModule
allows basic parameters to be modified by the Operations Safe
directly without needing to deploy a new instance of the contract. Additionally, the address of the
module itself is only utilized within the Optimism Foundation Operations Safe and can be safely
replaced.
Assumptions
NOTE: Assumptions are utilized by specific invariants and do not apply globally. Invariants typically only rely on a subset of the following assumptions. Different invariants may rely on different assumptions. Refer to individual invariants for their dependencies.
aSCP-001: Pause authorization process is well-defined
We assume that the process by which a pause can be authorized is well-defined such that the cases in which the pause should and should not be triggered are apparent. This assumption dictates that the cases in which the pause should be used are clearly enumerated and well known to all participants.
aSCP-002: Pause authorization process is robust
We assume that the process by which a pause can be authorized correctly accounts for all cases in which such a pause would be necessary. In other words, we assume that there are no situations where the pause should be used to protect the system but the defined protocol for triggering the pause would not require the pause to be triggered.
aSCP-003: Pause authorization process is fast
We assume that the process by which a pause can be authorized is fast acting such that it can make the decision to trigger the pause within a short period of time of any situation that would require such a pause.
aDPM-001: Contract is configured correctly
We assume that all inputs to the contract are configured correctly including:
- Address of the Operations Safe.
- Address of the
SuperchainConfig
contract. - Address of the Deputy account.
Mitigations
- Verify a signature from the Deputy in the contract constructor.
- Verify the configured values in the deployment script.
- Generate and test a signature on testnet.
aDPM-002: Deputy key is not compromised
We assume that the Deputy key is maintained securely and is not compromised by a malicious actor.
Mitigations
- Enforce strong access control around the Deputy key.
- Monitoring for any usage of the Deputy key.
- Regular rotation of the Deputy key.
aDPM-003: Deputy key is not deleted
We assume that the Deputy key has not been deleted by a malicious actor.
Mitigations
- Maintain duplicate copies of the key in multiple secure locations.
aDPM-004: Ethereum will not censor transactions for extended periods of time
We assume that Ethereum will not censor transactions for an extended period of time and that any transaction submitted to the network can be processed within a reasonable time bound (e.g., 1h).
Mitigations
- Extremely high priority fee if necessary.
aDPM-005: OpenZeppelin ECDSA and EIP712 contracts are free of critical bugs
We assume that both the ECDSA
library and the EIP712
contract provided by OpenZeppelin V4 at
commit ecd2ca2c (v4.7.3) are free of any critical bugs that would cause their
behaviors to diverge from their specified behaviors.
Mitigations
- Existing audits/safety processes for OpenZeppelin V4.
aDPM-006: Safe contracts are free of critical bugs
We assume that the Safe contract implementations used by the Security Council Safe and Optimism Foundation Operations Safe are free of any critical bugs that would cause their behaviors to diverge from their specified behaviors.
Mitigations
- Existing audits/safety processes for Safe.
aDPM-008: Deputy key is capable of creating signatures
We assume that the Deputy key configured is actually capable of creating signatures.
Mitigations
- Signature verification when changing Deputy key.
System Invariants
iSCP-001: Pause can be activated within 30 minutes of authorization
It is an important system-level invariant that the pause functionality can be activated within a short, bounded amount of time (30 minutes) of its authorization by the standard process that approves the usage of this pause. That is, after the pause is authorized, it should be possible to execute the pause in under 30 minutes under all circumstances.
Impact
Severity: High (estimated)
If this invariant is broken, various recovery options that rely on fast activation of the pause may fail. We estimate the severity of this invariant being broken to be high but final severity will depend on the formalization of other invariants that rely on this one.
Dependencies
iSCP-002: Pause is not activated outside of the standard process
We must maintain that the pause is not activated outside of the standard process that approves the usage of the pause.
Impact
Severity: High
If this invariant is broken, all components that rely on the pause would be placed into a paused state unexpectedly. This would cause a temporary liveness failure for withdrawals through the Standard Bridge system and would negatively impact users until liveness could be restored by the Guardian.
Dependencies
Component Invariants
iDPM-001: Only the Deputy may act through the module
The Deputy account must be the only address that can act through the module. Other accounts can execute an action on behalf of the Deputy if the account has a valid authorization signature from the Deputy for that action. No account may act through the module other than with the explicit authorization of the Deputy.
Impact
Severity: High
If this invariant is broken, accounts other than the Deputy would be able to carry out the actions allowed by this module. Assuming that iDPM-002 holds, this means that an account other than the Deputy would be able to trigger the pause, presumably without the authorization of the social consensus process that typically triggers this pause.
Mitigations
- Signature verification on the pause action.
- Monitoring for pause triggering actions.
Dependencies
iDPM-002: Deputy must only be able to trigger the pause
The Deputy must only be able to trigger the pause action by causing the module to call the pause
function on the SuperchainConfig
. The Deputy must not be able to trigger any other priviledged
action on behalf of the Guardian.
Impact
Severity: Critical
If this invariant is broken, the Deputy would be able to cause the Optimism Foundation Operations Safe to execute some unknown set of possible actions. We would treat this as a critical risk.
Mitigations
- Strict auditing and verification of the
DeputyPauseModule
.
Dependencies
iDPM-003: Deputy must always be able to act through the module
The Deputy account must always be able to act through the module, even if the Deputy account private key is compromised. Other than the total deletion of the Deputy key, there should not be any condition in the contract itself that would prevent the key from being able to quickly and efficiently execute the pause action.
Impact
Severity: High
If this invariant is broken, we would not be able to provide the system-level invariant that the Deputy account can always be used to trigger the pause within a bounded amount of time of the decision being made to carry out this action.
Mitigations
- Signature-based verification to bypass draining attacks.
- Strict auditing and verification of the
DeputyPauseModule
.
Dependencies
iDPM-004: Deputy authorizations must not be replayable
A Deputy authorization must apply to a specific DeputyPauseModule
on a specific blockchain as
identified by its chain ID. An authorization created for one DeputyPauseModule
must not be
reusable on any other DeputyPauseModule
. An authorization must be usable once and the same
authorization must not be usable again in any DeputyPauseModule
.
Impact
Severity: High
If this invariant is broken, a Deputy authorization created by the same Deputy address for
another DeputyPauseModule
or a previous authorization for the same module could be reused and
would result in the pause being triggered outside of the standard process by which such a pause is
approved.
Mitigations
- EIP-712 signature verification including a specific contract address and chain ID.
- Enforce unique nonces on signatures to prevent signature reuse within the same contract.
- Utilize unique Deputy accounts for each module instance or network.
Dependencies
iDPM-005: Foundation Safe must be able to change the Deputy account easily
The Foundation Safe must be able to change the address of the Deputy account without significant operational overhead.
Impact
Severity: Medium
If this invariant is broken, it would not be possible for the Safe account to easily rotate the Deputy account if the account is compromised. This creates operational overhead but is not a security risk as we assume that the Safe code does not have bugs and therefore the Safe can always remove the module if necessary.
Mitigations
- Authorized function to change the Deputy address.
Implementation Spec
constructor
- Sets the EIP-712 domain name to "DeputyPauseModule".
- Sets the EIP-712 domain version to "1".
- Takes the address of the Operations Safe as an authorized input.
- Takes the address of the
SuperchainConfig
as an authorized input. - Takes the address of the Deputy as an authorized input.
- Takes a signature from the Deputy over a known EIP-712 message.
- Must verify that the signature was produced by the provided Deputy address.
pause
- Takes a nonce as an untrusted input.
- Takes a Pause Identifier as an untrusted input.
- Takes a signature as an untrusted input.
- Callable by any address.
- Must verify that the nonce has not been used.
- Must verify that the signature is over an EIP-712 message that commits to the nonce and the pause identifier and was produced by the private key corresponding to the Deputy address.
- Must mark the nonce as used.
- Must trigger the pause on the
SuperchainConfig
function with the provided pause identifier. - Must revert if the call to the pause function failed.
- Must revert if the call succeeded but the
SuperchainConfig
contract was not paused.
setDeputy
- Takes a deputy address as an authorized input.
- Takes a deputy auth signature as an authorized input.
- Can only be called by the Foundation Safe as configured in the constructor.
- Must verify that the signature was produced by the provided Deputy address.
foundationSafe
- Returns the address of the Operations Safe as set in the constructor.
superchainConfig
- Returns the address of the
SuperchainConfig
contract as set in the constructor.
deputy
- Returns the address of the Deputy account as set in the constructor.
pauseMessageTypehash
- Returns the typehash that corresponds to
struct PauseMessage { bytes32 nonce }
.
deputyAuthMessageTypehash
- Returns the typehash that corresponds to
struct DeputyAuthMessage { address deputy }
.