KIP 290: Permissionless Smart Contracts

Abstract

This standard defines the spec for core smart contracts required to support permissionless validator operations. The contracts with major changes include AddressBookV2, CnStakingV4, PublicDelegationV2, and VRank. Other system contracts may have minor changes to accommodate these updates. These contracts replace or extend existing contracts while maintaining backward compatibility where possible.

Motivation

The updated contracts introduce the following improvements:

• Flexible key management: Validators can use external multisig solutions (e.g., KaiaSafe) or EOAs, instead of relying on embedded multisig functionality.
• Simplified data model: Each validator is represented by a single (nodeId, stakingContract, rewardAddress) entry, eliminating the complexity of consolidated staking.
• Unified validator registry: BLS public keys are stored directly in AddressBookV2, providing a single source of truth for all validator information.
• Upgradeability: Some contracts are deployed as upgradeable proxies, enabling protocol improvements without requiring validator migration.

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.

Parameters

Overview

The following contracts are introduced or updated:

SimpleBlsRegistry (KIP-113) is obsoleted by AddressBookV2.

Some contracts (e.g., VotingV2, StakingTrackerV3, CLRegistryV2, AuctionFeeVault) might have minor changes to accommodate the above updates.

AddressBookV2

AddressBookV2 serves as the unified registry for all validator and candidate information. It consolidates functionality previously spread across AddressBook, CnStaking, and SimpleBlsRegistry (KIP-113).

Key Changes from AddressBookV1

• Integrated information: On-chain information such as BLS key or gcId shall be stored directly in AddressBookV2.
• Unique reward address: Each validator entry must be a unique combination of (nodeId, stakingContract, rewardAddress). Stake consolidation by reward address shall no longer be supported, as mentioned in KIP-287.
• Removed embedded multisig: Administrative operations shall not use built-in multisig.
• State management: Validator states as defined in KIP-286 shall be stored and managed within AddressBookV2.
• Backward compatible interface: The contract shall implement the existing AddressBook interface to maintain compatibility with nodes and other contracts.
• Only CnStakingV4: The new address book must only accept CnStakingV4 deployed properly by the factory.
• Upgradeable: The contract must be deployed as an upgradeable proxy to enable future improvements.

Data Structures

struct NodeInfo {
    /// @dev Manager address for updating modifiable fields
    address manager;
    /// @dev Node identifier used in consensus (immutable)
    address nodeId;
    /// @dev Address to receive block rewards (immutable when PublicDelegation is enabled)
    address rewardAddress;
    /// @dev Associated staking contract address (immutable)
    address stakingContract;
    /// @dev Address for on-chain governance voting (mutable)
    address voterAddress;
    /// @dev BLS public key and proof-of-possession (immutable)
    BlsPublicKeyInfo blsInfo;
    /// @dev Governance Council ID, only for GCs (immutable)
    uint256 gcId;
    /// @dev Validator metadata in JSON format (mutable)
    string metadata;
    /// @dev Current state of the node
    NodeState state;
}

enum NodeState {
  Unknown,
  CandInactive,
  CandReady,
  CandTesting,
  ValInactive,
  ValReady,
  ValActive,
  ValPaused,
  ValExiting
}

Interface

TBU

CnStakingV4

CnStakingV4 is the staking contract used by candidates and validators to stake KAIA and manage their node operations.

Key Changes from CnStakingV3

• Removed embedded multisig: The contract does not include built-in multisig functionality. Validators MAY deploy the contract with a multisig wallet (e.g., KaiaSafe) as the owner, or use an EOA.
• No initial lockup: The initial lockup mechanism, originally designed for token lockup of initial investors before network launch, shall be removed.
• Removed redundant information: Information stored in CnStakingV3 (such as rewardAddress, stakingTracker, voterAddress, gcId) shall be managed by AddressBookV2.
• Upgradeable: The contract must be deployed as a beacon proxy, allowing the protocol to upgrade all CnStakingV4 instances simultaneously.
• Factory deployment: A dedicated factory contract must handle CnStakingV4 deployment, ensuring consistent initialization and registration with AddressBookV2.

PublicDelegationV2

PublicDelegationV2 enables KAIA holders to delegate their stake to validators and receive liquid staking tokens in return.

Key Changes from PublicDelegationV1

