Skip to content

fix: validate receiver is msg.sender in all deposit/creation functions (Issue #1)#10

Open
korpo1337 wants to merge 1 commit into
intuition-box:mainfrom
korpo1337:fix/receiver-validation-issue-1
Open

fix: validate receiver is msg.sender in all deposit/creation functions (Issue #1)#10
korpo1337 wants to merge 1 commit into
intuition-box:mainfrom
korpo1337:fix/receiver-validation-issue-1

Conversation

@korpo1337
Copy link
Copy Markdown

Fix for Issue #1: Receiver not validated as msg.sender

Problem

The deposit(), createAtoms(), createTriples(), and depositBatch() functions accept a receiver parameter without validating that it matches msg.sender. This allows a dApp integrating the Fee Proxy to set the receiver to an arbitrary address (the proxy contract itself, the dApp's own wallet, or any third-party address), as long as that address has approved the proxy on the MultiVault.

Impact: User funds (msg.value) are spent by the caller, but shares are credited to an arbitrary receiver — enabling unauthorized share redirection.

Solution

Added receiver == msg.sender validation (via custom error IntuitionFeeProxy_ReceiverNotCaller) to all four functions that accept a receiver parameter.

Changes

File Change
src/IntuitionFeeProxy.sol Added receiver validation to deposit(), createAtoms(), createTriples(), depositBatch() + updated NatSpec docs
src/libraries/Errors.sol Added IntuitionFeeProxy_ReceiverNotCaller custom error
test/IntuitionFeeProxy.test.ts Added 8 tests: 4 revert cases + 4 success cases for receiver validation

Test Results

  42 passing (611ms)

All existing tests continue to pass. All new receiver validation tests pass.

Bounty

This PR addresses Bounty 2A ($200 USDC) from Issue #2.

…s (Issue intuition-box#1)

Issue: The deposit(), createAtoms(), createTriples(), and depositBatch()
functions accept a 'receiver' parameter without validating that it matches
msg.sender. This allows a dApp integrating the Fee Proxy to set the receiver
to an arbitrary address (the proxy contract itself, the dApp's own wallet,
or any third-party address), as long as that address has approved the proxy
on the MultiVault.

Impact: User funds (msg.value) are spent by the caller, but shares are
credited to an arbitrary receiver. This breaks the fund-flow invariant and
enables unauthorized share redirection.

Fix: Added 'require(receiver == msg.sender)' check (via custom error
IntuitionFeeProxy_ReceiverNotCaller) to all four functions that accept a
receiver parameter. Updated NatSpec docs to reflect the new invariant.

Changes:
- src/IntuitionFeeProxy.sol: Added receiver validation to deposit(),
  createAtoms(), createTriples(), and depositBatch()
- src/libraries/Errors.sol: Added IntuitionFeeProxy_ReceiverNotCaller error
- test/IntuitionFeeProxy.test.ts: Added 8 tests covering receiver validation
  for all four functions (4 revert cases + 4 success cases)

All 42 tests passing.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant