AIP-1: Proposal to Distribute Voting Rewards based on Staking

Subspace Foundation Autonomys Improvement Proposals
1

AIP-[1]: [Vote Staking for Voting Reward Distribution]

Author

Jianming Liu (@jianmliu)

Status

Draft

Created

2025-12-03

Summary

This proposal introduces Voting Staking, an enhancement to the current block reward distribution model. Today, block rewards are distributed between block proposers and voters, with voting rewards allocated equally among all eligible voters. This proposal adds an optional staking mechanism that allows voters to stake tokens to receive rewards proportional to their staking amount, rather than equally.

This mechanism:

  • Does not require mandatory pre-staking.
  • Preserves storage capacity as the primary eligibility factor.
  • Adds staking as a secondary, optional dimension to optimize voter rewards.

Motivation

Currently, farmers optimize a single dimension for earning rewards: increasing storage capacity. Voting rewards are distributed equally among all voters, regardless of the level of economic commitment.

This AIP introduces a second, optional dimension: staking. Miners can now improve their voting reward share by staking tokens, creating a dual-axis optimization model:

Farmer Reward = f(Storage Capacity, Staking Amount)

This design introduces a natural economic balance between hardware investment and token staking, while maintaining low entry barriers because staking is not mandatory.

Specification

1. Voting Staking Mechanism

A new staking module SHALL be added to:

  • Accept deposits of the voting token.
  • Track per-account stake balances.
  • Provide effective voting weights used for reward distribution.

2. Eligibility

A farmer must first qualify for voting rewards based on storage capacity or other protocol-defined participation criteria. Only eligible voters may receive rewards.

3. Reward Distribution Logic

Voting rewards are computed in the runtime through FindVotingRewardAddresses.

At each reward event:

  1. The system retrieves a list of (voter, weight) pairs.

  2. Voters where weight == 0 are excluded.

  3. Let W = Σ weight_i.

  4. For each voter except the last:

    reward_i = floor(weight_i * reward_pool / W)

  5. The last voter receives the remainder to ensure:

    Σ reward_i = reward_pool

Weight Source and Constraints

  • Weight is determined by the VotingStakeProvider (i.e., pallet_voting_stake).

  • Raw stake is mapped to effective weight with:

    • Minimum stake threshold: below this threshold → weight = 0.
    • Maximum stake cap: above this cap → weight = MAX.

Resulting weight:

weight(user) =
  0                           if stake < MIN_VOTING_BALANCE
  MIN(stake, MAX_VOTING_BALANCE)   otherwise

4. Unstaking

  • Unstaking SHALL be allowed at any time.
  • No penalties SHALL be applied.
  • Rewards will be automatically and directly distributed; no manual reward claiming is required.

Rationale

Farming economics shift from a single-dimensional capacity race to a two-dimensional equilibrium between capacity contribution and staking contribution.

Benefits

  • Encourages long-term alignment.
  • Provides fairer reward distribution.
  • Avoids forced staking requirements.
  • Maintains accessibility: farmers may rely entirely on hardware.
  • Allows differentiation between high-capacity farmers and high-stake farmers.

Considerations

Potential Challenges

  • Staking concentration: large operators may accumulate excessive stake.
  • Small farmer disadvantage: proportional rewards may favor larger stakers.
  • Transition complexity: shifting from equal to proportional distribution.

Non-Mandatory Staking

  • Staking is optional for farmers.
  • No farmer is required to stake tokens to participate.
  • Storage capacity remains the foundation of participation.

Open Questions for Community Feedback

  1. Should there be a maximum multiplier or soft cap to reduce dominance?
  2. Should a minimum stake threshold be required?
  3. Should optional long-term lock-ups receive higher weighting?
  4. Should capacity influence reward weight, not just eligibility?

Backward Compatibility

  • No changes to farming or reward mechanics outside staking distribution.
  • Hard fork is required.
  • Staking is optional; existing voters remain unaffected.

Reference Implementation

The proposal is implemented through the Voting Pallet, added in commit:

https://github.com/jianmliu/subspace/commit/02ea92b6e6074604ca0c8896552dff4ac11fb914

Voting Pallet

The pallet provides:

  • storage of staking balances,
  • minimum/maximum effective weight enforcement,
  • stake/unstake extrinsics,
  • implementation of VotingStakeProvider,
  • integration with reward distribution through FindVotingRewardAddresses.

Runtime Integration

  • pallet_voting_stake implements VotingStakeProvider.
  • FindVotingRewardAddresses supplies (voter, weight).
  • pallet-rewards distributes rewards proportionally as described.

Security Considerations

  • The staking pallet MUST be audited.
  • Staked funds MUST remain withdrawable.
  • Flash-staking MUST be prevented (minimum duration ≥ 1 block recommended).
  • Reward logic MUST be resistant to manipulation.
2

本提案引入了 投票质押（Voting Staking），作为对现有区块奖励分配模型的增强。目前，区块奖励会在区块提议者（block proposers）和投票者之间分配，其中投票奖励会在所有符合条件的投票者之间平均分配。本提案新增一种可选机制，允许投票者质押代币，并根据其质押数量按比例获取奖励，而不是继续沿用平均分配的方式。

3

What a wonderfully structured AIP submission - thank you for putting this together.

I’ve got some questions and concerns after an initial read-through:

Clarifications on scope and mechanics

Scope: is this only about voting rewards?

The Summary and Backward Compatibility sections suggest that only the distribution of voting rewards among eligible voters is changing, and that farming/proposer rewards and eligibility logic remain unchanged.

  • Can you confirm that block rewards are still distributed relative to storage capacity alone?

Reads more broadly than other descriptions of the specification, so I want to be sure this is not implying a deeper change to overall farmer economics.

Cap and Sybil splitting across farmers

The spec defines effective weight as a capped function of stake:

  • How do you see this interacting with a very large token holder who can simply spread stake across many farmer accounts (or many nodes they control), each up to MAX_VOTING_BALANCE?
  • In practice that seems to bypass the cap and still allows a single economic actor to dominate, just via more identities. Is there a mitigation in mind beyond “soft cap per account”?

Code readiness and deployment risk

Thanks for linking the reference implementation in the AIP.

  • What level of testing has this pallet and its runtime integration seen so far?
    • Unit tests only?
    • Property/fuzz tests?
    • Integration tests on a devnet or staging network with real reward flows?
  • Would you consider it “audit-ready” in its current state, or do you expect further refactors before it’s stable enough for a formal security review? Given that this requires a hard fork and directly touches reward logic, I’m particularly interested in the rollout plan and how we minimise the implementation risk side of this change.

“Reward logic MUST be resistant to manipulation”

The Security Considerations section feels very expansive.

  • What specific manipulation vectors have you modelled and what are the intended mitigations?
    • Sybil splitting of stake across many controlled farmers.
    • Timing games around reward events (e.g. stake just before snapshot, unstake immediately after).
    • Collusion between large stakers and infrastructure operators.
  • The AIP mentions “minimum duration ≥ 1 block recommended” to prevent flash-staking. One block feels extremely short for preventing practical timing games. Have you considered a longer minimum stake duration or a warm-up period before stake becomes active for rewards?

Higher-level concerns

More generally, I have a few concerns about the broader impact:

Barrier to entry and decentralisation

While staking is formally optional, in practice this design shifts from a one-dimensional “capacity only” reward landscape to a two-dimensional one where farmers without stake are structurally disadvantaged in the voting reward pool.

Over time, that likely reduces the effective ROI for small, hardware-only farmers, especially in competitive environments.

Have you considered how this affects:

  • Payback time for new small farmers without significant token holdings?
  • The geographic and farmer diversity of the network if rewards concentrate around staked capital?
  • The above in the broader context of the token unlock schedule?

