Conflux Improvement Proposals

Conflux Improvement Proposals (CIPs) describe standards for the Conflux platform, including core protocol specifications, client APIs, and contract standards.

Contributing

1. Review CIP-1.
2. Fork the repository by clicking "Fork" in the top right.
3. Add your CIP to your fork of the repository. There is a template CIP here.
4. 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.

CIP Status Terms

• 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.

CIP List

Highlighted CIPs

These CIPs significantly influence the economic and governance models of Conflux, as well as its various features.

These CIPs are primarily aimed at following EIPs to maintain compatibility with Ethereum. The specifications are highly align with Ethereum.

The following CRCs do not have dedicated documentation; they are identical to the corresponding ERCs.

Spec Breaking CIPs

Ongoing

These CIPs are either in the midst of active development or have been fully developed, currently awaiting discussions on upgrade plans.

Activated

These CIPs have successfully undergone upgrades on the mainnet.

List of Hardforks

Dormancy

These CIPs have been dormant, lacking recent discussions or follow-ups.

Replaced

These CIPs have been replaced by other CIPs.

Database / RPC Breaking CIPs

These CIPs, while not requiring hard fork upgrades, could potentially impact the database or RPC.

Application-level CIPs

These CIPs establish standards at the application layer, thereby not involving upgrades to the Conflux nodes.