Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Overflow issue in swap ? #73

Open
20vision opened this issue Mar 26, 2024 · 0 comments
Open

Overflow issue in swap ? #73

20vision opened this issue Mar 26, 2024 · 0 comments

Comments

@20vision
Copy link

20vision commented Mar 26, 2024

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 ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant