各位社区的小伙伴，FC 赋能需要大伙儿的集思广益。

[fei221122]

fc在生态上有空投质押的权利，项目方可以考虑下把fc和cfx的做成母子币，fc用于生态和社群治理，cfx用于金融，希望官方考虑下，

[mengxianshi669]

关键是对FC的定位，社区是与conflux共同体，如果老是把FC作为一把割韭菜的利器，终究是走不远的

[518]

我觉得拥有FC的伙伴是对conflux贡献最大的，最初始的贡献者，就像开始推广支付宝的推广员一样，是conflux的开拓者，应该按照FC的多少分配原始股，或等同于原始股的权益。

[anby518]

FC本身就是社区治理币和投票币，我们应该发挥他的优势，继续为新人赋能，让新来的继续宣传，还有1000多万个如果能吸引更多新人，这就是它的价值。

[DP168]

既然已经提到了 2100w后没有铸币权 而且全部由社区自治 那么社区自治就明正言顺了 而项目方为了大家利益 还进行了保底 哪怕社区没利用好fc 还有cfx价值兜底 不急于变现 还有质押得分红拿 综上所述 感谢项目方 感谢conflux 为大家考虑了这么多
cfx为生态开发和矿场，投资方所用
剩下的fc就是社区所有小伙伴和fc持有者们的事了
0.1刀 还是10刀 100刀 你们看着办吧

[wangbin]

fc是社区的心血和时间付出的象征，可以把cfx生态的价值分点给fc

[Aaron]

官方这样做无非在割社区韭菜，为什么要这样？fc都是多少为conflux辛辛苦苦贡献者辛辛苦苦得来的，说1：1就兑换了，一开始为什么不直接发cfx？完全把fc稀释了，还免费得了这么多人一两年的免费劳动力，官方三思而后行呀

[LU6688]

质押10000FC一天收益1.09CFX

[No1]

FC是社区守护者心血，应该1：5兑换CFX，至少也应1：2兑换

[3013143008]

这也不是1：多少的问题，只是想让FC有更多功能，附加价值

[73745818]

1、前期fc有过治理与投票功能，后期是否可以完善以往缺陷，重整后推出相关赋能?
2、fc应该有一个牵头组织或团队，目前可以是基金会，后期呢?社区综管会?还是其他团队(议题迫切需要提上日程)
3、主网即将上线，FC是否要在同期或后期规划其他交易所上线?
4、既然区别cfx,建议fc专业专精、规避风险、另起炉灶。

[LU6688]

FC先完成对CFX1:1的兑换，然后以兑换的数目进行质押消毁，质押方可连续获取4年质押收益。

[fengyun]

问题是生态治理的范围和边界

[fengyun]

不如把fc的区块链公平投票的功能出圈做大，有偿使用，比如商业调查，问卷调查等等，使用方可到fc池子里租用，这样可以创造盈利，fc的投票机制也可以保证去中心化的有效数据。所有的收益归fc持有者。

也可以把社区开放独立，所有的生态想通过社区推广宣传就拿efx竞标附能，然后在把efx奖励的按劳分配给干活的成员。如果想成为社区正式级别会员，就得拥有fc门票。

[fengyun]

fc社区会员都可以维护自己的群，长期为区块链优质生态有偿传播，优质生态可由社区组委会审核

[hence]

fc与cfx一比一兑换，且fc数量远少于cfx，导致存在套利空间，使fc的价格将稳定的高于cfx。又因为fc只能与cfx单向兑换的模式，使得fc只能在交易所交易，缺乏消费场景。

1.闭环。
解铃还须系铃人。fc模式，处于中心化的发放，那么需要一个中心化的消费场景。可以将目前有的烤仔小店作为主要场所，形成引流的商业闭环。问题:那么为什么fc持有者愿意在烤仔小店消费，而不是兑换成法币。
答:可以将烤仔小店的模式设计成，面对fc持有者的低价的消费场景。比如，持有者可以在烤仔小店以非常低的价格买到机票。

问题，价格上，烤仔小店出大头，的确可以让用户获得fc的积极性增加，但如此一来，入不敷出，无法存活。
答:需要一个新的贡献度评判模式。

2.衡量标准
fc+nft
fc可以用作完成任务的衡量，但fc同样作为价格衡量，两者之间概念比较模糊。随着conflux的发展，今后的任务难度会拉大，从解决难度上说，应该将微小难度任务，一般难度任务，中等难度任务，重大难度任务相互分别，可结合nft概念，用nft来构造“勋章”来标记解决者的贡献，也显示了解决问题的难度。同时也是对解决者的能力的标记，对未来多方之间相互合作，留下场景基础。比如，可以与现在领取cfx的公链dapp建设团队进行贡献度nft发放，标记其贡献与能力。

3.反哺
烤仔小店的折扣
拥有nft勋章的团队，根据其贡献，可以在烤仔小店的部分领域享受相应折扣，由烤仔小店或基金会提供折扣补助。在nft的证明下，也可用稳定币交易，不必用fc进行交易，以避免较大的价格波动。

4.孵化
fc+nft+代币证券化

对于建设团队和官方，可能双方都不希望合作是拿笔死钱，干件预定的事。既然有能力可以继续发挥想象。
官方可以决定，当建设团队拿了多大级别的nft标签，或多少同级别的nft标签后，可以对这个团队背书，通过代币证券化，发放代币，官方基金会可以进行preA的投资。或是质押fc或cfx或别的方式，开展流动性挖矿或别的产生代币的方法。将其代币纳入cfx网络中，成为自身公链积木的一部分。不止是拥有nft标记的团队，而且使用其dapp的用户，也可按使用时长换取烤仔小店的相应的“兄弟折扣”。

5.生态
烤仔小店不仅提供商品的交易，也提供合作的交易。获得nft标记就是技术的含金量，在cfx网络的强大的跨链技术下，用户可用各种相应的代币与各团队进行合作上的交易。

概要

本文本将被隐藏

概要

本文本将被隐藏

[Observer.cfx]

在进行这些讨论之前，我觉得大家有必要复习一下公众号文章《Conflux CIP （改进提案）机制》。内容如下：
CIP 针对 Conflux 网络的新功能或新的运行环境提供详细描述，包括全节点功能的改进提案，如新增 VM 指令等，亦包含周边开发的标准（类 ERC20）等。CIP 将核心代码升级规范化、开放化，为 Conflux 网络去中心化研发的有序高效率进行提供了基础。

比特币有闪电网络（Lightning Network）、Taproot/Schnorr 签名、Miniscripts 以及许多改进升级，以太坊同样也有 EIP20、EIP137、EIP1155、EIP1679 和 EIP1559 等提案，每一个提案都对其网络的运行产生了重大影响。

CIP 将成为 Conflux 网络提案新功能、收集社区建议以及记录提案文档的主要机制。

CIP 提案共有四种状态，分别为草案（Draft）、公示（Last Call）、认可（Accepted）和最终生成（Final）。

所有涉及核心代码、生态开发的内容，都可以在 CIP 上进行提案。提案会以“CIP-X”编号形式呈现，提案一旦在 CIP 上被接受，提案实施必须完成，当提案实施完成并被社区接受时，状态将更改为“最终生成（Final）”。

目前在 CIP 上已有 11 个提案，内容覆盖 CIP 提案撰写规范、数据结构和如何处理执行中细节问题等。

通过 CIP 的提案，可以了解到 Conflux 网络参与者、关注者们的最新动向、如何规划 Conflux 网络的未来，并能感知到项目自身需要面对的挑战。

Conflux 认为，区块链技术最大的价值在于去中心化和安全性，而只有基于 PoW（工作量证明）的共识机制才能最大限度地保留这些优点。

对于 Conflux 来说，去中心化的选择不仅局限于组织成立 DAO 分布式自治社区，还要将 Conflux 网络未来的技术走向从几个研发人员的权限交付到每个人手中。

CIP 为 Conflux 网络实现技术研发的去中心化提供了规范的提案标准，迈出了从中心化开发团队到去中心化开发的重要一步，也是 Conflux 践行去中心化理念的重要探索之一。

志同，而气合。

Conflux 乐于与公众和社区成员分享这种探索，与志同道合的伙伴共同促进行业的进步和开放式发展。

CIP链接：github.com/Conflux-Chain/CIPs

Conflux 改进提案（CIP）规定了 Conflux 平台的标准，包括核心协议规范、客户端 API 和合同标准。

贡献提案的方式

1.阅读 CIP-1。
2.点击右上角的“Fork”复刻存储库。
3.将您的提案添加至您的存储库复刻。点击此处查看模板 CIP。
4.请求 Conflux CIP 库拉取你的提交（Pull Request，PR）。

您的第一个 PR 应该是最终通过的 CIP 的草案（Draft），必须符合开发要求的格式标准（通常要在标头中包含正确的元数据）。CIP 编辑会人工审核每个新的 CIP 的首个 PR，并在合并前为其指定一个 CIP 编号。确保包含讨论链接，附带讨论论坛或开放 GitHub 的链接，以便人们可以讨论整个 CIP。

如果您的 CIP 需要图片，图片应该放在 CIP assets 文件夹的子目录中，如：assets/CIP-N（N 是指 CIP 编号）。链接到 CIP 中的某张图片时，链接路径如：…/assets/CIP-1/image.png.

您的 PR 被合并后，我们会有机器人自动将 PR 合并至 CIP 中。为确保这一点，机器人需要能够确认您对当前 PR 的所有权，因此，请确保您提交的 CIP“作者”栏包含您的 GitHub 用户名或电子邮箱地址。如果您选择使用电子邮箱地址，该地址必须是您在 GitHub 个人资料上公开展示的地址。

当您认为自己的 CIP 已经成熟并且准备好通过草案（Draft）阶段时，可以发起请求将您的问题添加到即将举行的全体核心开发者会议（All Core Devs meeting）的议程中，可以在会议上讨论是否将其包含在将来的硬分叉中。如果执行者同意将其包含进去，CIP 编辑就会更新你的 CIP 状态为“认可（Accepted）”。

CIP 状态术语

· 草案（Draft）——快速迭代和更改状态下的 CIP。
· 公示（Last Call）——初步迭代阶段已经完成，准备好给更大范围评审者评审的 CIP。
· 认可（Accepted）——已经进入公示极阶段至少2周的 CIP，并且作者已经解决了所有必要的技术变更问题。核心开发者决定是否将一个 CIP 作为硬分叉的一部分编码进客户端的过程不属于 CIP 进程。如果做出了这样的决定，CIP 就会进入“最终生成（Final）”阶段。
· 最终生成（Final）——核心开发者决定执行并将在未来的硬分叉中发布，或已经在硬分叉中发布过的 CIP。

什么是 CIP？

CIP 全称是 Conflux Improvement Proposals，即 Conflux 改进提案。CIP 是一个设计文件，向 Conflux 社区提供信息，或规定 Conflux 的一些新功能、流程或环境。CIP 中应当简介该功能的技术规范以及基本原理。

我们计划将 CIP 作为提议新功能、收集社区对问题的意见以及记录已纳入 Conflux 的设计决策的主要机制。CIP 作者负责在社区内构建共识、记录有异议的观点。由于 CIP 在版本库中作为文本文件进行维护，因此 CIP 的修订历史记录就是功能提案的历史记录。

对于 Conflux 执行者来说，CIP 是一种很方便的追踪执行进程的方式。理想情况下，执行的维护者会列出他们已经执行过的 CIP 的清单，这为终端用户提供了一种便捷的途径来了解指定执行或库的当前状态。

CIP 分类

有 4 种不同类型的 CIP：

· 向后兼容变更：这种 CIP 中更新的客户端会完全兼容以前的旧版本，这种变更会引入另外的远程过程调用（RPC）API 或其他新功能。提交向后兼容变更时请采用以下步骤：

· 复刻 Conflux Rust 库，提交拉取请求（PR）；
· 如果是复杂变更，首先要提交问题与核心开发团队沟通。

数据库/ RPC 变更：更新的客户端能够与以前的版本共存，但是它可以更新现有 RPC 的接口或行为，或者可以更改区块链数据库格式。需要根据这些 RPC 对应用程序进行修改和/或清理数据库以重新开始进行同步。要提交数据库/RPC变更，可以按照上述步骤进行操作，但必须先提交一个问题。

