KIP-290: Permissionless Smart Contracts

KIPs/kip-290.md

@@ -0,0 +1,228 @@
+---
+kip: 290
+title: Permissionless Smart Contracts
+author: Lewis (@hyeonLewis), Ian (@ian0371), Ollie (@blukat29), Lake (@hyunsooda), and Joseph (@jiseongnoh)
+discussions-to: https://github.com/kaiachain/kips/issues/90
+status: Draft
+type: Core
+created: 2026-01-23
+requires: 81, 226, 227, 286, 287
+replaces: 113, 277
+---
+
+## 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
+
+| Constant     | Value |
+| ------------ | ----- |
+| `FORK_BLOCK` | TBD   |
+
+### Overview
+
+The following contracts are introduced or updated:
+
+| Contract           | Description                                                   |
+| ------------------ | ------------------------------------------------------------- |
+| AddressBookV2      | Unified validator registry with BLS keys and state management |
+| CnStakingV4        | Staking contract for validators                               |
+| PublicDelegationV2 | Instant delegation with transferable tokens                   |
+| VRank              | Validator ranking system                                      |
+
+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
+
+```solidity
+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](https://kips.kaia.io/KIPs/kip-81)
+- [KIP-113: BLS public key registry](https://kips.kaia.io/KIPs/kip-113)
+- [KIP-226: Consensus liquidity for Kaia](https://kips.kaia.io/KIPs/kip-226)
+- [KIP-227: Candidate and Validator Evaluation](https://kips.kaia.io/KIPs/kip-227)
+- [KIP-277: Self Validator Registration](https://kips.kaia.io/KIPs/kip-277)
+- [KIP-286: Permissionless Validator Lifecycle](https://kips.kaia.io/KIPs/kip-286)
+- [KIP-287: Permissionless Staking Policy](https://kips.kaia.io/KIPs/kip-287)
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).