You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Slightly expands the response capabilities within DelayedWETH to minimize the number of actions needed to quickly respond and the blast radius of these responses.
Context
The DelayedWETH contract acts as a holding contract for the bonded ETH submitted by any participant in a DisputeGame contract. As of the Granite upgrade, each implementation of the DisputeGame uses its own DelayedWETH contract. Each DelayedWETH contract is Ownable and is subject to a number of safety net actions by the owner address (holding balances from specific addresses or removing all ETH held in the DelayedWETH contract). DelayedWETH is additionally subject to the Superchain-wide pause mechanism within the SuperchainConfig. Bonds cannot be retrieved by game participants if the Superchain pause is active.
Problem Statement
Existing security mechanisms within the DelayedWETH contract are inconvenient and slow down the incident response process. Specifically:
The DelayedWETH.hold(address target) function creates an approval from the target address to the owner address. Since the target can simply remove this approval, hold MUST be triggered alongside a transferFrom in the same transaction. This adds unnecessary complexity to something that could simply be a single transaction.
The various security mechanisms inside of DelayedWETH can only be triggered by the System Owner which has a slow SLA. The Deputy Guardian can act to trigger the Superchain-wide pause, but this is highly disruptive to the entire Superchain ecosystem.
Additionally, it should be noted that all ETH inside a DelayedWETH contract is pooled together regardless of which games are using the contract. We currently mitigate this by using one DelayedWETH contract per game type, but this expands the number of contracts that the System Owner and Guardian roles must manage by at least 2 per additional chain. However, the modifications required to appropriately address this issue are sufficiently extensive that they are considered out of scope for this proposal.
Project Updates
[2024-09-27] Draft design document is available here.
[2024-09-27] Draft design document is being actively reviewed.
[2024-10-28] Design document has been approved and merged.
Summary
Slightly expands the response capabilities within
DelayedWETH
to minimize the number of actions needed to quickly respond and the blast radius of these responses.Context
The
DelayedWETH
contract acts as a holding contract for the bonded ETH submitted by any participant in aDisputeGame
contract. As of the Granite upgrade, each implementation of theDisputeGame
uses its ownDelayedWETH
contract. EachDelayedWETH
contract isOwnable
and is subject to a number of safety net actions by the owner address (holding balances from specific addresses or removing all ETH held in theDelayedWETH
contract).DelayedWETH
is additionally subject to the Superchain-wide pause mechanism within theSuperchainConfig
. Bonds cannot be retrieved by game participants if the Superchain pause is active.Problem Statement
Existing security mechanisms within the
DelayedWETH
contract are inconvenient and slow down the incident response process. Specifically:DelayedWETH.hold(address target)
function creates an approval from the target address to the owner address. Since the target can simply remove this approval, hold MUST be triggered alongside atransferFrom
in the same transaction. This adds unnecessary complexity to something that could simply be a single transaction.DelayedWETH
can only be triggered by the System Owner which has a slow SLA. The Deputy Guardian can act to trigger the Superchain-wide pause, but this is highly disruptive to the entire Superchain ecosystem.Additionally, it should be noted that all ETH inside a
DelayedWETH
contract is pooled together regardless of which games are using the contract. We currently mitigate this by using oneDelayedWETH
contract per game type, but this expands the number of contracts that the System Owner and Guardian roles must manage by at least 2 per additional chain. However, the modifications required to appropriately address this issue are sufficiently extensive that they are considered out of scope for this proposal.Project Updates
Resources
The text was updated successfully, but these errors were encountered: