· 前导码——RFC 822 样式标题，包含有关 CIP 的元数据，包括 CIP 编号、简短的描述性标题（最多 44 个字符）和作者详细信息。具体细节如下。

· 摘要——对要解决的技术问题的简短描述（约200字）。

· 动机（*可选）——对于想要更改 Conflux 协议的 CIP 至关重要。应该清楚地解释为什么现有协议规范不足以解决 CIP 应该解决的问题。没有足够动机的 CIP 可能会被完全驳回。

· 规范——技术规范应规定所有新功能的语法和语义。该规范应足够详细，以允许当前所有的 Conflux 平台（conflux-rust）可以进行竞争性、互操作性的执行。

· 基本原理——通过描述设计产生的动机以及做出特定设计决策的原因来完善规范。应该描述所考虑的替代设计和相关工作，例如：其他语言如何支持该功能。基本原理部分还可以提供社区内达成共识的证据，并应讨论在讨论过程中提出的重要异议或关切。

· 向后兼容性——所有引入向后不兼容性的 CIP 必须包含一部分描述这些不兼容性及其严重性。CIP 中必须解释作者建议如何处理这些不兼容问题。没有足够向后兼容性讨论的 CIP 可能会被完全驳回。

· 测试案例——对于影响共识变更的 CIP 来说，执行的测试案例是必须的。如果适用，其他 CIP 也可以选择附带测试案例的链接。

· 执行——在所有 CIP 的状态更改为“最终版”之前必须完成执行，但在将 CIP 合并为草稿之前不必完成。尽管可以在编写代码之前就规范和基本原理达成共识，但在进行许多 API 细节讨论时，“粗略共识和运行代码”的原则仍然很有用。

· 安全注意事项——所有 CIP 必须包含的部分，讨论与提议变更相关的安全影响/注意事项。包括对安全性讨论可能很重要的信息、暴露风险，可以在提案的整个生命周期中使用。例如：包括与安全性相关的设计决策、关注点、重要讨论、指向执行的指南和陷阱、威胁和风险概述以及如何解决这些威胁和风险。缺少“安全注意事项”部分的 CIP 将被驳回。审阅者认为没有足够的安全注意事项讨论的 CIP 无法进入“最终版”阶段。

· 版权豁免——所有的 CIP 必须适用于公共领域。版权豁免的示例请参阅此 CIP 的底部。