KIP 226: Consensus liquidity for Kaia
Author | Lewis, Ian, Ollie, Lake, and Aidan |
---|---|
Discussions-To | TBD |
Status | Draft |
Type | Core |
Created | 2024-11-07 |
Requires | 81, 82 |
Table of contents
Simple Summary
Introduce a consensus liquidity mechanism for Kaia. The staked KAIA through the consensus liquidity will contribute to the consensus and on-chain governance of Kaia.
Abstract
This KIP introduces a consensus liquidity mechanism where KAIA and CL Token holders can participate in Kaia network through liquidity provision. Users stake KAIA tokens in the native decentralized exchange (CLDEX), simultaneously providing market liquidity and securing the network. Stakers earn both swap fees and block rewards, creating an efficient capital utilization.
The eligibility of GC remains unaffected by consensus liquidity, which means it still requires maintaining 5M KAIA staked solely through CnStaking
contract, as is currently the case.
Motivation
The current staking model often leads to capital inefficiency, where staked tokens remain idle. This KIP addresses this limitation by introducing consensus liquidity, which serves multiple purposes:
-
New Utility: Staked KAIA simultaneously secure the network and provide DEX liquidity, increasing the token utility.
-
Enhanced Network Security: By tying liquidity provision to consensus, we can expect more KAIA staked for the network, which enhances the network security.
-
Sustainable Tokenomics: The dual reward structure (swap fees + block rewards) creates a new utility and burn mechanism, building a sustainable tokenomics for Kaia and CL Token.
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.
Terminology
Term | Description |
---|---|
CnStaking | The existing staking contract for Kaia. Usually referred as CnStakingV2 or CnStakingV3 |
Consensus Liquidity (CL) | A mechanism where KAIA and CL Token holders can participate in Kaia network through liquidity provision. |
CLDEX | A decentralized exchange (DEX) on Kaia that allows users to trade KAIA and CL Token. |
CL Token | A token pair with KAIA. |
LP Token | A token representing the liquidity provider’s share in the CLDEX. |
Overview
There’ll be modified and new smart contracts to be developed.
CLRegistry
: A new registry for CLDEX. Manage the information of CLDEXs forStakingTrackerV2
and Kaia core.CLDEX
: A new smart contract for CLDEX. It consists of router, factory, and pool.CLStaking
: A new smart contract to stake LP Token and distribute block rewards.StakingTrackerV2
: A modified staking tracker to track the staked KAIA in CLDEX for the governance. The existingStakingTracker
contract will be deprecated.
The detailed information of each smart contract is described in the following sections.
Configuration
The KIP-226 shall be activated since the PRAGUE_FORK_BLOCK_NUMBER
.
config | value |
---|---|
PRAGUE_FORK_BLOCK_NUMBER |
TBD |
CLRegistry
The CLRegistry contract must implement the ICLRegistry interface:
interface ICLRegistry {
struct CLInfo {
/// @dev The node ID of the validator
address nodeId;
/// @dev The governance committee ID of the validator
uint256 gcId;
/// @dev The address of the CLDEX pool
address clPool;
/// @dev The address of the CLStaking
address clStaking;
}
/// @dev Returns the CL information of all registered validators
/// @return The CL information of all registered validators
function getAllCLs() external view returns (address[] memory nodeIds, uint256[] memory gcIds, address[] memory clPools, address[] memory clStakings);
}
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.
The additional tracking processes of StakingTrackerV2
are as follows:
- Creating a new tracker: When creating a new tracker, the
StakingTrackerV2
contract must callCLRegistry.getAllCLs()
to populate the CL information. - Updating the tracker: When the staked KAIA in
CLPool
changes, theStakingTrackerV2
contract must update the staked KAIA for the corresponding validator.
Voting Power Eligibility
The validator is eligible for voting power if the staked KAIA in CnStaking
is greater than or equal to 5M.
For example:
- Validator A: CnStaking (6M) + CLPool (5M) = 11M total stake, 2 voting power
- Validator B: CnStaking (4M) + CLPool (10M) = 14M total stake, 0 voting power
CLDEX
The CLDEX is a decentralized exchange on Kaia for consensus liquidity based on UniswapV2’s CPMM model and implementation. The liquidity providers (LPs) deposit KAIA and CL Token in the CLDEX and earn swap fees and block rewards. It consists of router, factory, pool and staking contracts.
Staking Requirements
-
All LP tokens in CLDEX MUST be subject to a minimum staking period of 7 days from the moment of provision, without exception. This differs from the traditional CnStaking withdrawal process as:
- The 7-day period begins automatically upon LP token creation
- No separate withdrawal request is required
-
There are separate steps needed for staking and unstaking.
- Providing LP Token leads to staking automatically.
- Unstaking LP Token leads to removing liquidity automatically.
It makes the calculation of the staked KAIA in CLDEX more easier since the all KAIA in CLDEX can be considered as staked.
Pair Creation and Management
- CL Token pairs MUST be approved through governance before being listed on CLDEX
- No duplicate pair is allowed on CLDEX. Only one pair per CL Token is allowed.
- Only designated owner addresses SHALL have the authority to create new pairs
- During the initial stability period:
- Liquidity provision SHALL be restricted to designated addresses
- After stability is confirmed, liquidity provision SHALL be opened to all participants
- Swap SHALL be available to all participants since the beginning
Block Rewards
The CLDEX will receive block rewards from the Kaia core for contributing to the consensus. Note that the block rewards will be directly injected into the CLStaking contract, similar to the Public Delegation contract.
- Block rewards for CLDEX SHALL be distributed based on:
- The proportional LP Token of each staker
- Rewards SHALL be distributed per second to eligible stakers
- No lockup period for rewards
StakingTrackerV2 Interaction
As CnStaking
notifies its staked KAIA changes to StakingTracker
, the CLDEX must notify to StakingTrackerV2
whenever the staked KAIA in CLDEX changes. For example, based on UniswapV2’s implementation, the target functions must call stakingTrackerV2.refreshStake(address(this))
.
CLDEX.mint
: Used when providing liquidityCLDEX.burn
: Used when removing liquidityCLDEX.swap
: Used when swapping tokensCLDEX.skim
: Used when skimming tokens
Commission
CLDEX commissions are derived from two sources:
- Swap fees from CLPool
- Block rewards from CLStaking
Swap Fee Commission:
- Commissions can be collected from swap fees
- Burn ratios can be configurable by token type (e.g., KAIA: 10%, CL Token: 5%)
Block Reward Commission:
- Commissions can be collected from block rewards
For both commission types, the following parameters are configurable:
- Commission receiver addresses
- Split ratios for each receiver address
- Burn ratios
Consensus
After the PRAGUE_FORK_BLOCK_NUMBER
, staked KAIA will be tracked through two mechanisms:
-
CnStaking
- Existing staking mechanism through the
CnStaking
contract
- Existing staking mechanism through the
-
Consensus Liquidity
- New staking mechanism through CLDEX liquidity provision
Similar to voting power requirements, validators must maintain at least 5M KAIA staked in CnStaking to be eligible to propose blocks. The total effective staked amount for staking rewards distribution is calculated as:
totalEffectiveStakedKAIA = staked KAIA in CnStaking + staked KAIA in CLDEX
Block Rewards Distribution
The total block reward for each validator will be calculated based on KIP-82, while the split ratio between CnStaking
and CLDEX
will be proportional to their respective staked KAIA amounts.
On-chain Governance
The on-chain governance will be maintained except using StakingTrackerV2
instead of StakingTracker
.
StakingTracker Replacement Process
- Deploy the new
StakingTrackerV2
contract - Propose a
StakingTracker
replacement on Voting - After the proposal is approved, the new
StakingTrackerV2
contract will be set for Voting - Replace all
StakingTracker
contracts ofCnStaking
withStakingTrackerV2
Rationale
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.
Minimum Staking Period
The decision not to implement a 7-day waiting period after unstaking request (like in CnStaking) was made for several reasons. From a consensus perspective, since Kaia’s validators will be selected as proposer randomly based on KIP-146, requiring 5M in CnStaking provides sufficient protection against consensus instability. From a governance perspective, while it’s important to prevent sudden voting power shifts in response to specific proposals, this can be adequately addressed through the minimum staking period alone. Additionally, LP assets receive comparatively lower block rewards relative to their invested assets compared to CnStaking, and are subject to impermanent loss risks. Therefore, to promote CL adoption through the ecosystem, the requirements were made more lenient to allow users to utilize CL more easily.
5M KAIA in CnStaking to be validator
As mentioned in the Minimum Staking Period, the 5M KAIA in CnStaking is to prevent the consensus instability. It’ll act as a safety margin for network stability. Even if the validator is not malicious, the staked KAIA in CLDEX can be extremely volatile due to the external market conditions. It’s not reasonable to rely solely on the volatile staked KAIA.
Backward Compatibility
StakingTrackerV2
The StakingTrackerV2
contract will support same functions as the existing StakingTracker
contract to be compatible with the existing contracts.
References
Copyright
Copyright and related rights waived via CC0.