dApps Staking v3 - proposal

General
1

Hello everyone!

The purpose of this post is to share the design sketch for dApps Staking v3 we’ve been working on lately. We’d like to get YOUR (community’s) opinion, feedback & ideas!

Please keep in mind that the requirement for understanding this post is knowledge about current dApps staking design.

It’s a long post so strap in! :smile:

1. Overview

The main purpose of dApps staking is to incentivize developers & builders who choose Shiden or Astar network as their platform.

ASTR or SDN holders can choose to lock their tokens so they can vote (nominate) for a registered dApp of their choosing. Stakers are rewarded for their action by being rewarded a part of inflation.

The registered dApp will receive rewards, depending on the TVL of that dApp. E.g. if dApp A nomination consists of 10% of total dApps staking TVL, it will receive 10% of the inflation meant for dApp rewards.

2. Problems

Over the past year, many problems with dApps staking design have surfaced. Some of the community members voiced their concern and we’ve discussed them internally. Here is a short non-exhaustive summary of the problems (in no particular order):

  1. Registration & unregistration needs to be fully decentralized.
  2. Not all registered dApps are really dApps (infra providers, community projects) but are treated equally all the same.
  3. Lack of insight into dApps performance (metrics).
  4. Reward schema for dApps isn’t scalable (zero sum game).
  5. Theoretically, a single dApp could earn 100% of rewards intended for dApps staking.
  6. High entry threshold for new dApps if they want to receive tangible rewards (new dApp has to immediately compete with another dApp which might have billions in TVL).
  7. Low engagement from stakers, which results in stake & forget behavior. It’s enough to bond & stake once and to just keep claiming rewards.
  8. Unclaimed (stale) rewards are never burned.

3. Solution Sketch

Not all of the aforementioned problems can necessarily be fixed by tweaking or redesigning the dApps staking pallet (module). Decentralized registration requires governance integration, dApp performance metrics require off-chain logic with a UI (which is in works already).

The following solution sketch will focus on what should be changed in the core dApps staking protocol. We want to achieve:

  • Scalable dApps rewards. We cannot accommodate an infinite amount of dApps in dApps staking since rewards are finite. But as the network grows in value, a positive feedback loop must allow increase of number of supported dApps.
  • There is a limited amount of rewards that a single dApp can earn.
  • A new dApp which just entered dApps staking protocol doesn’t need to immediately compete with the top dogs in order to earn tangible rewards. However, there competition is still present and encouraged.
  • Stakers are encouraged to engage in dApps staking more often, instead of staking & forgeting.
  • Active stakers are rewarded more than passive ones.

The following sub-chapters will explain proposed changes for v3.

3.1. Separate Locking & Staking

In dApps Staking v2, locking and nominating is joined together in a single action (bond_and_stake). Same goes for removing nomination and unlocking funds (unbond_and_unstake).

As part of v3, these actions will be separated.

  • Locking funds will make them usable for staking
  • Nominating funds will provide votes for the staked dApp
  • If funds aren’t used to stake, they do not contribute to any dApp score
  • Unlocking funds will begin the unlocking (unbonding) process
  • Same as today, after unbonding period finishes, owner can withdraw unlocked funds back to their free balance
  • Nomination transfer functionality will most likely be kept although it might have some additional effect compared to today (depends on the final design)
    Locking&staking diagram
    Locking&staking diagram1072×771 42.3 KB

3.2. dApp Tiers For Developer Rewards

In dApps Staking v2, dApp reward scaled linearly with the portion of dApps Staking TVL coming from that dApp. In v3, we will use tier-based reward distribution system.

Perhaps the easiest way to explain is by a simple example:

Tiers Example
Tiers Example1606×1015 116 KB

We have 3 tiers.
Altogether, they can support up to 23 dApps (3 + 5 + 15).
Only 13 dApps are part of dApps staking.

An era ends and tier sorting is started. After it finishes, 13 dApps will be sorted into 3 tiers.

1 dApp, A, has made it into the top tier 1. There are two vacant spots in this tier but none of the other dApps has fulfilled the requirements to join. This is a major shift from the current mentality where we always distribute the entire reward between active dApps.

In tier 2 we have 4 dApps and only one spot is vacant.
In tier 3 we have 8 dApps and 7 spots are left vacant.

3.2.1. Tier Configuration

The first parameter for tiers is how much of them we have.

  • number of tiers

Each tier will have separate basic configuration parameters:

  • number of dApps - number of dApps that can be part of this tier
  • % of dApps Reward - percentage of dApp reward going into this tier

Using these two parameters we can calculate how much each dApp in tier earns: %_of_dApp_reward / num_of_dApps.

Small Example

  • Inflation per block: 2.5 ASTR
  • Inflation percentage going towards dApp rewards: 20%
    • which means 0.5 ASTR goes towards dApp rewards
  • Let’s assume we have multiple tiers and one of the tiers has basic config params:
    • number of dApps = 20
    • % of dApp rewards = 10%
  • This means that for each dApp we allocate 0.5 * 0.1 / 20 = 0.0025 ASTR per block
    • in today terms, era takes 7200 blocks, so dApps in this tier would earn 18 ASTR per era

(this is just an example and has no correlation to real numbers)

We can have an additional configuration parameter like:

  • minimum TVL (or percentage) - minimum amount that has to be nominated for dApp in order to enter a tier. This means that we don’t need to reward highest tier rewards always!
    • Scenario: we have 20 spots in total for the highest earning tier but since we have an entry threshold, we could have 100 dApps in dApps Staking with only 5 of them being part of the top tier.
    • This is a shift from the mentality that we need to distribute ALL the inflation intended for dApps reward. We don’t need to do that.

There were various ideas on how to sort dApps into tiers. To provide greater flexibility, the best approach is to have this logic outside of dApps Staking core protocol. This would allow us to design different tier sorting functions for different runtimes, if needed.

This would make tier sorting functionality one of the core tier configuration parameters.

The most basic example would be sorting by TVL and taking into account minimum TVL parameter.

We might want to whitelist a dApp for a certain tier Or in another words, to force put it into a tier. This might be an interesting way to accomplish project bootstrapping. We utilize the core dApps staking mechanism to provide funds to a project for some time.

We could have this as a forced tier configuration parameter.

E.g. a projects gets forced into 3rd tier for 3 months. After that period, the forced tier parameter gets removed, and they are sorted into tiers based on whichever functionality is used for that runtime (e.g. by TVL).

Although whitelist term is used, it can also work in opposite direction via blacklisting dApps. We could outright ban projects from dApps staking or limit them to some tiers. E.g. a specific type of project could be limited to allow it to enter tier 2 at most.

3.2.2. Eras & Tier Calculation

In general, calculating staker’s reward will be computationally easier than calculating developer rewards. Tier sorting can be time consuming operation since it might depend on many different parameters (see previous chapter). For that end, calculating developer rewards more rarely (weekly or monthly) might be better.

In production, this would mean that stakers could still claim on a daily basis, as they do today. For developers, they would claim less often. When developer era finishes, number crunching would start and provide back the tier information to the dApps staking pallet.

IMPORTANT: This doesn’t mean developers would earn less rewards, it only means they would be able to claim them less often. Each claim would be much heftier than before though. If we assume that developer era lasts for 7 days, it would mean that it accumulates rewards for 50400 instead of 7200* as today.

3.2.3. Keeping Track of (Un)Claimed Rewards

We might want to keep a better track of the amount of rewards that were claimed versus what was rewarded versus what was assigned for rewards.

A fixed amount of inflation goes towards dApps rewards but by utilizing tier logic, it is highly unlikely that we’ll distribute all of the rewards.

We’ve also had developers (and stakers) who haven’t claimed their rewards for a very long time.

Being able to easily keep track of these values would allow us to handle unclaimed/unused rewards on-chain. We could burn them to reduce inflation or utilize them in some other way.

3.3. Voting Period and Build&Earn Period

In dApps Staking v2, users staking (nominating) a dApp in era X directly contributes to that dApps TVL for that era. There are no special periods designated for voting.

Stakers could also stake & forget, keeping potentially high nomination on a project they don’t even really support. They could loose their private key, and nomination would remain there forever.

This will be addressed in v3.

3.3.1. Two Periods

Two distinct periods will be introduced:

  • Voting Period
  • Build&Earn Period

These two periods would cycle on a regular basis. For example, a week long voting period would be followed by 11 week long build&earn period. Then the cycle would repeat.

