You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Summary
The protocol has introduces a functionality to claim an incentive for other claimants , this would require data for the claim and according to the sponsor (asked in thread) -> Signatures are available publicly by way of API , so this way I can claim for someone else , it's a neat feature but for CGDA incentive can be disastrous.
Expected Behavior
No response
Steps To Reproduce
Scrawny Mustard Tadpole
High
claimIncentiveFor Might Lead To Loss Of Funds For CGDA Incentive
Summary
The protocol has introduces a functionality to claim an incentive for other claimants , this would require data for the claim and according to the sponsor (asked in thread) -> Signatures are available publicly by way of API , so this way I can claim for someone else , it's a neat feature but for CGDA incentive can be disastrous.
Vulnerability Detail
1.) Alice completes an action and for this action the incentive was a CGDAIncentive , the off chain mechanism verifies that Alice has performed the action successfully and grants her the claim , the claim as mentioned Signatures are available publicly by way of API
2.) Alice has a valid claim now for the CGDAIncentive , but she wants to wait for some time to claim since CGDA is dependent on lastClaimTime and she wants to maximise her gains , she wants to wait for 5 more blocks.
He does it such that Alice would get lesser incentive due to uint256 timeSinceLastClaim = block.timestamp - cgdaParams.lastClaimTime; being smaller than Alice intended and hence the rewards sent would be lesser
Is there an existing issue for this?
Package Version
0.0.0-alpha.12
Current Behavior
Summary
The protocol has introduces a functionality to claim an incentive for other claimants , this would require data for the claim and according to the sponsor (asked in thread) -> Signatures are available publicly by way of API , so this way I can claim for someone else , it's a neat feature but for CGDA incentive can be disastrous.
Expected Behavior
No response
Steps To Reproduce
Scrawny Mustard Tadpole
High
claimIncentiveFor Might Lead To Loss Of Funds For CGDA Incentive
Summary
The protocol has introduces a functionality to claim an incentive for other claimants , this would require data for the claim and according to the sponsor (asked in thread) -> Signatures are available publicly by way of API , so this way I can claim for someone else , it's a neat feature but for CGDA incentive can be disastrous.
Vulnerability Detail
1.) Alice completes an action and for this action the incentive was a CGDAIncentive , the off chain mechanism verifies that Alice has performed the action successfully and grants her the claim , the claim as mentioned Signatures are available publicly by way of API
2.) Alice has a valid claim now for the CGDAIncentive , but she wants to wait for some time to claim since CGDA is dependent on lastClaimTime and she wants to maximise her gains , she wants to wait for 5 more blocks.
https://github.com/sherlock-audit/2024-06-boost-aa-wallet/blob/main/boost-protocol/packages/evm/contracts/incentives/CGDAIncentive.sol#L124
3.) Bob comes and claims the incentive for Alice earlier ->
https://github.com/sherlock-audit/2024-06-boost-aa-wallet/blob/main/boost-protocol/packages/evm/contracts/BoostCore.sol#L164
He does it such that Alice would get lesser incentive due to uint256 timeSinceLastClaim = block.timestamp - cgdaParams.lastClaimTime; being smaller than Alice intended and hence the rewards sent would be lesser
https://github.com/sherlock-audit/2024-06-boost-aa-wallet/blob/main/boost-protocol/packages/evm/contracts/incentives/CGDAIncentive.sol#L123-L130
4.) Alice lost her incentives , she wanted to claim after 5 blocks and make maximum gains , but Bob ruined her returns.
Impact
Alice will get way lesser incentives than intended due to Bob claiming on her behalf.
Code Snippet
https://github.com/sherlock-audit/2024-06-boost-aa-wallet/blob/main/boost-protocol/packages/evm/contracts/BoostCore.sol#L164
Tool used
Manual Review
Recommendation
Done let users cliam for other for such time dependent incentives.
Link to Minimal Reproducible Example (StackBlitz, CodeSandbox, GitHub repo etc.)
sherlock-audit/2024-06-boost-aa-wallet-judging#178
Anything else?
No response
The text was updated successfully, but these errors were encountered: