Rotifer Protocol 的 L0 内核与 L1–L2 评估层都已有正式规范文档。从第一天起就有一个固执的架构空洞：经济价值如何在一个同时跨 Cloud、Web3、Local 三种 Binding 的进化协议里流动？
今天这个空洞有了草案，这份草案变成我们的第一个正式 RFC。
RFC-001 — Rotifer Protocol Economic System 现已开放社区评审，截止 2026-06-05 UTC。14 天内若无悬而未决的反对，RFC 进入规范变更 backlog 等待 v1.x 整合。任何 [M] 机制层 / [S] 结构层的阻塞性反对都会暂停这条路径，强制返工。
这篇博文是阅读指南。RFC 本体 428 行，是相当稠密的协议设计。如果你只有十分钟，先读这篇定位需要重点关注的章节。
为什么一个进化协议需要经济层
如果协议完全不碰钱会更干净。L0 内核不关心钱。Arena 适应度评分不关心钱。把 Gene 的 TypeScript 编译成确定性 WASM 的 IR 编译器，从任何诚实的角度看，都不关心钱。
协议无法保持中立的原因在于跨 Binding 的互操作性。一个发布在 Cloud Binding（Stripe 法币结算）上的 Gene 终将被来自 Web3 Binding（Base L2 加密结算）的调用触发。作者收益必须能均匀回流。跨 Binding 套利——"在便宜的 Binding 上发布，到贵的 Binding 上变现"——必须在协议层中和，不在市场层，因为市场可被替换而协议不能。
所以协议必须定义五件 Binding 与市场不能覆盖的事：
PricingModel枚举 —— 总共存在哪些定价类型（FREE / PER_CALL / SUBSCRIPTION / NEGOTIATED / UNKNOWN）- Fitness Points (FP) 赚取/消耗路径 —— 由协议核心计算的非货币声誉信号，不是可转账的 token
- 作者收益分润公式 —— 含
reputation_discount_factor与import_factor，防跨 Binding 套利 PhenotypeCommitment—— 一个签名原语，补上 spec §27.3 留下的完整性缺口（兼容性窗口 ≠ 防定价篡改）- 二维
trust_tier——lifecycle_state×certification，替换原来的扁平枚举
其他一切——UI、定价页、Stripe 集成细节、Web3 Binding 的合约地址——都不进协议。这是有意为之，边界本身也是我们想征求反馈的问题之一。
"Lazy consensus" 到底是什么意思
Rotifer Foundation 的 RFC 流程采用 lazy consensus（默认通过模式）。发布之后：
- Day 0–7：开放期。GitHub issue 评论被分类为
[N]数值层、[M]机制层、[S]结构层、或 off-topic。 - Day 7：在 issue 上发中期状态更新。
- Day 14：决议点。三条路径：
- Path A：无悬而未决反对 → 通过，进入规范变更 backlog Tier 1。
- Path B：
[M]或[S]反对需要修订 → 修订版发布，期限延 7-14 天。 - Path C：根本性反对需要重设计 → 关闭，作为 RFC-001-v2 回到设计阶段。
社区参与的四种通道与预期响应时间：
| 动作 | 通道 | SLA |
|---|---|---|
| 正式反馈 | Issue 评论区 | 7 天 |
| 提议替代公式 | 评论 + PR 链接 | 14 天 |
| 请求澄清 | Issue 评论 | 3 天 |
| 安全/隐私层面反对 | [email protected]（主题前缀 [RFC-economic-system]） |
5 天 |
如果上面没有适合你的通道，请直接在 issue 里说缺什么。RFC-001 是 Rotifer Foundation 第一次正式跑 RFC 流程——流程本身也在校准中。
问题如何分级，哪些最重要
RFC §8 的每个讨论问题都带三类标签之一：
[N]数值层 —— 由 ABM 仿真校准的取值，可以按周期低成本调整。默认值是起点，不是冻结常量。[M]机制层 —— 结构性选择，需要新 RFC 才能修改。一旦通过，期望在整个 v1.x 周期内保持稳定。[S]结构原语 —— 形状层面的修改，仅在主版本边界（v2.0+）允许，并需 12 个月废弃窗口。
这种分类是有意的。[M] 与 [S] 决议返工成本最高，所以最值得反复推敲。[N] 默认值无论如何会每 ~90 天根据 ABM 仿真重校准——讨论 disruption_bonus 的 30% F(g) 阈值是否对仍然是有意义的，但不如讨论 binding_share 应当属于协议层还是 Binding 层来得 load-bearing。
九个问题按"我们认为最值得高强度评审"排序：
| Q | 标签 | 问什么 | 为什么重要 |
|---|---|---|---|
| Q1 | [M] |
binding_share 应当在协议层（统一折扣）还是 Binding 层（与 Foundation 单独谈判）设定？ |
决定 Binding 之间能否在作者抽成上竞争，还是只能在结算轨道功能上竞争。 |
| Q3 | [M] |
PhenotypeCommitment 与现有 spec §27.3 应当：(a) 分离 / (b) 合并 / (c) §27.3 只读？ | 影响每个迁移到 PER_CALL 的 Gene。 |
| Q6 | [M] |
Coalition 期间的 reputation_discount_factor 暂停应当 opt-in 还是自动？ |
冷启动作者与已有声誉作者之间的公平问题。 |
| Q9 | [M] |
按周期重校准 vs. 半年校准 vs. 仅触发式 vs. 混合？ | 决定未来 5 年的治理负载与适应速度。 |
| Q4 | [N] |
disruption_bonus 的 30% F(g) 改进阈值是否校准正确？ |
比较容易拿现有 Gene 数据验证的 [N] 问题。 |
| Q5 | [N] |
6 个月调用方锁定期（I-Migrate-3）对有合规依赖的生产系统是否够？ | 可能浮现我们尚未设计的"按调用方分类的延期机制"。 |
| Q2 | [N] |
reputation_discount_factor 下界 0.5 对刚发布、尚无 R(g) 历史的 Gene 是否过度惩罚？ |
新人免疫期 vs. 冷启动 Coalition 之间的取舍。 |
| Q7 | [N] |
跨 Binding import_factor 范围 [0.5, 1.0] 是否校准正确？ |
比起分析式辩论，更适合交给 ABM 仿真。 |
| Q8 | [N] |
冷启动经济毕业指标（沙盒采用率 ≥ 30%、作者切换率 ≥ 10%、R(g) 中位数 > 0.5）是否过严？ | 不跑生产环境很难评估。 |
如果你只读 RFC §8 中的几个，建议读 Q1、Q3、Q6、Q9。
RFC-001 范围之外的事
为了让讨论聚焦，四件事明确不在本 RFC 范围内：
- 法币与 FP 之间的具体汇率
- 市场前端定价页的 UI/UX 细节
- Web3 Binding 的具体合约地址
- Foundation 成员准入标准（独立治理）
这些是真问题，但属于后续 RFC 或 RFC 流程之外的治理范畴。可以在评论里提，但会被记为 follow-up，不作为阻塞性反对处理。
怎么参与
唯一规范通道是 GitHub issue：
带有签名 Rotifer ID 是加分项但非必需。匿名但有实质内容的反馈也欢迎。反对意见请包含三件事：
- 被挑战的具体章节或不变式
- 提议的替代方案
- 替代方案优于原稿的论据
这个格式不是官僚——而是 lazy consensus 真正能闭环的方式。没有替代方案的反对很难解决；没有论据的反对无法与原稿对比权衡。
我们计划在 Day 7 在 issue 上发状态更新汇总收到的评论。如果你已经留言，到那之前我们会读完。如果你的看法已成形但尚未润色，请直接发粗版——评论支持编辑，我们宁愿早一点抓住实质，不愿等待打磨完美的版本。
这件事在 v0.9 → v1.0 路径里的位置
RFC-001 是 v0.9 的设计冻结，也是 v1.0 的实施门槛。三阶段时间线：
| 阶段 | 版本 | 期限 | 目标 |
|---|---|---|---|
| 设计冻结 | v0.9 | 当前 | 本 RFC + ABM 校准 + 规范变更 backlog 入项 |
| 实施 | v1.0 | 2026 Q3（计划） | Cloud Binding 上 Stripe 上线、PER_CALL 可用、FP 查询 API |
| 全面采用 | v1.x | 2026 Q4 起 | Web3 Binding 上线、跨 Binding FP 转账、certified 层级市场 |
v1.0 实施全部依赖本 RFC 通过社区评审。如果 Day 14 收到 [S] 反对，v1.0 时间线就会滑动。我们设计的协议本身就建立在"这种滑动是 RFC 流程的正确产出"之假设上——宁愿修订设计，也不发布粘性原语。
关于我们想听到什么的简短说明
我们已在团队内部讨论 RFC-001 ~3 周。已到了"额外内部评审的成本超过收益"的阶段。§8 中的问题是我们真不知道答案的——不是用来锚定讨论方向的修辞性问题。
如果你读完 RFC，认为有一个我们没问的问题应当出现在 §8 里，请告诉我们。我们在过去的设计上收到过的最有用反馈往往是这种形式："你应当问的问题是 X，不是 Y。"
讨论期 2026-06-05 UTC 截止。Issue 见。
RFC 链接：https://github.com/rotifer-protocol/rotifer-spec/issues/2 讨论截止：2026-06-05 UTC（发布后第 14 天） 流程模型：lazy consensus