During (and before) the voting period, projects can run marketing campaigns to attract stakers. All the stakes made during the voting period are counted separately from nominations in build & earn period. This will be explained in more details later. But for now, please note that voting period is just a name - the voting here is simply staking (or nominating), so same as it is today.

We should foster building a culture around voting period, like projects committing on what they will deliver in following build&earn period. This could be in line with their roadmap or milestones. If voting + build&earn period would last together for e.g. 3 months (configurable), it would allow our marketing & projects to build activities around it.

Voting during the voting period ONLY nominates the dApp for the next build&earn period. It doesn’t mean dApp is nominated indefinitely.

While voting period is active, no rewards would be earned or distributed. Instead, they would just be accumulated (read on for further explanation).

During build & earn period, projects focus on building. They can earn rewards based on their tier.

If user decides to nominate additional funds, or claims with automatic re-stake, these additions would not be counted in same way towards dApp score as they would have during the voting period. They would be kept track of separately. This is useful since we can construct modified TVL metrics which could provide dApp score with a formula like:

score = nomination_from_voting_period + 0.5 * nomination_from_build/earn_period

This approach gives voting period bigger weight but still makes voting in build & earn period relevant. IMPORTANT: This is only related for tier sorting it’s not related to stakers stake If someone locks & stakes 100 ASTR during build&earn period, it will be counted as if 100 ASTR was staked from their perspective.

3.3.2. Voting Period Reward Accumulation

During the voting period, it is not possible to earn rewards, neither for stakers or dApps. Instead, rewards are accumulated into a loyalty reward fund.

For all stakers who vote during the voting period and don’t unstake any funds during the entire follow-up build&earn period, they can claim the rewards accumulated during the voting period.

This aims to reward voting period participants (active stakers), who remained staked for the entirety of the build&earn period.

This is the monetary incentive for dApps staking participation in voting period.

Example Of Reward Accumulation

Before explaining this, let’s just quickly go over how inflation and dApps staking works today.

Producing each block results in minting of new tokens. These new tokens are distributed between collators, treasury and dApps staking.

The dApps Staking part of the inflation is split between stakers & dApps. As blocks are produced, both staker and dApp rewards are accumulated. Once enough blocks have passed (we call this an era), snapshot is taken and both stakers and dApp devs can claim the accumulated rewards.

Let’s say for the sake of example that voting period lasts 3 blocks and build&earn period lasts 4 blocks. Reward accumulation would look like the following image:

Reward Accumulation Diagram
Reward Accumulation Diagram3090×1560 454 KB

As blocks are produced during voting period, all rewards are accumulated into the extra reward accumulator. During build&earn period, rewards are normally distributed between dApps and stakers (same as today).

Continuing the example, let’s assume the following:

  • We only have a single dApp on which stakers can stake
  • We assume that build & earn period lasts for 1 era which is 4 blocks
  • dApp Reward Inflation per block is 1 ASTR
  • staker Reward Inflation per block is 2 ASTR
  • Alice, Bob and Charlie stake during the voting period
  • Bob and Charlie remain staked during the entire build&earn period
  • Alice decides to reduce her stake during the build&earn period

Block 1

  • Alice stakes 10 ASTR, Bob stakes 20 ASTR, Charlie stakes 40 ASTR

  • Both rewards get deposited into Extra Rewards accumulator

    Alice Bob Charlie
    Locked 10 ASTR 20 ASTR 40 ASTR
    Staked 10 ASTR 20 ASTR 40 ASTR
    Extra Rewards dApp Rewards Staker Rewards
    Accumulated 3 ASTR 0 ASTR 0 ASTR

Block 2 & Block 3

  • Since it’s voting period, rewards are accumulated into Extra Rewards

    Alice Bob Charlie
    Locked 10 ASTR 20 ASTR 40 ASTR
    Staked 10 ASTR 20 ASTR 40 ASTR
    Extra Rewards dApp Rewards Staker Rewards
    Accumulated 9 ASTR 0 ASTR 0 ASTR

Block 4

  • Build & earn period begins, rewards are deposited in their respective accumulators

    Alice Bob Charlie
    Locked 10 ASTR 20 ASTR 40 ASTR
    Staked 10 ASTR 20 ASTR 40 ASTR
    Extra Rewards dApp Rewards Staker Rewards
    Accumulated 9 ASTR 1 ASTR 2 ASTR

