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

Masternode Rewards list, estimator & calculator #61

Open
JSKitty opened this issue Nov 25, 2022 · 8 comments
Open

Masternode Rewards list, estimator & calculator #61

JSKitty opened this issue Nov 25, 2022 · 8 comments
Labels
Enhancement New feature or request

Comments

@JSKitty
Copy link
Member

JSKitty commented Nov 25, 2022

Abstract

This feature request aims to improve the experience of Masternodes on MPW with a huge increase in monitoring and tools for the user to keep up with information about their node(s).

The exact UI design is undetermined, but I'd initially like to propose three additions (could be three extra 'boxes' in the Masternode Dashboard, but this may take up 'too much' screen space and instead be designed a better, more compact way).

  1. Rewards list (essentially a clone of the Staking rewards list, keeps users updated on their rewards history).
  2. Reward hit estimator (use the last reward date, if any, and the total enabled MN count, to predict roughly when the next reward arrives, i.e: "In 6 hours"), could even have a neat little purple progress bar!
  3. Live Calculator (a calculator, without inputs, showing Daily / Monthly / Yearly reward estimations).

Rather than hardcoding PIVX chainparams such as 'MN rewards' (for the calculator), we should instead base the calculation on the last reward generated in the list (if any), since if PIVX changes it's emissions, MPW will automatically correct itself then.

All in all, this is one UI element that users will love - folks enjoy watching how their numbers / portfolios are doing.

Note

Ideas to change this proposal are more than welcome! This is just a quick concept to help add additional juicy "context" for Masternode owners, if you think something should be dropped, changed, or added, leave a comment and we'll discuss!

@panleone
Copy link
Member

I would also add:
4. Masternode support for ledger

@JSKitty
Copy link
Member Author

JSKitty commented Nov 25, 2022

I think Ledger support should be a separate PR (would make this scope pretty large), this idea is mainly an upgrade to the MN dashboard UI for monitoring/stats/portfolio reasons.

@panleone
Copy link
Member

panleone commented Dec 1, 2022

Hmm ok, I also don't like the idea of having a bar that tells you when you will have the next reward... Since it will be most of the time wrong

@Liquid369
Copy link

Hmm ok, I also don't like the idea of having a bar that tells you when you will have the next reward... Since it will be most of the time wrong

In terms of the masternode list we can actually use a form of parsing list masternodes and getmasternodewinners for the upcoming rewards that should/could be fairly accurate.

@JSKitty
Copy link
Member Author

JSKitty commented Dec 1, 2022

We can easily achieve estimations within a ~15-20 minute accuracy with simple calculations, which is more than good enough IMO, near the end of the reward queue, it can simply be full and state "Reward Incoming".

@panleone
Copy link
Member

panleone commented Dec 1, 2022

4.1 since we have the new mempool system a nice add is preventing the user from clicking the activate masternode if the tx has less than 15 confirmations

@Liquid369
Copy link

Picking back up here, I think for something like this do we want to expand on @Duddino RPC/API thats being used for starts/votes?

One consistent add-on for the additions and if we bring it here we can have similar standardization, and can offload some more heavy lifting from the browser if we wanted to

Thoughts?

@JSKitty
Copy link
Member Author

JSKitty commented Dec 31, 2022

Hm, depends how far we want to 'server-compute', I'm generally in favor of putting as much in to the client-side as possible, rather than adding upon layers of dependency on RPC servers. (Even worse, if we do custom endpoints that perform multiple RPCs at a server level, then MPW is truly 'dependent' on that implementation).

For instance, I think we'd be safe with two RPC calls, one for the masternode count, one for our masternode's data (which we can find queue status, etc), this basic data can estimate reward times and such.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement New feature or request
Projects
Status: Planned
Development

No branches or pull requests

3 participants