BriVault
First Flight #52
Beginner FriendlySolidity
100 EXP
View results
Previous Next
Submission Details
Severity: high
Valid

Inconsistent Deposit and Join Logic for Non-Self Receivers

stevenalenga

Risk

Likelihood

Depositing assets for another address.

Impact

Receiver cannot participate, limiting usability and potentially causing confusion or stuck funds.

Reference Files

src/briVault.sol

Description

  • Normally, depositing for another address should allow that address to join and participate fully in the event.

  • The inconsistency is that stakedAsset is credited to receiver, but joinEvent checks stakedAsset[msg.sender], preventing the receiver from joining and participating.

if (stakedAsset[msg.sender] == 0) { // @> Checks msg.sender, not allowing deposits for others
revert noDeposit();
}

Proof of Concept

Depositing for user2 credits stakedAsset to user2, but user2 cannot join because joinEvent checks user2's stakedAsset via msg.sender.

function testDepositForOtherCannotJoin() public {
vm.startPrank(user1);
mockToken.approve(address(briVault), 5 ether);
briVault.deposit(5 ether, user2); // Credits stakedAsset to user2
vm.stopPrank();
​
vm.startPrank(user2);
vm.expectRevert(abi.encodeWithSignature("noDeposit()")); // user2 cannot join despite having stakedAsset
briVault.joinEvent(1);
vm.stopPrank();
}

Recommended Mitigation

Require deposits to be for self to avoid confusion.

// In deposit function, add:
+ require(receiver == msg.sender, "Cannot deposit for others");
Updates

Appeal created

bryanconquer Lead Judge 16 days ago
Submission Judgement Published
Validated
Assigned finding tags:

Shares Minted to msg.sender Instead of Specified Receiver

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.

Give us feedback!