Block 5

  • Alice decides to reduce her stake (nomination) by 7 ASTR, bringing it down to just 3 ASTR

  • This no longer makes Alice eligible for extra rewards but since she only unstaked, without unlocking, she’s still eligible for standard staker rewards

    Alice Bob Charlie
    Locked 10 ASTR 20 ASTR 40 ASTR
    Staked 3 ASTR 20 ASTR 40 ASTR
    Extra Rewards dApp Rewards Staker Rewards
    Accumulated 9 ASTR 2 ASTR 4 ASTR

Block 6 & Block 7

  • Rewards are being accumulated

    Alice Bob Charlie
    Locked 10 ASTR 20 ASTR 40 ASTR
    Staked 3 ASTR 20 ASTR 40 ASTR
    Extra Rewards dApp Rewards Staker Rewards
    Accumulated 9 ASTR 4 ASTR 8 ASTR

Block 8

  • This marks the beginning of the new voting period, which means we can payout rewards for the previous period

  • First we consider standard rewards paid for just locking

    • TVL is 10 + 20 + 40 = 70 ASTR
    • Staker reward accumulator contains 8 ASTR
    • Alice will get 10 / 70 * 8 = 1.14 ASTR

  • Then we can consider extra rewards paid for staking (voting) during voting period and remaining staked throughout the entire build & earn period

    • Loyalty TVL is calculated by summing up only Bob and Charlie’s stake which is 20 + 40 = 60 ASTR

    • Bob earns 20 / 60 * 9 = 3 ASTR

      Alice Bob Charlie Sum
      Standard Reward 1.14 ASTR 2.29 ASTR 4.57 ASTR 8 ASTR
      Extra Reward 0 ASTR 3 ASTR 6 ASTR 9 ASTR
      Total Reward 1.14 ASTR 5.29 ASTR 13.57 ASTR 17 ASTR

Please also check Kahori’s post below.

Nominations During Voting Events Example

Alice and Bob have decided to participate in dApps staking which only has two dApps registered: A and B.

New voting period has started (VP1)

  1. Alice nominates dApp A with 80 ASTR and dApp B with 20 ASTR
    dApp A dApp B
    voting period nomination 80 ASTR 20 ASTR
    build&earn nomination 0 0
  2. Alice nominates dApp B with an additional 10 ASTR
    dApp A dApp B
    voting period nomination 80 ASTR 30 ASTR
    build&earn nomination 0 0

Voting period (VP1) has ended, build&earn period has started (BEP1)

  1. Bob nominates dApp B with 90 ASTR
    dApp A dApp B
    voting period nomination 80 ASTR 30 ASTR
    build&earn nomination 0 90 ASTR
  2. Alice claims some of the rewards (1 ASTR), automatically re-staking them on dApp A
    dApp A dApp B
    voting period nomination 80 ASTR 30 ASTR
    build&earn nomination 1 ASTR 90 ASTR

Build&earn period (BPE1) has ended, new voting period has begun (VP2)

  1. Nomination (votes) do not carry over, both dApps start with zero
    dApp A dApp B
    voting period nomination 0 ASTR 0 ASTR
    build&earn nomination 0 ASTR 0 ASTR
  2. Same as in VP1, stakers can nominate dApps again

NOTE: tier sorting can utilize the above information, but is not core part of the voting events.

NOTE 2: please refer to the new inflation model forum post for more concrete numbers for staker rewards, dApp rewards, and tiers.

32 Likes
2

I like the parameter min. TVL to start earning rewards. Also, we need to make sure dApp are encouraged to increase TVL to get more rewards using the Tier mechanism.
Very well done Team!
100% support the proposal

What dou you have in mind for stakers vote? off-chain vote mechanism?

9 Likes
3

Well , I really like this v3 proposal. Just wondering about which extra parameters we can use to decide the appropriate tier for a dApp. I will support it :+1:

6 Likes
4

I like the V3 dapps staking design. I support this.

I would like to make a suggestion to improve dapp staking access:

In certain countries it is necessary to use a VPN to access the dapps staking page, this is limiting the # of users can access to our dapp staking technology.

