diff --git a/KIPs/kip-226.md b/KIPs/kip-226.md
index 1c969ad..519b64f 100644
--- a/KIPs/kip-226.md
+++ b/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)
@@ -77,7 +78,7 @@ The detailed information of each smart contract is described in the following se
 
 ### Configuration
 
-The KIP-226 shall be activated since the `PRAGUE_FORK_BLOCK_NUMBER`.
+The KIP-226 shall be used since processing `PRAGUE_FORK_BLOCK_NUMBER` block. Please note that the staking information at previous block will be used to process current block since the Kaia hardfork.
 
 | config                     | value |
 | -------------------------- | ----- |
@@ -85,7 +86,7 @@ The KIP-226 shall be activated since the `PRAGUE_FORK_BLOCK_NUMBER`.
 
 ### 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.
@@ -196,7 +201,7 @@ For both commission types, the following parameters are configurable:
 
 ### Consensus
 
-After the `PRAGUE_FORK_BLOCK_NUMBER`, staked KAIA will be tracked through two mechanisms:
+Since the `PRAGUE_FORK_BLOCK_NUMBER`, staked KAIA will be tracked through two mechanisms:
 
 1. **CnStaking**
 
@@ -232,7 +237,7 @@ The on-chain governance will be maintained except using `StakingTrackerV2` inste
 
 ### `kaia_getStakingInfo`
 
-The new field `clStakingInfo` will be added to the response of `kaia_getStakingInfo` to provide the CLStaking information.
+The new field `clStakingInfo` will be added to the response of `kaia_getStakingInfo` since the `PRAGUE_FORK_BLOCK_NUMBER` to provide the CLStaking information if exists.
 
 - Example
 
@@ -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.