KIP 287: Permissionless Staking Policy

Abstract

This KIP introduces a permissionless staking policy for the Kaia network, removing potential attack vectors and simplifying the protocol for open validator participation.

The current staking system has two design aspects that become problematic in a permissionless environment:

1. Unstaking amounts are counted as effective stake: The effective staking amount includes KAIA pending withdrawal, allowing validators to earn rewards on assets no longer committed to network security.

2. Multiple staking contracts per validator: Validators can register multiple CnStaking contracts, adding unnecessary complexity to node consolidation and creating potential attack surfaces through excessive contract registration.

This KIP addresses both issues by: (1) calculating effective staking amount as staking() - unstaking(), excluding pending withdrawals from reward distribution, and (2) restricting each validator to a single staking contract.

These changes align the consensus reward calculation with the existing governance voting power calculation, which already excludes unstaking amounts. The minimum 5M KAIA requirement in CnStaking for validator eligibility remains unchanged. Consensus Liquidity (KIP-226) is unaffected as it uses an upfront cooldown mechanism.

Motivation

The current staking system was designed for a permissioned environment with trusted validators. Two aspects of this design become problematic in a permissionless context:

Unstaking Counted as Effective Stake

When a staker requests a withdrawal, the amount enters a 7-day lockup period. During this period, the unstaking amount remains included in the validator’s effective staking amount for block reward calculation. This creates:

• Misaligned Incentives: Unstaking assets earn rewards despite no longer being committed to network security.
• Logical Inconsistency: Governance voting power already excludes unstaking amounts, creating a gap between consensus rewards and governance participation.
• Economic Attack Surface: Attackers could cycle stake through withdrawal requests, maintaining reward eligibility while minimizing actual economic commitment.

Multiple Staking Contracts per Validator

Validators can currently register multiple CnStaking contracts under the same consensus node. This was not an intended design but emerged from implementation flexibility. This creates:

• Protocol Complexity: Node consolidation logic must aggregate staking amounts across multiple contracts, increasing implementation and maintenance burden.
• Attack Surface: Malicious actors could register excessive staking contracts, exploiting the consolidation overhead.

This KIP addresses these issues by excluding unstaking amounts from effective stake and restricting validators to a single staking contract.

Specification

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

Configuration

This KIP SHALL be activated at PERMISSIONLESS_FORK_BLOCK_NUMBER.

Single Staking Contract per Validator

After activation, each validator MUST have exactly one CnStaking contract registered. Validators with multiple staking contracts MUST consolidate to a single contract before activation.

Effective Staking Amount Calculation

Before this KIP, the effective staking amount for a validator is derived from the contract’s native KAIA balance (balance), which includes both actively staked and unstaking amounts. After activation, the effective staking amount MUST exclude unstaking amounts.

CnStaking Contract Interface

The CnStaking contract provides the following relevant methods:

Before (Current Behavior)

def get_effective_staking_amount(consolidated_staking_contracts: List[CnStaking]) -> int:
    """
    Current implementation: uses contract balance which includes unstaking.
    Allows multiple staking contracts per validator.
    """
    total = 0
    for contract in consolidated_staking_contracts:
        # balance includes both active stake and unstaking amount
        total += contract.balance
    return total

After (This KIP)

def get_effective_staking_amount(staking_contract: CnStaking, block_number: int) -> int:
    """
    After PERMISSIONLESS_FORK_BLOCK_NUMBER:
    - Single staking contract per validator
    - Excludes unstaking amounts
    """
    if block_number >= PERMISSIONLESS_FORK_BLOCK_NUMBER:
        # Exclude unstaking: staking() includes unstaking, so subtract it
        return staking_contract.staking() - staking_contract.unstaking()
    else:
        # Legacy behavior: use balance (includes unstaking)
        return staking_contract.balance

Impact on Reward Distribution

The reward distribution mechanism (KIP-82) uses each validator’s staking amount to calculate their share of block rewards. After this KIP, the staking amount MUST reflect only the actively staked amount from a single staking contract:

effectiveStake = cnStaking.staking() - cnStaking.unstaking() + clStaking

Where clStaking is the staked KAIA in Consensus Liquidity pools, which remains unaffected by this KIP.

Consensus Liquidity Compatibility

This KIP does not affect Consensus Liquidity (KIP-226). CLDEX uses an upfront cooldown mechanism where the 7-day minimum staking period begins upon liquidity provision. Therefore, all KAIA in CLDEX pools is already considered actively staked.

Validator Eligibility

The minimum 5M KAIA requirement in CnStaking for validator eligibility remains unchanged. This requirement is evaluated against only the actively staked amount (excluding unstaking) from the single staking contract after this KIP.

Rationale

Single Staking Contract per Validator

The current AddressBook doesn’t check the duplication of reward address for new staking entry. This unintentionally enables the current multiple staking contract registration. It requires additional complexity to consolidate the validator information and operation cost. Currently, there’re 3 main reasons for multiple staking contracts:

1. Legacy purpose (can be simply removed)
2. Delegation purpose (can be handled by public delegation)
3. Internal product purpose

For 2, we can handle it by explicit delegation contract. We’re already utilizing delegation contract for public delegation that separates the principal and reward. It can be also used for CnStaking that doesn’t use public delegation. For 3, it’s a valid use case but not a common one (only 1 validator), but with enough transition period, it’s not critical to migrate to single staking contract.

No Changes to Consensus Liquidity

Consensus Liquidity (KIP-226) uses an upfront cooldown mechanism where the 7-day minimum staking period begins upon liquidity provision. This design inherently ensures all KAIA in CLDEX is actively committed, eliminating the need for unstaking exclusion logic.

Backwards Compatibility

This KIP introduces breaking changes that require hardfork. Validators must consolidate their staking contracts before activation. The core client and on-chain components (e.g., on-chain governance) must follow the new logic after the hardfork.

References

• KIP-82: A new GC reward structure
• KIP-163: Public Delegation
• KIP-226: Consensus Liquidity
• KIP-277: Self Validator Registration

Copyright

Copyright and related rights waived via CC0.