# Gas fees are refunded to a wrong address when transferring tokens via InterchainToken.interchainTransferFrom

InterchainToken.interchainTransferFrom refunds cross-chain gas fees to the token owner instead of the approved caller who paid them, causing fee loss.

- Payout: Contest reward
- Severity: medium
- Program: Axelar Network
- Credited: Jeiwan
- Disclosed: 2023-11-29
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2023-07-axelar-findings/issues/316
- Library page: https://bugbountylibrary.com/r/c4%3A2023-07-axelar%3AM-05
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:business-logic

**Target:** InterchainToken / TokenManager / InterchainTokenService cross-chain transfer
**Root cause:** interchainTransferFrom passes the token owner as the sender/sourceAddress down to gasService.payNativeGasForContractCall, which uses that address as refundTo, so refunds go to the owner rather than msg.sender who paid msg.value.
**Steps:**
1. Approved address calls `InterchainToken.interchainTransferFrom(owner, to, amount, ...)` with `msg.value` for gas
2. interchainTransferFrom calls `tokenManager.transmitInterchainTransfer` passing owner as sender
3. TokenManager calls `interchainTokenService.transmitSendToken` with sourceAddress=owner
4. transmitSendToken calls `_callContract` which uses msg.value to pay gas via `gasService.payNativeGasForContractCall` with refundTo=owner
5. Refund of unused gas goes to owner, not the caller who paid
**How found:** Traced the call stack from interchainTransferFrom down to _callContract and noticed the refundTo address passed to payNativeGasForContractCall was the sender argument (token owner), not msg.sender.
**Exploitation:** Caller pays gas fees via msg.value but refund is routed to token owner; caller loses fees and owner gains them. Requires an approved spender transferring on behalf of an owner.
**Insight:** When auditing cross-chain/paymaster flows, trace who pays msg.value versus who is recorded as refund recipient; approved-spender paths often conflate 'sender' with 'payer'.
