Following our previous post on the Tokenomics 3.0 & dApp Staking Revamp direction, we are sharing the technical implementation overview today. Please review the post and feel free to ask questions or request clarification under this post.
Overview
This post follows up on the Tokenomics 3.0 Update & dApp Staking Model Revision proposal with the technical details.
The first post outlined the strategic direction: lower inflation, simpler staking, and a focus on fewer high-impact projects. This post explains how we’re implementing those changes - specifically the new dApp Staking parameters, tier structure, staking thresholds, and expected rewards.
What We’re Changing and Why
The Problem with the Current Model
Today, dApp Staking has ~72 registered projects across four tiers. This creates several issues:
- Rewards are spread thin across too many projects
- Inactive or low-impact projects can extract value without meaningful contribution
- The tier system confuses users about reward disparities
- The period structure (Voting + Build & Earn) requires restaking three times per year
The New Model at a Glance
The revised dApp Staking model addresses these issues:
- 16 projects maximum instead of ~72
- 2 active tiers instead of 4
- Higher thresholds to ensure only impactful projects qualify
- Yearly cycle instead of three periods per year
- Simplified UI that hides tier complexity while maintaining backend logic
Implementation Approach
Parameter-Based Change, Not a Rewrite
Rather than rebuilding dApp Staking from scratch, we’re achieving the new model by adjusting existing parameters in the current codebase. This approach:
- Minimizes breaking changes and audit requirements
- Keeps development work focused on Portal UI updates
- Allows faster delivery through governance referendum
- Reduces risk compared to a full system rewrite
What Changes Technically
Program size cap. The max_registered_apps parameter is reduced from 500 to 16, hard-capping the number of projects that can enter dApp Staking.
Fixed slot allocation. The slotNumberArgs parameter changes from [1000, 50] (dynamic calculation) to [0, 16] (fixed). This switches slot allocation from a dynamic formula to a fixed 16 slots.
Cycle alignment. dApp Staking moves to a yearly cycle aligned with the annual inflation recalculation. This is a constraint of how the inflation system works - it recalculates once per year, so dApp Staking positions reset at that point.
Tier configuration. We’re reconfiguring tier parameters to effectively use only two tiers (Tier 2 and Tier 3), with Tier 1 and Tier 4 set to zero allocation.
UI simplification. The Portal will display a cleaner list view without tier labels, while keeping detailed tier and reward information on individual dApp pages.
The New Tier Structure
Why Two Tiers Instead of Four
The current four-tier system creates confusion. Users see different reward levels across tiers but don’t always understand why. Projects compete for tier placement in ways that don’t always reflect actual contribution.
The new model simplifies this to two meaningful tiers:
- Tier 2 for top-performing projects with strong community support
- Tier 3 for qualifying projects that meet the baseline threshold
Tier 1 and Tier 4 remain in the code (for technical reasons) but are set to 0% allocation - they’re effectively inactive.
Slot Distribution
| Tier | Slots | Purpose |
|---|---|---|
| Tier 1 | 0 | Inactive |
| Tier 2 | 6 | Top projects with highest staking support |
| Tier 3 | 10 | Qualifying projects meeting baseline threshold |
| Tier 4 | 0 | Inactive |
Total: 16 slots
This distribution reflects the intent: a small group of leading projects (Tier 2) receiving the majority of rewards, with a broader base of qualifying projects (Tier 3) receiving meaningful but smaller allocations.
Reward Pool Distribution
| Tier | % of dApp Reward Pool |
|---|---|
| Tier 2 | 70% |
| Tier 3 | 30% |
Tier 2 projects share 70% of the total dApp reward allocation. Tier 3 projects share the remaining 30%. This concentrates rewards on projects with the strongest community backing.
Within-Tier Reward Distribution
Rewards within each tier are distributed using a weight-based system controlled by a rank multiplier:
| Tier | Rank Multiplier | What It Means |
|---|---|---|
| Tier 2 | 240% | Rank 10 earns 2.4x what Rank 0 earns |
| Tier 3 | 467% | Rank 10 earns 4.67x what Rank 0 earns |
The multiplier determines the spread between top and bottom performers within each tier. A higher multiplier (like Tier 3’s 467%) creates more differentiation based on staking support.
Staking Thresholds
How Thresholds Work
To qualify for a tier, a dApp must have at least the threshold amount of ASTR staked to it. Thresholds are defined as a percentage of total issuance, so they adjust automatically as issuance changes over time.
Current Threshold Values
Based on total issuance of 8,627,106,523 ASTR:
| Tier | Threshold (ASTR) | % of Total Issuance | What It Means |
|---|---|---|---|
| Tier 1 | 200M+ | ~2.32% | No dApp rewards (stakers still earn) |
| Tier 2 | 80M+ | ~0.93% | Projects need 80M-200M ASTR staked |
| Tier 3 | 30M+ | ~0.35% | Projects need 30M-80M ASTR staked |
| Below Tier 3 | <30M | <0.35% | No dApp rewards (stakers still earn) |
Why These Thresholds Are High
These thresholds are intentionally set high. The goal is to ensure that only projects the ecosystem genuinely wants to support can qualify. Reaching 30M ASTR (Tier 3 minimum) or 80M ASTR (Tier 2 minimum) requires significant community conviction.
This design filters for:
- Core infrastructure projects
- Key ecosystem applications
- Projects with demonstrated community support
Projects that cannot attract meaningful staking support do not receive dApp rewards. This is the “quality over volume” principle in practice.
Additionally, reducing from 72 to 16 dApps will concentrate ASTR staking across a smaller number of applications. Given that 1B> ASTR is currently locked in dApp Staking, this would result in an average staking allocation of 62.5M ASTR per dApp, which is double the minimum threshold for Tier 3.
Expected Rewards Per Project
Tier 2 Projects (6 slots)
- Threshold band: 80M - 200M ASTR
- Expected reward range: ~$3,500 - $8,000 per month (at $0.01/ASTR)
The exact reward depends on rank within the tier. A project at the top of Tier 2 (close to 200M ASTR staked) earns toward the higher end. A project just above the 80M threshold earns toward the lower end.
Tier 3 Projects (10 slots)
- Threshold band: 30M - 80M ASTR
- Expected reward range: ~$500 - $2,500 per month (at $0.01/ASTR)
Same principle: more staked ASTR means higher rank and higher rewards within the tier.
Important Notes on Reward Estimates
- These ranges assume $0.01/ASTR. Actual USD value varies with token price.
- Rewards are paid in ASTR, not USD.
How Rank-Based Rewards Work
Understanding the reward calculation helps projects and stakers know what to expect.
Step 1: Tier Qualification
A dApp qualifies for a tier when its total staked amount crosses the tier threshold, provided that available slots exist within that tier:
- 30M+ ASTR → Tier 3
- 80M+ ASTR → Tier 2
Step 2: Rank Determination
Within each tier, projects are ranked based on their staked amount. The system uses 11 ranks per tier.
The ranking formula:
rank_divisor = (upper_threshold - lower_threshold) / 10 rank = (stake_amount - lower_threshold) / rank_divisor
For example, in Tier 3 (30M to 80M range):
- A project with 30M ASTR staked = Rank 0 (lowest)
- A project with 55M ASTR staked = Rank 5 (middle)
- A project with 80M ASTR staked = Rank 10 (highest, about to enter Tier 2)
Step 3: Weight Calculation
Each dApp receives a weight based on its rank within the tier. The weight starts at 100% for Rank 0 and increases with each rank level.
The increment per rank depends on the tier’s multiplier:
- Tier 2 (240% multiplier): Each rank adds 14% (so Rank 0 = 100%, Rank 5 = 170%, Rank 10 = 240%)
- Tier 3 (467% multiplier): Each rank adds 36.7% (so Rank 0 = 100%, Rank 5 = 283.5%, Rank 10 = 467%)
Higher rank means higher weight, which means a larger share of the tier’s reward pool.
Step 4: Reward Calculation
The tier’s total budget is divided among all qualified dApps based on their weights:
- Add up the weights of all dApps in the tier
- Calculate reward rate = tier budget ÷ total weight
- Each dApp’s reward = their weight × reward rate
This ensures the entire tier budget is distributed proportionally. Projects with more staking support (higher rank) receive a larger share.
App Reward Formula
Full Formula
dApp\_reward = tier\_allocation \cdot \frac{base + rank \cdot \frac{multiplier - base}{10}}{\max(filled\_slots \cdot base + ranks\_sum \cdot \frac{multiplier - base}{10}, \ max\_slots \cdot (base + 5 \cdot \frac{multiplier - base}{10}))}
Where:
- base = 100%
- multiplier = tier rank multiplier (240% for Tier 2, 467% for Tier 3)
- rank = dApp’s rank within the tier (0-10)
- filled_slots = number of dApps currently in the tier
- ranks_sum = sum of all ranks of dApps in the tier
- max_slots = maximum slots for the tier (6 for Tier 2, 10 for Tier 3)
- 5 = average rank (middle of 0-10 range)
Example for Tier 2 (6 dApps, 240% multiplier)
Assume the tier budget is $21,000/month and all 6 slots are filled with dApps at various ranks:
| dApp | Rank | Weight |
|---|---|---|
| Project A | 10 | 240% |
| Project B | 8 | 212% |
| Project C | 6 | 184% |
| Project D | 4 | 156% |
| Project E | 2 | 128% |
| Project F | 0 | 100% |
| Total | 1,020% |
Reward rate = $21,000 ÷ 1,020% = $20.59 per 1%
| dApp | Weight | Reward |
|---|---|---|
| Project A (Rank 10) | 240% | $4,941 |
| Project B (Rank 8) | 212% | $4,365 |
| Project C (Rank 6) | 184% | $3,789 |
| Project D (Rank 4) | 156% | $3,212 |
| Project E (Rank 2) | 128% | $2,636 |
| Project F (Rank 0) | 100% | $2,059 |
The top-ranked project earns 2.4x more than the bottom-ranked project, matching the 240% multiplier.
What Happens to Unfilled Slots
If fewer than 16 projects qualify, the unused allocation is not minted. It doesn’t redistribute to other projects - it simply isn’t created.
Note: Full technical details on reward formulas and edge cases will be available in Astar’s official documentation.
What Happens If a dApp Doesn’t Qualify
If a dApp does not reach the 30M ASTR threshold:
For the dApp: No dApp rewards. The project is still listed but does not receive emissions.
For stakers: No impact on staker rewards. Stakers still earn base + adjustable staking rewards regardless of whether their chosen dApp qualifies for a tier.
This separation is important: staking to a project is never “wasted” from a staker reward perspective, even if the project doesn’t hit tier thresholds.
Portal UI Changes
Main List View (Simplified)
The main dApp Staking page will show:
- All 16 dApps
- Sorted by staked amount (highest first)
- Displayed info: staked amount, staker count, category, project name
Not displayed on main view: Tier labels, dApp reward amounts
This removes the tier comparison that caused confusion. Users see a ranked list of projects by community support.
dApp Detail Page (Full Information)
When viewing an individual project page:
- Current tier and rank
- Estimated dApp rewards
- Staked amount
This keeps detailed information accessible without cluttering the main experience.
Yearly Cycle: What Changes for Users
Current Model (Three Periods Per Year)
Today, dApp Staking runs in cycles with Voting and Build & Earn periods. Users must:
- Restake or re-vote three times per year
- Track bonus periods to maximize rewards
- Perform maintenance actions to avoid missing incentives
New Model (One Cycle Per Year)
Under the new model:
- Stake once per year
- Maintain position until the next yearly inflation recalculation
- No bonus tracking required (bonus allocation is now 0%)
The yearly reset aligns with when the inflation system recalculates. At that point, dApp Staking positions reset and users restake for the new cycle.
Summary of Parameters
| Parameter | Current | New |
|---|---|---|
max_registered_apps |
500 | 16 |
slotNumberArgs |
[1000, 50] (dynamic) | [0, 16] (fixed) |
| dApps listed | ~72 | 16 |
| Active tiers | 4 | 2 |
| Tier 1 slots | 5% (~3) | 0 |
| Tier 2 slots | 20% (~12) | 37.5% (~6) |
| Tier 3 slots | 30% (~18) | 62.5% (~10) |
| Tier 4 slots | 45% (~27) | 0 |
| Tier 1 threshold | ~307M (3.57%) | ~200M (~2.32%) |
| Tier 2 threshold | ~76M (~0.89%) | ~80M ASTR (~0.93%) |
| Tier 3 threshold | ~20M (~0.23%) | ~30M ASTR (~0.35%) |
| Tier 4 threshold | ~1.7M (~0.02%) | 0M (~0%) |
| Tier 1 reward share | 25% | 0% |
| Tier 2 reward share | 47% | 70% |
| Tier 3 reward share | 25% | 30% |
| Tier 4 reward share | 3 | 0% |
| tier_rank_multipliers* | NA | [0, 24_000, 46_700, 0] |
| Restaking frequency | 3x per year | 1x per year |
*Values are expressed in bips, where 10,000 = 100%. The multipliers are [0%, 240%, 467%, 0%]. For clarification: 10,000 (100%) indicates that dApps receive only base rewards with no rank-based multipliers, while 0 indicates no rewards.
Timeline
Assuming referendum cycles commence on Sunday (as anticipated), the following outlines the expected timeline for all governance procedures and the complete activation of Tokenomics 3.0 and the dApp Staking revamp.
Governance Process
Two referendums will be executed:
- Tokenomics parameter updates
- dApp Staking implementation (runtime upgrade)
Referendum 1: Tokenomics Parameters
| Milestone | Date |
|---|---|
| Main Council External Proposal | Saturday, February 21 |
| Voting period | Sunday, February 22 - Sunday, March 1 |
| Enactment | Tuesday, March 3 (2-day delay) |
| Inflation recalculation | Sunday, March 8 |
Referendum 2: dApp Staking Runtime Upgrade
| Milestone | Date |
|---|---|
| Main Council External Proposal | Saturday, February 28 |
| Voting period | Sunday, March 1 - Sunday, March 8 |
| Runtime upgrade | Week of March 9 |
Target go-live: March 9-15
Testnet Rollout
| Network | Timeline |
|---|---|
| Shibuya upgrade | This week (Thursday) |
| Shiden upgrade | Next week |
Questions and Feedback
We welcome questions on:
- Threshold levels and whether they’re appropriate
- Reward distribution between tiers
- The rank-based reward calculation
- UI changes and what information should be visible
- Any other aspect of this implementation
This is a follow-up for community discussion. Final parameters will be confirmed before governance submission.
Gaius_sama 
Astar Foundation