No validation that deposit receiver is the actual user (msg.sender)

[jeremie-olivier]

Description

The deposit(), createAtoms(), createTriples(), and depositBatch() functions all accept a receiver parameter that is forwarded directly to ethMultiVault.deposit() without any validation that it matches msg.sender.

This means a dApp integrating the Fee Proxy could set the receiver to:

• The proxy contract itself
• The dApp's own wallet
• Any arbitrary address

...as long as that address has approved the proxy on the MultiVault. The user pays msg.value (deposit + fees), but the shares are minted to someone else entirely.

Attack scenario

1. User interacts with a malicious/misconfigured dApp that uses the Fee Proxy
2. The dApp calls proxy.deposit{value: userFunds}(dAppWallet, termId, curveId, 0)
3. The user's ETH is deposited, fees are collected, but shares go to the dApp's wallet — not the user
4. The user has no recourse — the transaction was valid from the contract's perspective

Suggested fix

Option A: Force receiver == msg.sender

function deposit(...) external payable returns (uint256 shares) {
    // receiver is always the caller
    shares = ethMultiVault.deposit{value: assets}(
        msg.sender,  // hardcoded
        termId, curveId, minShares
    );
}

Option B: Validate receiver explicitly

if (receiver != msg.sender) {
    revert Errors.IntuitionFeeProxy_ReceiverMismatch();
}

Affected functions

• deposit()
• createAtoms()
• createTriples()
• depositBatch()

[Sikkra]

Claiming Bounty 2A for Issue #1 with PR #11: #11

Summary:

• Added IntuitionFeeProxy_ReceiverMismatch and enforce receiver == msg.sender in createAtoms, createTriples, deposit, and depositBatch before forwarding value to MultiVault.
• Added regression tests for all four affected functions.

Verification:

• npm run compile passed
• npm test passed: 38 passing

USDC/Base payout address if accepted: 0xa925FdD65a0f34bb415Bae1c57536Be33AbCfA92