Skip to content

Conversation

@aalavandhan
Copy link
Member

@aalavandhan aalavandhan commented Dec 29, 2022

  1. Using mulDiv for perp math. Allows intermediate values to be as large as 2**256-1
  2. Updated some inconsistent comments. "Rollover" instead of "rotation".
  3. Updated internal helper to use depositBond reference from storage
  4. Allowing keeper reference to be address(0) to allow for eventual retirement
  5. Added a whitelist for rollovers. (Empty whitelist means every address can rollover)
  6. Added a helper function (getReserveTrancheValue) to perp which calculates the value of each reserve token.
  7. Moved onlyOwner methods and events out of the interface definition
  8. Bumped up solidity version

@aalavandhan aalavandhan added the next-release Changes for upcoming release label Feb 1, 2023
} else if (!authorize && _authorizedRollers.contains(roller)) {
_authorizedRollers.remove(roller);
} else {
revert RollerAuthorizationFailed();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason to make this not idempotent?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Torn between both options. Reverting intuitively feels safer ..

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Depends on context, I guess.

Reverting can make interoperability between smart contracts more difficult, but it can make calls from outside like Gelato potentially easier. I'd normally default to not reverting, just like you default to not throwing exception in the JVM.

In this case, it shouldn't /really/ matter since this'll generally be called by governance. It just seems a bit weird to revert the authorize call when, at the end of it, the address is actually still authorized. I think that would still be successful as far as the caller is concerned--it just happens to be a no-op.

I can see some weird cases where a governance action might want to pre-emptively call an authorize function as a pre-step before another op, just to make sure the starting context is correct and not rely on a separate governance action to execute first. So I think I'd still prefer idempotency.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

aalavandhan and others added 2 commits February 14, 2023 09:57
Co-authored-by: Brandon Iles <brandon@fragments.org>
} else if (!authorize && _authorizedRollers.contains(roller)) {
_authorizedRollers.remove(roller);
} else {
revert RollerAuthorizationFailed();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Depends on context, I guess.

Reverting can make interoperability between smart contracts more difficult, but it can make calls from outside like Gelato potentially easier. I'd normally default to not reverting, just like you default to not throwing exception in the JVM.

In this case, it shouldn't /really/ matter since this'll generally be called by governance. It just seems a bit weird to revert the authorize call when, at the end of it, the address is actually still authorized. I think that would still be successful as far as the caller is concerned--it just happens to be a no-op.

I can see some weird cases where a governance action might want to pre-emptively call an authorize function as a pre-step before another op, just to make sure the starting context is correct and not rely on a separate governance action to execute first. So I think I'd still prefer idempotency.

Copy link
Member

@brandoniles brandoniles left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, just the last minor comment about emitting the event

@aalavandhan aalavandhan merged commit e4884a0 into main Feb 23, 2023
@aalavandhan aalavandhan deleted the perp-updates branch February 23, 2023 15:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

next-release Changes for upcoming release

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants