diff --git a/docs/build/dapp-staking/technical_solution.md b/docs/build/dapp-staking/technical_solution.md index c64dbecdc64..e4a85778d78 100644 --- a/docs/build/dapp-staking/technical_solution.md +++ b/docs/build/dapp-staking/technical_solution.md @@ -122,8 +122,16 @@ The relevant storage map is `DAppTiers` which maps `era` to information about dA After reading `DappTiers` storage map for a particular `era`, `dapp_tiers_rewards.dapps` _tree map_ must be checked whether it contains the `dapp_id` of the smart contract for which we want to claim rewards. Please note that `dapp_id` is `u16` dApp identifier which can be read from the `DAppInfo` struct in `IntegratedDAppsStorage`. -In case entry for the `dapp_id` exists, it will also contain the `tier_id` value which can be used to read the earned dApp reward from `dapp_tier_info.rewards`. -It’s enough to use `tier_id` it as index in the `rewards` vector to find the reward associated with that tier. +In case entry for the `dapp_id` exists, it will also contain the `tier_id` value (and rank within tier) which can be used to read the earned dApp reward components from `dapp_tier_info`. + +With deterministic tier+rank rewards, the claim value is derived from two per-tier components: + +- `tier_base_reward0 = dapp_tier_info.rewards[tier_id]` (rank 0 reward) +- `reward_per_rank_step = dapp_tier_info.rank_rewards[tier_id]` (per +1 rank) + +Final reward for a dApp with `rank` is: + +`dapp_reward = tier_base_reward0 + rank * reward_per_rank_step` Once reward has been claimed, the associated entry will be removed `dapp_tiers_rewards.dapps` _tree map_. @@ -144,6 +152,12 @@ Once we know the oldest period, we can use `PeriodEnd` storage map to find when ### Bonus Rewards +:::warning Attention + +Tokenomics 3.0 has **no user-facing bonus rewards**, so indexers and UIs should not surface a "bonus pool", "bonus APR", or "vote-to-earn-bonus" guidance as a user benefit. + +::: + When checking whether staker is eligible for any bonus rewards, it is necessary to check all of the `StakerInfo` double storage map entries related to that staker. The first key of the double map is `staker account` so it can easily be iterated via prefix iteration. @@ -179,11 +193,22 @@ However, it is possible that in that very same block, someone calls `claim_dapp_ Reward pools per era can be read from the `Inflation` pallet, by reading the `ActiveInflationConfig` storage value. -Each tier gets a portion of the reward pool (denoted as `reward_portion` in the configuration). These portions are further partitioned per slots. +Each tier gets a portion of the dApp reward pool (denoted as `reward_portion` in the configuration). Tokenomics 3.0 then computes deterministic tier reward components using `tier_rank_multipliers` (bips, `10_000 = 100%`) and a weight-based normalization cap: + +```text +MAX_RANK = 10 +step_bips = max(0, tier_rank_multipliers[tier] - 10_000) / MAX_RANK -E.g. for tier 1 dApp reward is calculated as: +observed_total_weight = filled_slots * 10_000 + ranks_sum * step_bips +expected_full_weight = max_slots * (10_000 + 5 * step_bips) // avg rank = 5 +normalization_weight = max(observed_total_weight, expected_full_weight) + +tier_base_reward0 = tier_allocation * 10_000 / normalization_weight +reward_per_rank_step = tier_allocation * step_bips / normalization_weight +dapp_reward(rank) = tier_base_reward0 + rank * reward_per_rank_step +``` -`tier_1_dapp_reward = dapp_reward_pool_per_era * reward_portion[0] / slots_per_tier[0]` +This replaces any "empty slots fund rank rewards" interpretation: empty slots only affect `filled_slots` / normalization, and under-filled tiers can leave part of the tier allocation unminted. ### When To Call Expired Entry Cleanup diff --git a/docs/learn/dapp-staking/dapp-staking-faq.md b/docs/learn/dapp-staking/dapp-staking-faq.md index 446b4868ed5..25de96ea2d5 100644 --- a/docs/learn/dapp-staking/dapp-staking-faq.md +++ b/docs/learn/dapp-staking/dapp-staking-faq.md @@ -88,9 +88,11 @@ Once unlocking is complete, you can then withdraw these tokens to your free bala ### Q: When will I start getting rewards after I stake? -If you stake during the dedicated **Voting Subperiod**, you qualify for bonus rewards as long as you maintain or increase your staked amount during the following Build&Earn Subperiod. Bonus rewards can be claimed after the period ends. +No rewards are generated during the **Voting** subperiod. -If you stake during any era of **Build&Earn Subperiod**, the staked amount is only eligible for rewards from the next era onward. +If you stake during the **Voting** subperiod, your stake is set up for the upcoming **Build&Earn** subperiod. Staker rewards are earned only for **Build&Earn** eras in which your stake was active for the entire era. + +If you stake (or change your stake) during any era of **Build&Earn** subperiod, the updated amount is eligible for rewards from the **next era** onward. ### Q: When can I claim my rewards? @@ -102,15 +104,15 @@ Generally, it’s recommended to claim your rewards once a week. ### Q: What are bonus rewards? -If a staker staked on a dApp during the `Voting` Subperiod and **keeps the same staked amount or higher** on a dApp through the whole `Build&Earn` Subperiod, they are eligible for the bonus rewards. +Tokenomics 3.0 has **no user-facing bonus rewards**. `Voting` and `Build&Earn` remain protocol phases, but integrators should not promote a separate "bonus pool" or "bonus APR" as a user benefit. -Bonus eligibility can be safely transferred between projects, preserving it for a limited number of moves, as defined by `MaxBonusSafeMovesPerPeriod`. Exceeding this limit results in bonus forfeiture for the affected stake. +If you see bonus-related fields in older tooling or runtimes, treat them as **legacy/internal compatibility** only. ### Q: Can my rewards expire? Unclaimed rewards will eventually expire, so it's important to claim them in time or they'll miss out on earnings. -We encourage stakers’ engagement. This way, failing to actively revisit dApp staking at the start of each new period to select dApps for staking means missing out on bonus rewards and earnings. +We encourage stakers' engagement. If you don't revisit dApp staking at the start of each new period to select dApps for staking, you won't be earning rewards for expired **Build&Earn** eras. ### Q: What happens to my rewards if the project I'm staking on is unregistered from dApp Staking? @@ -182,7 +184,7 @@ The threshold for tier 4 is fixed, while it is dynamic for the other tiers. Rewards for dApps are **dynamic** (tier-dependent), meaning they change from one tier to another. -The rewards of a tier are split evenly among all its slots, ensuring equal rewards for each dApp within a tier, regardless of whether all slots are filled. +Within a tier, dApp rewards are **deterministic** and can also depend on the dApp's **rank (0..10)** (see the technical overview for the `tier_rank_multipliers` model). If a tier is under-filled, part of that tier allocation can remain **unminted** (lazy minting). ### Q: What happens to my rewards if my project is unregistered from dApp Staking? diff --git a/docs/learn/dapp-staking/dapp-staking-protocol.md b/docs/learn/dapp-staking/dapp-staking-protocol.md index 9ba47c37a28..a9799253fa0 100644 --- a/docs/learn/dapp-staking/dapp-staking-protocol.md +++ b/docs/learn/dapp-staking/dapp-staking-protocol.md @@ -43,7 +43,9 @@ When `Voting` subperiod starts, all _stakes_ are reset to **zero**. Projects participating in dApp staking are expected to market themselves to (re)attract stakers. Stakers must assess whether the project they want to stake on brings value to the ecosystem, and then `vote` for it (or _stake_ on it). -Casting a vote, or staking, during the `Voting` subperiod makes the staker eligible for bonus rewards. so they are encouraged to participate during this time. +Staking during the `Voting` subperiod is the normal way to (re)establish stake for the upcoming `Build&Earn` subperiod. + +Tokenomics 3.0 note: there are **no user-facing bonus rewards** associated with staking during `Voting`. `Voting` remains a coordination/selection phase, and rewards are only generated for eras in `Build&Earn`. `Voting` subperiod length is expressed in _standard_ era lengths, even though the entire voting subperiod is treated as a single _voting era_. E.g. if `Voting` subperiod lasts for **5 eras**, and each era lasts for **100 blocks**, total length of the `Voting` subperiod will be **500** blocks **BUT** it will consume only a single numeric era: @@ -169,7 +171,7 @@ User's stake on a contract must be equal or greater than the `MinimumStakeAmount Although user can stake on multiple smart contracts, the amount is limited. To be more precise, amount of database entries that can exist per user is limited. This should not be a problem in practice though. -The protocol keeps track of how much was staked by the user in the `Voting` and `Build&Earn` subperiods. This is important for the bonus reward calculation. +The protocol keeps track of stake amounts across subperiods. Some bonus-related bookkeeping may still exist in protocol storage for legacy/internal compatibility, but Tokenomics 3.0 provides **no separate user-facing bonus pool**. It is not possible to stake on a dApp that has been unregistered. However, if dApp is unregistered after user has staked on it, user will keep earning @@ -193,23 +195,20 @@ Once period finishes, all stakes are reset back to zero. This means that no unst #### Moving Stake Between Contracts -The moving stake feature allows users to transfer their staked amount between two smart contracts without undergoing the unstake and stake process separately. This feature ensures that the transferred stake remains aligned with the current staking period, but the moved stake is effective in the next era and any bonus eligibility is preserved as long as the conditions for the bonus reward are not violated. Move actions are limited by `MaxBonusSafeMovesPerPeriod` from the protocol configuration. +The moving stake feature allows users to transfer their staked amount between two smart contracts without undergoing the unstake and stake process separately. This feature ensures that the transferred stake remains aligned with the current staking period, but the moved stake is effective in the next era. Key details about moving stake: - The destination contract must be different from the source contract. - The user must ensure that unclaimed rewards are claimed before initiating a stake move. -- Only a limited number of move actions (defined by `MaxBonusSafeMovesPerPeriod`) are considered _safe_ during a single period to preserve bonus reward eligibility. Additional moves actions are feasable but forfeit the bonus reward. - If the destination contract is newly staked, the user's total staked contracts must not exceed the maximum allowed number of staked contracts (same as the staking operation). -- The destination contract must not be unregistered, but moving stake away from an unregistered contract is allowed **without affecting bonus eligibility**. - -This feature is particularly useful for stakers who wish to rebalance their stake across multiple contracts (including new registrations) or move their stake to better-performing dApps while retaining the potential for rewards and maintaining bonus eligibility. +- The destination contract must not be unregistered, but moving stake away from an unregistered contract is allowed. -#### Bonus Status Handling in Moves +:::note Legacy/internal compatibility -When moving stake, if the destination contract has no existing bonus eligibility, it inherits the incoming bonus status from the source contract. If both the source and destination have nonzero bonus statuses, they are merged by averaging their values. This prevents unintended bonus gains or losses while ensuring fairness in bonus distribution. +Older pallet versions may still contain bonus-eligibility and "safe move" bookkeeping for backward compatibility. Tokenomics 3.0 has **no user-facing bonus rewards**, and UIs should not promote or surface bonus mechanics as a user benefit. -For example, if the configuration allows **2** _safe moves_, if the source conctract as already be moved once and if the destination contract as not consumed move actions, the resulting merged for the remaining _safe moves_ of teh destination stake will be **1** ((2+0) / 2 = 1). +::: #### Claiming Staker Rewards @@ -226,25 +225,7 @@ $staker\_reward = \frac{staker\_reward\_pool * staker\_staked\_amount}{total\_st #### Claiming Bonus Reward -If a staker has staked on a dApp during the voting subperiod, and the bonus status for the associated staked amount has not been forfeited due to excessive move actions, they remain eligible for the bonus reward. - -Only a limited number of _safe move actions_ are allowed during the `build&earn` subperiod to preserve bonus reward eligibility. Move actions refer to either: -- A 'partial unstake that decreases the voting stake', -- A 'stake transfer between two contracts'. (check previous "Moving Stake Between Contracts" section) - -The number of authorized safe move actions is defined by `MaxBonusSafeMovesPerPeriod`. For example: -If 2 safe bonus move actions are allowed for one period, and a user has staked **100** on contract A during the `voting` subperiod and **50** during the `build&earn` subperiod, they can safely: - -1. Unstake **70**, reducing the `voting` stake to **80**. -2. Transfer **50** to contract B. - -After these actions, the user will still be eligible for bonus rewards (**20** on contract A and **50** on contract B). However, if an additional move action is performed on contract A, the bonus eligibility will be forfeited. - -Bonus rewards need to be claimed per contract, unlike staker rewards. - -Bonus reward is calculated using a simple formula: - -$bonus\_reward = \frac{bonus\_reward\_pool * staker\_voting\_subperiod\_stake}{total\_voting\_subperiod\_stake}$ +Tokenomics 3.0 note: there are **no user-facing bonus rewards**. Any bonus-related storage/extrinsics that still exist are for legacy/internal compatibility and should be treated as such by integrators (do not present a "bonus pool" or "bonus APR" to end users). ### Developers @@ -253,9 +234,9 @@ Main thing for developers to do is develop a good product & attract stakers to s #### Claiming dApp Reward If at the end of a `Build&Earn` subperiod era dApp has high enough score (support) to enter a reward tier, it will get rewards assigned to it. -Rewards aren't paid out automatically but must be claimed instead, similar to staker & bonus rewards. +Rewards aren't paid out automatically but must be claimed instead, similar to staker rewards. -dApp reward is calculated based on the tier in which ended. All dApps that end up in one tier will get the exact same reward. +dApp reward is calculated based on the tier and (where enabled) the dApp rank within that tier. The protocol computes, per tier and era, a **rank-0 base reward** and a **per-rank-step reward**, and the final dApp reward is derived from those components. ### Tier System @@ -335,15 +316,9 @@ If the number of slots changes, the threshold is further adjusted based on the d #### Tier Rewards Better tiers bring bigger rewards, so dApps are encouraged to compete for higher tiers and attract staker's support. -dApp reward pool is divided between tiers, e.g. _tier 1_ gets **40%** of the total reward pool, and the assigned tier reward pool -is further divided between the dApps in the pool. +dApp reward pool is divided between tiers, e.g. _tier 1_ gets **40%** of the total reward pool. -This means that each dApp within a tier always gets the same amount of reward. -Even if tier capacity hasn't been fully taken, rewards are paid out as if they were. - -For example, if _tier 1_ has capacity for 10 dApps, and reward pool is **500 ASTR**, it means that each dApp that ends up -in this tier will earn **50 ASTR**. Even if only 3 dApps manage to enter this tier, they will still earn each **50 ASTR**. -The rest, **350 ASTR** in this case, won't be minted. +Within a tier, rewards are **deterministic** and can depend on the dApp's **rank** (0..10) via the `tier_rank_multipliers` weight model described below. In addition, when a tier is under-filled (fewer dApps than the tier capacity), part of that tier's allocation can remain **unminted** (lazy minting), reducing effective inflation. #### More On Tiers @@ -361,7 +336,7 @@ the larger Id but this can change in the future. ### Tier ranking system -Because dApps at the same tier receive equal rewards regardless of their staked amount, ranking system has been introduced for dApps within the tier itself. This will improve reward distribution for dApps that perform better within a tier if there are available rewards to be distributed. +A **rank (0..10)** is assigned to dApps inside a tier to express how close they are to the next tier threshold. Rank affects dApp rewards **deterministically** via `tier_rank_multipliers` (see **Rank reward** below). dApps are not only grouped into tiers but they're also ranked inside each tier (except highest tier which doesn't have ranking). When a dApp has the minimum stake amount to just enter the tier, its rank will be **0** (zero). As they progress towards the upper tier, their rank will increase. @@ -382,28 +357,49 @@ The `set_static_tier_params` call allows dynamic modification of tier-related dA #### Rank reward -Each rank provides up to a **10%** extra reward on top of the tier reward. To respect inflation, each rank reward comes from empty slots within the same tier. Each tier has its own portion of rewards to distribute. If all tier slots are occupied, the tier reward is distributed equally to each dApp in that tier, leaving no remaining reward for ranks. If there is a remaining reward, it goes towards rewarding the ranks. Depending on the availability, the rank reward can go up to **10%** of the tier reward. For example, if you are in tier **2** with a rank of **5** and the tier reward is **1000 ASTR**, then rank reward will be **rank_reward = 0.1 * 1000 ASTR = 100 ASTR**. Therefore given formula +Tokenomics 3.0 uses a **deterministic multiplier/weight model**. Rank rewards do **not** come from "empty slots" or "remainder distribution"; empty slots only affect the normalization/cap. -${total\_reward} = {tier\_reward} + {rank} * {rank\_reward}$ +Each tier has a `tier_rank_multipliers[tier]` parameter (in **bips**, where `10_000 = 100%`) which defines how much **rank 10** earns **relative to rank 0** in that tier. -Total reward for dApp will be **1000 ASTR + 5 * 100 ASTR = 1500 ASTR**. +Definitions (per tier, per era): -:::note -If **10%** of tier reward cannot be satisfied then the following formula is used +```text +MAX_RANK = 10 +rank ∈ [0..10] +multiplier_bips = tier_rank_multipliers[tier] // rank10 vs rank0, in bips +step_bips = max(0, multiplier_bips - 10_000) / MAX_RANK -${rank\_reward} = \frac{remaining\_reward}{\sum \forall dApp\_rank}$ +weight(rank) = 10_000 + rank * step_bips -where $\sum \forall dApp\_rank$ is the sum of all dApp ranks in a tier. +filled_slots = number of dApps assigned to this tier +max_slots = configured capacity (slots) for this tier +ranks_sum = Σ rank(dApp) over dApps in this tier -**e.g.** Given a tier **2** with a slot capacity of **3**, where **2** slots are occupied by dApp _Alice_ with rank **9** and dApp _Bob_ with rank **7**. The rank reward comes from the empty slots, which in this case is only **1**. Therefore, a **10%** rank reward cannot be achieved. In this scenario, the remaining reward will be divided by ranks sum. +observed_total_weight = filled_slots * 10_000 + ranks_sum * step_bips -${rank\_reward} = \frac {1000 ASTR} {7 + 9} = 62.5 ASTR$ +// "normally filled tier" cap calibrated at average rank = 5: +expected_full_weight = max_slots * (10_000 + 5 * step_bips) -Total reward for _Alice_ will be: **1000 ASTR + 9 * 62.5 ASTR = 1562.5 ASTR** +// normalization prevents over-distribution and makes under-filled tiers leave part unminted: +normalization_weight = max(observed_total_weight, expected_full_weight) +``` -Total reward for _Bob_ will be: **1000 ASTR + 7 * 62.5 ASTR = 1437.5 ASTR** +Let `tier_allocation` be the amount of the per-era dApp reward pool allocated to this tier. The protocol computes two claim components: -::: +```text +tier_base_reward0 = tier_allocation * 10_000 / normalization_weight +reward_per_rank_step = tier_allocation * step_bips / normalization_weight +``` + +And the dApp's final reward is: + +```text +dapp_reward(rank) = tier_base_reward0 + rank * reward_per_rank_step +``` + +Notes: +- If `tier_rank_multipliers[tier] <= 10_000`, then `step_bips = 0` and rank does not increase rewards in that tier. +- Under-filled tiers can result in `expected_full_weight` dominating the normalization, meaning part of the tier allocation is never minted. ### Reward Expiry @@ -415,7 +411,7 @@ In case they don't, they will simply miss on the earnings. However, this should not be a problem given how the system is designed. There is no longer _stake&forget_ - users are expected to revisit dApp staking at least at the beginning of each new period to pick out old or new dApps on which to stake on. -If they don't do that, they miss out on the bonus reward & won't earn any staker rewards. +If they don't do that, they miss out on earning staker rewards. ### Oracle Price Feed diff --git a/docs/learn/dapp-staking/index.md b/docs/learn/dapp-staking/index.md index bd8285cafbb..bf04e0eb3bb 100644 --- a/docs/learn/dapp-staking/index.md +++ b/docs/learn/dapp-staking/index.md @@ -89,7 +89,7 @@ Each Period consists of two Subperiods: **Voting (Staking) Subperiod** A subperiod when stakers can decide to vote for dApp(s) to stake their tokens and when dApps owners and team can market their products, conduct campaign and attract stakers. -No staking rewards are generated during the Voting subperiod but if users vote and stake on dApps during this subperiod, they will become eligible for the **Bonus Reward**; +No staking rewards are generated during the Voting subperiod. :::important @@ -99,8 +99,8 @@ It's very important for dApp owners and their teams to get organized before and **Build&Earn Subperiod** -A subperiod when stakers and dApps start earning rewards; -Users can still stake tokens during the Build&Earn subperiod to increase the rewards they get from staking. However, the amount staked during Build&Earn does not contribute to the Bonus Reward. +A subperiod when stakers and dApps start earning rewards. +Users can still stake tokens during the Build&Earn subperiod to increase the rewards they get from staking. At the end of a **Build&Earn** subperiod, the current period ends. A new period begins, and all tokens are `unstaked` from dApp(s) but remain `locked`. A new **Voting Subperiod** starts. @@ -119,6 +119,10 @@ As an user or a dApp owner, you need to take the following parameters into consi For the full list of parameters, please check the [dApp staking parameters page](/docs/learn/dapp-staking/protocol-parameters.md) and [Tokenomics 2.0 page](/docs/learn/tokenomics2/Inflation/#parameters). +Tokenomics 3.0 note: +- At most **16 dApps are reward-eligible per era** (across tiers). +- Historical reward data and claim paths may reference up to **500** dApps for backward compatibility. + #### Tier System Tier System is a method to rank dApps based on the total value staked on them. The Tier System is updated at the end of each Build&Earn Subperiod era. @@ -127,6 +131,8 @@ There are a limited number of tiers, each with a set number of slots and a minim A dApp must gain enough support to enter a tier, with dynamic thresholds for fair competition. Higher tiers offer larger rewards. +Within a tier, dApps can also have a **rank (0..10)**. Tokenomics 3.0 uses a deterministic `tier_rank_multipliers` weight model so a dApp's rewards can depend on **tier + rank** (not on empty slots). For the technical details and formulas, see the [technical overview](/docs/learn/dapp-staking/dapp-staking-protocol.md). + You can always view in what tier the dApp is in the Projects Leaderboard on the Astar Portal. :::tip @@ -151,7 +157,7 @@ As a result, stakers are rewarded for their commitment and staking efforts. - For detailed **technical overview** of dAppStaking protocol, visit this [page](/docs/learn/dapp-staking/dapp-staking-protocol/). -- Check the [**FAQ section**](/docs/learn/dapp-staking/dapp-staking-faq.md), especially covering topics around new version of dApp Staking (V3) planned to go live on Astar in Q1 2024. +- Check the [**FAQ section**](/docs/learn/dapp-staking/dapp-staking-faq.md). ::: diff --git a/docs/learn/dapp-staking/protocol-parameters.md b/docs/learn/dapp-staking/protocol-parameters.md index 6c7d12e4dff..1377bd290b7 100644 --- a/docs/learn/dapp-staking/protocol-parameters.md +++ b/docs/learn/dapp-staking/protocol-parameters.md @@ -6,7 +6,7 @@ title: dApp Staking Parameters ## Overview The following parameters are tightly tied to dApp staking, however, some parameters are shared with the _Tokenomics 2.0_ model. -To find out more, please check the documentation [here](/docs/learn/tokenomics2/Inflation/). +To find out more, please check the documentation [here](/docs/learn/tokenomics2/Inflation). ### Era Reward Span Length @@ -21,8 +21,12 @@ The larger this parameter is, the higher the deviation from the max inflation ra ### Max Number Of Contracts -There is a technical limitation on how many dApps the protocol can support at this time. -However, this limit won't have a _real_ impact on the protocol since at the moment of writing this document, neither Astar or Shiden are close to that limit. +Tokenomics 3.0 introduces a tighter active bound for reward processing: + +- **Active rewarded dApps (per era): 16** — at most 16 dApps are reward-eligible per era across tiers. +- **Legacy compatibility bound: 500** — historical reward-era structures and claim paths may reference up to 500 dApps for backward compatibility. + +This separation exists so the protocol can keep compatibility with older stored reward structures while enforcing a much smaller active set going forward. ### Max Unlocking Chunks @@ -51,11 +55,9 @@ It's suggested to keep this value same as the _minimum locked amount_. ### Max Bonus Safe Moves Per Period -The number of authorized safe move actions of the amount staked during the Voting subperiod to remain eligible for the bonus reward. -Only a limited number of _safe move actions_ are allowed during the `build&earn` subperiod to preserve bonus reward eligibility. Move actions refer to either: +Legacy/internal compatibility parameter. -- A 'partial unstake that decreases the voting stake', -- A 'stake transfer between two contracts'. (check previous "Moving Stake Between Contracts" section) +Historically used to bound "safe move" actions related to bonus-eligibility bookkeeping. Tokenomics 3.0 has **no user-facing bonus rewards**, so integrators should not promote bonus mechanics. This constant may still exist for legacy/internal state transitions and backward compatibility. ### Number Of Tiers @@ -71,6 +73,12 @@ E.g. `[10%, 20%, 30%, 40%]` means that `10%` of the reward pool goes for **tier Describes the portion/percentage of the total number of slots that goes towards each tier. E.g. `[5%, 15%, 20%, 60%]` means that `5%` of the total slots are assigned for **tier 1** dApps, `15%` for **tier 2** dApps, and so on. +### Tier Rank Multipliers (`tier_rank_multipliers`) + +Per-tier vector of **bips** (basis points) where `10_000 = 100%`. + +For each tier, this value defines how much **rank 10** earns relative to **rank 0** (i.e., it parameterizes the deterministic rank reward slope). A value of `10_000` disables rank-based increase for that tier. The exact weight/normalization formulas are documented in the technical overview. + ### Tier Thresholds The threshold a dApp must meet, based on a percentage of the total issuance staked, to enter a tier. @@ -93,20 +101,21 @@ Length of the circular buffer used to implement the _moving-average_ solution. | -------------------------------------------------- | ----------------------------- | --------------------------- | ---------------------------------- | | Era Reward Span Length | 16 | 16 | 16 | | Reward Retention In Periods | 4 | 3 | 2 | -| Max Number Of Contracts | 500 | 500 | 500 | +| Max Number Of Contracts | 16 | 16 | 16 | | Max Unlocking Chunks | 8 | 8 | 8 | | Minimum Locked Amount | 500 ASTR | 50 SDN | 5 SBY | | Unlocking Period | 9 | 4 | 4 | | Max Number Of Staked Contracts | 16 | 16 | 8 | | Minimum Stake Amount | 500 ASTR | 50 SDN | 5 SBY | -| Max Bonus Safe Moves Per Period | 2 | 2 | 2 | +| Max Bonus Safe Moves Per Period (legacy/internal) | 2 | 2 | 2 | | Baseline Native Currency Price | 0.05 USD | 0.05 USD | 0.05 USD (mock) | | Number Of Tiers | 4 | 4 | 4 | -| Reward Distribution | [25%, 47%, 25%, 3%] | [25%, 47%, 25%, 3%] | [40%, 30%, 20%, 10%] | -| Slot Portions | [5%, 20%, 30%, 45%] | [5%, 20%, 30%, 45%] | [10%, 20%, 30%, 40%] | -| Tier 1 Threshold (total issuance % - base/min/max) | Dynamic(3.57%/2.38%/3.57%) | Dynamic(3.57%/2.38%/100%) | Dynamic(0.0020%/0.0017%/0.0030%) | -| Tier 2 Threshold (total issuance % - base/min/max) | Dynamic(0.89%/0.6%/0.89%) | Dynamic(0.89%/0.6%/100%) | Dynamic(0.0013%/0.0010%/0.0020%) | -| Tier 3 Threshold (total issuance % - base/min/max) | Dynamic(0.238%/0.179%/0.238%) | Dynamic(0.238%/0.179%/100%) | Dynamic(0.00054%/0.00034%/0.0010%) | -| Tier 4 Threshold (total issuance % - base/min/max) | Fixed(0.02%) | Fixed(0.06%) | Fixed(0.00014%) | +| Reward Distribution | [0%, 70%, 30%, 0%] | [25%, 47%, 25%, 3%] | [40%, 30%, 20%, 10%] | +| Slot Portions | [0%, 37.5%, 62.5%, 0%] | [5%, 20%, 30%, 45%] | [10%, 20%, 30%, 40%] | +| Tier Rank Multipliers (bips; rank10 vs rank0) | [0, 24_000, 46_700, 0] | Runtime configured | Runtime configured | +| Tier 1 Threshold (total issuance % - base/min/max) | Fixed(2.32%) | Dynamic(3.57%/2.38%/100%) | Dynamic(0.0020%/0.0017%/0.0030%) | +| Tier 2 Threshold (total issuance % - base/min/max) | Fixed(0.93%) | Dynamic(0.89%/0.6%/100%) | Dynamic(0.0013%/0.0010%/0.0020%) | +| Tier 3 Threshold (total issuance % - base/min/max) | Fixed(0.35%) | Dynamic(0.238%/0.179%/100%) | Dynamic(0.00054%/0.00034%/0.0010%) | +| Tier 4 Threshold (total issuance % - base/min/max) | Fixed(0%) | Fixed(0.06%) | Fixed(0.00014%) | | Price Aggregation Duration | 7200 blocks | 7200 blocks | 7200 blocks | | Circular Buffer Length | 7 | 7 | 7 | diff --git a/docs/learn/tokenomics2/Inflation.md b/docs/learn/tokenomics2/Inflation.md index 220f1bc6f5e..c46c2710cbb 100644 --- a/docs/learn/tokenomics2/Inflation.md +++ b/docs/learn/tokenomics2/Inflation.md @@ -29,7 +29,7 @@ Each **cycle** consists of one or more **periods**. **Periods** are a core time unit in the dApp Staking protocol. Each period consists of a `Voting` and `Build&Earn` subperiods. During the `Voting` subperiod, neither stakers nor dApp owners can earn any rewards, only _collators_ and _treasury_ continue earning. -During the the `Build&Earn` subperiod, stakers earn staking rewards per **era** and have the opportunity to earn bonus reward at the end of a period. +During the the `Build&Earn` subperiod, stakers earn staking rewards per **era**. dApp owners also earn rewards, based on how well their dApp is performing in dApp staking, at the end of each **era**. ### Eras @@ -86,9 +86,12 @@ $dapp\_reward\_pool\_per\_era = \frac{total\_dapp\_cycle\_reward}{periods\_per\_ The dApp staking protocol will calculate how much each staked dApp should get. +Tokenomics 3.0 note: per-era dApp rewards are distributed via **tier allocation** plus a deterministic **tier+rank** model (parameterized by `tier_rank_multipliers`), not by "empty slot remainder" rank distribution. Under-filled tiers can leave part of the tier allocation **unminted**. + ### Stakers -There are two components to the staker rewards - regular _staking_ rewards & the _bonus_ reward for loyal stakers. +Staker rewards are awarded for staking native currency, **ASTR**, on a dApp. +Tokenomics 3.0 provides **no user-facing bonus rewards**. `Voting` and `Build&Earn` remain protocol phases, but UIs should not promote a separate "bonus pool" as a user benefit (any remaining bonus-related internals are legacy/internal compatibility only). #### Regular Staker Rewards @@ -119,18 +122,7 @@ With the above formulas, we can finally express how much staker _Alice_ earns in $staker\_reward\_per\_era_{Alice} = \frac{staked\_value_{Alice,n}}{total\_staked\_value_n} * (base\_staker\_reward\_pool\_per\_era_n + adjustable\_staker\_reward\_pool_n)$ -#### Bonus Rewards - -In case a staker stakes during the `Voting` subperiod, and doesn't reduce their stake during the `Build&Earn` subperiod below what -was staked at the end of the `Voting` subperiod, it will make them eligible for the bonus reward. - -Bonus reward pool is assigned per period, and can be expressed as: - -$bonus\_reward\_pool\_per\_period = \frac{total\_bonus\_cycle\_reward}{periods\_per\_cycle}$ - -The bonus reward for a staker _Alice_ can then be expressed as: -$bonus\_staker\_reward_{Alice} = \frac{voting\_subperiod\_staked\_value_{Alice}}{total\_voting\_subperiod\_staked\_value} * (bonus\_reward\_pool\_per\_period)$ ## Lazy Minting @@ -161,7 +153,7 @@ a single cycle. | Treasury Part | 5% | 5% | 5% | | Collators Part | 3.2% | 3.2% | 3% | | dApps Part | 13% | 13% | 20% | -| Base Staker Part | 10% | 10% | 25% | -| Adjustable Staker Part | 55% | 58.8% | 35% | -| Bonus Part | 13.8% | 10% | 12% | +| Base Staker Part | 15.8% | 15% | 30% | +| Adjustable Staker Part | 63% | 63.8% | 42% | +| Bonus Part (legacy/internal; not user-facing) | 0% | 0% | 0% | | Ideal Staking Rate | 50% | 50% | 20% | diff --git a/docs/use/how-to-guides/layer-1/dapp-staking/for-devs/index.md b/docs/use/how-to-guides/layer-1/dapp-staking/for-devs/index.md index f735199f930..a8fe5d7eab0 100644 --- a/docs/use/how-to-guides/layer-1/dapp-staking/for-devs/index.md +++ b/docs/use/how-to-guides/layer-1/dapp-staking/for-devs/index.md @@ -22,17 +22,19 @@ Before reading the dApp Staking section for dApp owner, make sure you understand dApp Staking introduces the concept of a tier system for dApps. It's important to fully understand the [tier mechanism](/docs/learn/dapp-staking/dapp-staking-protocol.md#tier-system) before proceeding with dApp Staking application and registration as a dApp owner. -Currently, there are **4 tiers** with a limited number of slots per tier. Tier capacity for dApp staking is calculated at the start of each period based on the ASTR price as described [here](/docs/learn/dapp-staking/dapp-staking-protocol.md#tier-system). +dApp Staking uses reward tiers (each with a limited number of slots), and where applicable assigns ranks within tiers so dApp rewards are determined deterministically by **tier + rank**. Tier capacity for dApp staking is calculated at the start of each period based on the ASTR price as described [here](/docs/learn/dapp-staking/dapp-staking-protocol.md#tier-system). The slots allocated to each tier can be viewed on the [dApp Staking Page](https://portal.astar.network/astar/dapp-staking/discover) of the Astar Portal. At the end of each **Build&Earn** subperiod, dApps are assigned to a tier based on the total value staked on them by users. Each tier has a **threshold** that a dApp must reach in order to access it. +At the protocol level, at most **16 dApps are reward-eligible per era** (across tiers). + The threshold for tier 4 is fixed, but for the other tiers, the threshold is **dynamic** and calculated at the start of each new period based on the total number of slots for the period. To find out more, [click here](/docs/learn/dapp-staking/dapp-staking-protocol.md#tier-threshold-entry). **Rewards** for dApps are also **dynamic**, fluctuating from tier to tier. The higher the tier, the greater the number of ASTR tokens allocated from inflation as rewards for that tier. -The rewards of a tier are divided between all available slots and distributed to the dApps occupying slots. This means that the rewards for dApps within a tier are the same for each dApp, even if not all slots within a tier are occupied. +Within a tier, dApp rewards are **deterministic** and can depend on the dApp's **rank (0..10)** via `tier_rank_multipliers` (bips, where `10_000 = 100%`). When a tier is under-filled, part of that tier allocation can remain **unminted** (lazy minting), reducing effective inflation. > Refer to the [**dApp staking parameters**](/docs/learn/dapp-staking/protocol-parameters#network-values) page to find out more about the tier system and reward allocation. @@ -43,12 +45,13 @@ You have to claim your rewards to receive them. We recommend that you claim your :::info -**Example:** +**Example (tier+rank rewards):** -- Tier 1 has 5 slots for dApps and 50,000 ASTR tokens are allocated as a reward; -- At the end of the voting subperiod, only 3 slots are occupied by dApps in Tier 1 ; -- These 3 dApps will each receive 10,000 ASTR as reward; -- The remaining 20,000 ASTR tokens will not be minted by the network and will be considered burnt; +- Tier 1 has **5 slots** and **50,000 ASTR** is allocated as a reward for that tier in a given era; +- At the end of the voting subperiod, only **3 slots** are occupied by dApps in Tier 1; +- Assume `tier_rank_multipliers` for Tier 1 is **24,000 bips**, meaning **rank 10 earns 2.4× rank 0** in that tier; +- If the 3 dApps have ranks **0**, **5**, and **10**, their era rewards are computed deterministically from tier **base (rank 0)** and **per-rank-step** components (see the technical overview formulas); +- Under-filled tiers can leave part of the tier allocation **unminted** due to the normalization cap (lazy minting). ::: @@ -70,4 +73,3 @@ import DocCardList from '@theme/DocCardList'; import {useCurrentSidebarCategory} from '@docusaurus/theme-common'; - diff --git a/docs/use/how-to-guides/layer-1/dapp-staking/for-devs/manage-dApp-Staking.md b/docs/use/how-to-guides/layer-1/dapp-staking/for-devs/manage-dApp-Staking.md index abd70af512c..3ceb585f92d 100644 --- a/docs/use/how-to-guides/layer-1/dapp-staking/for-devs/manage-dApp-Staking.md +++ b/docs/use/how-to-guides/layer-1/dapp-staking/for-devs/manage-dApp-Staking.md @@ -14,7 +14,7 @@ By clicking on your dApp in the **Your Project** panel, you will have access to ### Your Dashboard: -- **Curent Tier:** The current tier to which your dApp has been assigned. See [Tier system](/docs/use/how-to-guides/layer-1/dapp-staking/for-devs/index.md#tier-system-and-rewards) for more information; +- **Current Tier (ranked):** The current tier (and where applicable, rank) to which your dApp has been assigned. See [Tier system](/docs/use/how-to-guides/layer-1/dapp-staking/for-devs/index.md#tier-system-and-rewards) for more information; - **Number of stakers:** Total of current stakers on your dApp; - **Total Earned:** Total tokens received in the dApp Staking program; diff --git a/docs/use/how-to-guides/layer-1/dapp-staking/for-stakers/index.md b/docs/use/how-to-guides/layer-1/dapp-staking/for-stakers/index.md index e76eeb7c4d0..b6d0b3d2581 100644 --- a/docs/use/how-to-guides/layer-1/dapp-staking/for-stakers/index.md +++ b/docs/use/how-to-guides/layer-1/dapp-staking/for-stakers/index.md @@ -41,29 +41,18 @@ There is no rewards during the Unlocking period when unstaking from dApp Staking ::: -### Bonus Staking Rewards: +### Voting and rewards: -If an user stake on dApp(s) during the **Voting Subperiod** and keep the same staked amount or higher on a dApp through the whole **Build&Earn Subperiod**, they will be eligible for the **Bonus Reward** for this dApp. +The **Voting** subperiod is used to (re)establish stakes for the upcoming **Build&Earn** subperiod, but it does not generate staking rewards. -:::info - -**Example** - -- User stake 1500 ASTR on **dApp A** and 1000 ASTR on **dApp B** during the `Voting`subperiod. -- During the `Build&Earn` subperiod, user move 500 ASTR from **dApp B** to **dApp A**; -- He now has 2000 ASTR on **dApp A** and 500 ASTR on **dApp B**, so he's still eligible for the `Bonus reward` for **dApp A** but no longer for **dApp B** because the tokens staked on **dApp** B are less than those staked at the end of the `Voting` subperiod (500 < 1000 ASTR). -- To be eligible for the `Bonus reward` for **dApp B**, the user must stake an additional 500 ASTR on **dApp B** to reach 1000 ASTR. - -::: - -Bonus rewards for a period can only be claimed after the period finishes. +Tokenomics 3.0 note: there are **no user-facing bonus rewards**. Staker rewards are earned only during **Build&Earn**. ### Other: - You need to keep a minimum of 10 ASTR or 5 SDN tokens as transferable after staking. - **You need to claim to receive your rewards, we recommend claiming your staking rewards once a week.** -- When unlocking tokens, there is a unlocking period on Astar and on Shiden. The unlocking period lenghts can be consulted [here] (/docs/about/products/dapp-staking/#parameters). **LINK TO UPDATE** +- When unlocking tokens, there is a unlocking period on Astar and on Shiden. The unlocking period lengths can be consulted [here](/docs/learn/dapp-staking/#parameters). Please note that this is based on a perfect block production of 12s. In case of any delay, your unlocking period can be a little longer. In case you have any questions, please check the [FAQ page](/docs/learn/dapp-staking/dapp-staking-faq.md) in the Learn section or join our [Discord channel](https://discord.com/invite/astarnetwork). @@ -76,4 +65,3 @@ import DocCardList from '@theme/DocCardList'; import {useCurrentSidebarCategory} from '@docusaurus/theme-common'; - diff --git a/docs/use/how-to-guides/layer-1/dapp-staking/for-stakers/manage-dApp-Staking.md b/docs/use/how-to-guides/layer-1/dapp-staking/for-stakers/manage-dApp-Staking.md index 937c3f989f3..a90fb03d468 100644 --- a/docs/use/how-to-guides/layer-1/dapp-staking/for-stakers/manage-dApp-Staking.md +++ b/docs/use/how-to-guides/layer-1/dapp-staking/for-stakers/manage-dApp-Staking.md @@ -16,9 +16,8 @@ My Staking Panel is where you track your staking and locked tokens, see your pen - **Unlock (↑):** Unlock your locked tokens _(subject to [unlocking parameters](/docs/use/how-to-guides/layer-1/dapp-staking/for-stakers/unstaking.md#overview)_); - **Stake (↓):** Stake your locked tokens in dApp Staking; - **Staked amount**: Total amount of tokens you have staked; -- **Rewards**: Total of the estimated Basic and Bonus rewards; - - **Available**: Basic estimated rewards earned during the **Build&Earn subperiod**; - - **Bonus:** Bonus estimated rewards earned during the **Vote subperiod** if eligible; +- **Rewards**: Total of your estimated staking rewards; + - **Available**: Estimated rewards earned during the **Build&Earn subperiod**;
@@ -46,7 +45,6 @@ You can manage your rewards from the dApp Staking page and collect them by click My dApps Panel is where you can see all dApps you have staked with and manage your stake. -- **Bonus:** if you are eligible for the [Bonus](/docs/use/how-to-guides/layer-1/dapp-staking/for-stakers/index.md#bonus-staking-rewards) on this dApps; - **Move (→) :** you can move staked tokens between different dApps; - **Add (↓) :** you can add more tokens in dApp staking on the desired dApp; - **Unlock (↑) :** you can select how many tokens you want to unlock from your staked amount. @@ -58,8 +56,8 @@ My dApps Panel is where you can see all dApps you have staked with and manage yo The unlocking panel is where you can see the progress of unlocking and withdrawing. For the runtime logic, when unlocking, you don’t unlock from a specific dApp but unlock as `Chunks`. First pending unlocking gives Chunk 1, second pending unlocking gives Chunk 2 etc. -After you have unstaked and when those ERAs pass, you will be able to withdraw. More information about [Unlocking](/docs/use/how-to-guides/layer-1/dapp-staking/for-stakers/unstaking/). -The unlocking period lenghts can be consulted [here](/docs/learn/dapp-staking/#parameters). +After you have unstaked and when those ERAs pass, you will be able to withdraw. More information about [Unlocking](/docs/use/how-to-guides/layer-1/dapp-staking/for-stakers/unstaking.md#overview). +The unlocking period lengths can be consulted [here](/docs/learn/dapp-staking/#parameters). - **Remaining days:** The number of days or `Eras` you have to wait before you can withdraw your tokens; - **Available to withdraw:** Unlock your tokens and make them `transferable`; diff --git a/docs/use/how-to-guides/layer-1/dapp-staking/for-stakers/move-staked-tokens/move-staking.md b/docs/use/how-to-guides/layer-1/dapp-staking/for-stakers/move-staked-tokens/move-staking.md index 32c98401e7a..25d7a30d2e9 100644 --- a/docs/use/how-to-guides/layer-1/dapp-staking/for-stakers/move-staked-tokens/move-staking.md +++ b/docs/use/how-to-guides/layer-1/dapp-staking/for-stakers/move-staked-tokens/move-staking.md @@ -11,57 +11,41 @@ import Figure from '/src/components/figure'
-The **Move** function in Astar dApp Staking lets **you transfer your already staked ASTR tokens from one dApp to another, without losing your bonus**, as long as you stay within your allowed move limits. +The **Move** function in Astar dApp Staking lets you transfer your already staked ASTR tokens from one dApp to another. -- You start each staking **cycle** (about 122 days) with a set number of **safe moves** you can perform during the **Build & Earn** subperiod: - - **Current cycle**: up to 2 safe moves - - **Next cycles**: up to 2 safe moves -- During the **Voting** subperiod, you can move your stake **freely and unlimitedly**, with **no effect on your bonus**. -- If you move to a **registered dApp** during Build & Earn and use up all your safe moves, any extra moves will **forfeit your bonus** on that stake. +In practice, a `move` is an **unstake → stake** sequence, so it can affect when your updated stake becomes reward-eligible. -:::info Staking rewards during Move - -When you perform a `move`, it involves an **unstake** followed by a **stake** call. That means your tokens are considered **unstaked** during that era. As a result, **you won’t earn staking rewards for that specific era**. +- You can use **Move** during both the **Voting** and **Build & Earn** subperiods. +- If you Move during **Build & Earn**, your tokens are considered **unstaked** for that era (see below), so you won't earn staking rewards for that specific era. +- The moved stake becomes effective from the **next era** (same as a normal stake update). +- Moving stake away from **unregistered** dApps is allowed. -::: -:::info Moving from unregistered dApps +:::info Staking rewards during Move -When moving stake from **unregistered contracts**, the **bonus status is always preserved**, and it **does not count** toward your Safe Moves Remaining. +When you perform a `move`, it involves an **unstake** followed by a **stake** call. That means your tokens are considered **unstaked** during that era. As a result, **you won't earn staking rewards for that specific era**. ::: ## 2. Why Move matters for you -**Move** empowers you to switch your staking support from one dApp to another without penalty, whether you're reallocating support, pursuing top-performing projects, or executing real-time arbitrage, just be mindful of your safe-move limit to protect your bonus rewards, as all staking rules still apply. +**Move** empowers you to switch your staking support from one dApp to another without waiting for an unlocking period. It's useful for reallocating support as the ecosystem changes. -In simple terms, the advantages of `move` are: +### 2.1. When can you use Move? -- **You’re not locked in:** If Project A is underperforming and Project B looks promising, **you can redirect your tokens** seamlessly. -- **Your bonus stays safe:** As long as you stay within your *safe-move* allowance. -- **Freedom to react:** Dynamics in the dApp ecosystem change fast. Move gives you flexibility without downside. - -### 2.1. When is Move yours to use? - -| Timeframe | Moves allowed | Bonus effect | +| Timeframe | Moves allowed | Reward note | | --- | --- | --- | -| **Voting period** | Unlimited free moves | No effect on bonus | -| **Build & Earn** | Up to 2 safe moves in each period. | First 2 moves: safe, Third: you lose the bonus. | - -### 2.2. Before Move: What to know - -- Each stake tracks **Safe Moves Remaining,** start with 2 safe moves each cycle. -- **Moving to a registered dApp** during Build & Earn uses up 1 safe move. -- If safe moves hit zero and you move again → ⚠️ **bonus is lost**. +| **Voting subperiod** | Available | No staking rewards are generated during Voting | +| **Build & Earn** | Available | A move causes a 1-era reward gap for the moved amount | -:::info Reward gap +### 2.2. Before you Move: What to know -Since `move` triggers an **unstake → stake** sequence, your tokens are not **staked** for that era. **This means you won’t receive staking rewards during the era in which the Move was made**. - -::: +- You may need to **claim pending rewards** before making staking changes (depending on the interface and runtime rules). +- Keep some ASTR available for **gas**. +- Plan around the **reward gap**: a Move during **Build & Earn** means no staking rewards for that era for the moved amount. ### 2.3 Conclusion -The **Move operation** gives you flexibility to adjust your strategy during the Build & Earn period **without losing bonus rewards**. It helps you maximize rewards and diversify your staking across multiple dApps. +Move gives you flexibility to adjust your staking allocations without unlocking funds, but it's best used intentionally due to the 1-era reward gap during **Build & Earn**. ## 3. Step-by-step: How to use Move @@ -102,39 +86,29 @@ After confirmation: - Original stake is unstaked - New stake shows up under target dApp -- Bonus eligibility updated accordingly +- Your staking positions update accordingly
## 4. Real-use examples for clarity -1. **One safe move left**: You move 100 ASTR from App A to B during Build & Earn - - * App B shows your 100 ASTR and **SafeMovesRemaining = 0** - * Bonus remains intact. - -2. **Second move = bonus lost**: You move again to App C - - * App C shows your 100 ASTR but **bonus forfeited**. - -3. **Voting period, unlimited moves**: Move anytime freely; safe-move count doesn't change. -4. **Reward gap after move**: You Move 500 ASTR from App A to App B during Build & Earn - - * App B shows 500 ASTR and updated safe move count - * ⚠️ You won’t earn staking rewards for that era due to the **unstake/stake** process. +1. **Move during Build & Earn (reward gap)**: You Move 500 ASTR from App A to App B during Build & Earn + * Your stake appears under App B + * ⚠️ You won't earn staking rewards for that moved amount in the era where the Move was made -5. **A combining bonus moves across stakes**: +2. **Move during Voting**: You rearrange stakes during Voting + * Voting does not generate staking rewards + * Your new allocations are set up for the upcoming Build & Earn - * You staked on dApps A and B during Voting - * You unstake part of your tokens from A during Build & Earn, leaving 1 safe move - * You move the remaining stake from A to B - * The new number of safe moves at B becomes: ((A's remaining moves - 1) + B's remaining moves) / 2 +3. **Move away from an unregistered dApp**: + * Moving stake away from an unregistered dApp is allowed + * You can reallocate to an active registered dApp ### 4.1 Pro tips -1. **Always stake during Voting** to secure bonus eligibility early. You can move it later if new dApps join. -2. **Use "Move" instead of "Unstake"** when shifting tokens between dApps, this helps preserve your bonus status. Particularly for unregistered dApps! -3. **Spread your stake across multiple dApps** during Voting. This gives you flexibility to move between them and keep your bonuses. +1. **Avoid frequent moves mid-epoch**: each Move during Build & Earn creates a reward gap for that era. +2. **Claim regularly** to reduce the chance of being blocked by pending rewards. +3. **Keep extra ASTR for gas** so you can claim and manage stakes when needed. ## 5. Video tutorial diff --git a/docs/use/how-to-guides/layer-1/dapp-staking/for-stakers/staking.md b/docs/use/how-to-guides/layer-1/dapp-staking/for-stakers/staking.md index aa9a754757f..f5ef380f4cc 100644 --- a/docs/use/how-to-guides/layer-1/dapp-staking/for-stakers/staking.md +++ b/docs/use/how-to-guides/layer-1/dapp-staking/for-stakers/staking.md @@ -40,6 +40,8 @@ We’ll now walk through the full transfer process step by step. Before using dApp Staking, make sure you understand all the parameters described [**here**](/docs/learn/dapp-staking/#parameters). +At the protocol level, at most **16 dApps are reward-eligible per era** (across tiers). + An address can only stake on a maximum of 16 contracts (dApps). ::: @@ -80,7 +82,7 @@ There, you’ll see a panel with all the staking information: current period, AP
-You can start staking either by clicking the blue **“Choose dApps”** button or by scrolling down to view all the listed dApps. +You can start staking either by clicking the blue **"Choose dApps"** button or by scrolling down to view all the listed dApps.
@@ -98,7 +100,7 @@ You can choose up to 16 projects that you would like to support. ::: -Go back to the previous screen and click on **“Choose dApp”.** +Go back to the previous screen and click on **"Choose dApp".**
diff --git a/docs/use/how-to-guides/layer-1/dapp-staking/for-stakers/unstaking.md b/docs/use/how-to-guides/layer-1/dapp-staking/for-stakers/unstaking.md index ed5c235955d..58e3394b5ae 100644 --- a/docs/use/how-to-guides/layer-1/dapp-staking/for-stakers/unstaking.md +++ b/docs/use/how-to-guides/layer-1/dapp-staking/for-stakers/unstaking.md @@ -35,7 +35,6 @@ If you have staked on one of the dApp(s), you can now click on `Unlock` from **M :::tip If you `unstake` some of your tokens from a dApp and your remaining tokens are below the minimum staking amount for a dApp, all your tokens will be unstaked from that dApp; -If you `unstake` your tokens from one dApp during the Build&Earn subperiod and your staked tokens on this dApp are less than your staked tokens at the end of the Voting subperiod for the same dApp, you will no longer be eligible for the Bonus Rewards for that dApp; ::: diff --git a/docs/use/how-to-guides/layer-1/dapp-staking/index.md b/docs/use/how-to-guides/layer-1/dapp-staking/index.md index 09473f4b9b8..c108c53a211 100644 --- a/docs/use/how-to-guides/layer-1/dapp-staking/index.md +++ b/docs/use/how-to-guides/layer-1/dapp-staking/index.md @@ -10,6 +10,8 @@ dApp staking on Astar and Shiden Network introduces a novel approach, empowering For every block produced on the network, a segment of inflation is specifically allocated to dApp staking. These rewards are then divided between the dApp developers and stakers involved, offering benefits to both developers and stakers. +Rewards for stakers and developers are generated during the **Build&Earn** phase of dApp staking; the **Voting** phase does not generate staking rewards (Tokenomics 3.0 has no user-facing bonus rewards). + As a dApp gains popularity and attracts more stakers, the developers stand to receive a greater share of block rewards. Importantly, the dApp staking program is inclusive, accommodating projects utilizing EVM and Wasm technologies. For a more detailed explanation of dApp Staking, refer to the comprehensive presentation in the [About Astar section](/docs/learn/dapp-staking/index.md).