Suggestion: Remove the necessity to access to dapps staking page using a VPN from certain Countries.

In my case Cuba

Thank you

2 Likes
5

I like this proposal cause it will force the DApp to build and take care of their respective communities/stacker to earn their DApp rewards. For the stacker it will make them renew their support to the project on a regular basis giving them more influences on the project.

However, i’m not fond of the none distribution reward during voting periode. For projects, it is just a delay in their reward payment. However, for stacker they may loss part of their due reward if for a reason or another they have to unstack part or all of their token during a build&earn period or can’t vote while they still had their token stacked during voting periode. In addition it would force people to unstack only during voting period which is quite a restriction in addition to the 10 era unstacking periode… DApp stacking is already in comparisons to inApp stacking far less rewarding and more constraining for the only advantage of being less risky. So adding more constraints is not necessarily a good idea (especially for big wallets which often are not owned by individues).

Other point, what will happen to the undistributed rewards, will they be burned or will they be distributed to the remaining stacker?

4 Likes
6

I have a question. For example, the Algem project can collect a large number of astr tokens in the astar network (EVM), which can automatically help me stake tokens and obtain rewards.
So, I just need to stake my token to this project, and it will automatically help me to nominate. I still don’t need to manually operate, and the activity has little impact on me. So how can dApps Staking v3 alleviate or avoid such things.
Does this design only design the astr native network and not involve astr evm network?

4 Likes
7

Thank you everyone who was quick to provide feedback! :raised_hands:

@pitcoin777

What dou you have in mind for stakers vote? off-chain vote mechanism?

Could you please expand the question? Not sure I understand it now :slight_smile:

@VasaKing

Just wondering about which extra parameters we can use to decide the appropriate tier for a dApp.

It’s not an easy question to answer since it requires designing a metric which would allow dApp ranking.
But the design will support adding new metrics later on, without the need to redesign the whole system.
So if we come up with a better ranking system in one year, we can focus on designing the metric, instead of redesigning the whole dApps staking protocol (again).

@anon24836865

dApps Staking page isn’t covered by this post (or infrastructure to be more precise). The focus is on on-chain protocol.
I’d suggest raising an issue ticket in GitHub for astar portal.

@Mouthmouth68
It doesn’t mean that projects would get rewards accumulated during the voting period. My idea is to push both rewards (projects & stakers) into the same loyalty reward pool.

However, for stacker they may loss part of their due reward if for a reason or another they have to unstack part or all of their token during a build&earn period or can’t vote while they still had their token stacked during voting periode.

The idea behind the proposal is to reward engagement & loyalty. We want to design the rewards so stakers are in the gain even when they just lock, without staking. However, those who engage during voting period and stick to their vote for the entire build & earn period get rewarded more.

I cannot go into reasons why someone had to unstake their funds but don’t see a problem with unstaking meaning they don’t get bonus rewards. How exactly this system will work on-chain remains to be seen.

In addition it would force people to unstack only during voting period which is quite a restriction in addition to the 10 era unstacking periode… DApp stacking is already in comparisons to inApp stacking far less rewarding and more constraining for the only advantage of being less risky.

Purpose of unbonding period is to reduce selling pressure, while purpose of loyalty rewards is to foster engagement from stakers.

For the reward amounts, if we’re talking in terms of pure APY, I’m sure it is. Our inflation has to be distributed between stakers, projects, collators & treasury so we cannot match e.g. Polkadot’s or Kusama’s APY. There are other rewards that are extrinsic to the dApps staking protocol, like projects giveback or the fact that you’re supporting a project you like :slightly_smiling_face:

We’ve been talking about increasing rewards via off-chain events in the future but it’s still to early to share more info about that.

Other point, what will happen to the undistributed rewards, will they be burned or will they be distributed to the remaining stacker?

Not decided yet, but personally I’m leaning more towards burning (it makes more sense).
It’s an open discussion though.

About your concerns, please feel free to propose alternatives!
No guarantees we can do it (has to be technically feasible for on-chain protocol) but it’s good to hear ideas and it can always steer the development into a (slightly) new course.

@sanyun
In case you’re using Algem, you’re not interacting with Astar’s dApps staking protocol directly but via Algem dApp. They will have to ensure to stake their tokens during the voting period. So you are right, this doesn’t impact you much.

Does this design only design the astr native network and not involve astr evm network?

The protocol is same for both.

3 Likes
8

I support this proposal. I especially like the “Separate Locking & Staking” part of this proposal.

1 Like
9

Hi @Dino
Before i answer your comments, i would like you to clarifiy the following point which is unclear for me.
When you say :

Do you intend to reward locking token and staking/voting separately?

1 Like
10

@Mouthmouth68
That’s correct, I see now it’s not explained in the original post.

Locking would provide locker with rewards, regardless of whether they stake or not.
Staking & remaining staked would net the staker extra rewards.

2 Likes
11

this make more sens to me now.

So do staker will continu to earn rewards for locking their token during voting periode since they will be searated from voting/stacking? If yes , how do you intend to finance staking/voting rewards ? by transfering a part of locking APR to voting/staking rewards or with fresch token?

2 Likes
12

@Mouthmouth68

So do staker will continu to earn rewards for locking their token during voting periode since they will be searated from voting/stacking? If yes , how do you intend to finance staking/voting rewards ? by transfering a part of locking APR to voting/staking rewards or with fresch token?

During voting period rewards are accumulated (this is explained above), no one is rewarded.
During build & earn period, everyone is rewarded. Stakers would be rewarded in the same manner as they are today.

For active loyalists (I’m sure someone will come up with a cool name xD), rewards accumulated during the voting period would be distributed ONLY between those who staked and remained staked.

So no fresh tokens are introduced. One of the goals with the new design is to reduce overall inflation as well.

1 Like
13

For all stakers who vote during the voting period and don’t unstake any funds during the entire follow-up build&earn period, they can claim the rewards accumulated during the voting period.

What do you mean by vote? Is an off-chain voting mechanism similar to Shiden Network which allows holders to vote on dApp?

1 Like
14

By vote I mean stake. We could call it nomination period or staking period.
Nothing will be done off-chain. The entire protocol will remain on-chain as it is todat.

One of the tasks I’ve put for V3 is to get nomenclature in order :grin:.

3 Likes
15

@Dino ok, so if i follow you during voting periode (about a week per 3 month or so) locking APR would be 0% and around 10-11% during build&earn.

Would reward accumulated during voting period would be paid in one go (at the end of the build&earn period) or spread over the build&earn period?

3 Likes
16

GM Dino,

First of all i wish u a happy new year!

Very nice proposal! i really like the “nominations do not carry over” that i was strongly suggesting many months ago :wink:

However i have some comments:

  • My understanding is that astar “passive” holders who lock their tokens without nominate a dapp, will earn the same amounts of astar tokens during 11 weeks over 12 weeks. If my understanding is correct, i think that you should incentivize much much more “active” holders who will analyze, use and nominate dapps on a regular basis. Holders who only lock their tokens for months/years and forget should only get a low % of reward, where active holders should be much more rewarded. (this could be done by defining a 2 weeks for voting, followed by 6 weeks of B&E for example).
  • I think that the duration of “cycles” should be quite short (no more than 2 months) in order to really ensure that the community is active.
  • I think that the tier sorting should be calculated at the beginning of each cycle (hence based on the TVL at the end of the voting period), and not every 24h or era. It may be much easier to code and simplify the process. Indeed in this case, you dont need anymore to take into account tokens used to nominate a dapp during the B&E period.
  • If the tier sorting calculation has to be done off-chain, it could be nice to use phala network computation cloud :grin:
  • The tier sorting may be a nice solution, but it is not enough. I mean you should create also “categories”, and allocate a specific % or rewards by categories. As an example, 3 categories could be created: 1 for DEFI dapps, one for NFT, gaming, & others dapp, and the last one for bootstrapping new projects. Of course, into each category, you will keep several “tiers” based on number of tokens used to nominate dapps (ie what u call TVL).
  • the definition of the parameters, if not only based on TVL, should be proposed to the community through the forum but the team should have the final decision. All astar tokens holders trust the team, by definition. However, i think that by creating distinct “categories”, the tier sorting by using only the TVL parameter might be relevant.
4 Likes
17

@Mouthmouth68

The proposed idea is to pay the accumulated rewards in one go.
This is because the requirement would be to vote/stake during the voting period and to remain staked during the entire build & earn period. Only after it ends can we pay out the rewards.