· 网络协议变更：这些更改不涉及 Conflux 协议的规范，需要更新 Conflux 或 Conflux-Rust 中的 P2P 网络协议。无需硬分叉即可实现更改，但需要特殊的协议版本处理和兼容性测试。要提交协议变更，请按照以下步骤操作：

·提交一个 CIP 草案（Draft）。
·讨论该草案（Draft）直至草案认可。请注意，在 CIP 中，指定当前执行如何与先前协议版本保持兼容性是很重要的（通过版本控制或其他技术实现）。如果无法做到这一点，则应将变更划分为规范变更。
·在 Conflux-Rust 中创建与该 CIP 相关的问题。
·提交 PR 执行该 CIP。
·审核、测试、和/或确认执行。PR 会被合并到主分支上。核心开发团队可能会选择将 PR 合并到其他分支，进行 Conflux-Rust 客户端发布。
·发布版本实现变更后，将 CIP 状态更新为“最终版”。

· 规范变更：此类变更需要更新 Conflux 协议的规范，需要硬分叉才能实现变更，完全没有向后兼容性。进行规范变更的一般步骤如下：

·提交一个 CIP 草案。草案中应讨论如何在硬分叉中实现变更。
·讨论该草案直至草案认可。
·在 Conflux 协议库中创建与该 CIP 相关的问题。
·提交 PR 至 Conflux 协议库根据该 CIP 更改规范。
·在 Conflux Rust 库中创建与该 CIP 相关的问题。
·提交 PR 执行该 CIP。
·审核、测试、和/或确认执行。PR 会被合并到主分支上。
·等待硬分叉以实现变更。更改 CIP 状态至“最终生成”。

注意：目前 Conflux-Rust 中的轻客户端模式是实验性的。仅影响轻客户端的所有变更目前都被视为“向后兼容变更”。

强烈建议单个 CIP 仅包含一个关键提议或想法，CIP 针对性越强，被通过的成功率就越高。仅涉及到一个客户端的更改不需要 CIP，会影响多个客户端或定义多个应用程序使用标准的更改需要 CIP。

一个成功的 CIP 必须满足一定的最低标准。它必须清晰、完整地描述了提议的改进功能，改进功能必须是净改进。提议的执行（如果适用）必须是可靠的，并且不能使协议过于复杂。

如果 CIP 提及或提议对虚拟机进行更改，则它应参考其指令助记符的说明，并定义至少一次这些助记符的操作码。首选方式如下：
· REVERT (0xfe)

CIP 工作流程

CIP 引导

参与此过程的各方包括您，也就是 CIP 贡献者或原作者，以及 CIP 编辑者和 Conflux 核心开发者。

在开始编写正式的 CIP 之前，您应该先审视一下自己的想法。首先需要询问 Conflux 社区您的想法是否是独创的，避免因为之前已有过相关研究会被拒绝而浪费时间。因此建议您在此存储库的“问题（issue）”部分中打开一个讨论线程。

除了确保您的想法具有独创性之外，您还将作为作者向审稿人和相关方明确您的想法，并邀请编辑、开发人员和社区通过上述渠道提供反馈。您应该尝试衡量一下 CIP 的关注度是否与执行 CIP 所涉及的工作量以及有多少方必须遵守该 CIP 相一致。例如，执行规范变更 CIP 所需的工作量比执行向后兼容 CRC（循环冗余校验码）大得多，并且 CIP 需要 Conflux 客户端产品团队足够多的关注。负面的社区反馈将被考虑在内，可能影响您的 CIP 通过草案阶段。

由于 CIP 需要将客户端执行视为最终版标志（请参阅下面的“ CIP进程”），您需要提供客户端执行，或说服客户端执行您的 CIP。

总之，作为 CIP 拥护者，您需要用以下格式写 CIP，在对应论坛中引导 CIP 的讨论，并围绕这个想法建立社区共识。

CIP 进程

成功通过的 CIP 流程如下：
· 想法阶段 -> 草案阶段 -> 公示（Last Call） -> 认可（Accepted） -> 最终版
每次状态变更都需要由 CIP 作者发起请求并且由 CIP 编辑审核。使用 PR 更新状态。请附带链接方便人们继续讨论您的 CIP。CIP 编辑会根据以下条件处理这些请求。

