diff --git a/proposals/00010-reducing-staking-thresholds.md b/proposals/00010-reducing-staking-thresholds.md new file mode 100644 index 0000000..c9f66a6 --- /dev/null +++ b/proposals/00010-reducing-staking-thresholds.md @@ -0,0 +1,124 @@ +--- +number: '00010' +title: Reducing Staking Thresholds +authors: Jack Chan (jack.chan@piplabs.xyz) +sponsors: Ramtin Seraj (ramtin.seraj@piplabs.xyz) +created: 2026-01-18 +type: Standard +status: Accepted +supersedes: +superseded-by: +extends: +--- + +## Summary + +This proposal reduces staking thresholds by lowering the minimum stake, +unstake, and redelegate amounts from 1024 IP to 32 IP, reducing the minimum +reward claim threshold from 8 IP to 1 IP, and decreasing all staking operation +fees from 1 IP to 0.1 IP. These changes make staking accessible to retail +participants while maintaining spam protection. + +## Motivation + +The current 1024 IP minimum stake represents a significant barrier for retail +investors seeking to participate in network staking. This threshold excludes +many potential participants who would otherwise contribute to network security +and decentralization. + +The 8 IP minimum reward distribution threshold forces smaller stakers to wait +extended periods before seeing rewards in their accounts, creating a poor user +experience. Additionally, the 1 IP staking operation fee disproportionately +impacts smaller stakers — representing over 3% of a minimum stake under the +proposed 32 IP threshold. + +Lowering these thresholds democratizes staking participation, improves user +experience for smaller holders, and encourages broader community engagement +with the network. + +## Proposal + +### Minimum Staking Amount + +| Parameter | Current Value | New Value | +| --- | --- | --- | +| Minimum stake amount | 1024 IP | 32 IP | +| Minimum unstake amount | 1024 IP | 32 IP | +| Minimum redelegate amount | 1024 IP | 32 IP | + +### Minimum Reward Distribution Threshold + +| Parameter | Current Value | New Value | +| --- | --- | --- | +| Auto-reward distribution threshold | 8 IP | 1 IP | + +Rewards will be automatically distributed when accumulated amount reaches 1 IP +or greater. The distribution queue (32 per block) remains unchanged. + +### Staking Operation Fee Changes + +| Operation Name | Function Name | Current Value | New Value | +| --- | --- | --- | --- | +| Set Operator | setOperator | 1 IP | 0.1 IP | +| Unset Operator | unsetOperator | 1 IP | 0.1 IP | +| Set Withdrawal Address | setWithdrawalAddress | 1 IP | 0.1 IP | +| Set Rewards Address | setRewardsAddress | 1 IP | 0.1 IP | +| Update Validator Commission | updateValidatorCommission | 1 IP | 0.1 IP | +| Redelegate | redelegate | 1 IP | 0.1 IP | +| Redelegate On Behalf | redelegateOnBehalf | 1 IP | 0.1 IP | +| Unstake | unstake | 1 IP | 0.1 IP | +| Unstake On Behalf | unstakeOnBehalf | 1 IP | 0.1 IP | +| Unjail | unjail | 1 IP | 0.1 IP | +| Unjail On Behalf | unjailOnBehalf | 1 IP | 0.1 IP | + +### Rationale + +The 32 IP minimum aligns with common proof-of-stake precedents while remaining +economically accessible. The 1 IP reward threshold ensures meaningful, regular +distributions without overwhelming the queue. The 0.1 IP unstaking fee +maintains spam deterrence while being proportionate to smaller stakes (~0.3% +of minimum). + +### Drawbacks + +Lower minimums may increase total delegation and reward distribution count, +leading to faster state growth. However, the 32 IP threshold for staking +amounts and 0.1 IP threshold for staking-related operations still provides +meaningful barrier against spam, and economic costs remain prohibitive for +attackers. + +### Alternatives Considered + +- **Delegator minimum = 1 IP (instead of 32 IP):** Suggested in the forum as + the most inclusive option and closer to typical Cosmos delegator UX. + Rejected for this SIP due to accelerated state-growth and the 32 IP minimum + also needs devnet benchmarking to determine a safe floor before going that + low. +- **Remove the minimum "top-up / additional stake" amount (allow immediate + restaking of rewards):** Proposed to enable continuous compounding for + delegators and validators and improve validator economics. Not included in + this SIP because it is a separate parameter/design change and could increase + operation frequency (which is effectively a spammy behavior); we focus here + on the base minimums and fee/thresholds (see original post at + ) +- **Manual reward claiming at any amount (no forced threshold):** Discussed as + a way to let small delegators claim accumulated rewards below the + auto-distribution threshold via a manual transaction. Rejected due to spam + concerns — adding fees for manual claims would be impractical given the + small amounts involved, yet feeless claiming could be exploited. This SIP + addresses the same UX concern by reducing the auto-distribution threshold to + 1 IP. Note that delegators receive all remaining unclaimed rewards upon + unstaking, so no rewards are forfeited (see post reply at + ) +- **Guardrails instead of a higher minimum (rate limits / dust floor / + batching):** Suggested as mitigations to support lower minimums while + protecting performance (state growth, reward distribution throughput, + latency). Not adopted in this SIP to keep scope limited and because these + require additional implementation/testing (see post reply at + ) + +### User Impact + +Retail participants gain access to staking with lower capital requirements. +Smaller stakers receive more frequent reward distributions and face +proportionally lower fees across all staking operations.