Why does the token-swap use whole u64 amounts in the following I64F64 calculation - which in my view could lead to overflow issues. The maximum Integer part from I6F64 is 2^63 -1. In their deposit_liquidity.rs file they calculated liquidity like:
That means if for example amount_a and amount_b is give in lamports which is sol * 10^9 they could only provide the square root of (2^63 - 1) / 10^9 = 3 SOL into the contract on each side. Why not cut amount/10^9 before the calculations as I64F64 has its floating precision also set to 2^-64 . Meaning, the overflow issue isnt a problem if the arguments are lamports - great for precision. But why don't they convert and calculate in SOL / use U128F0 within the contract? Or am I misunderstanding something here ?
Why does the token-swap use whole u64 amounts in the following I64F64 calculation - which in my view could lead to overflow issues. The maximum Integer part from I6F64 is 2^63 -1. In their deposit_liquidity.rs file they calculated liquidity like:
That means if for example amount_a and amount_b is give in lamports which is sol * 10^9 they could only provide the square root of (2^63 - 1) / 10^9 = 3 SOL into the contract on each side. Why not cut amount/10^9 before the calculations as I64F64 has its floating precision also set to 2^-64 . Meaning, the overflow issue isnt a problem if the arguments are lamports - great for precision. But why don't they convert and calculate in SOL / use U128F0 within the contract? Or am I misunderstanding something here ?