Skip to content
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

Unfair changes to cooldown period affect existing withdrawals #607

Open
howlbot-integration bot opened this issue May 28, 2024 · 7 comments
Open

Unfair changes to cooldown period affect existing withdrawals #607

howlbot-integration bot opened this issue May 28, 2024 · 7 comments
Labels
bug Something isn't working downgraded by judge Judge downgraded the risk level of this issue grade-a primary issue Highest quality submission among a set of duplicates QA (Quality Assurance) Assets are not at risk. State handling, function incorrect as to spec, issues with clarity, syntax 🤖_31_group AI based duplicate group recommendation sponsor disputed Sponsor cannot duplicate the issue, or otherwise disagrees this is an issue sufficient quality report This report is of sufficient quality

Comments

@howlbot-integration
Copy link

Lines of code

https://github.com/code-423n4/2024-04-renzo/blob/main/contracts/Withdraw/WithdrawQueue.sol#L287

Vulnerability details

To prevent users from immediately claiming their withdrawals, the WithdrawQueue enforces a cooldown period during which the funds cannot be claimed. This cooldown period is stored in the coolDownPeriod variable and can be modified by the admin via the updateCoolDownPeriod() function.

The issue is that when a user goes to claim their withdrawal by calling claim(), the current value of coolDownPeriod is used to check if enough time has elapsed since the withdrawal was initiated:

if (block.timestamp - _withdrawRequest.createdAt < coolDownPeriod) revert EarlyClaim();

This means that if the cooldown period is increased after a user initiates a withdrawal, they will have to wait longer than expected to claim their funds. This is unfair as the terms of the withdrawal should be honored as they were when the user initiated it. Conversely, if the cooldown period is decreased, users can claim their withdrawals sooner than was originally enforced when they initiated the withdrawal.

Impact

Changes to the cooldown period will unexpectedly affect existing user withdrawals.

Proof of Concept

  1. User initiates a withdrawal via withdraw() when the coolDownPeriod is set to 7 days
  2. Admin calls updateCoolDownPeriod() to change the coolDownPeriod to 30 days
  3. 7 days later, when the user tries to claim() their withdrawal, the transaction reverts with EarlyClaim
  4. User has to wait a total of 30 days to claim their withdrawal, even though the original terms were 7 days

Tools Used

Manual review

Recommended Mitigation Steps

Instead of storing the timestamp at which the request was created as WithdrawRequest.createdAt, store the timestamp at which it can be claimed by adding the current cooldown period to block.timestamp on creation and storing it as e.g. unlockTime.

Assessed type

Other

@howlbot-integration howlbot-integration bot added 2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value 🤖_31_group AI based duplicate group recommendation bug Something isn't working sufficient quality report This report is of sufficient quality labels May 28, 2024
howlbot-integration bot added a commit that referenced this issue May 28, 2024
@c4-judge
Copy link
Contributor

alcueca marked the issue as primary issue

@alcueca
Copy link

alcueca commented May 28, 2024

@jatinj615, please review

@jatinj615
Copy link

Expected behaviour. as AVS slashing can enforce a longer cooldown. and protocol want the ability to price the existing withdrawals for slashing at time of claim.

@jatinj615 jatinj615 added the sponsor disputed Sponsor cannot duplicate the issue, or otherwise disagrees this is an issue label May 29, 2024
@alcueca
Copy link

alcueca commented May 30, 2024

Usually, giving the protocol the option to change terms and conditions without giving users an option to bail out is considered a Medium. To avoid excessive reporting of issues that would invariably be found as expected behaviour by sponsors, I'm going to recommend the sponsor to clearly include in the terms and conditions that that cooldown period can be changed by governance, affecting withdrawals in the queue.

@c4-judge
Copy link
Contributor

alcueca marked the issue as unsatisfactory:
Invalid

@c4-judge c4-judge added unsatisfactory does not satisfy C4 submission criteria; not eligible for awards downgraded by judge Judge downgraded the risk level of this issue QA (Quality Assurance) Assets are not at risk. State handling, function incorrect as to spec, issues with clarity, syntax and removed 2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value labels May 30, 2024
@c4-judge
Copy link
Contributor

alcueca changed the severity to QA (Quality Assurance)

@c4-judge c4-judge reopened this May 30, 2024
@c4-judge c4-judge added grade-b and removed unsatisfactory does not satisfy C4 submission criteria; not eligible for awards labels May 30, 2024
@c4-judge
Copy link
Contributor

alcueca marked the issue as grade-b

@C4-Staff C4-Staff added grade-a and removed grade-b labels Jun 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working downgraded by judge Judge downgraded the risk level of this issue grade-a primary issue Highest quality submission among a set of duplicates QA (Quality Assurance) Assets are not at risk. State handling, function incorrect as to spec, issues with clarity, syntax 🤖_31_group AI based duplicate group recommendation sponsor disputed Sponsor cannot duplicate the issue, or otherwise disagrees this is an issue sufficient quality report This report is of sufficient quality
Projects
None yet
Development

No branches or pull requests

4 participants