-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a variant of the Vesting wallet for updating the beneficiary #1
Conversation
Co-authored-by: Ernesto García <[email protected]>
I suggest using a Tenderly simulation of the multisig transaction before executing it. It should show the beneficiary storage slot as the only change. |
The operation will have to go through a multisig. I'll suggest this is done through defender (which includes tenderly support?) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor nit.
|
||
function upgradeTo(address newImplementation) external { | ||
require(msg.sender == _owner); | ||
StorageSlot.getAddressSlot(_IMPLEMENTATION_SLOT).value = newImplementation; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Without specifying, it looks weird that we're checking ownership but not emitting the event.
StorageSlot.getAddressSlot(_IMPLEMENTATION_SLOT).value = newImplementation; | |
StorageSlot.getAddressSlot(_IMPLEMENTATION_SLOT).value = newImplementation; | |
// Upgraded event is not emitted given this function is only used by UUPS's rollback test. |
It's our own simulation support. If it goes through a Safe multisig it can be simulated through Tenderly as well |
Replaces forta-network#264
The goal is to perform this on an instance that is currently using
VestingWallet
(v0). Still, this solution is designed to work with all existing versions of the VestingWallet (as demonstrated by the tests)