Add system registry activation

KIPs/kip-226.md

@@ -23,6 +23,7 @@ requires: 81, 82
   - [CLDEX](#cldex)
   - [Consensus](#consensus)
   - [On-chain Governance](#on-chain-governance)
+  - [Preparation](#preparation)
 - [JSON-RPC API](#json-rpc-api)
 - [Rationale](#rationale)
 - [Backward Compatibility](#backward-compatibility)
@@ -85,7 +86,7 @@ The KIP-226 shall be used since processing `PRAGUE_FORK_BLOCK_NUMBER` block. Ple
 
 ### CLRegistry
 
-The CLRegistry contract must implement the ICLRegistry interface:
+The `CLRegistry` contract must implement the `ICLRegistry` interface:
 
 ```solidity
 interface ICLRegistry {
@@ -106,6 +107,8 @@ interface ICLRegistry {
 }
 ```
 
+The `CLRegistry` will be registered in [KIP-149](https://kips.kaia.io/KIPs/kip-149) system registry with activation of `PRAGUE_FORK_BLOCK_NUMBER - 1`.
+
 ### StakingTrackerV2
 
 The all external functions of `StakingTrackerV2` contract must have same selector and semantics as the existing `StakingTracker` contract to be compatible with the existing contracts.
@@ -115,6 +118,8 @@ The additional tracking processes of `StakingTrackerV2` are as follows:
 1. Creating a new tracker: When creating a new tracker, the `StakingTrackerV2` contract must call `CLRegistry.getAllCLs()` to populate the CL information.
 2. Updating the tracker: When the staked KAIA in `CLPool` changes, the `StakingTrackerV2` contract must update the staked KAIA for the corresponding validator.
 
+The `StakingTrackerV2` will be registered in [KIP-149](https://kips.kaia.io/KIPs/kip-149) system registry with activation of `PRAGUE_FORK_BLOCK_NUMBER`.
+
 #### Voting Power Eligibility
 
 The validator is eligible for voting power if the staked KAIA in `CnStaking` is greater than or equal to 5M.
@@ -274,6 +279,12 @@ The new field `clStakingInfo` will be added to the response of `kaia_getStakingI
 
 ## Rationale
 
+### Set activation to `PRAGUE_FORK_BLOCK_NUMBER - 1` for `CLRegistry`
+
+The Kaia's using previous block's staking information to process current block since the Kaia hardfork. It makes the `CLRegistry` at `PRAGUE_FORK_BLOCK_NUMBER - 1` to be required to track the staked KAIA in CLDEX at `PRAGUE_FORK_BLOCK_NUMBER` if exists.
+
+Please note that the `StakingTrackerV2` will also populate the staked KAIA in CLDEX at `PRAGUE_FORK_BLOCK_NUMBER - 1` if transaction creating a new tracker is executed at exact `PRAGUE_FORK_BLOCK_NUMBER - 1` block, which is not feasible.
+
 ### Separate Reward Address
 
 The validator only has one reward address even if it has multiple `CnStaking` contracts. But this KIP will break that invariant by separating the reward address for `CnStaking` and `CLDEX`. It's natural to separate the reward address since consensus liquidity is a new staking mechanism and has different form and reward profile.