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

Get map of liquidity info for given account #23

Open
marco-sundsk opened this issue Apr 30, 2021 · 3 comments
Open

Get map of liquidity info for given account #23

marco-sundsk opened this issue Apr 30, 2021 · 3 comments

Comments

@marco-sundsk
Copy link
Contributor

marco-sundsk commented Apr 30, 2021

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.

@kcole16
Copy link

kcole16 commented May 3, 2021

@marco-sundsk Seems fine to me to add the lookup. Thoughts @ilblackdragon?

@kcole16
Copy link

kcole16 commented May 6, 2021

@evgenykuzyakov What are your thoughts on this approach?

  • Adding LookupMap::<AccountId, HashSet> into contract storage to keep track of LP's relevant pools.

@referencedev
Copy link
Contributor

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.

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

3 participants