I will edit the original post so this part is properly explained.

Regarding the APY, we’ll see how much exactly it will be. We still have to model the new inflation model that will support the new dApps staking v3.
Hope to have this as part of another forum discussion.

Thanks for the engagement and keep the questions coming! :slight_smile:

@Rod
Happy New Year and thanks for the elaborate post!

We did design the above sketch with past feedback in mind so I’m glad you’ve noticed it. :slightly_smiling_face:

  • I agree that active holders should be incentivized more. The numbers I gave for periods duration are just for example but reflect what we’ve been discussing in the team. Right now, I am not sure how many addresses will be active so I don’t want to commit to any number. What I can say is that all of these parameters will be configurable and discussed with the community.

  • That is a good point however it might be a double edged sword. @0xRamz pointed out that having this too often can result in “staking choice fatigue”.

  • I think that calculating tiers only at the end of each cycle would reduce the competition. Basically you could have very low TVL until the last day when you push it to the max and reap rewards from the top tier. By calculating tiers more often (personally I don’t think it should be days but instead each week/ two weeks/ each month).
    One of the reasons I saw voting during B&E period is that it keeps the competition and voting alive all the time. Your vote would still matter, it would only carry less weight.

  • We can see about using Phala :slight_smile:. My thinking at the moment is that off-chain worker would be good enough. We’ll see in the future though!

  • Great ideas about the categories! We can definitely do that! (someone brought it up during our internal discussions but seems I didn’t consider it in the sketch above)
    I think this is doable and we should do it. We’ll just see if it is done in the first version or as part of future improvements. One concern that I have is that the more complex the system becomes, the higher the chance it gets exploited.

  • Yes, it will be done via forum. I also hope we can make it configurable via root call in some way. That way, with governance in place, token holders could have direct influence over the params.

9 Likes
18

@Kahori & @Mouthmouth68
I’ve added another extensive example in the original post which I hope will be helpful:

5 Likes
19

Hi Dino

Thx for your quick answer.

Please find below my comments to your answers:

  • if the only way to give more rewards to the active users is the amount of tokens obtained during the voting period, the ratio between the voting period and the B&E period is key. I think this is an issue because it is very difficult to find a ratio that reward much much more active users than passive ones. Have u considered using another methodology, like providing a fixed of rewards (ie 5% apy) to “passive” users who lock their tokens but not nominate dapps on a regular basis?
  • I don’t believe in the “staking choice fatigue” argument. Active users may not change their nominations for several cycles, but i don’t think that they can get “tired” of signing off 2 or 3 transactions every 6 or 8 weeks. “a real active user should not be tired for being active on a regular basis :joy:”
  • my pov is that the “categories” are a key element to ensure a fair distribution between dapps, and it would be fantastic to see them at the launch of the v3.

Rod

2 Likes
20

Hi @Dino,

thanks for the additional exemple. I think it will help people to understand more the mecanic behind the proposed reward system.

  • like @Rod I do agree that the cycle frequency should not be longer than 2 months in order for the projects to feel the need to keep their community involved and informed of their developpment to keep their tier. However, I do also fear that “staking choice fatigue” could also be an issue since i will definitively be part of them, not by fatigue but by lack of time (even if signing a tx do not take long, the entire process of reviewing new devlopments for each Dapps and deciding if they still meet my expectations and thus my support - does take time - I don’t think it would be a good developpment if people just become lazy and just restack on the same Dapp all the time - not by interest and support but by lack of time/motivation. Maybe an option to vote for the same DApp for 2 to 3 cycles could be offered in exchange for shorter cycle (1-2 month per cycle) AND/OR an option to be exempted of voting if they stack on Astar Core Contributors DApp for exemple (to support the Astr network in general). It could be used as a tool to the DApp teams to visualize the amount of active supporter rather than the mix with the “lazy restacker”

  • Regarding the ratio of VOT : B&E, in my opinion, a 1 : 3 weeks seems balanced to me.

  • The DApp category is definitly something to put in action since DEFI projects will, by definition, have tendency to collect higher TVL than NFT projects and In-dev projects and thus higher chance to be in 1 tier. Therefore, category is definitly a must to have right from the start in my opinion.

3 Likes