Normal behavior:
The deposit(uint256 assets, address receiver) should mint vault shares to the specified receiver address. The receiver is intended to be the beneficiary of the deposit, not necessarily the caller. The function is supposed to buy the assets for others, but it mints to msg.sender instead.
Issue:
In the current implementation, the function accepts a receiver parameter but ignores it when minting shares, always minting to msg.sender instead. At the same time, it emits the deposited(receiver, value) event and records stakedAsset[msg.sender].
This inconsistency leads to misaligned ownership records:
The event log and function parameters suggest that receiver received the deposit.
In reality, msg.sender owns the minted shares and recorded stake.
This discrepancy can mislead front-ends, off-chain indexers, and users, creating false attribution of ownership and potential loss of expected returns for the intended receiver.
Likelihood:
Occurs whenever receiver != msg.sender.
Common in scenarios such as staking on behalf of another user, integrations with DAOs, or deposit relayers.
Impact:
Accounting mismatch between event logs and on-chain state.
Receiver never actually receives shares, while they appear to have deposited assets.
Could break integrations, create user confusion, or lead to loss of rewards or withdrawals if the wrong account is recognized as depositor.
This PoC demonstrates the misleading behavior when receiver differs from msg.sender.
This shows that while the event and parameter imply user2 deposited, the shares and staked amount belong to user1, creating inconsistent state.
Align the function logic with ERC-4626 standard by minting shares to the receiver and recording the correct ownership mapping.
This ensures the depositor and receiver relationship remains consistent both on-chain and in emitted events.
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.