Core Improvement Proposals (CIPs)

Core Improvement Proposals define standards for the Core platform, including protocol specifications, client APIs, and contract standards.

Contributing

Before writing a proposal, open a CIP issue to describe the idea and gather early feedback. An editor will assign the CIP number.

Review

• What is a CIP
• CIP rationale
• CIP tags
• CIP workflow
• CIP editors
• CIP template

How to start

After discussing the idea and receiving a CIP number:

1. Review the CIP template.
2. Create a draft in the online editor, replacing ID with the assigned number.

Or

1. Fork the repository.
2. Copy the template into the appropriate category under cip/, and name it cip-ID.md.
3. Open a pull request against the master branch.

Place images in static/cip/cip-ID/, where ID is the CIP number. Reference them from Markdown as /cip/cip-ID/image-name.png.

Tags

• Draft: The CIP is under consideration.
• Accepted: The CIP is approved for adoption, often in an upcoming hard fork.
• Final: The CIP has been adopted.
• Deferred: The CIP is not being considered now but may be revisited later.

Categories

CIPs are categorized into various types, each with its own list:

• Core: Improvements involving a consensus fork or changes significant to core development discussions.
• Networking: Enhancements concerning network protocol specs.
• Interface: Client API and RPC specifications, language-level standards, method names, and contract ABIs.
• CBC: Application standards and conventions, such as token standards and name registries.
• Informational: Core design issues and guidance for the community that do not propose new features.
• Meta: Core processes and process changes. These CIPs are more binding than informational CIPs and often require community consensus.

Channels

• Discussions
• GitHub Issues

Machine-readable documentation

Automated tools and language models can use the generated llms.txt index or the complete llms-full.txt corpus. Individual Markdown sources are published under static/llms/. These files are generated after the daily front-matter workflow completes successfully. General documentation and CIPs with final status are included; do not edit generated files manually. The newest packaged corpus is also retained as the non-expiring Latest CoreAI knowledge release, while GitHub Actions keeps the 10 newest temporary workflow artifacts.