“Rich get richer” dynamics

The AIP itself notes the risks of staking concentration and small farmer disadvantage.

  • Do you have any preliminary modelling (even rough simulations) showing:
    • How reward share evolves for small vs large participants under reasonable assumptions for MIN_VOTING_BALANCE and MAX_VOTING_BALANCE?
    • Under what parameter ranges this becomes effectively “pay-to-win” for large stakers, versus a modest optimisation layer? It would be helpful to see scenarios where this proposal clearly doesn’t just accelerate wealth concentration, and what constraints on parameters are necessary to stay in that safer regime.

Need for an economic impact study

I strongly feel this proposal needs a more formal economic analysis before being adopted. For example:

  • Impact on:
    • Farmer churn (who is likely to exit if their relative share drops).
    • Incentives to run many small nodes vs fewer large ones.
    • Token liquidity elsewhere in the ecosystem (e.g. if staking for voting rewards competes with other uses of the token).
  • Sensitivity to parameter choices (min stake, cap, potential multipliers, lock-up bonuses, etc.) Right now the AIP is technically clear but economically under-specified.

Terminology and conceptual clarity

The term “voting” is already overloaded in crypto (runtime consensus vs governance vs off-chain signalling). This AIP concerns block production voting rewards, not governance voting, but that may not be obvious to many community members.

It might be worth explicitly clarifying that distinction and ensuring documentation clearly separates “voting for blocks” from “governance voting” so users don’t conflate the two when they see “Voting Staking”.

Cultural alignment with “free and fair blockchain for all”

Finally, while not a strictly technical point, I have a concern about the cultural and philosophical direction. The Autonomys/Subspace vision has consistently emphasised a “free and fair blockchain for all,” with low hardware requirements and minimal capital barriers as a differentiator from classic PoS systems.

Introducing a mechanism where capital stake becomes a key lever for optimising rewards feels like a significant shift in that paradigm, even if staking is technically optional.

I think this tension needs to be addressed explicitly in the AIP:

  • What safeguards or design constraints will preserve the accessibility and fairness ethos in practice, not just in principle?

Weighing potential benefits against risks

To be clear: I see real potential value in aligning long-term incentives via optional staking, but I don’t think the concerns above are invalid. They seem directly aligned with the “Potential Challenges” you’ve already highlighted, and mostly come down to:

  • The concrete parameterisation (min/max, any multipliers, lock-up options).
  • The quality of security & economic modelling.
  • Clear communication about what is and isn’t changing.

If you can share more detail on the threat model, test status, and any preliminary economic scenarios you’ve considered, that would go a long way toward helping me (and likely others) evaluate the trade-offs here.

I’m looking forward to your answers and to seeing the open questions receive feedback from the wider community.

4

Vote block rewards distribution becomes two-stage process instead of one:
1, to be eligible as voter, it is based storage capacity. The more storage, the more chance being selected
2, after being selected as voter, staking weight will decide how much rewards.
The more storage, the more vote rewards. The more staking, the more vote rewards. Block proposer rewards is not related to staking, but still storage capacity only.

The current equal distribution of vote rewards is simplified case of the new design, i.e. no one stake, or everyone stakes the same amount

There are many parameters to be tuned, including min_stake, and max_stake. This can be adjusted based on governance. min_stake=max_stake=0 will be current no-stake design.

The current implementation is only PoC purpose, and will need testnet first.

Stake across many farmers is always there, should be considered when setting up the parameters

It’s not based on snapshot, but dynamic vote reward distribution for each block

Pool might be concern, i.e. many farmers set the same address with huge stake

There is not much attack around stake/unstake to game the system, since it is based on per-block vote rewards.

5

To answer the high level concerns:
The motivation is to build hybrid system of both PoW and PoS
The hodler will get more incentivized. Which one do we prefer: a big whale farmer who sells all its rewards, or smaller farmers who farm and hold their rewards. We don’t consider the scenario that the big whale farmers also hold their rewards, because there is no reason to discourage them to do so, right? The design is to make sure our holder gets richer. The whale farmers who farm and sell are not ideal for small farmers either.

