Closed c4-bot-2 closed 8 months ago
raymondfam marked the issue as insufficient quality report
raymondfam marked the issue as primary issue
Intended design.
rocketman-21 (sponsor) disputed
MarioPoneder marked the issue as unsatisfactory: Invalid
Lines of code
https://github.com/code-423n4/2023-12-revolutionprotocol/blob/d42cc62b873a1b2b44f57310f9d4bbfdd875e8d6/packages/protocol-rewards/src/RevolutionProtocolRewards.sol#L110
Vulnerability details
HIGH
The
builderReferral
,purchaseReferral
anddeployer
can never be equal toaddress(0)
, which leads to therevolutionRewardRecipient
stealing their rewardsDescription:
revolutionRewardRecipient
will receive the rewards of thebuilderReferral
,purchaseReferral
anddeployer
anytime that their addresses equaladdress(0)
Proof of Concept:
builderReferral
,purchaseReferral
anddeployer
can never be equal toaddress(0)
due to the fact that the function_depositPurchaseRewards
inRewardSplits.sol
explicitly checks for their address and sets it to therevolutionRewardRecipient
's address if they are equal toaddress(0)
. After that the function callsRevolutionProtocolRewards::depositRewards
. There is a check in theRevolutionProtocolRewards::depositRewards
that checks all thebuilderReferral
,purchaseReferral
anddeployer
if they have an address different thanaddress(0)
, and if they do, their addresses receive the rewards (all of their addresses will be set to the address of therevolutionRewardRecipient
). That means that if their addresses are equal toaddress(0)
, then the address that receives all the rewards is the address of therevolutionRewardRecipient
RewardSplits.sol
RevolutionProtocolRewards.sol
Tools Used:
Manual Code Review.
Recommended Mitigation Steps:
Remove the if clause in
RewardSplits::_depositPurchaseRewards
so that if the addresses of thebuilderReferral
,purchaseReferral
ordeployer
are equal to address(0), their rewards will not be received by therevolutionRewardRecipient
Assessed type
Math