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
There is a nature and strong requirement that a ref LP wanna know all his liquidity share throughout all the pools. But now, the contract is lack of liquidity record for given user. There are two ways to address that:
Using a backend dataserver to fetch all pool info and frontend using some complex SQL query to join data and fetch a whole liquidity view for given LP;
Adding LookupMap::<AccountId, HashSet<PoolId>> into contract storage to keep track of LP's relevant pools.
I would prefer the second way, cause the amount of LP woundn't be so large, and this would be a frequently query entry.
The text was updated successfully, but these errors were encountered:
This doesn't really provide enough information and adds extra storage needs which is complicated to track.
Instead indexer should be used. By processing all add/remove liquidity, indexer can maintain current amount of deposited liquidity by user and also calculate ROI from fees by maintaining deposited base vs the current amounts allocated for this LP tokens. Doing this as part of smart contract is possible but will be very complex.
Generally, indexer is needed to maintain all the relevant info anyway and it all should shift there.
There is a nature and strong requirement that a ref LP wanna know all his liquidity share throughout all the pools. But now, the contract is lack of liquidity record for given user. There are two ways to address that:
LookupMap::<AccountId, HashSet<PoolId>>
into contract storage to keep track of LP's relevant pools.I would prefer the second way, cause the amount of LP woundn't be so large, and this would be a frequently query entry.
The text was updated successfully, but these errors were encountered: