# 50461 sc insight incorrect deposit event receiver logged in bridge functions of dexaggregatorwrapperwithpredicateproxy sol 

**Submitted on Jul 25th 2025 at 03:35:14 UTC by @Rhaydden for** [**Attackathon | Plume Network**](https://immunefi.com/audit-competition/plume-network-attackathon)

* **Report ID:** #50461
* **Report Type:** Smart Contract
* **Report severity:** Insight
* **Target:** <https://github.com/immunefi-team/attackathon-plume-network-nucleus-boring-vault/blob/main/src/helper/DexAggregatorWrapperWithPredicateProxy.sol>
* **Impacts:** Any off-chain system that attributes shares to addresses based on the emitted `Deposit` event may incorrectly attribute shares to the wrong address.

## Description

### Brief / Intro

The two bridge helper functions `depositAndBridgeOneInch()` and `depositAndBridgeOkxUniversal()` emit a `Deposit` event that uses `msg.sender` as the share receiver. In practice, shares are burned locally and recreated for `bridgeData.destinationChainReceiver` on the destination chain, so the event’s `receiver` field is incorrect.

### Vulnerability Details

Relevant code:

```solidity
function _calcSharesAndEmitEvent(
        ERC20 supportedAsset,
        CrossChainTellerBase teller,
        address fromToken,
        uint256 fromTokenAmount,
        uint256 supportedAssetAmount
) internal {
    ...
    uint256 shares = supportedAssetAmount.mulDivDown(
        10 ** teller.vault().decimals(),
        AccountantWithRateProviders(teller.accountant()).getRateInQuoteSafe(supportedAsset)
    );
    emit Deposit(
        fromToken,          // depositAsset
        msg.sender,         // ← incorrect when bridging
        address(supportedAsset),
        fromTokenAmount,
        supportedAssetAmount,
        shares,
        address(teller),
        address(teller.vault())
    );
}
```

Both bridge wrappers call this helper after performing the bridge:

```solidity
teller.depositAndBridge(...);
_calcSharesAndEmitEvent(...);
```

During a bridge:

* `msg.sender` is the EOA that calls the wrapper.
* `teller.depositAndBridge` mints shares to the wrapper, immediately burns them, and bridges the same amount to `bridgeData.destinationChainReceiver`.
* The emitted `Deposit` event thus claims that `msg.sender` received `shares`, which never happens.

### Impact Details

Off-chain systems that rely on this event to determine who received shares will attribute them to the caller (`msg.sender`) instead of the actual recipient (`bridgeData.destinationChainReceiver`).

## Fix

Pass the real receiver into `_calcSharesAndEmitEvent` so the `Deposit` event correctly records the true destination receiver.

## References

<https://github.com/immunefi-team/attackathon-plume-network-nucleus-boring-vault/blob/0ee676b5715075c26db6706960fd49ab59b587fc/src/helper/DexAggregatorWrapperWithPredicateProxy.sol#L407>

## Proof of Concept

{% stepper %}
{% step %}

### Step: Setup / Deploy

1. Deploy the relevant contracts.
2. Choose two EOAs:
   * Alice (caller)
   * Bob (destinationChainReceiver)
     {% endstep %}

{% step %}

### Step: Execute and Observe

1. Alice calls `depositAndBridgeOneInch` with `bridgeData.destinationChainReceiver = Bob`.
2. Observe the `Deposit` event on the source chain: it reports `receiver = Alice`.
3. After the bridge finalizes, Bob holds the bridged shares on the destination chain, while Alice never held them — demonstrating the event reports the wrong receiver.
   {% endstep %}
   {% endstepper %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://reports.immunefi.com/plume-or-attackathon/50461-sc-insight-incorrect-deposit-event-receiver-logged-in-bridge-functions-of-dexaggregatorwrapper.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.