规则与治理

每份合约都会将其将被评判所依据的确切规则——即对结果打分的评估者——在签署那一刻以哈希形式固定进协议中。这就是钉定保证：规则之后的任何变更只适用于新协议。它永远无法回溯并重新评分已在其自身承诺条款下锁定的价值。

说得直白一些：将用来结算你合约的规则，就是你同意合约那一刻所存在的那些规则，事后的任何升级都不能移动这个目标。规则变更是前瞻性的，永远不会对已锁定的价值追溯生效。

对规则的变更——或对执行这些规则的系统所做的软件升级——不会在有人做出决定的那一刻立即生效。它首先要经过一个公开的、留有记录的流程：

审查期的存在是为了让一项变更永远不会是一个突然袭击：你可以提前看到它到来，并且可以在新规则适用之前，按旧规则结算或退出任何正在进行中的事项。

具体来说：能够重写链上执行逻辑的权限本身，被置于一个3 之 5 多重签名和一个 48 小时链上时间锁（Squads）之后。它已在 devnet 上线，且在链上得到证明——在一次治理演练中，5 个独立机构中有 3 个批准了一项变更，而执行仍被时间锁阻止——因此没有任何单一方能够悄无声息地在已锁定的价值上更改规则。这目前运行在 Solana devnet 上（未经审计）；关于哪些已上线、哪些以审计为前提的诚实记录，见信任与可验证性。

审查期不只是一个候诊室——它是一个可以提出异议的窗口。在此期间，任何人都可以对一项拟议中的变更提出质疑。为了让这个渠道不被垃圾信息淹没，一项质疑需要以一笔保证金作为担保：为一项异议押上真金白银，才使它有资格获得听证。

随后，一项质疑会通过与其他任何有争议的结果相同的客观纠纷流程来裁定——即仲裁与纠纷中所描述的同一套已固定、可复现的评估与升级阶梯。一项被支持的质疑会阻止该变更。质疑一项规则变更，走的正是你用来质疑一项裁定的那套机制——提出异议的权利并不局限于你自己的合约。

一份简短的核心保护清单不受任何普通规则变更的触及。其中最重要的一项：让你的纠纷被听取的权利。任何试图剥夺这项权利的变更，会在一票都还没被计入之前，就被批准逻辑本身拒绝——因此没有任何投票，也没有任何多数，能够剥夺你将一个有争议的结果引导至纠纷流程的权利。这是一道固定的底线，而不是一项可以被投票修改掉的礼遇。

更准确地说，这道底线今天是如何被守住的：它是由这个应用强制执行的——即我们运行的这套已部署的批准与结算逻辑——这正是它对任何投票都免疫的原因。让它同样对我们免疫，是下一步：一旦这套逻辑被冻结进一个链上程序，这道底线就将由无人能够悄悄更改的代码来强制执行，而不再依赖于我们运行正确代码的承诺。我们会说明这两者中哪一个是今天的真实情况，而不是暗示更强的那一个。

一旦一场纠纷得到结算，其裁定就会被写入一条已在链上最终确定的记录——一条经过确认的、一次写入的条目，而不是一条发出后就不再理会的记录。从那时起，它不能被悄悄地重新变为未结算、重新评分，或被之后的规则变更或软件升级编辑。昨天已结算的案例将保持已结算，因此对今天规则的变更永远无法重新打开它们。

这项保证的强度，取决于那份记录的强度：一项裁定一旦在链上被最终确定，就会受到保护，这正是为什么结算锚点要写入以求确认，而不是发出后就不再理会。

今天，这些保护是由这个应用——即我们运行的批准与结算逻辑——强制执行的，因此准确的说法是没有任何投票能移除它们，而不是说它们在物理上不可撼动。将这套逻辑冻结进链上代码，是路线图上的下一步，以下是完整的脉络：