-
Notifications
You must be signed in to change notification settings - Fork 35
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
Always revert when there is a value already pending #353
Conversation
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.
This design relies on the fact the pending value is deleted every time a value is set
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.
The natspec should be updated
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.
Pointing out that being consistent with #348 requires to revert in submitMarketRemoval
and submitCap
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.
A test on submitting a guardian while there is already a pending guardian should be added
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.
I still think the naming change was not necessary
@MathisGD can you revert back the naming and fix the conflicts please? |
…rt-already-pending
b3602c1
@@ -214,14 +214,12 @@ contract MetaMorpho is ERC4626, ERC20Permit, Ownable2Step, Multicall, IMetaMorph | |||
/// @inheritdoc IMetaMorphoBase | |||
function submitTimelock(uint256 newTimelock) external onlyOwner { | |||
if (newTimelock == timelock) revert ErrorsLib.AlreadySet(); | |||
if (pendingTimelock.validAt != 0) revert ErrorsLib.AlreadyPending(); |
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.
Before, you could have a pending value (decrease of timelock) that could have been deleted by another submitTimelock
that set the new timelock to a new one (higher timelock)
Now you won't be able to do that, and you are forced to wait for the timelock to expire or revoke it and call it again.
The same goes for submitting an even lower timelock when one pending timelock was already submitted.
Is this the intended new behavior?
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.
yes we enforce to revoke every pending values before submitting a new one.
@@ -281,16 +276,14 @@ contract MetaMorpho is ERC4626, ERC20Permit, Ownable2Step, Multicall, IMetaMorph | |||
Id id = marketParams.id(); | |||
if (marketParams.loanToken != asset()) revert ErrorsLib.InconsistentAsset(id); | |||
if (MORPHO.lastUpdate(id) == 0) revert ErrorsLib.MarketNotCreated(); | |||
|
|||
if (pendingCap[id].validAt != 0) revert ErrorsLib.AlreadyPending(); | |||
if (config[id].removableAt != 0) revert ErrorsLib.PendingRemoval(); |
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.
I think that this is a welcome check because the removal of a market is a very strong operation that also has a timelock that is different compared to the cap timelock (and previously they were non correlated within the logic). Now if a market is marked as "to-be-removed" such operation has the priority and will lock any changes to the cap.
Now as soon as a market is marked as to-be-removed, there's no way to re-enable the cap (that is already set to zero) unless you explicitly call revokePendingMarketRemoval
@@ -281,16 +276,14 @@ contract MetaMorpho is ERC4626, ERC20Permit, Ownable2Step, Multicall, IMetaMorph | |||
Id id = marketParams.id(); | |||
if (marketParams.loanToken != asset()) revert ErrorsLib.InconsistentAsset(id); | |||
if (MORPHO.lastUpdate(id) == 0) revert ErrorsLib.MarketNotCreated(); | |||
|
|||
if (pendingCap[id].validAt != 0) revert ErrorsLib.AlreadyPending(); |
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.
Like for the submitTimelock
, this new check brings some side effects. Unless you revoke the previous pending proposal, or you wait for the timelock + accept it, you cannot
- create a new proposal
- insta-change the supply cap (when the new cap is lower)
In general, you are giving much more priority and power to the pending proposals. Is this the intended behavior?
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.
yes it is. What we'll do is that in the frontend we can leverage the multicall functionality to bundle a revoke + submit in a single tx to perform the required actions.
Would you mind confirming the logic of the behavior? Because otherwise, I'm trying to reverse engineering it and could arrive at the wrong conclusion. The new logic allows the submission of a change to the
Only if there's no direct or indirect pending proposal currently in action. To be more clear
Moreover, there are some "custom" requirements (that still need to be documented), like for example
Would you mind confirming or detailing more/correct my recap? |
Giving the immutable nature of MM (you can't upgrade and change the logic) it could make sense to create utility contracts to manage it. Like for example an external contract (with the owner or curator role) that perform all the actions needed to be able to execute
|
I confirm your first comment. We wanted For the second comment, the vault inherits from |
https://morpholabs.slack.com/archives/C02N7CSP91C/p1702634824993509
Fixes #221