Small farmers can’t afford to lots of hardware, but they could choose farm and hold to get more rewards. A small farmer can’t survive when they compete with professional whale farmers today.

The utility of our tokens are not strong enough, and this proposal is to incentivize holders. Our current PoAS is very similar to PoW, which is very capital intensive in practice (like BTC mining). The setting of min and max staking will give us flexibility to trade off all the concerns, i.e. we can turn it off through setting parameters based on governance decisions.

1 Like
6

I do have prototype simulation setup as below:

n_farmers = 100

total_capacity = 1000.0

MIN_BALANCE = 0.0

max_values = [100.0, 300.0, 600.0]

Figure_1
Figure_1640×480 32.9 KB

Figure_3
Figure_3640×480 25.2 KB

Figure_2
Figure_2640×480 24.3 KB

7

I am strongly against this proposal. Storage rewards are for the storage providers. Stakers make tokens from staking. Simple. It is decentralized and fair. Why should a rich farmer get paid more per Terabyte than a poor farmer? This proposal would make the richer farmers richer, and the poorer farmers poorer. This will bring mining pools which are currently not needed.

1 Like
8

Good idea。。。。。。。。。。。。。。。。。。。

9

There is already a pledge node (operator) that does not require farmland, but when introducing another farmland pledge, where will the focus be on? Besides, can pledging generate profits and give more people confidence to join? Because regardless, its total revenue only exists in a constant proportion of daily output. Without subsidies. The profit from operator staking is basically zero (the profit only comes from XDM cross chain bridge). Where does the revenue from the newly launched farmland pledge come from? Depriving agricultural miners of their normal mining profits?

10

I will make a deduction: the AI3 reward that can be used now, which is 60 million - 5 million - 7 million in the national treasury, can be used to promote 48 million. So are other ecosystems not supported? Only supporting pledges? If paid from Nissan mining. So farmers’ income will inevitably decrease. Do you think our farmers will still support it?

11

The system MAY be extended in the future to support delegated vote staking, where:

  • Any user (delegator) can stake their voting tokens to a target farmer address.

  • The effective voting weight of that farmer is increased by the sum of delegated stake.

  • Rewards allocated to that farmer (from voting rewards) can then be shared with delegators according to on-chain revenue-sharing pallet.

This is conceptually similar to Autonomys’ current delegation model for domain operators, where users delegate stake to an operator and share fee revenue. For the initial version of this AIP:

  • Delegation is NOT required.

  • All stake is assumed to be self-stake.

  • The design intentionally leaves the delegation mechanism as a future extension to avoid over-complicating the initial rollout.

12

I have seen this type of pledge model before. Similar to: My token can be pledged to myself. It can also be pledged to someone else’s farmland. Allocate different rewards based on the size of the farmland. Divide the cake between farmland and pledgers. However, the fundamental problem is that there are no more items available for distribution to farmers or pledgers. The cake has already been divided. Where will the extra rewards come from?

13

The current staking rewards only come from the profits of XDM Crossbridge. Or in other words, the additional 5 million incentive reward now. Expenditure from the national treasury. Because of the staking reward itself. Basically equal to 0. The cake has already been divided. There is no additional expenditure or plan. Used to support pledging.

There are only three situations to obtain additional staking rewards (POS) now: 1. Transfer of 48 million li from the national treasury. 2: Increase the issuance of AI3 by more than 1 billion, for example, to 1.2 billion. 3: Reduce agricultural output (pow) output. Which one do you think is the most feasible?

14

There are two other ways to obtain additional AI3, but I think there is basically no possibility of implementation. one The project party uses U to repurchase AI3 in the secondary market. 2 . The project team took out those accounts with lock periods. Allocate a portion of the tokens for use.