Sigrid 宪章 v1.1 · 修订提案
状态：提案稿（DRAFT）。未生效，不具规范效力。 本文按《附则一》要求编写：含修订条款、修订理由、影响评估、回滚方案。 生效需：公示 90 天 → 宪法层表决 → 7 天冷静期 → 双锚定。 v1.0 原文一字不改（其 19499 字节、sha256
024d16b8…必须保持可验证）。
0. 这份文件是什么，不是什么
是：一份可以直接并入 v1.1 正文的条款草案，附诊断与闸门设计。
不是：
- 不是"补丁"。补丁会改 v1.0 的 hash，等于另立新宪章，又要走 90 天——这正是要修的毛病。
- 不是对 v1.0 缺陷的事后追认。v1.0 的缺口按 §4 如实记录，不追认、不掩盖。
1. 缺陷诊断
1.1 核心诊断：生效触发器与锚点义务在文本上互斥
三条联立：
| 条款 | 原文要点 |
|---|---|
| 附则二.1 | "本宪章 v1.0 自其全文 sha256 首次锚定于 Arweave 之时生效" |
| 第 3.2 条 | 工程映射表："多锚点冗余 … 至少两个独立锚点" |
| 第 3.3 条 | "只依赖单一锚点且无降级方案 → 违宪" |
由附则二.1，生效时刻 t₀ 定义为单数事件（"首次"一个锚点完成）。
于 t₀ 时，锚点集合 = {Arweave}，|set| = 1 < 2。
⇒ 任何以"第一个锚点"定义生效、又要求"至少两个锚点"的宪章， 在其生效的瞬间必然不达标。这不是执行疏漏，是条款文本的必然推论。
这就是为什么"补一个 OTS"不能从根上解决：它把违宪区间从"无限长"缩短到 "09:39:39Z → OTS 确认"，但没有消除"生效瞬间必然不达标"这个结构。 下一版若照抄附则二.1，同样的问题会原样复发。
1.2 修复通道被自己的 hash 封死
附则二.1 已把 v1.0 锁定在 024d16b8…。任何补正都改变 hash ⇒ 成为"新宪章" ⇒
按附则一又需 90 天公示。后果：一个 16 KiB 的参数就能把整个修订流程卡死。
这不是"修订很麻烦"，是"修订在结构上被禁止"。一部不能修正的宪章， 在遇到第一个未预见的缺陷时就已经失效了。
1.3 v1.0 自身缺口的精确记录（不夸大，也不缩小）
| 区间（UTC） | 状态 | 依据 |
|---|---|---|
09:39:39Z → 11:48:06Z | 违宪：单一锚点 + 无在途降级方案 | 同时满足 3.3 的两个条件 |
11:48:06Z → OTS CONFIRMED | 未满足 3.2，但不构成 3.3 的"无降级方案"违宪 | pending 证明是在途降级方案，但不是锚点 |
OTS CONFIRMED 之后 | 3.2 达成（2 个独立锚点） | Arweave（存储型）+ Bitcoin（时间型） |
必须说清的两句话：
- 不能声称"v1.0 自生效起即满足 3.2" —— 这是假的，且是 8.1.3 禁止的那类假。
- 可以声称"v1.0 现已在事实上满足 3.2" —— 但仅限 OTS 确认之后，且不追认此前区间合规。
1.4 术语与状态口径漂移
同一份 OTS 证明，历史文档里出现过 PENDING / BITCOIN_ATTESTED / VERIFIED 三种叫法，
而代码里现已是 PENDING_DIGEST / DIGESTED / CONFIRMED。
8.1.3 要求"不伪造存证状态"，但没有定义状态词汇表时，8.1.3 无法机械判定——
"把 DIGESTED 说成已锚定"到底算不算违规，取决于各人脑中的词表。这是可被无意违反的条款。
2. 修订条款（可直接并入 v1.1 正文）
2.1 附则二 全文替换
替换 v1.0 附则二全部 4 款。编号沿用，新增款以字母续接。
## 附则二 · 生效、锚定与生效文本集
### 二.1 生效与公开
（a）本宪章 v1.1 自其全文 `sha256` 首次锚定于**永久存储锚点**（Arweave 或其继任者）之时生效，
并自同一时刻起取代 v1.0。v1.0 保持公开可读、可独立验证，不删除、不改写。
（b）锚定信息（tx id / 区块高度 / Merkle proof）必须**公开可查、任何人可独立验证**，
且该验证不得依赖本组织或任何单一基础设施的存活。
验证所需的结构（步骤链、区块高度、merkle root）须以与语言无关的形式导出，
不得要求第三方安装专用工具才能验证。
### 二.2 暂定生效（PROVISIONAL）与效力中止（SUSPENDED）
（a）宪章生效时，若同一 `digest` 的**独立时间戳锚点**（OTS→Bitcoin 或其继任者）
尚未达到 `CONFIRMED`（定义见二.6），宪章自动进入 **PROVISIONAL**（暂定生效）状态。
（b）PROVISIONAL 期间：宪章**有效**，但下列事项暂缓表决——
宪法层修订、锚点技术变更、第 3.4 条所指的锚点变更。
（c）PROVISIONAL 硬期限 **30 日**。经受影响方申请，可公示 14 日延长一次，最长再 30 日。
**延长仅限一次。**
（d）期满仍未达到 `CONFIRMED` ⇒ 宪章效力**中止**（SUSPENDED）。中止期间：
① 第三条（永久存证）不因中止而失效——已产生的记录与证明仍然成立，且仍可验证；
② 第四条（退出权）不因中止而失效——不得以中止为由阻断数据导出或资金提出；
③ 不得新增任何宪法层义务，不得对用户施加新的实质不利处置；
④ 治理程序**仍可运行**，但仅限用于：解除中止、以及二.3 允许的补正。
不得在中止期间进行实质修订（否则中止将成为一个无法自救的死锁）。
（e）解除中止：达到 `CONFIRMED`，并公示 14 日。
（f）PROVISIONAL 与 SUSPENDED **不是**"违宪"，是**明示的受限状态**。
二者的名称、起止时间、期限余量必须在 `/api/anchor/status` 与前端如实显示（8.1.3）。
### 二.3 补正（Corrigendum）
（a）**允许的四类**，每份补正须逐条声明所属类别：
| 编号 | 类别 | 判据 |
|---|---|---|
| C1 | 内部矛盾 | 两条条文对同一事项给出互斥要求，履行任一条即违反另一条 |
| C2 | 履行不能 | 按原文措辞，某义务在生效之时在数学或物理上不可能被满足 |
| C3 | 术语缺失 | 条文使用未定义术语，且两种合理解释导致不同义务 |
| C4 | 状态口径 | 同一状态存在多个称谓，导致 8.1.3 无法机械判定 |
（b）**补正不得**：
① 新增或删除任何义务；
② 调整任何表决门槛、公示期、时限；
③ 改变锚点独立性、数量或验证标准；
④ 触及第一条、第八条（第 8.4 条为永久不可修订，本款不得被解释为对其的任何放宽）；
⑤ 扩大任何自动化处置的权限（第一条）；
⑥ 以"术语澄清"为名，实质改变谁承担何种负担。
（c）**程序**：
① 公示 14 日（90 日窗口外为 30 日，见 (d)）。公示须含"类别声明"与
"若不补正，则第 X 条在何种情形下无法履行"的书面论证。
② 公示期内任何人类钱包可提异议，异议须公开。
③ 异议由 ≥2 名**不同**人类钱包判定，判定记录锚定。
④ **分类存疑时，一律按修订处理**（fail-closed，从严）。
理由：把修订误判为补正，等于绕开 90 天公示；把补正误判为修订，
代价只是多等 90 天。两种错误的代价不对称。
⑤ 通过后，补正记录锚定，并登记进生效文本集（二.5）。基准文本 hash **不变**。
（d）**时间窗（两档）**：
| 窗 | 允许类别 | 公示 | 表决门槛 |
|---|---|---|---|
| 生效后 **90 日**内 | C1 / C2 / C3 / C4 | 14 日 | 宪法层 |
| 90 日**之后** | 仅 C3 / C4 | 30 日 | 宪法层 |
| 任何时候 | 实质规则变化 | —— | **只能走完整修订（90 日）** |
**90 日后为何收窄**：宪章运行 90 天后，各方已据其行事（reliance）。
改动内部矛盾（C1）或履行不能（C2）会实质改变"谁承担什么"；
而术语与状态口径（C3/C4）是定义性的，不移动负担分配。这条线是诚意的分界。
补充理由（为何这条线可操作）：**C1/C2 自显，C3/C4 渐显**。
矛盾的条款在你一试图履行时就会撞上；按原文不可能的**义务**在第一次执行时就暴露。
这两个类别在 90 天内几乎必然被发现（事实上 v1.0 的锚点缺口就是）。
而"某术语有两种合理解释"往往要等第二个读者出现才浮现——所以它需要更长的可补正期。
### 二.4 版本链
本宪章的历次修订形成**版本链**：每一版的 `base_sha256` 均记录其前任的 `base_sha256`，
链条不可断裂。版本链的每一节均可独立验证（第三条）。
### 二.5 生效文本集（Effective Set）
宪章作为规范对象**不是一个文件**，而是：
生效文本集 = { 基准文本 base, 已生效补正集 [c1, c2, …] }
（a）基准文本 hash 一经锚定即不变；补正不改变它。
（b）任何声称"现行宪章"的引用，**必须**同时给出：
effective_id = sha256("sigrid:charter-effective:v1:" ‖ base_sha256 ‖ sorted(补正 sha256[]))
（c）任何人仅凭 `effective_id` + 公开锚点，即可复算出"某一时刻生效的完整规范文本"。
（d）**禁止只引用 base hash 而不说明是否存在已生效补正。**
—— 这是"不改变 hash"的必要配套。一个 hash 稳定、含义却在漂移的文本，
比 hash 变化更危险：两个人说"读 v1.1"，可能读的是两套不同的义务。
### 二.6 锚点状态口径（与代码同名，禁止别称）
| 状态 | 含义 | 允许的对外表述 |
|---|---|---|
| `PENDING_DIGEST` | 只算出 digest，未提交 | 只能说"已算出哈希" |
| `DIGESTED` | 日历已收下，**无任何比特币事实** | 只能说"已提交，待确认" |
| `CONFIRMED` | 有区块高度 **且** merkle root 对链验证通过 | 唯一可称"已锚定到比特币" |
定义以 `ops/arweave/ots.mjs` 的 `STAGE` 常量为唯一来源。
`CONFIRMED` 的两个条件缺一不可；只有高度、未验证 ⇒ 仍为 `DIGESTED`。
### 二.7 正本
本宪章中文版本为正本。其他语言译本仅供参考，冲突时以中文正本为准。2.2 新增 第 3.2-A 条（资源边界的界分）
插在 3.2 之后、3.3 之前。不改 3.2/3.3 任何一字，只补一层界分。
### 3.2-A 资源边界 ≠ 速率歧视
3.2 的"公开、无鉴权、无速率歧视"约束的是**区别对待**，不是**资源上限**。
（a）允许且必须公开声明的资源边界：请求体上限、单次计算时长上限、并发上限、响应体上限。
这些上限必须对所有调用者**完全相同**。
（b）一个上限**不构成**速率歧视，当且仅当同时满足：
① 与调用者身份、钱包、付费状态、来源 IP/ASN **无关**；
② 上限值在文档中公开，超限时返回可识别的错误（如 `413 body-too-large`）；
③ 同一上限适用于所有人，**包括运营方自己**。
（c）**构成**速率歧视（因而违宪）的情形，例如：
① 按来源、钱包或付费与否施加不同上限；
② 对第三方验证请求施加人工审批、白名单或隐性延迟；
③ 以"防滥用"为名，仅对非运营方限流。
（d）现行 `POST /api/anchor/verify` 的 **16 KiB** 请求体上限，性质是**计算成本边界**
（公开端点对任意请求免费算哈希，必须有上限），不是准入条件。
若将来业务对象普遍超过 16 KiB，应**提高上限并公示**；
不得改为"大对象需申请"或"大对象走付费通道"——那会让 3.2 的"任何第三方"失效。2.3 附则三 · 状态表更新
只更新"当前状态"列，条款与实现位置不动。凡标 ✅ 者均附可复跑的回归入口。
| 宪章条款 | 工程实现位置 | 当前状态（2026-11-11） |
|---|---|---|
| 1.1 人类最终放电权 | audit/enforce.ts、circuit.ts（L3 双签） | 待实现（M2） |
| 2.1 动机审计 | audit/fingerprint.ts、patterns/p1-p7 | 待实现（M2-M3） |
| 3.1 永久存证 | anchor/pipeline.ts、merkle.ts、ops/arweave/anchor_document.mjs | 文档级 ✅（宪章 v1.0 已双锚定在途）· 管道 ✅（含 §A2 漂移闸）· 事件级存储 ⏳（store: null ⇒ 503） |
| 3.2 多锚点冗余 | Arweave + OTS→Bitcoin | 1/2 成立：Arweave ✅ / OTS DIGESTED（待 CONFIRMED） |
| 3.2 独立验证 | POST /api/anchor/verify | ✅ 已实现：无鉴权、统一 16 KiB 上限、anchor-route.test.mjs 锁定"超限 ⇒ 413" |
| 3.2-A 资源边界 | anchor-route.mjs MAX_VERIFY_BODY_BYTES | ✅ 已实现（上限对预缓冲 body 同样生效） |
| 3.3 状态诚实 | ops/arweave/ots.mjs STAGE / assess() | 后端 ✅（三态唯一来源）· 前端 ⏳（AnchorVerifyPanel 尚未接三态） |
| 4.1 退出权 | routes/export.ts、routes/wallet.ts | 待实现（M3） |
| 5.1 底层可迁移 | anchor/（多锚点）、canonical.ts | 部分（M1-M3） |
| 6.1 层分离 | governance/layers.ts | 待实现（M3） |
| 7.1 代际传承 | 本文档 + 全部架构文档 | ✅ |
| 8.1.1 不发行代币 | LedgerType 无 TRANSFER | ✅ 已定 |
| 8.1.2 无 PII 上链 | anchor/guard.ts | 待实现（M1） |
| 8.1.3 状态诚实 | 前端 AnchorStatus 映射 | 后端 ✅ / 前端待实现（M2） |
| 8.1.4 数据诚实 | 上游适配器降级标注 + 读节点 degraded | ✅ 部分（ao-read 已落地） |
| 8.1.5 不囤卡 | 无相关代码路径 | ✅ 天然满足 |
| 8.1.6 治理权不可买 | Proposal 权重 = trustScore | 待实现（M3） |
| 8.1.7 规则一致 | 规则引擎无例外分支 | 待实现（M2） |
3. 补正通道的七道闸（防它变成后门）
引入补正通道，最大的风险是它变成"绕过 90 天公示的快捷方式"。 一个为修复缺陷而设的条款，本身必须比被它修复的缺陷更严谨。
| # | 闸 | 防的是什么 |
|---|---|---|
| 1 | 四类限定（C1-C4），每份须声明类别 | 把"想改规则"包装成"修 bug" |
| 2 | 六项禁止清单（不增删义务、不动门槛、不碰 1/8 条…） | 以技术性补正实质修宪 |
| 3 | 分类存疑一律按修订 | 边界模糊时的系统性偏袒——从严 |
| 4 | 90 日后收窄至 C3/C4 | 长期"慢慢补"，架空 reliance |
| 5 | 生效文本集 effective_id 强制引用 | hash 不变而含义漂移 |
| 6 | 补正记录独立锚定 + 版本链 | 事后悄悄替换某条补正 |
| 7 | 异议判定需 ≥2 名不同人类钱包 | 运营方单方裁定"这是补正不是修订" |
第 3 条是全部闸门的地基。理由不是"谨慎"，是代价不对称： 误判为补正 ⇒ 实质修宪免公示；误判为修订 ⇒ 多等 90 天。前者破坏制度，后者只是慢。
4. v1.0 自身缺口怎么处置（不追认、不掩盖）
结论：v1.0 的缺口用"事实补正"关闭，不用"解释补正"关闭。
| 缺口 | 处置 | 是否追认此前合规 |
|---|---|---|
| 生效时仅单一锚点 | OTS 达 CONFIRMED 后，事实上具备 2 个独立锚点 | ❌ 不追认。区间 09:39:39Z → CONFIRMED 如实记为"未满足 3.2" |
| 无补正通道 | 由本文 v1.1 建立，仅向前适用 | ❌ 不追溯。v1.0 期间的任何补正都不被本条款合法化 |
| 状态口径不统一 | 由二.6 统一词汇表，仅向前适用 | ❌ 不追溯；历史文档的旧叫法保留原样并加注 |
为什么不追认：追认等于承认"宪章可以事后宣布自己一直合规"。 一旦这条成立，8.1.3 就死了——因为任何伪造都可以事后追认为"当时的意思"。 v1.0 的那段不达标是真的，就让它留在记录里。
5. 公示与生效时间表
| 阶段 | 起 | 止 | 动作 |
|---|---|---|---|
| 公示 | 2026-11-11 | 2027-02-09 | 本文公开，接受异议（90 日） |
| 表决 | 2027-02-09 | —— | 参与率 ≥30%、赞成 ≥80%、人类钱包 ≥50% |
| 冷静期 | 表决通过日 | +7 日 | 可发起撤销动议 |
| 双锚定 | 冷静期结束 | —— | v1.1 全文 sha256 → Arweave + OTS |
| 生效 | 冷静期结束 且 Arweave 锚定完成 | —— | 进入 PROVISIONAL |
| 达标 | OTS CONFIRMED | —— | 退出 PROVISIONAL；3.2 达成 |
若 2026-11-11 起算 90 日，落点为 2027-02-09；加 7 日冷静期，最早 2027-02-16 生效。 在此之前，v1.0 仍是唯一有效文本，本文不约束任何人。
一个必须提前说清的事实：在 v1.1 生效前，v1.0 的缺口只能靠 OTS 确认来关闭。 若 OTS 一直不确认，v1.0 就一直是"1/2 锚点"——本文不能救它， 这正是"不能修正的宪章"的真实代价。
6. 红队自检：这份修订可能怎么被玩坏
| 攻击 | 手法 | 现条款是否挡住 |
|---|---|---|
| 补正当修订用 | 把"降低表决门槛"声称为 C3 术语澄清 | 挡：闸 1+2，且分类存疑 ⇒ 修订 |
| PROVISIONAL 常态化 | 反复延长 | 挡：仅可延长一次，期满自动中止 |
| 中止当冻结令 | 借 SUSPENDED 冻结不利条款（如退出权） | 挡：二.2(d)② 明定第四条不失效 |
| 中止造成死锁 | 中止后无法修宪自救 | 挡：二.2(d)④ 治理程序仍可运行（仅限解除与补正） |
| hash 稳定、含义漂移 | 只引 base_sha256 不引 effective_id | 挡：二.5(d) 明令禁止 |
| 悄悄换补正 | 事后替换某条补正文本 | 挡：每条独立锚定 + effective_id 覆盖补正集 |
| 用 16 KiB 排挤第三方 | 大对象"需申请" | 挡：3.2-A(d) 明令不得改申请制 |
| 拿"资源上限"做歧视 | 对不同来源设不同上限 | 挡：3.2-A(b)① 与实际代码一致（统一上限） |
仍未被覆盖的两处，我列出来而不假装解决了：
- 异议判定人如何产生。二.3(c)③ 只说"≥2 名不同人类钱包"，未定选任规则。 在治理系统（M3）就绪前，这条在实操上依赖人工。这是已知薄弱点。
- C2（履行不能）的判定仍需人来认定。"数学上不可能"对锚点类是客观的， 对"义务过重"类则不是。二.3 只给了类别名，没给判据细则。这也是已知薄弱点。
7. 影响评估与回滚方案（附则一要求）
7.1 影响
| 对象 | 影响 |
|---|---|
| 宪章本体 | 只增补附则二、3.2-A、附则三状态列。第一至八条零改动 |
| 现有实现 | 无破坏性改动。3.2-A 是对现状的描述性确认（代码已是统一上限） |
| 运营层 | 新增一项常态义务：/api/anchor/status 必须暴露 PROVISIONAL/SUSPENDED |
| 用户 | 无新增负担。二.2(d) 反而在效力中止时保护退出权与已产生证明 |
| 后续修订 | 获得 14 日补正通道（90 日内）；但受七道闸约束 |
7.2 回滚
| 情形 | 动作 |
|---|---|
| 公示期内反对强烈 | 撤回提案，v1.0 继续有效，无任何状态变更 |
| 表决未通过 | 同上；本文归档，不产生锚定记录 |
| 生效后发现二.3 被滥用 | 走完整修订（90 日）收窄或废除二.3 —— 不能再用二.3 去改二.3 |
| OTS 始终不确认 | 宪章停在 PROVISIONAL，30 日后 SUSPENDED；此时仅可解除中止或补正，不能实质修宪 |
最后一条是刻意的：中止状态不能成为逃避宪章的地方。
8. 改动清单（v1.0 → v1.1）
| 位置 | 改动 | 性质 |
|---|---|---|
| 附则二.1 | 改为"首次锚定于永久存储锚点即生效" + 自动进 PROVISIONAL | 替换 |
| 附则二.2（原「锚定信息公开可查」） | 原文义务整条保留，并入二.1(b)，并加一句"不得要求第三方安装专用工具" | 保留 + 加强 |
| 附则二.2 | 新增 PROVISIONAL / SUSPENDED 机制（含期限、后果、自救） | 新增 |
| 附则二.3 | 新增 补正通道（四类 + 六禁 + 两档时间窗 + 七道闸） | 新增 |
| 附则二.4 | 版本链保留，补一句"记录前任 base hash" | 补充 |
| 附则二.5 | 新增 生效文本集与 effective_id | 新增 |
| 附则二.6 | 新增 三态词汇表（与代码同名） | 新增 |
| 附则二.7 | 正本条款（原二.3 移位） | 移位 |
| 3.2-A | 新增 资源边界 ≠ 速率歧视 | 新增 |
| 附则三 | 仅更新"当前状态"列 | 更新 |
| 第一至八条 | 零改动 | 不变 |
| 附则一 | 零改动（90 天公示、表决门槛、7 天冷静期全部保留） | 不变 |
9. 需要你拍板的三件事
见对话中的选项。三条都影响条文措辞，改起来容易，但一经锚定就难改。
起草：Cursor · 2026-11-11 本文为提案稿，未生效。v1.0 仍为唯一有效文本。 若本文与 v1.0 冲突，以 v1.0 为准——直到 v1.1 完成全部生效程序。