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

Fix add liquidity proportional with 0 slippage failing #552

Closed
brunoguerios opened this issue Jan 9, 2025 · 3 comments
Closed

Fix add liquidity proportional with 0 slippage failing #552

brunoguerios opened this issue Jan 9, 2025 · 3 comments
Labels
bug Something isn't working

Comments

@brunoguerios
Copy link
Member

Reported by @gosuto-inzasheru

pool 0x10a04efba5b880e169920fd4348527c64fb29d4d
eoa 0x4BC8121278056BFCaC2BD14D455659224d6dDf48
slippage 0% fails
slippage 1% succeeds

gosuto.eth
1 hour ago
ok then im wondering why it didnt work with slippage set to 0
there are no swaps in this pool that could have changed the proportional price

Image

assumption: rounding issue?

@brunoguerios brunoguerios added the bug Something isn't working label Jan 9, 2025
@agualis
Copy link
Contributor

agualis commented Jan 9, 2025

@brunoguerios

Here you have some concrete info to debug better.
@gosuto-inzasheru already added to this pool so his balances are different now (from the screenshot above) but you still can reproduce the issue with the current balances.

User Address: 0x4BC8121278056BFCaC2BD14D455659224d6dDf48
Block number: 21586944n

The new state is this one in that block :

Screenshot 2025-01-09 at 15 01 26

In the specific case of proportional adds for v3 boosted pools we use referenceAmount.

So from the FE we send the following query when the user maximises USDC balance (409248):

 {
    "chainId": 1,
    "rpcUrl": "http://localhost:3000/api/rpc/MAINNET",
    "referenceAmount": {
        "address": "0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48",
        "rawAmount": "409248",
        "decimals": 6,
        "symbol": "USDC"
    },
    "kind": "Proportional",
    "sender": "0x4BC8121278056BFCaC2BD14D455659224d6dDf48"
}

We get this query output:

{
    "poolId": "0x10a04efba5b880e169920fd4348527c64fb29d4d",
    "poolType": "Stable",
    "addLiquidityKind": "Proportional",
    "bptOut": {
        "token": {
            "chainId": 1,
            "address": "0x10a04efba5b880e169920fd4348527c64fb29d4d",
            "decimals": 18,
            "wrapped": "0x10a04efba5b880e169920fd4348527c64fb29d4d"
        },
        "scalar": "1",
        "decimalScale": "1000000000000000000",
        "amount": "490366908522601726",
        "scale18": "490366908522601726"
    },
    "amountsIn": [
        {
            "token": {
                "chainId": 1,
                "address": "0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48",
                "decimals": 6,
                "wrapped": "0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48"
            },
            "scalar": "1000000000000",
            "decimalScale": "1000000",
            "amount": "408259",
            "scale18": "408259000000000000"
        },
        {
            "token": {
                "chainId": 1,
                "address": "0x7751e2f4b8ae93ef6b79d86419d42fe3295a4559",
                "decimals": 18,
                "wrapped": "0x7751e2f4b8ae93ef6b79d86419d42fe3295a4559"
            },
            "scalar": "1",
            "decimalScale": "1000000000000000000",
            "amount": "82638373915523091",
            "scale18": "82638373915523091"
        }
    ],
    "chainId": 1,
    "protocolVersion": 3,
    "userData": "0x",
    "to": "0x1CD776897ef4f647bf8241Ec69549e4A9cb1D608"
}

with that, we build the tx calldata with (slippage 0% by default):

{
    "functionName": "addLiquidityProportionalToERC4626Pool",
    "args": [
        "0x10A04efbA5B880e169920Fd4348527C64FB29d4D",
        [
            "408259",
            "82638373915523091"
        ],
        "490366908522601726",
        false,
        "0x"
    ]
}

@brunoguerios
Copy link
Member Author

After some discussion we're under the impression this is not caused by filling out user maxBalance, but it's just a side effect of addLiquidityBoosted queries not being 100% precise.
With that, setting 0% slippage is likely to fail because limits are set slightly below the actual amountsIn required.

@brunoguerios
Copy link
Member Author

Fixed on the FE ✅

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants