Usually these findings are at most lows and and have 1000 dups, but this was not the case. Why? the truncation was hidden and you had to do the math to verify it is exploitable (gas fees can be bigger than the mistake).
Alfa: next time you spot a rounding error, do the math. And also, languages that are not Solidity are like Solidity in 2022 in terms of knowledge lol.
More specifically on this issue, there is an incorrect rounding direction in geometric pool ask_exact_amount_out, which allows theft of funds via multiple swaps..
The interesting thing about this finding is that the bug is not in checked_div_dec_floor() (well it is but it is not exploitable there, difference is on the decimal part only), but is input_amount.into_int(), which completely removes the decimal part.
So, consider a scenario BTC-USDC pool where 1 sat unit of BTC = 1999 units of USDC. An attacker can execute a swap with exact amount out 1999 units of USDC which translates to 1.999 sat of BTC.
As a result of the bug above, the attacker can obtain 1999 units of USDC while paying 1 sats of BTC every swap (actual price: 1000 units of USDC per 1 sat of BTC). Eventually this can accumulate with multiple swaps to drain the BTC pool.
Conclusion
This finding would earn you $7467, which is honestly huge, if this was solidity it would have way more dups, even if this is a particularity of the into_int() operation. Do what you want with this information.
