Description
Fee-on-transfer tokens will cause pools to account for more tokens than they actually receive. This happens because the pools use user-provided amounts or amounts derived from these, instead of the actual received balances.
The snippets below, extracted from the swap function, illustrate this issue. The offer_amount transferred to the contract, which could be less than the amount actually received by the contract, is used to compute the pool balance.
Additionally, the provide_liquidity function in the stable pool uses user-provided amounts to compute the number of shares allocated to users.
However, the pool balance is safely updated by querying the actual contract balance.
Moreover, the events triggered in the provide_liquidity function of both pool contracts use user-derived amounts. In a fee-on-transfer scenario, this would cause the events to not reflect the actual received balance. An example from the stable pool is provided below.
Recommendation
Use effectively received balance values instead of user-provided values, or values derived from these. Otherwise, clearly document these limitations.
Location
Description Fee-on-transfer tokens will cause pools to account for more tokens than they actually receive. This happens because the pools use user-provided amounts or amounts derived from these, instead of the actual received balances. The snippets below, extracted from the swap function, illustrate this issue. The offer_amount transferred to the contract, which could be less than the amount actually received by the contract, is used to compute the pool balance. Additionally, the provide_liquidity function in the stable pool uses user-provided amounts to compute the number of shares allocated to users. However, the pool balance is safely updated by querying the actual contract balance. Moreover, the events triggered in the provide_liquidity function of both pool contracts use user-derived amounts. In a fee-on-transfer scenario, this would cause the events to not reflect the actual received balance. An example from the stable pool is provided below.
Recommendation Use effectively received balance values instead of user-provided values, or values derived from these. Otherwise, clearly document these limitations.