Pull Request Summary

Closes #1585

This PR implements the technical foundation for Tokenomics 3.0 dApp Staking simplification,
as outlined in this forum post.

The goal is a minimal, predictable upgrade that:

• Removes bonus mechanics
• Eliminates reward unpredictability
• Preserves all historical rewards and claim logic
• Reuses existing structures wherever possible

Problem (Current Design)

Rank rewards currently depend on empty_slots:

let remaining_reward = tier_reward * empty_slots;
let reward_per_rank = min(tier_reward / MAX_RANK, remaining_reward / ranks_sum);

This causes:

• Zero rank rewards when tiers are full
• Rewards that depend on ranks_sum
• Unpredictable outcomes based on how many dApps qualify

Design Choice: Rank Multiplier Model

The empty_slots dependency is replaced with a single rank multiplier per tier, producing deterministic rewards.

Core Idea

Each tier defines one value:

“Rank 10 earns X% of the rank-0 reward.”

From this:

• Rank increments are derived linearly
• Rewards scale by rank weight
• Total distribution is capped to prevent overflow

Reward Model (High Level)

increment = (multiplier - 100%) / MAX_RANK
weight = 100% + rank × increment

target_weight = max_slots × avg_weight
denominator = max(actual_weight, target_weight)

reward = weight × (tier_allocation / denominator)

Why This Works

• Predictable: Fixed % per rank when a tier is normally filled
• Overflow-safe: Rank collisions (e.g. all rank 10) are capped
• Permissionless-safe: Partial tiers distribute proportionally
• Simple config: One intuitive parameter per tier

Unfilled slots remain unminted (never redistributed).

Configuration Change

Add a single field to tier parameters:

pub struct TierParameters<NT> {
    // existing fields…

    /// Rank 10 reward as % of rank 0 reward (express in bips)
    pub tier_rank_multipliers: BoundedVec<u32, NT>,
}

Example production values:

• Tier 0: 10_000bips (default, no rank rewards)
• Tier 1: 24_000bips (rank 10 earns 2.4× rank 0)
• Tier 2: 46_700bips (rank 10 earns 4.67× rank 0)
• Tier 3: 0bips (no rewards)

This replaces multiple interacting parameters with one clear control.

What’s Preserved (Intentionally)

• MAX_RANK = 10
• find_rank() logic
• RankedTier encoding
• Claim formula and storage (DAppTierRewards)
• Backward-compatible reward claims (no migration)

Why MaxNumberOfContractsLegacy = 500

Historical reward entries were bounded by 500 contracts.
This is preserved only to allow post-migration claims and can be removed once all legacy rewards are exhausted.

Alternatively we can claim all historical rewards ourselves and start fresh, preserving only the 16 desired dApps, so no need of the MaxNumberOfContractsLegacy config parameter. This is extra operational complexity, maybe unnecessary.

Rollout suggestion:

1. Call to update inflation parameters before current B&E subperiods ends to use new params during the inflation recalculation (expected March 7th).
2. Runtime upgrade during Voting subperiod. The storage migration sets new tiers params and the runtime configs are updated.
3. Monitor first B&E eras for correct tier assignment and reward distribution.

Check list

• added or updated unit tests
• updated Astar official documentation
• rerun benchmark to update weights

Follow up task

• dAppStaking truly stake-and-forget via infinite Build&Earn #1589