feat: add hook emergency installation #150
Conversation
| ///< Mapping of selectors to their respective fallback handlers. | ||
| IHook hook; | ||
| ///< Current hook module associated with this account. | ||
| mapping(address hook => uint256) emergencyUninstallTimelock; |
There was a problem hiding this comment.
do we provide emergencyUninstallTimelock while installing hook now?
mapping makes me think multiple hooks associated with uninstall timelocks
There was a problem hiding this comment.
so how it works is that you can initiate a timelock for a hook and when that timelock is expired you can uninstall the hook. It uses a mapping since you could initiate the timelock, then uninstall the hook normally, reinstall it and then still have the timelock counting down even though its a different hook now
|
Also Todo: change the base to dev once other PRs are merged in dev. |
|
also, these are fine?
|
|
yeah although _authorizeUpgrade is an internal function so dont think it needs the modifier |
| accountStorage.emergencyUninstallTimelock[hook] = block.timestamp; | ||
| emit EmergencyHookUninstallRequest(hook, block.timestamp); | ||
| } else if (block.timestamp >= hookTimelock + 3 * _EMERGENCY_TIMELOCK) { | ||
| // if the timelock has been left for too long, reset it |
There was a problem hiding this comment.
what is the reason for this?
can we not just allow uninstall here?
There was a problem hiding this comment.
yeah I was thinking through this and we could allow these timelocks to not expire. The main upside of this is that when you initiate a timelock and the waiting time (1 day) has elapsed, the account is in a state where the hook can always be instantly uninstalled, which kind of defeats the purpose of the timelock as a guarantee that uninstallation cannot be instant
No description provided.