Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Specify the activation of kip-226 #40

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Specify the activation of kip-226 #40

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
a023bd2
kip-226: Specify the activation of kip-226
hyeonLewis Dec 31, 2024
8d343cd
Add system registry activation
hyeonLewis Jan 2, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 15 additions & 4 deletions KIPs/kip-226.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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)
Expand Down Expand Up @@ -77,15 +78,15 @@ 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 |
| -------------------------- | ----- |
| `PRAGUE_FORK_BLOCK_NUMBER` | TBD |

### CLRegistry

The CLRegistry contract must implement the ICLRegistry interface:
The `CLRegistry` contract must implement the `ICLRegistry` interface:

```solidity
interface ICLRegistry {
Expand All @@ -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.
Expand All @@ -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.
Expand Down Expand Up @@ -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**

Expand Down Expand Up @@ -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

Expand Down Expand Up @@ -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.
Expand Down
Loading