# Users will lose their cross-chain transaction if the destination router do not have enough WETH reserves.

When destination router's WETH reserves are insufficient, dcntEth is sent to the bridge adapter target instead of the user, permanently losing the cross-chain funds.

- Payout: Contest reward
- Severity: high
- Program: Decent
- Credited: haxatron
- Disclosed: 2024-03-22
- Write-up quality: 7/10
- Original: https://github.com/code-423n4/2024-01-decent-findings/issues/59
- Library page: https://bugbountylibrary.com/r/c4%3A2024-01-decent%3AH-04
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:evm tech:solidity technique:source-review vuln:business-logic

**Target:** DecentEthRouter.onOFTReceived cross-chain OFT receiver
**Root cause:** onOFTReceived falls back to dcntEth.transfer(_to, _amount) when WETH balance < amount, but for MT_ETH_TRANSFER_WITH_PAYLOAD _to is the destination bridge adapter, not the user, and the adapter has no way to withdraw dcntEth.
**Steps:**
1. Source chain: UTB calls DecentBridgeAdapter.bridge, which calls router.bridgeWithPayload with _toAddress = destinationBridgeAdapter[dstChainId].
2. _getCallParams encodes payload as (msgType, msg.sender, _toAddress, deliverEth, additionalPayload), so _to on destination = destination bridge adapter.
3. Destination router receives OFT via onOFTReceived; if weth.balanceOf(router) < _amount, it executes `dcntEth.transfer(_to, _amount)` and returns.
4. dcntEth lands on the destination bridge adapter, which has no function to redeem or forward dcntEth; user funds are stuck.
**How found:** Code-reading of onOFTReceived fallback branch, then tracing the payload encoding to confirm _to is the destination bridge adapter rather than the end user for MT_ETH_TRANSFER_WITH_PAYLOAD.
**Exploitation:** No attacker needed; occurs naturally when destination router WETH reserves are depleted by more inbound than outbound transfers. User's bridged funds are irrecoverably sent to the adapter contract.
**Insight:** In cross-chain receivers, the payload's _to field often means the execution target, not the beneficiary; check every fallback/refund path that reuses _to to ensure funds reach a user-controlled address.