Conflux Improvement Proposals (CIPs) describe standards for the Conflux platform, including core protocol specifications, client APIs, and contract standards.
- Review CIP-1.
- Fork the repository by clicking "Fork" in the top right.
- Add your CIP to your fork of the repository. There is a template CIP here.
- Submit a Pull Request to Conflux's CIPs repository.
Your initial PR should be a draft of the final CIP, and it must comply with the formatting rules set by the build, including correct metadata in the header.
Your PR ID may be utilized as a provisional CIP ID at the submitter's discretion, obviating the necessity for editorial approval. An editor will manually review the first PR for a new CIP and assign a definitive CIP ID. Typically, editors do not alter CIP ID. However, exceptions do occur, as demonstrated by CIP-1820. In the event that the chosen PR ID is occupied by an existing CIP, the submitter is obliged to await the editor's allocation of a new CIP ID. CIPs submitted via issues are considered invalid.
Considering the current size of the Conflux community, it's not practical for community members to follow up with technically complex CIPs. For such CIPs, the main discussions are held within the dev team, and the outcomes are promptly updated in the CIP documents. For CIPs that may have a significant impact, triggering large-scale discussions, you should start a topic in the GitHub issue or Conflux forum for more in-depth discussions. These CIPs must include a Discussion header with a link to a discussion forum or open GitHub issue where the CIP can be discussed as a whole.
If your CIP requires images, the image files should be included in a subdirectory of the assets folder for that CIP as follows: assets/CIP-N (where N is to be replaced with the CIP number). When linking to an image in the CIP, use relative links such as ../assets/CIP-1/image.png.
If your CIP depends on other CIPs that haven't been activated on the mainnet, include a "Required CIPs" field in the header. You don't need to list prerequisites that have been activated on the mainnet.
To facilitate communication, you can provide multilingual versions for CIP, such as CIP-109. However, an English version is essential. In case of discrepancies between different language versions, the English one will serve as the definitive reference.
Once your first PR is merged, we have a bot that helps out by automatically merging PRs to draft CIPs. For this to work, it has to be able to tell that you own the draft being edited. Make sure that the 'author' line of your CIP contains either your GitHub username or your email address inside. If you use your email address, that address must be the one publicly shown on your GitHub profile.
When you believe your CIP is mature and ready to progress past the draft phase, you should ask to have your issue added to the agenda of an upcoming All Core Devs meeting, where it can be discussed for inclusion in a future hard fork. If implementers agree to include it, the CIP editors will update the state of your CIP to Accepted.
- Draft - a CIP that is undergoing rapid iteration and changes.
- Last Call - a CIP that is done with its initial iteration and ready for review by a wide audience.
- Accepted - a CIP that has been in Last Call for at least 2 weeks and any technical changes that were requested have been addressed by the author. The process for Core Devs to decide whether to encode a CIP into their clients as part of a hard fork is not part of the CIP process. If such a decision is made, the CIP will move to Final.
- Final - a CIP that the Core Devs have decided to implement and release in a future hard fork or has already been released in a hard fork.
These CIPs significantly influence the economic and governance models of Conflux, as well as its various features.
| CIP Number | Title |
|---|---|
| 37 | Introduce Base32 Checksum Addresses |
| 40 | Reduce Block Base Reward to 2 CFX |
| 43 | Introduce Finality Through Staking Vote |
| 90 | Introduce a Fully EVM-Compatible Space |
| 94 | On-Chain DAO Vote for Chain Parameters |
| 107 | DAO-Adjustable Burn of Storage Collateral |
| 1559 | Fee market change for Conflux |
These CIPs are primarily aimed at following EIPs to maintain compatibility with Ethereum. The specifications are highly align with Ethereum.
| CIP Number | Title | Related EIP Number |
|---|---|---|
| 23 | Hashing and Signing Typed Structured Data | EIP-712 |
| 92 | Enable Blake2F Builtin Function | EIP-152 |
| 119 | PUSH0 (0x5f) Instruction |
EIP-3855 |
| 142 | Transient Storage Opcodes | EIP-1153 |
| 143 | MCOPY (0x5e) Opcode for Efficient Memory Copy |
EIP-5656 |
| 144 | Point Evaluation Precompile from EIP-4844 | EIP-4844 |
| 1820 | Migrate ERC1820 to Conflux | EIP-1820 |
The following CRCs do not have dedicated documentation; they are identical to the corresponding ERCs.
| CRC Number | Related ERC Number |
|---|---|
| 20 | ERC-20 |
| 721 | ERC-721 |
| 1155 | ERC-1155 |
These CIPs are either in the midst of active development or have been fully developed, currently awaiting discussions on upgrade plans.
| CIP Number | Title | Status |
|---|
These CIPs have successfully undergone upgrades on the mainnet.
| CIP Number | Title | Activation Hardfork |
|---|---|---|
| 3 | Octopus Proof-of-Work Mining Algorithm | Tethys (V1.0) |
| 5 | Fix MPT Key Encoding Corner Case | Tethys (V1.0) |
| 8 | Delay Code Collateral Settlement | Tethys (V1.0) |
| 10 | Mining Reward Finalization | Tethys (V1.0) |
| 12 | Allow Non-Existent Sponsor for Collateral | Tethys (V1.0) |
| 13 | Employ Big-Endian MPT Keys | Tethys (V1.0) |
| 16 | Consolidate Contract Destruction Logic | Tethys (V1.0) |
| 21 | Minimum Storage Commitment Per Epoch | Tethys (V1.0) |
| 22 | Add Interfaces for Internal Contracts | Tethys (V1.0) |
| 26 | Use Pivot Block Timestamp for Opcode TIMESTAMP | Tethys (V1.0) |
| 27 | Delete Whitelist Keys at Contract Removal | Tethys (V1.0) |
| 31 | Genesis Block Contract: Create2Factory | Tethys (V1.0) |
| 39 | Use Custom Field for Incompatible Upgrade | Tanzanite (V1.1) |
| 40 | Reduce Block Base Reward to 2 CFX | Tanzanite (V1.1) |
| 43 | Introduce Finality Through Staking Vote | Hydra (V2.0) |
| 62 | Enable EC-Related Builtin Contracts | Hydra (V2.0) |
| 64 | Get Current Epoch Number via Internal Contract | Hydra (V2.0) |
| 71 | Disable Anti-Reentrancy | Hydra (V2.0) |
| 76 | Remove VM-Related Constraints in Syncing Blocks | Hydra (V2.0) |
| 78 | Correct is_sponsored Fields in Receipt |
Hydra (V2.0) |
| 86 | Update Difficulty Adjustment Algorithm | Hydra (V2.0) |
| 90 | Introduce a Fully EVM-Compatible Space | Hydra (V2.0) |
| 92 | Enable Blake2F Builtin Function | Hydra (V2.0) |
| 94 | On-Chain DAO Vote for Chain Parameters | V2.1 |
| 97 | Clear Staking Lists | V2.1 |
| 98 | Fix BLOCKHASH Opcode Bug in eSpace | V2.1 |
| 99 | Extend Non-Voting Grace and Shorten Unlock Time | V2.1 |
| 105 | Minimal DAO Vote Count Based on PoS Staking | V2.1 |
| 107 | DAO-Adjustable Burn of Storage Collateral | V2.3 |
| 112 | Fix Block Headers custom Field Serde |
V2.3 |
| 113 | Accelerate Up PoS Finalization | V2.3 |
| 118 | Query Unused Storage Points in Internal Contract | V2.3 |
| 119 | PUSH0 (0x5f) Instruction |
V2.3 |
| 130 | Aligning Gas Limit with Transaction Size | V2.4 |
| 131 | Retain Whitelist on Contract Deletion | V2.4 |
| 132 | Fix Static Context Check for Internal Contracts | V2.4 |
| 133 | Enhanced Block Hash Query | V2.4 |
| 136 | Increase PoS Retire Period | V2.4 |
| 137 | Base Fee Sharing in CIP-1559 | V2.4 |
| 141 | Disable Subroutine Opcodes | V2.4 |
| 142 | Transient Storage Opcodes | V2.4 |
| 143 | MCOPY (0x5e) Opcode for Efficient Memory Copy |
V2.4 |
| 144 | Point Evaluation Precompile from EIP-4844 | V2.4 |
| 145 | Fix Receipts upon NotEnoughBalance Error |
V2.4 |
| 1559 | Fee market change for Conflux | V2.4 |
| Hardfork Version Number | Main Features | Time Nodes |
|---|---|---|
| Tethys (V1.0) | Mainnet Activation | All features activated at genesis block (2020-10-29) |
| Tanzanite (V1.1) | Reducing base reward to alleviate selling pressure | All features activated at epoch number 3,615,000 (2020-11-18) |
| Hydra (V2.0) | Introduction of PoS hybrid consensus and EVM-compatible Space | Features activated based on epoch number: activated at epoch number 36,935,000 (2022-02-21) Features activated based on block number: activated at block number 92,060,600 (2022-02-22) First round of PoS consensus committee election ends at block number 92,751,800 (2022-02-26) PoS consensus starts at epoch number 37,400,000 (2022-02-27) |
| V2.1 | Introduction of DAO voting mechanism | Features activated based on epoch number: activated at epoch number 56,800,000 (2022-10-15) Features activated based on block number: activated at block number 133,800,000 (2022-10-25) |
| V2.2 | Emergency bug fix for PoS Key security | Activated at block number 137,740,000 (2022-11-17) |
| V2.3 | Introduction of storage collateral token burning mechanism | Features activated based on epoch number: activated at epoch number 79,050,000 (2023-09-10) Features activated based on block number: activated at block number 188,900,000 (2023-09-09) |
| V2.4 | Introduction of EIP-1559 gas fee burning mechanism | Features activated based on epoch number: activated at epoch number 101,900,000 (2024-08-06) Features activated based on block number: activated at block number 247,480,000 (2024-08-13) |
These CIPs have been dormant, lacking recent discussions or follow-ups.
| CIP Number | Title |
|---|---|
| 28 | Include Block Number in Contract Address Calculation |
| 33 | Transaction Fee Pricing Mechanism for Tephys |
| 34 | Contract-Friendly Verification Rules |
| 42 | Support Event-Driven Execution Model |
| 44 | Introduce a VDF Verification Builtin |
| 45 | Introduce Flexible Account Authorization |
| 51 | Support SM-2/3 Verification in Internal Contracts |
| 52 | Custom Eligibility Rules for Sponsorship |
| 102 | Change PoW Mining Algorithm |
| 104 | Create EVM-Compatible Space with Ethereum State |
These CIPs have been replaced by other CIPs.
| CIP Number | Title | Replaced By |
|---|---|---|
| 2 | Prohibit Storage Owner Destruction in Sub-Call | 12 |
| 72 | Support Ethereum-Type Transactions | 90 |
| 80 | Align Conflux and Ethereum Address Generation Rules | 90 |
These CIPs, while not requiring hard fork upgrades, could potentially impact the database or RPC.
| CIP Number | Title | Status |
|---|---|---|
| 4 | Add Node Type in Status Message | Activated |
| 11 | Distinguish Status and Heartbeat Messages | Activated |
| 37 | Introduce Base32 Checksum Addresses | Activated |
| 60 | Log VM Errors in Tracer | Activated |
These CIPs establish standards at the application layer, thereby not involving upgrades to the Conflux nodes.
| CIP Number | Title |
|---|---|
| 19 | KeyValue EventLog Standard |
| 23 | Hashing and Signing Typed Structured Data |
| 46 | Introduce Conflux Domain Name Service |
| 109 | RPC API for Wallet Provider |
| 1820 | Migrate ERC1820 to Conflux |