· 想法——如果 CIP 拥护者已经问过 Conflux 社区是否有任何通过的机会，他们会撰写一份 CIP 草案进行拉取请求（PR）。如果执行有助于人们研究 CIP，可以考虑提供一个执行。

· 草案（Draft）——如果 CIP 可以接受，编辑会为该 CIP 分配一个编号（通常是与该 CIP 相关的问题或 PR 的编号）并合并您的 PR。CIP 编辑不会毫无理由地驳回 CIP。
· × 草案（Draft）——驳回草案的原因包括不够专注、过于宽泛、重复工作、技术上不够健全、没有提供适当的动机、没有解决向后兼容性问题，或者不符合 Conflux 理念。

· 草案（Draft）——合并第一份草案后，您可以提交后续的 PR，并对草案进行进一步更改，直到您认为 CIP 成熟并准备好进入下一阶段。

· 公示（Last Call）——如果 CIP 可以接受，编辑会将 CIP 指定为公示（Last Call）阶段，并设置审核结束日期（review-period-end），通常为14天。
· × 公示（Last Call）——如果仍然需要对草案进行必要的更改，CIP 进入公示（Last Call）阶段的请求会被驳回。我们希望所有 CIP 都只需要进入公示（Last Call）阶段一次。

· 公示（Last Call）——该 CIP 将在网站上的显眼位置列出。
· × ——如果公示阶段发现需要必要的更改或未解决的技术问题，CIP 会被退回草案状态。
· 已接受——成功的公示，不需要做必要更改、没有未解决的技术问题的 CIP 将进入“认可”状态。

· 认可（Accepted）——此状态表明不需要进行必要更改，Conflux 客户端开发人员应考虑将此 CIP 包括在现实计划内。核心开发人员决定是否将 CIP 作为硬分叉的一部分编码进客户端的过程不属于 CIP 进程。
· 草案（Draft）——核心开发人员可以自行决定将此 CIP 退回草案状态。例如：在 CIP 中发现了一个但可纠正的缺陷。
· 被驳回——核心开发人员可以自行决定将此 CIP 标记为被驳回。例如：在 CIP 中发现了一个且不可纠正的缺陷。
最终版——在最终通过之前，CIP 必须要先被执行。执行完成并且被社区采用时，CIP 状态会被更改为“最终生成”。

· 最终生成（Final）——此时的 CIP 代表了当前的最新水平。最终版的 CIP 只有在进行勘误时才可以更新。
其他异常状态包括：
· 激活——如果有些 CIP 本身是无法最终完成的，也可能会包含“激活”状态。如：CIP-1 （本 CIP）。
· 遗弃——原作者不再采用该 CIP，或者不再将它作为（技术上）的首选项。
· 草案（Draft）——作者或者想要采用该 CIP 的拥护者可以请求更改草案状态。
· 被驳回——被核心开发人员从根本上驳回的 CIP，并且不会被执行。进入此阶段的 CIP 不会再更新为其他状态。
· 被取代——之前的最终版 CIP，但是不再是当前的最新水平。会有新的 CIP 进入最终版状态，并引用被取代的 CIP。进入此阶段的 CIP 不会再更新为其他状态。

成功的 CIP 包含什么？

每一个 CIP 都需要包含以下部分：

· 前导码——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 的底部。

CIP 格式与模板

必须使用 Markdown 格式写 CIP。图片文件应该放置在 CIP 资产文件夹的子目录中，如：
asset/cip-N（将 N 替换为 CIP 编号）。

链接到 CIP 中的某张图片的相关链如：…/assets/cip-1/image.png.

CIP 标头前导码

每个 CIP 必须以 RFC 822 样式的前导码开头，并在其后跟三个连字符（-）。此标头在 Jekyll 中被称为“前件”（front matter）。标头必须按照以下顺序排列：标有“ *”的标题是可选的，如下所述。其他所有的标头都是必选的。

cip: CIP 编号（由 CIP 编辑指定）
title: CIP 标题
author: 作者姓名和/或用户名列表，或作者姓名和邮箱地址列表具体细节如下。

• discussions-to: 指向官方讨论线程的链接
  status: 草案（Draft）/公示（Last Call）/认可（Accepted）/最终版/激活/遗弃/被驳回/被取代
• review-period-end: 审核结束日期
  type: 向后兼容变更/数据库/RPC变更/协议变更/规范变更
  created: 创建日期
• updated: 逗号分隔的日期列表
• requires: CIP 编号
• replaces: CIP 编号
• superseded-by: CIP 编号
• resolution: 指向此 CIP 解决方案的链接
  包含列表的标头必须用逗号分隔不同元素。
  包含日期的标头必须采用 ISO 8601（yyyy-mm-dd）格式。

作者标头
作者标头可以选择列出 CIP 作者/所有者的姓名、电子邮件地址或用户名。喜欢匿名的作者可以只使用用户名，也可以使用姓名和用户名。作者标头值的格式必须为：
Random J. User <[email protected]

或（如果包含电子邮箱地址或 GitHub 用户名）
Random J. User (@username)

和（如果没有提供电子邮箱地址）
Random J. User

解决方案标头
解决方案标头要包含一个URL，指向发出有关 CIP 的声明的电子邮件或其他网页资源。

讨论链接标头
当 CIP 是草案时，讨论链接标头指示正在讨论 CIP 的邮件列表或URL。如果正在与作者私下讨论该 CIP，则无需讨论链接标头。
一个例外情况是，讨论链接标头不能指向 GitHub PR。

类型标头
类型标头指定 CIP 的具体类型：向后兼容变更、数据库/RPC变更、协议变、规范变更

创建日期标头
创建日期标头记录了 CIP 被指定编号时的日期。两个标头都应采用 yyyy-mm-dd 的格式，例如 2001-08-14。

更新日期标头
更新日期标头记录了 CIP 有更新时的日期。此标头仅对“草案”和“激活”状态下的 CIP 有效。

需求标头
CIP 可能包含一个需求标头，表明 CIP 编号。

被取代和替换标头
CIP 可能还会有一个被取代标头，表示该 CIP 已被更高版本的文档淘汰；该值是替换当前文档的 CIP 的编号。新的 CIP 必须具有替换标头，包含已被取代的 CIP 的编号。

附件

CIP 可以包含附件，如图表等。附件命名格式必须是：CIP-N-Y.ext，N 是指 CIP 编号，Y 是序列号码，从1开始，将 ext 替换为实际的文件拓展名，如 “png”。

转让 CIP 所有权

有时有必要将 CIP 的所有权转让给新的拥护者。通常情况下，我们希望保留原作者作为所有权已转让的 CIP 的联合作者，但实际上是否保留由原作者决定。转移 CIP 所有权的较好的原因是原作者不再有时间或兴趣来更新 CIP 或遵循 CIP 流程，或者已经失去网络联系（即无法联系到原作者或作者未回复电子邮件）。转移所有权的不太好的原因包括原作者不同意 CIP 的发展方向等。我们会尝试建立关于 CIP 的共识，但是如果无法达成共识，您永远都可以选择提交一份竞争性的 CIP。

如果你有意获得某个 CIP 的所有权，可以向原作者和 CIP 编辑发信息申请接管。如果原作者没有及时回复信息，CIP 编辑会做出单方面决定（但这个决定是可能会逆转的）。

CIP 编辑责任

对于每一个新的 CIP，编辑都有如下责任：

· 阅读 CIP 并检查是否已经就绪：CIP 需要合理、完善。即使不一定能走到最终版阶段，想法也一定要有技术意义。
· 标题必须能够准确地概括内容。
· 检查 CIP 的语言（拼写、语法、句子结构等）、标记符号（GitHub 偏好 Markdown 格式）和代码类型。

如果 CIP 还没有就绪，编辑会将其退回至作者进行修改，同时会给出具体指示。
如果 CIP 准备就绪可以入库了，CIP 编辑就会：

· 指定一个 CIP 编号（通常是 PR 编号，如果关于此 CIP 的库中的问题部分有讨论过这个问题，作者更倾向于使用问题编号的话，也可以使用问题编号）。
合并对应的 PR。
· 向 CIP 作者回信，告知下一步。

CIP 编辑会监视 CIP 的每一次变更，纠正所有遇见的结构、语法、拼写或标记符号错误。
编辑不会对 CIP 做出评判，只负责行政和编辑部分。

[Observer.cfx]

以下问题，纯属个人观点，持续更新…（欢迎私信给我，讨论完善）
现阶段社区治理主体：社区管委会、技术委员会、算力矿工委员会、官方基金会。
（治理主体可以根据实际情况增加或删除，应由以上主体投票决定）
目前存在的主要问题（矛盾）：FC应该退出历史舞台，还是继续发挥这区治理作用？
基金会观点：
1.永远不会主动销毁 FC。（大佬观点FC还有过渡期，会逐渐退出历史舞台。）
2. 投入2100万CFX矿池的FC（单向不可逆）按比例瓜分年化收益率为 4% 质押收益分红（质押收益原理详见经济白皮书）。转换的CFX可提现。
3.存入累积超过 1000 FC 的用户将获得一个 NFT 作为纪念徽章。
4.FC 将停止发放，FC 铸币权限将被销毁，FC 完全回归于社区，基金会将不再参与 FC 的任何治理工作。
5.把经济上的诉求和共识混为一谈，应予以否定。希望大家能以建设和发展生态为重心。

【技术委员会】观点：编号030 Conflux社区FC治理投票系统

【算力矿工委员会】观点：
1.基金委为社区谋求DAO自治铺垫好了的先决条件。
2.管方已经给予社区法制治理代币D最大诚意和自由
3.社区有价值，FC终将起飞。

【社区管委会】观点：

【守护者观点】观点：

【协调会】观点：人力pow项目，实现每个参与者，终生都有一份保障和盈利。
其他观点：

CIP提案（草案029V0.1版）：
（这是一个牺牲一些人利益的去中心化的议案，能够一定程度对抗巨鲸，但笔者认为对社区治理有长远意义。一个团结、有效、去中化的自治社区，能够最大限度保障FC的价值。）
0.大多数的人类行为是受利益趋势的，我们只有承认个体都具有的利益诉求，才能更好凝聚个体的力量。放弃信仰者可以出售自己的自治权，怀揣理想者可以持有或者购买一定的自治权。
1.未来充分保障FC持有人的利益，各方协调，主动投入1000万FC到CFX矿池，享受8%的质押分红。（FC主动销毁计划第一阶段）
2.理想情况下，剩余1000万FC参与社区治理,这些FC可以交易，且每1000枚FC换算成一份，投票权按持币地址计算，可随FC的流动而流动。（投票期，需锁仓。）
V1=1000FC，有1个投票权。
V2=10000FC，有8个投票权。
V3=100000FC，有60个投票权。
3.采用技术委员会制定的投票系统，投票全程匿名。编号029 Conflux社区FC治理投票系统
4.社区管委会、技术委员会、算力矿工委员会、官方基金会，和未来的其他委员会平权，负责指定提出议案、其他生态项目可以申请补贴，由全社区共同投票决定。

[ljh]

各位大咖，我要个邀请码，谁给我发一个谢谢

[partick]

基于《白皮书》IV-2部分关于社区和生态建设的描述：社区基金：4亿cfx将用于营销和社区建设。未来2100万fc发放完毕后，社区守护工资开始按cfx来发放。

目前守护工资发放按照v1,V2,V3的等级发放，既然基金会明确要将fc完全交给社区，社区拥有fc绝对话语权。我建议：1、将社区证券化，fc就是社区股票。2、v1、v2、v3等级划分按照持有fc的量来定。3、根据等级划分，差异分配cfx工资。4、不再要求fc必须在账户里，只需要持有fc即可拥有对应等级。5、每位员工账户进行每期的检查，卖出或者买入fc后及时调整他的等级，来领取不一样的守护工资。6、要想领取工资，也必须完成守护任务。

以上方法一出，fc必成为市场上趋之若鹜的稀有品种，拥有fc既取得崇高的conflux社区地位，领取高昂的cfx工资奖励，并且在社区治理过程中拥有更大的话语权。并且会吸引更多的人进入社区，参与社区建设，这也复合conflux官方对社区的期待。