balancer / b-sdk Goto Github PK

Add Init Pool functionality to Gyro Pools

If no swapOptions.block is set the subgraph query fails. Think it's on fetchDataFromSubgraph().

https://github.com/balancer-labs/b-sdk/blob/b219f2953a089999518a40661ad247947fa13f24/src/data/providers/subgraphPoolProvider.ts#L102-L104

Instead of setting a default latest, if no block is set we should remove the block query filter. Have a feeling this will slightly improve query speed on the graph's side even though it shouldn't matter.

Add Create Pool functionality for Gyro Pools

Currently beets API does not support Nested Weighted Pools.
As soon as the API is updated, b-sdk API client should be updated as well.

Note: add/remove liquidity nested logic already supports it. It's just the API client that needs to be updated.

Before implementing, we should evaluate the experience of adding custom types (not only pool types, but add liquidity types, remove liquidity types, etc.).
One key feature of the SDK is that it's extensible, so we have to make sure that changing poolType from string to PoolType won't affect the ability to add custom types.

Circular imports caused build issues before.
This lint was suggested by Alberto in the API:
https://github.com/import-js/eslint-plugin-import/blob/main/docs/rules/no-cycle.md
Will likely need a bunch of refactoring if implemented.

Prepare b-sdk to support both v2 and v3 implementation

Addresses for BASE chain are missing in the constants.ts file

Use beets api implementation as reference (here)

This setup looks pretty fragile, it will only work for those two explicit pool types.

It should work with all supported pool types + any custom pool type added to b-sdk

A few months ago we replaced Balancer Queries contract with MulticallV3 for querying onChain data, but there are still some places using it.
It should be replaced by equivalent contracts, such as Balancer Helpers, so we reduce the amount of contracts we depend on.

It should follow what's defined by the SC for each pool.

Create Add Liquidity Init Functionality for Weighted Pools

Comment from Daniel: Could be worthwhile pulling init into its own function as it is really a special case and not something needed by most integrators.

https://github.com/balancer-labs/b-sdk/blob/b219f2953a089999518a40661ad247947fa13f24/src/data/types.ts#L25-L36

Thinking about supporting other data providers, we should make only the minimum fields required for functionality a hard requirement. It may also make sense to separate a RawPool type between a PoolDataProvider and a PoolDataEnricher to be less opinionated. Ex: a GetPoolsResponse shouldn't require these fields:

• address - pool classes regenerate this using the id in the constructor
• poolTypeVersion - can assume latest
• swapFee - can assume will be queried in enricher
• swapEnabled - can assume this has already been checked
• tokens - can assume will be queried in enricher
• tokensList - i think this can be removed entirely throughout
• liquidity - same as above
• totalShares - can assume will be queried in enricher. on enricher type we should only force this for composable stable

It would be nice to have a helper method to calculate proportional amounts in, that can later be used as input to add liquidity methods.

Please use the old SDK implementation as reference (here)

Note: we'll likely need a new api client to fetch pool balances. I'd say it's ok to use that instead of on chain balances.

Make sure both static.ts and sor.ts reflect the same change

Implement price impact within b-sdk for:

• design and specs on Notion
• swap
• add liquidity single token
• add liquidity unbalanced (generalized for multiple tokens)
• remove liquidity single token
• remove liquidity unbalanced (v2 only)

Comment from Daniel: Could be worthwhile pulling init into its own function as it is really a special case and not something needed by most integrators.

Implement price impact for nested liquidity within b-sdk.
Note: releasing this depends on relayerV6 being audited and approved by governance. Development can still be done with a locally deployed relayer. It should be ok to build on top of the existing nested liquidity working branch.

• add liquidity nested unbalanced
• remove liquidity nested single token

My task list

• #13
• #116

Pool types:

• Weighted
• Composable Stable
• Gyro Pools
• Fx Pools

Add Liquidity Init Functionality for Composable Stable Pools;

Considering Daniel's comment about v3 not having a getPoolId method, we should break InitPoolDataProvider into v2 and v3 implementation.
Since we don't yet have everything ready for v3, v3 implementation can be blank for now.

Following the Ledger issue its worth reviewing. Couple of useful threads:
https://twitter.com/ricmoo/status/1735414433956999177
https://twitter.com/LefterisJP/status/1735389403357319253
https://twitter.com/evan_van_ness/status/1740491595152318623

From @agualis:

Regarding undefined env vars, I don’t think we need it (yet) as we don’t have so many of them. But if the project env var handling becomes more complex we could probably add a zod schema for env content validation:

• https://github.com/balancer/b-sdk/pull/112/files/8e34a4dfe4644e2e5d3f8b1cff0a012904119608..4340eb20e1b6f671514ddc6e6151b04ce498ea1b
• https://twitter.com/harsh_p_patel/status/1720586984639344868?t=G_LvHAmCnhRTn56WMPaO-A&s=35

95% sure that queryExit does not work for recovery. Couple of options:

1. Is it queryContracts that don't work or pools themselves? Ask SC team.
2. Have to add maths 😞 Might be worth considering not doing this?

Request from @agualis:

Ideally, it would be good to allow the users to check the “quote” before connecting
If you are a new user and you are simply exploring balancer is good to have this ability

To achieve that we could to remove accountAddress from AddLiquidityNestedInput and fill in with ZERO_ADDRESS.
Then we'd need to replace that with sender/recipient provided on buildCall.

This is probably not a high priority task at this development stage but I would consider avoiding barrels for different reasons.

There are some good examples of libraries consumed by thousands of users that could inspire our bundle setup (i.e. viem?)

Note: solution should be generalized for multiple tokens

This task depends on the development of a helper contract that should prevent the need for several query swaps as the current implementation needs.