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

Protocol fees from execution layer rewards will be lost #497

Open
howlbot-integration bot opened this issue May 10, 2024 · 3 comments
Open

Protocol fees from execution layer rewards will be lost #497

howlbot-integration bot opened this issue May 10, 2024 · 3 comments
Labels
bug Something isn't working downgraded by judge Judge downgraded the risk level of this issue duplicate-498 grade-a Q-33 QA (Quality Assurance) Assets are not at risk. State handling, function incorrect as to spec, issues with clarity, syntax 🤖_230_group AI based duplicate group recommendation 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/1c7cc4e632564349b204b4b5e5f494c9b0bc631d/contracts/Deposits/DepositQueue.sol#L160

Vulnerability details

Vulnerability Detail

The DepositQueue contract states the following regarding the receive() function:

/// This should receive ETH from scenarios like Execution Layer Rewards and MEV from native staking

However, Execution layer rewards are sent by directly increasing the contract's balance without calling the receive() function.

This means that when rewards are accrued the following logic within the receive() function will not execute:

  1. Protocol fee collection
  2. Filling of WithdrawalQueue buffer
  3. Incrementing the value at totalEarned[address(0x0)]

Impact

The protocol does not receive fees from execution layer rewards, which is a major disruption to protocol functionality. Also, the WithdrawalQueue is not prioritised leading to a potential state of inability to withdraw.

Proof of Concept

receive() function

https://github.com/code-423n4/2024-04-renzo/blob/1c7cc4e632564349b204b4b5e5f494c9b0bc631d/contracts/Deposits/DepositQueue.sol#L160

Tools Used

Manual Review

Recommended Mitigation

Ensure that rewards are sent to a different contract, not DepositQueue as it is stated in the comments.

Assessed type

Error

@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 🤖_230_group AI based duplicate group recommendation bug Something isn't working sufficient quality report This report is of sufficient quality labels May 10, 2024
howlbot-integration bot added a commit that referenced this issue May 10, 2024
@C4-Staff
Copy link

CloudEllie marked the issue as duplicate of #498

@c4-judge c4-judge added 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 17, 2024
@c4-judge
Copy link
Contributor

alcueca changed the severity to QA (Quality Assurance)

@c4-judge
Copy link
Contributor

alcueca marked the issue as grade-a

@C4-Staff C4-Staff reopened this Jun 3, 2024
@C4-Staff C4-Staff added the Q-33 label 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 duplicate-498 grade-a Q-33 QA (Quality Assurance) Assets are not at risk. State handling, function incorrect as to spec, issues with clarity, syntax 🤖_230_group AI based duplicate group recommendation sufficient quality report This report is of sufficient quality
Projects
None yet
Development

No branches or pull requests

3 participants