INITIAL PROPOSAL: Cronos POS Chain Slashing Parameters Update

[lezzokafka]

Abstract

In response to community feedback regarding the current slashing parameters on Cronos POS Chain, we propose updating the slashing parameters to provide validators with more reasonable operational flexibility while maintaining network security. The current parameters are relatively restrictive compared to other public chains such as Cosmos Hub, with a short downtime allowance (~3.6 hours) and lengthy jailing period (24 hours). Networks such as Cosmos Hub offer significantly more generous parameters, with downtime allowances of up to 16 hours.
This proposal aims to update the following parameters:

• signed_blocks_window from 5000 to 12000
• downtime_jail_duration from 86400s (24 hours) to 28800s (8 hours)

These proposed changes will create a more balanced environment for validator operations while preserving the security and reliability of the network.

Background

The current slashing parameters on Cronos POS Chain have been identified by the community as being overly restrictive when compared to established networks in the Cosmos ecosystem. Specifically:

Current limitations:

• Downtime allowance: Validators can only miss approximately 3.6 hours of blocks (calculated as 5000 × 0.5 × 5.2 seconds / 3600) before being jailed
• Jailing duration: Once jailed for downtime, validators must wait 24 hours before they can unjail themselves

Technical Details

The slashing module in Cosmos SDK chains is responsible for penalizing validators who engage in malicious behavior or fail to maintain adequate uptime. The parameters we propose to update directly affect how the network handles validator downtime.

Current Parameters

{
  "params": {
    "signed_blocks_window": "5000",
    "min_signed_per_window": "0.500000000000000000",
    "downtime_jail_duration": "86400s",
    "slash_fraction_double_sign": "0.050000000000000000",
    "slash_fraction_downtime": "0.000000000000000000"
  }
}

Proposed Changes

1/ Update signed_blocks_window from 5000 to 12000

The signed_blocks_window parameter defines the rolling window of blocks that the network uses to track validator signing activity.

Current situation:

• Window size: 5000 blocks
• Required signatures: 50% (2500 blocks)
• Approximate time: 6.94 hours window (5000 × 5.2 seconds / 3600)
• Allowed downtime: ~3.6 hours (before missing 50% of blocks in the window)

Proposed situation:

• Window size: 12000 blocks
• Required signatures: 50% (6000 blocks)
• Approximate time: 17.33 hours window (12000 × 5.2 seconds / 3600)
• Allowed downtime: ~8.6 hours (before missing 50% of blocks in the window)

This change provides validators with a more reasonable buffer for handling routine maintenance, infrastructure updates, and unexpected technical issues while still maintaining accountability for consistent uptime.

2/ Update downtime_jail_duration from 86400s to 28800s

The downtime_jail_duration parameter specifies how long a validator must remain jailed after being penalized for excessive downtime before they can submit an unjail transaction.

Current situation:

• Jailing duration: 86400 seconds (24 hours)
• Impact: Extended downtime for validators and their delegators

Proposed situation:

• Jailing duration: 28800 seconds (8 hours)
• Impact: Faster recovery time, enabling validators to resume operations more quickly

Reducing the jailing period from 24 hours to 8 hours allows validators to return to active status more quickly after addressing the underlying issues that caused the downtime. This strikes a better balance between penalizing poor performance and allowing validators to resume their duties in a timely manner.

3/ Parameters Remaining Unchanged

The following parameters will remain at their current values:

• min_signed_per_window: 0.5 (50%) - Maintains the requirement that validators must sign at least half of the blocks in the window
• slash_fraction_double_sign: 0.05 (5%) - Maintains strong deterrent against double-signing attacks
• slash_fraction_downtime: 0.0 (0%) - No token slashing for downtime, only jailing as the penalty

Expected Outcomes

With the proposed changes:

1. Increased operational flexibility: Validators can perform maintenance, upgrades, and migrations with reduced risk of being jailed
2. Faster recovery: Reduced jailing time means validators can resume operations and delegators can continue earning rewards sooner
3. More competitive environment: Parameters more aligned with industry standards like Cosmos Hub
4. Maintained security: The 50% signing requirement and double-sign slashing remain unchanged, preserving network security
5. Validator retention: More reasonable parameters may encourage high-quality validators to join and remain in the active set

Proposed Changes

{
  "params": {
    "signed_blocks_window": "12000",
    "min_signed_per_window": "0.500000000000000000",
    "downtime_jail_duration": "28800s",
    "slash_fraction_double_sign": "0.050000000000000000",
    "slash_fraction_downtime": "0.000000000000000000"
  }
}

If the proposal passes, the parameters will be automatically updated at the end of the voting period.

Testing

Proposed changes have been applied to the Croeseid testnet testnet-croeseid-4 to ensure the expected outcomes are achieved.

Governance Votes

The following items summarize the voting options and what it means for this proposal:

• YES: You approve of the proposal to update the slashing parameters to provide validators with more operational flexibility while maintaining network security. You support increasing the signed blocks window to 12000 and reducing the downtime jail duration to 8 hours.

• NO: You disapprove of the proposal in its current form. Feel free to provide feedback and suggestions on how to improve the proposal, including alternative parameter values that might better balance validator operations with network security.

• NO (VETO): You veto the entire motivation for the proposal and are strongly opposed to its implementation. You believe the current slashing parameters should remain unchanged.

• ABSTAIN: You are impartial to the outcome of the proposal.

If the quorum is not met or less than 1/3 of participating voting power has voted No, the proposal fails and is considered to be vetoed. In this case, the proposal deposit is burned rather than being returned to respective depositors.