From 336ad3894bfe10294d983a2ed06646e730726a67 Mon Sep 17 00:00:00 2001 From: jack-piplabs Date: Sun, 18 Jan 2026 12:02:06 -0700 Subject: [PATCH 1/3] SIP-00010: Reducing Staking Thresholds MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit | number | title | authors | sponsors | created | type | status | supersedes | superseded-by | extends | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | 00010 | Reducing Staking Thresholds | Jack Chan (jack.chan@piplabs.xyz) | Ramtin Seraj (ramtin.seraj@piplabs.xyz) | 2026-01-18 | Standard | Draft | | | | ## 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 https://forum.story.foundation/t/proposal-discussion-reduce-the-1024-ip-staking-minimum/37190) - **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 https://forum.story.foundation/t/proposal-discussion-reduce-the-1024-ip-staking-minimum/37190/5) - **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 https://forum.story.foundation/t/proposal-discussion-reduce-the-1024-ip-staking-minimum/37190/19) ### 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. --- .../00010-reducing-staking-thresholds.md | 77 +++++++++++++++++++ 1 file changed, 77 insertions(+) create mode 100644 proposals/00010-reducing-staking-thresholds.md diff --git a/proposals/00010-reducing-staking-thresholds.md b/proposals/00010-reducing-staking-thresholds.md new file mode 100644 index 0000000..e601ac8 --- /dev/null +++ b/proposals/00010-reducing-staking-thresholds.md @@ -0,0 +1,77 @@ +--- +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: Draft +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 https://forum.story.foundation/t/proposal-discussion-reduce-the-1024-ip-staking-minimum/37190) +- **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 https://forum.story.foundation/t/proposal-discussion-reduce-the-1024-ip-staking-minimum/37190/5) +- **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 https://forum.story.foundation/t/proposal-discussion-reduce-the-1024-ip-staking-minimum/37190/19) + +### 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. From aca0447976e95fe2480053bdb25fa2b9f39a438c Mon Sep 17 00:00:00 2001 From: jack-piplabs Date: Sun, 18 Jan 2026 13:41:52 -0700 Subject: [PATCH 2/3] Format SIP-00010 to 80 char line width --- .../00010-reducing-staking-thresholds.md | 71 +++++++++++++++---- 1 file changed, 59 insertions(+), 12 deletions(-) diff --git a/proposals/00010-reducing-staking-thresholds.md b/proposals/00010-reducing-staking-thresholds.md index e601ac8..b349827 100644 --- a/proposals/00010-reducing-staking-thresholds.md +++ b/proposals/00010-reducing-staking-thresholds.md @@ -13,15 +13,28 @@ 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. +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 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. +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. +Lowering these thresholds democratizes staking participation, improves user +experience for smaller holders, and encourages broader community engagement +with the network. ## Proposal @@ -39,7 +52,8 @@ Lowering these thresholds democratizes staking participation, improves user expe | --- | --- | --- | | 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. +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 @@ -59,19 +73,52 @@ Rewards will be automatically distributed when accumulated amount reaches 1 IP o ### 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). +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. +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 https://forum.story.foundation/t/proposal-discussion-reduce-the-1024-ip-staking-minimum/37190) -- **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 https://forum.story.foundation/t/proposal-discussion-reduce-the-1024-ip-staking-minimum/37190/5) -- **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 https://forum.story.foundation/t/proposal-discussion-reduce-the-1024-ip-staking-minimum/37190/19) +- **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. +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. From a34a53e8748a20c98fe7a6673f667f9ea2d00477 Mon Sep 17 00:00:00 2001 From: jack-piplabs Date: Mon, 2 Mar 2026 09:21:23 -0800 Subject: [PATCH 3/3] Update 00010-reducing-staking-thresholds.md Update status to Accepted --- proposals/00010-reducing-staking-thresholds.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/00010-reducing-staking-thresholds.md b/proposals/00010-reducing-staking-thresholds.md index b349827..c9f66a6 100644 --- a/proposals/00010-reducing-staking-thresholds.md +++ b/proposals/00010-reducing-staking-thresholds.md @@ -5,7 +5,7 @@ authors: Jack Chan (jack.chan@piplabs.xyz) sponsors: Ramtin Seraj (ramtin.seraj@piplabs.xyz) created: 2026-01-18 type: Standard -status: Draft +status: Accepted supersedes: superseded-by: extends: