# dApps Staking v3 - proposal
**URL:** https://forum.astar.network/t/dapps-staking-v3-proposal/4206
**Category:** General
**Created:** [January 2, 2023, 2:09pm UTC](https://forum.astar.network/t/dapps-staking-v3-proposal/4206 "2023-01-02T14:09:40Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@Dino](https://forum.astar.network/u/Dino)
#### Post date: [January 2, 2023, 2:09pm UTC](https://forum.astar.network/t/dapps-staking-v3-proposal/4206/1 "2023-01-02T14:09:40Z")
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! 😄
# 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)
## 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:
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:
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
**Block 2 & Block 3**
- Since it’s `voting period`, rewards are accumulated into `Extra Rewards`
**Block 4**
- `Build & earn period` begins, rewards are deposited in their respective accumulators
**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
**Block 6 & Block 7**
- Rewards are being accumulated
**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_
- Then we can consider **extra rewards** paid for staking (voting) during `voting period` and remaining staked throughout the entire `build & earn period`
Please also check Kahori’s post [below](https://forum.astar.network/t/dapps-staking-v3-proposal/4206/21).
### 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](https://forum.astar.network/t/astar-tokenomics-2-0-a-dynamically-adjusted-inflation/4924) for more concrete numbers for staker rewards, dApp rewards, and tiers.
---
### Author:  [@pitcoin777](https://forum.astar.network/u/pitcoin777)
#### Post date: [January 2, 2023, 3:49pm UTC](https://forum.astar.network/t/dapps-staking-v3-proposal/4206/2 "2023-01-02T15:49:55Z")
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?
---
### Author:  [@VasaKing](https://forum.astar.network/u/VasaKing)
#### Post date: [January 2, 2023, 4:23pm UTC](https://forum.astar.network/t/dapps-staking-v3-proposal/4206/3 "2023-01-02T16:23:24Z")
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 👍
---
### Author:  [@anon24836865](https://forum.astar.network/u/anon24836865)
#### Post date: [January 2, 2023, 4:24pm UTC](https://forum.astar.network/t/dapps-staking-v3-proposal/4206/4 "2023-01-02T16:24:51Z")
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
---
### Author:  [@Mouthmouth68](https://forum.astar.network/u/Mouthmouth68)
#### Post date: [January 3, 2023, 3:40am UTC](https://forum.astar.network/t/dapps-staking-v3-proposal/4206/5 "2023-01-03T03:40:20Z")
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?
---
### Author:  [@sanyun](https://forum.astar.network/u/sanyun)
#### Post date: [January 3, 2023, 4:19am UTC](https://forum.astar.network/t/dapps-staking-v3-proposal/4206/6 "2023-01-03T04:19:40Z")
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?
---
### Author:  [@Dino](https://forum.astar.network/u/Dino)
#### Post date: [January 3, 2023, 9:25am UTC](https://forum.astar.network/t/dapps-staking-v3-proposal/4206/7 "2023-01-03T09:25:30Z")
Thank you everyone who was quick to provide feedback! 🙌
@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 🙂
* * *
* * *
@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 🙂
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.
---
### Author:  [@realtakahashi](https://forum.astar.network/u/realtakahashi)
#### Post date: [January 3, 2023, 10:01am UTC](https://forum.astar.network/t/dapps-staking-v3-proposal/4206/8 "2023-01-03T10:01:09Z")
I support this proposal. I especially like the “Separate Locking & Staking” part of this proposal.
---
### Author:  [@Mouthmouth68](https://forum.astar.network/u/Mouthmouth68)
#### Post date: [January 3, 2023, 2:42pm UTC](https://forum.astar.network/t/dapps-staking-v3-proposal/4206/9 "2023-01-03T14:42:51Z")
Hi @Dino
Before i answer your comments, i would like you to clarifiy the following point which is unclear for me.
When you say :
> [@Dino](#):
>
> 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.
Do you intend to reward locking token and staking/voting separately?
---
### Author:  [@Dino](https://forum.astar.network/u/Dino)
#### Post date: [January 3, 2023, 2:52pm UTC](https://forum.astar.network/t/dapps-staking-v3-proposal/4206/10 "2023-01-03T14:52:52Z")
@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.
---
### Author:  [@Mouthmouth68](https://forum.astar.network/u/Mouthmouth68)
#### Post date: [January 3, 2023, 3:03pm UTC](https://forum.astar.network/t/dapps-staking-v3-proposal/4206/11 "2023-01-03T15:03:52Z")
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?
---
### Author:  [@Dino](https://forum.astar.network/u/Dino)
#### Post date: [January 3, 2023, 3:16pm UTC](https://forum.astar.network/t/dapps-staking-v3-proposal/4206/12 "2023-01-03T15:16:47Z")
@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.
---
### Author:  [@pitcoin777](https://forum.astar.network/u/pitcoin777)
#### Post date: [January 3, 2023, 3:30pm UTC](https://forum.astar.network/t/dapps-staking-v3-proposal/4206/13 "2023-01-03T15:30:53Z")
> 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?
---
### Author:  [@Dino](https://forum.astar.network/u/Dino)
#### Post date: [January 3, 2023, 3:32pm UTC](https://forum.astar.network/t/dapps-staking-v3-proposal/4206/14 "2023-01-03T15:32:21Z")
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 😁.
---
### Author:  [@Mouthmouth68](https://forum.astar.network/u/Mouthmouth68)
#### Post date: [January 3, 2023, 4:31pm UTC](https://forum.astar.network/t/dapps-staking-v3-proposal/4206/15 "2023-01-03T16:31:37Z")
@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?
---
### Author:  [@Rod](https://forum.astar.network/u/Rod)
#### Post date: [January 3, 2023, 11:01pm UTC](https://forum.astar.network/t/dapps-staking-v3-proposal/4206/16 "2023-01-03T23:01:46Z")
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 😉
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 😁
- 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.
---
### Author:  [@Dino](https://forum.astar.network/u/Dino)
#### Post date: [January 4, 2023, 8:37am UTC](https://forum.astar.network/t/dapps-staking-v3-proposal/4206/17 "2023-01-04T08:37:18Z")
@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! 🙂
* * *
* * *
@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. 🙂
- 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 🙂. 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.
---
### Author:  [@Dino](https://forum.astar.network/u/Dino)
#### Post date: [January 4, 2023, 6:10pm UTC](https://forum.astar.network/t/dapps-staking-v3-proposal/4206/18 "2023-01-04T18:10:52Z")
@Kahori & @Mouthmouth68
I’ve added another extensive example in the original post which I hope will be helpful:
> [@dApps Staking v3 - proposal](https://forum.astar.network/t/dapps-staking-v3-proposal/4206#example-of-reward-accumulation-13):
>
> 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! smile1. Overview The main purpose of dApps staking is to incentivize developers & builders who choose Shiden or Astar network as their platform. ASTR or SDN ho…
---
### Author:  [@Rod](https://forum.astar.network/u/Rod)
#### Post date: [January 4, 2023, 6:43pm UTC](https://forum.astar.network/t/dapps-staking-v3-proposal/4206/19 "2023-01-04T18:43:16Z")
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** 😂”
- 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
---
### Author:  [@Mouthmouth68](https://forum.astar.network/u/Mouthmouth68)
#### Post date: [January 4, 2023, 8:06pm UTC](https://forum.astar.network/t/dapps-staking-v3-proposal/4206/20 "2023-01-04T20:06:49Z")
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.
[Next page](https://forum.astar.network/t/dapps-staking-v3-proposal/4206.md?page=2)