The protocol documentation suggests that users should be able to register a friend or another participant as a beneficiary. However, the current implementation of both the deposit and receive functions only operates on msg.sender, which limits functionality. Furthermore, the receive function does not allow specifying a beneficiary, creating an inconsistency in the expected behavior.
Root Cause:
The deposit function lacks a _beneficiary parameter to specify an external participant's address.
The receive function exclusively operates on msg.sender, preventing it from supporting beneficiary registration.
Expected Behavior:
Both deposit and ETH-based contributions should allow specifying a beneficiary address, enabling participants to register others.
Current Behavior:
The deposit function only registers or adds funds for msg.sender.
The receive function adds ETH balance only to msg.sender.
This inconsistency in implementation and lack of flexibility lead to:
User Confusion: Users cannot register friends or other participants as suggested in the protocol documentation.
Reduced Usability: The inability to register external participants may hinder the protocol's adoption.
Protocol Misalignment: The actual behavior does not align with the protocol’s stated goals.
Manual code review
Foundry
1 - Introduce a depositWithETH Function:
Replace the receive function with a more explicit function that allows specifying a _beneficiary.
2 - Update the deposit Function:
Include a _beneficiary parameter in the deposit function to allow registering other participants.
3 - Test the New Functionalities:
Add unit tests to validate beneficiary registration for both token-based and ETH-based contributions.
Implementing these changes ensures consistency with the protocol’s stated goals and improves usability by allowing users to register beneficiaries.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.