You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It looks like a query interface (view function) of contract that can return multiple pool states is neccessary for your solution.
And although there is a get_return view function in contract to estimate swap out amount according to swap in amount, I guess it is not what you need, cause you can not know the exactly amount of input in advance.
So I am considering to add a view function that can receive multiple pool id as a vector and return each liquidity amounts of each pool. Besides that, pool fee is more static and can be retrieved in advance from ref-finance backend data service.
Then, amountA, amountB and fee of each pool are all in your hand, the solution would go smoothly, wouldn't it? Is there anything else needed for this solution?
The text was updated successfully, but these errors were encountered:
Hi @marco-sundsk , yes, we used the contract view function "get_pools" to get those states. This gave us the collection of pool structs that each contain fields for id, token_account_ids, amounts, total_fee, and shares_total_supply. For our solution, we mainly just need the fee and the reserves in the AMM (amounts field) associated with token A and token B. We didn't want to use the get_return function since that could broadcast user intent, and risk front-running. Since we already know how the pools calculate the expected token B output given a certain amount of token A input in a constant-product bonding curve AMM, we can calculate that on the front-end.
And as long as you have viewed the info of the fee, the reserves of A, and the reserves of B in each pool, that is all the data you need to run the parallel swap algorithm.
Let me know if you have any other questions! I'm happy to help.
It looks like a query interface (view function) of contract that can return multiple pool states is neccessary for your solution.
And although there is a
get_return
view function in contract to estimate swap out amount according to swap in amount, I guess it is not what you need, cause you can not know the exactly amount of input in advance.So I am considering to add a view function that can receive multiple pool id as a vector and return each liquidity amounts of each pool. Besides that, pool fee is more static and can be retrieved in advance from ref-finance backend data service.
Then, amountA, amountB and fee of each pool are all in your hand, the solution would go smoothly, wouldn't it? Is there anything else needed for this solution?
The text was updated successfully, but these errors were encountered: