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

Consolidate Data Sources for Accurate Display of 'Lifetime Rewards' in RCP Stake Movement #256

Open
rickstaa opened this issue Jan 12, 2024 · 0 comments

Comments

@rickstaa
Copy link
Member

rickstaa commented Jan 12, 2024

Issue Observed

In the Livepeer Explorer, when stakeholders move their stake, the bondingManager's pendingStake (see this YouTube video), there's an inconsistency in the display of "Lifetime Rewards." This inconsistency arises due to the current method of data retrieval: the principal stake information is fetched using the subgraph, while the pending stake and unbonded information are sourced from the RCP. Since these data sources update at different intervals, the "Lifetime Rewards" display becomes temporarily inaccurate. This discrepancy resolves itself once the RCP cache expires, but it can confuse the interim.

Proposed Solution

To address this, I propose integrating the pendingStake data into the subgraph. This change would allow us to use a singular data source for calculating the "Lifetime Rewards," ensuring consistent and accurate information display. Implementing this feature should eliminate the temporary discrepancies caused by the different update rates of the current data sources.

I've initiated a feature request for this improvement on our GitHub repository, which can be tracked here.

@adamsoffer and @0xcadams, although this is a low-priority issue, I'd appreciate your input on this proposal. Would this effectively resolve the issue and improve the accuracy of our data display?

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

1 participant