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:
pub fn deposit_liquidity(
ctx: Context<DepositLiquidity>,
amount_a: u64,
amount_b: u64,
) -> Result<()> {
...
let mut liquidity = I64F64::from_num(amount_a)
.checked_mul(I64F64::from_num(amount_b))
.unwrap()
.sqrt()
.to_num::<u64>();
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 ?