deposit(uint256 assets, address receiver) should mint vault shares to receiver, but BriVault calls _mint(msg.sender, participantShares) (src/briVault.sol:231). Integrators that deposit on behalf of users transfer the assets, yet the caller retains the shares. The receiver’s stakedAsset is updated, allowing them to join, but because balanceOf(receiver) == 0, they can never withdraw. The caller holds shares but is not mapped to any team and fails the winner check.
Likelihood: High – delegated deposits are standard for ERC4626 vaults (e.g., routers, smart accounts).
Receivers lose 100% of the deposit; callers hold unusable shares.
Breaks ERC4626 compatibility, blocking integrations.
Account A calls deposit(5 ether, accountB).
stakedAsset[accountB] shows a balance, but balanceOf(accountB) == 0.
Account B cannot withdraw winnings because they never receive shares; Account A cannot withdraw because they have no team registration.
(Reproduced in test/BriVaultAttack.t.sol:219 via testDepositForDifferentReceiverMintsSharesToCaller.)
Mint shares to receiver (_mint(receiver, participantShares)) and ensure all accounting follows the share holder.
Update stakedAsset, userToCountry, and userSharesToCountry to align with whichever address actually owns the shares.
Add ERC4626 compliance tests covering delegated deposits.
Proposed patch (Solidity-like pseudocode):
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.