frontend-monorepo
frontend-monorepo copied to clipboard
vegaprotocol
Show rewards and fees earned (no wallet connected)
Dependent on summary ticket on vega core that needs to be created @dexturr
Story
As a user who has not connected their wallet I want to see a total of rewards and fees paid out So that I can understand the financial benefits of using Vega
Acceptance criteria
- [ ] I can see rewards and infrastructure fees paid out per epoch, per asset, per type (staking rewards, infrastructure fees, price taking rewards, price making rewards, liquidity provision rewards, market creation rewards)
- [ ] I can see a total per asset
- [ ] I can see a description of each type to help me understand where they've come from on mouseover
- [ ] There is a link to docs to "Understand how rewards are calculated ↗"
- [ ] I can see whether there is a delay on reward payout i.e. "Earn rewards and fees for trading and maintaining the network. Rewards are paid out at the end of an epoch." becomes "Earn rewards and fees for trading and maintaining the network. Rewards will be paid out from the treasury [6h] after the epoch ends." when there is a delay to payout
- [ ] Epoch list should be shown in descending order with the most recent at the top
Background / additional details
- Staking rewards = types.AccountTypeGlobalReward
- Infrastructure fees = types.AccountTypeFeesInfrastructure
- Price taking rewards = types.AccountTypeMakerPaidFeeReward
- Price making rewards = types.AccountTypeMakerReceivedFeeReward
- Liquidity provision rewards = types.AccountTypeLPFeeReward
- Market Creation Rewards = types.AccountTypeMarketProposerReward
Mouseovers per type
- ( i ) Staking rewards supplement infrastructure fees in the early stages of the network, rewarding validators and those who stake them for maintaining the network.
- ( i ) Infrastructure fees are incurred across the network during trading. They are distributed to validators according to their share of total stake on the network, and passed onto those who stake them, proportionate to their own stake after validator commission is taken.
- ( i ) Price taking rewards are based on the proportion of the total maker fees you paid while trading, on markets where there is a funded reward
- ( i ) Price making rewards are based on the proportion of the total maker fees you received while trading, on markets where there is a funded reward
- ( i ) Liquidity provision rewards are distributed based on how much you have earned in liquidity fees, funded by a liquidity reward pool for that market.
- ( i ) Market creation rewards are paid out to the creator of any market that exceeds a set threshold of cumulative volume in a given epoch, currently [rewards.marketCreationQuantumMultiple].
Tasks
- [ ] Work it out
- [ ] Build
Sketch
Currently we cannot query reward types per epoch, only the last N rewards and therefore have no way to accurately present to the user rewards grouped per epoch.
Implementing this solution with existing API would mean we take a risk on presenting an epoch with an incomplete data set - the totals could be wrong, and it's possible we miss out whole reward types as well as individual rewards - and we'd have no way of knowing it. A first step might be adding the ability to query the existing API by epoch.
Raised a ticket for core here - https://github.com/vegaprotocol/vega/issues/6650
01.1 and 01.2 show how, until the new API is implemented to see % of total distributed, as a user you would only see your own rewards and therefore there is no segmented control to toggle between TOTAL DISTRIBUTED and EARNED BY ME. Instead, when wallet not connected you are prompted to connect your wallet (01.1) and then you'll see your rewards (01.2) but without the % of the total in the table as well.
02.1 shows the TOTAL DISTRIBUTED state with the segmented control once the new API has been implemented.
02.2 shows EARNED BY ME with a prompt to connect wallet.
It might make sense to jump on a quick call to run through it all and clarify any questions or feedback you may have, LMK!
Decision to pull in everything for now and paginate later when it's available (it crashing on mainnet might push to get the pagination work done by core)
