The L1AssetRouter:: transferFundsToNTV
function assumes that the _amount of tokens specified will be successfully transferred from the user or legacyBridge to the NativeTokenVault. However, this assumption does not hold for non-standard ERC20 tokens, such as fee-on-transfer tokens or rebalancing tokens, which can result in an incorrect amount being transferred. This may lead to discrepancies in L1 and L2 states, and in some cases, funds may become locked in the NativeTokenVault.
When users call Bridgehub::requestL2TransactionDirect/requestL2TransactionTwoBridges
on L1 to perform an L1->L2 transaction, they must deposit token to L1NativeTokenVault to mint a corresponding amount of tokens on L2 at a 1:1 ratio. The deposit logic is implemented in L1AssetRouter::transferFundsToNTV
, which uses safeTransferFrom
to transfer tokens from _originalCaller
( or legacyBridge
) to L1NativeTokenVault
. The code is as follows:
However, the actual transferred amount is not validated against _amount
, which poses a significant risk for non-standard tokens, such as:
Fee-on-transfer tokens: Actual transferred amounts may be less than _amount.
Rebalancing tokens: Balances may adjust dynamically, leading to discrepancies with _amount.
This could result in inconsistencies between the L1 and L2 states. For example:
Tokens minted on L2 are based on _amount
, but the actual amount received by L1NativeTokenVault
may be less.
Recovery of failed deposits (bridgeRecoverFailedTransfer) on L2 may fail due to insufficient L1 funds. L2->L1 withdrawals could also fail, locking funds in the L1 vault.
Inconsistent states between L1 and L2: Over-minting on L2 could lead to user balance discrepancies and loss of trust.
Funds locked in L1NativeTokenVault
: Insufficient funds could block operations such as: Failed deposit recovery (bridgeRecoverFailedTransfer); L2->L1 withdrawals. Ultimately, funds may become permanently inaccessible.
Manual
After invoking safeTransferFrom
, verify the actual amount transferred by comparing the L1NativeTokenVault balance before and after the transaction. Improved code:
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.