While looking through the bridge accounting flow, I noticed that fee-on-transfer and rebasing tokens are explicitly documented as unsupported in both L1StandardBridge and L2StandardBridge.
At the same time, the bridge still accepts these assets and appears to account using the requested _amount directly instead of the actual received balance.
In StandardBridge::_initiateBridgeERC20 (around lines 351–363), the bridge performs safeTransferFrom(...) and then updates accounting using _amount without checking the balance delta before/after transfer.
On the receiving side, finalizeBridgeERC20 (around lines 284–293) also appears to mint/transfer using the bridged _amount directly from the message payload.
Because of that, unsupported token mechanics can still create accounting divergence instead of failing safely. For example, with a fee-on-transfer token, the bridge may receive less than _amount while the full _amount is still represented remotely.
In practice, this could lead to under-collateralized representations of the asset on the remote chain and eventual withdrawal failures once the escrowed balance becomes insufficient.
I understand these token types are documented as unsupported already, so this may be considered an accepted limitation rather than a vulnerability. Still, I thought it was worth raising since unsupported assets are currently accepted permissionlessly rather than being explicitly rejected or normalized through balance-delta accounting.
While looking through the bridge accounting flow, I noticed that fee-on-transfer and rebasing tokens are explicitly documented as unsupported in both
L1StandardBridgeandL2StandardBridge.At the same time, the bridge still accepts these assets and appears to account using the requested
_amountdirectly instead of the actual received balance.In
StandardBridge::_initiateBridgeERC20(around lines 351–363), the bridge performssafeTransferFrom(...)and then updates accounting using_amountwithout checking the balance delta before/after transfer.On the receiving side,
finalizeBridgeERC20(around lines 284–293) also appears to mint/transfer using the bridged_amountdirectly from the message payload.Because of that, unsupported token mechanics can still create accounting divergence instead of failing safely. For example, with a fee-on-transfer token, the bridge may receive less than
_amountwhile the full_amountis still represented remotely.In practice, this could lead to under-collateralized representations of the asset on the remote chain and eventual withdrawal failures once the escrowed balance becomes insufficient.
I understand these token types are documented as unsupported already, so this may be considered an accepted limitation rather than a vulnerability. Still, I thought it was worth raising since unsupported assets are currently accepted permissionlessly rather than being explicitly rejected or normalized through balance-delta accounting.