Closed code423n4 closed 1 year ago
141345 marked the issue as primary issue
141345 marked the issue as sufficient quality report
As discussed with this warden on Immunefi, the situation described is accurate, however this has long been a known behavior in the protocol. Any delegator who claims their rewards in a round, prior to their Orchestrator calling reward, forfeit that rounds' rewards. Delegators have been instructed as such in terms of the side effects of choosing to take bonding actions before their delegate has called reward.
victorges (sponsor) disputed
Recognised consequence of design, marking as invalid.
HickupHH3 marked the issue as unsatisfactory: Invalid
hello @HickupHH3 i would like to point you to some facts and hope that you will upgrade this report to valid medium 1.sponsor confirms that this is correctly described situation and test also does that. 2.known issues had no word about this as known. 3.BondingManager contract was in scope.
So this is the situation. I have spent time on this and found the issue. Even that sponsor says that it's known for all participants of protocol, doesn't actually mean that it's known for us - auditors. For such cases we have known issues section that should describe all known issues. So this protocol didn't list this concern as known. That's why i have spend time and provided test that proves my point.
I believe that as lose of yields this issue should be accepted as medium severity and sponsor should mark it as acknowledged as indeed they agree that such situation can occur, but they wouldn't like to fix it.
Also, pls, consider you own comment which also talks about the need to provide known limitations in the readme.
thanks
Even that sponsor says that it's known for all participants of protocol, doesn't actually mean that it's known for us - auditors
This isn't exactly true, as it seems that you've reported this before and got rejected, so at least you know about it.
As discussed with this warden on Immunefi, the situation described is accurate, however this has long been a known behavior in the protocol.
It feels like a dangerous precedent to award findings that were rejected before, with the assumption that the sponsor is acting in good faith here.
Delegators have been instructed as such in terms of the side effects of choosing to take bonding actions before their delegate has called reward.
While it may not be documented, it's at least been communicated to the relevant parties.
This isn't exactly true, as it seems that you've reported this before and got rejected, so at least you know about it.
It was done in the same time with audit contest and with the consent(advice) of sponsor. So no, i didn't know that.
While it may not be documented, it's at least been communicated to the relevant parties.
Indeed, but i didn't know about that, as well as all auditors.
@victorges can u verify the claim made regarding the immunefi submission, and do u have written documentation for the known behaviour?
Hey @HickupHH3 ! The Immunefi submission was made in concurrence with the C4 audit as a strategy to get paid from 2 different sources for the same issue. @rvierdiyev did message me on Discord about it and I told him the preferable would be submitting only on C4 audit as the contract in question was in scope [1]. Since we got the Immunefi report before the C4 audit finished, the conversation had already happened and the report was dismissed over there.
Regardless, we dismissed the report in Immunefi as it refers to a known behavior of the cumulative reward claiming logic, not due to the duplicate report. Here are some places where we've talked about this publicly:
CAUTION: After you call claimEarnings() for a round, you can not call it again for that round. That means that if the transcoder earns more fees or calls reward() later in that round, you can not access those rewards or fees. To really optimize, change your bonding status late in the round after most of the fees have been collected and reward() has been called.
And the one mistake you can make is claiming earnings for the current round before reward is called, because then you miss the chance to re-allocate the rewards for the current round into your account.
If you think this report should be accepted given that context, I'd say it should at least have a reduced severity as it's at most an improvement proposal, not an inconsistency with the expected behavior.
[1] It would be great to have a way to prevent the double reporting practice on modified contracts when we run an audit.
victorges marked the issue as disagree with severity
@victorges appreciate the context & info you've given!
I agree that at best this issue is QA(R).
[1] It would be great to have a way to prevent the double reporting practice on modified contracts when we run an audit.
This shouldn't be the case, I'll flag to the C4 team to tighten guidelines!
Lines of code
https://github.com/code-423n4/2023-08-livepeer/blob/main/contracts/bonding/BondingManager.sol#L1550
Vulnerability details
Impact
User who will do any action in round before reward is called will loose rewards for that round
Proof of Concept
BondingManager operates with rounds. When user performs any action, then
_autoClaimEarnings
is called for him in order to claim rewards from the user'slastClaimRound
tillcurrentRound
.In order to do so, each round has earning pool data information that contains
cumulativeRewardFactor
variable. This variable is likely to increase from past rounds to future rounds.This is because, transcoder can call
reward
function for each round, which will claim stake tokens that should be distributed among delegators. This will changecumulativeRewardFactor
variable for current round.In case if user has already claimed round, then he can't claim it again as it's stored as
lastClaimRound
. Because of that, in case if use did any action, for example staked more funds, then_autoClaimEarnings
is called for him, which will claim current round for user. Then if transcoder will callreward
for current round andcumulativeRewardFactor
for it will increase, then user will not be able to receive rewards for it.I have created test to show this. This test was created inside
Rewards.js
file in thetest/integration
folder. Copy content there and run. Pls, check my comments under the test to see how to run it and how to detect error.Tools Used
VsCode
Recommended Mitigation Steps
I don't know good solution. This will need to change rounds handling. Maybe do not claim current round for user in case if last reward round of transcoder is less than current round.
Assessed type
Error