• Transferable token: pdKAIA token must be transferable, unlike PublicDelegationV1 where transfers were prohibited.
• Instant redelegation: Delegators must be able to redelegate their stake to a different validator instantly, without waiting for the standard 7-day withdrawal period.
• Upgradeable: The contract must be deployed as an upgradeable proxy to enable future improvements.

VRank

VRank is a newly introduced contract that manages validator and candidate scoring based on performance metrics.

TBU

Other contracts

• Upgradeable: VotingV2, StakingTrackerV3, CLRegistryV2, and other contracts must be deployed as an upgradeable proxy to enable future improvements.

Rationale

Removing Embedded Multisig

The original contracts include built-in multisig functionality to provide security for validator operations. However, this approach has several drawbacks:

• Limits flexibility in key management strategies
• Increases contract complexity and gas costs
• Duplicates functionality available in mature external solutions (e.g., KaiaSafe)

By removing embedded multisig, validators gain flexibility to choose their preferred security model while reducing contract complexity.

One-to-One Mapping in AddressBookV2

The previous design allows multiple staking contracts to share a reward address, with stakes consolidated for reward distribution, voting power calculation, etc:

[NodeId1, StakingContract1, RewardAddress1]
[NodeId2, StakingContract2, RewardAddress1]  // same reward address
[NodeId3, StakingContract3, RewardAddress1]  // same reward address
=> Voting power = StakingContract1 + StakingContract2 + StakingContract3

This design allows validators to manage multiple staking contracts as a single validator entity. However, the consolidation adds unnecessary complexity. In AddressBookV2, each validator entry represents a single staking contract with a unique reward address, simplifying the data model. See KIP-287 for details.

Integrating information to AddressBookV2

Storing BLS public keys and GC IDs in a separate contract was inevitable, as the existing AddressBook could not be upgraded. With AddressBookV2, they can be stored directly in a single contract, reducing the number of contract calls and providing a single source of truth for validator data.

Upgradeability

There have been several contract upgrades in the past (e.g., CnStakingV1 -> V2 -> V3, StakingTrackerV1 -> V2). Migrations often involved significant overhead; especially, CnStaking migration takes over 7 days for withdrawal. With PublicDelegation, migrations become even more complex as they require coordination with individual delegators. This degraded user experience and delayed protocol improvements.

Deploying contracts as upgradeable proxies eliminates this migration overhead, allowing protocol improvements to apply immediately. Upgrades are authorized through on-chain governance, ensuring transparent and decentralized control over contract changes.

Backwards Compatibility

Parties depending on the system contracts MUST review this document and update their implementations accordingly.

AddressBookV2

AddressBookV2 is designed to be compatible with AddressBook interface and existing consolidation logic, in order to reduce the friction with existing services. Despite this compatibility, services MUST adopt AddressBookV2 interfaces to take full advantage of the new features. Existing consolidation logic that groups stakes by reward address continues to work correctly; each group simply contains exactly one entry.

AddressBookV2 replaces the existing AddressBook at 0x0000000000000000000000000000000000000400. The address will contain proxy code starting from FORK_BLOCK.

CnStakingV4

All validators MUST migrate to CnStakingV4 before FORK_BLOCK, as AddressBookV2 only accepts staking contracts deployed by the CnStakingV4 factory. Since withdrawals require a 7-day waiting period, validators SHOULD begin their migration well in advance of FORK_BLOCK.

Each validator MUST use a single staking contract; validators with multiple staking contracts MUST consolidate before migration.

Services reading old CnStaking (V1-V3) state (such as rewardAddress or voterAddress) MUST update to read from AddressBookV2.

PublicDelegationV2

Users and contracts MUST NOT rely on the non-transferable property of delegation tokens, since pdKAIA tokens become transferable in PublicDelegationV2.

On-chain information

Users MUST read on-chain information from AddressBookV2 after FORK_BLOCK.

References

• KIP-81: Implementing the on-chain governance voting method
• KIP-113: BLS public key registry
• KIP-226: Consensus liquidity for Kaia
• KIP-227: Candidate and Validator Evaluation
• KIP-277: Self Validator Registration
• KIP-286: Permissionless Validator Lifecycle
• KIP-287: Permissionless Staking Policy

Copyright

Copyright and related rights waived via CC0.