9 月 11 日 XRP 账本修正案：检查您的钱包、节点和 AMM 头寸的内容

世界标准时间 2026 年 9 月 11 日 11:15 修订版 fixCleanup3_3_0 可以在 XRP Ledger 上上线。对于作为投资者的你来说，这在大多数情况下意义不大，但在其中意义重大：如果你的 XRP 位于交易所或维护的钱包应用程序中，那么你无事可做。如果您运行自己的节点，如果您通过自托管接口访问网络，或者如果您持有账本的高级功能，那么 9 月 11 日是您进行版本检查的截止日期。

该分析由 cryptoticker.io 于 2026 年 9 月 9 日自行进行。我们直接询问链，而不是从新闻报道中获取运行状态：通过 XRPL 节点的公共接口，使用功能和 ledger_entry 调用针对已验证账本的修改对象。结果与目前有关该日期的报道有两点不同。

修正案 fixCleanup3_3_0：9 月 11 日 XRP 账本上会发生什么

修正案是对 XRP Ledger 协议规则的更改。网络的验证者对其进行投票，一旦投票通过，它将永久适用于随后的每个账本版本。没有人集中部署；这是大多数运营商组合在一起的开关。

fixCleanup3_3_0 是一系列修正，而不是新功能。它在六个地方进行整理：单一资产金库（为协议保存单一资产的金库对象）、借贷协议（直接在协议级别计划的借贷业务）、自动做市商（通过公式而不是订单簿报价的交易池）、许可的 DEX（只为经过批准的参与者提供服务的交易场所）、支票（付款承诺接收者自行赎回）和伪账户（不属于任何交易的技术账户）。人类，因为协议对象持有它们）。

具体而言，该捆绑包协调了对伪账户转账的冻结检查，在初步阶段拒绝格式错误的检查标识符，修复了删除混合报价时的错误，并在 AMM 池中添加了对存款、取款和回拨损失的四舍五入检查，前提是旧的修订版 fixAMMv1_3 也处于活动状态。最重要的是一个名为 ObjectHasPseudoAccount 的新不变量，它确保删除分类帐条目也会删除关联的伪帐户。

这听起来像是细节工作，确实如此。这正是为什么这个新闻对你来说不是一个价格故事，而是一个有严格期限的维护故事。

80% 规则：XRPL 修正案最初是如何激活的

XRP 账本的修订文档中规定了该程序，并且非常严格。一项修改需要得到服务器监听的 80% 以上的验证者的批准，并且需要两周不间断的支持。如果同时支持率降至 80% 或以下，则时钟重新从零开始。一项修正案在最终通过之前可能会多次赢得或失去多数票。

计数发生在所谓的旗形分类账上，即每 256 个分类账进行一次，平均大约每一刻钟一次。在标志分类账上，验证者进行投票，一个分类账之后，网络将结果写入一个伪交易，在标志分类账之后的两个分类账上，新规则对交易生效。因此，启动仪式是在计数之后进行的，而不是在整点举行仪式。

任何了解该模式的人都会从其他网络中识别出它。在 Solana 上，协议变更的激活同样取决于运营商的权益权重；我们在有关 Alpenglow 激活的文章中写了这一点。区别在于细节：在 XRP 账本上，两周的周期固定在协议中，因此可以从账本本身读取。

我们根据账本统计：93 项活跃修正案，11 项开放，1 项多数

世界标准时间 2026 年 9 月 9 日 00:52，我们查询了一个公共 XRPL 节点，该节点当时携带经过验证的账本，编号为 106,856,830，并报告服务器版本 3.3.0。方法：对服务器已知的所有修改列表进行功能调用，加上针对正式状态的分类帐修改对象的 ledger_entry 调用。该服务器已知的所有 104 项修订均已检查。

数字结果：93 项修正案处于活动状态，11 项修正案处于开放状态。在这 11 个中，恰好有一个在分类帐中具有多数条目，即 fixCleanup3_3_0。对象中为该条目存储的结束时间将转换为 2026 年 8 月 28 日 11:15 UTC。添加规定的十四天，您将获得最早的激活时刻：2026 年 9 月 11 日，11:15 UTC。

这使得目前流通的两个数字得以澄清。首先，一些报道将投票开始日期定为8月6日；然而，重要的最后期限只是大多数人第一次站起来的那一刻，根据分类账，是 8 月 28 日。其次，一些报告给出了美国东部时间 11 点 15 分。该账本采用 UTC 时间，对于欧洲读者而言，这一时刻为 9 月 11 日中午。

对此需要注意的是：我们测量的是一个节点的状态；它不涵盖每个验证者的投票。最近报告的支持率为 82.86%，其中 29 票赞成，来自第三方分析，只是一个快照。目前没有人能保证 9 月 11 日之前是否能保持在阈值以上。

XRP Ledger 的保管库功能正在由 fixCleanup3_3_0 修复，尽管它仍被锁定在主网上。

单一资产库和借贷协议甚至还没有在主网上上线

我们查询的最重要的发现并未出现在有关该日期的报告中。 SingleAssetVault 和 LendingProtocol 本身也在同一个 11 项公开修正案列表中。因此，两者尚未在主网上开启。 ConfidentialTransfer、DynamicMPT、BatchV1_1、Sponsor、XChainBridge、PermissionDelegationV1_1、CryptoConditionsSuite 和 fixXChainRewardRounding 也是如此。目前这十项修正案均未获得多数票通过。

由此而来的一个值得记住的保证是：如果有人告诉你，你必须在 9 月 11 日之前确保你在 XRP Ledger 上的金库或借贷头寸，那么他们描述的是主网络上不存在的情况。目前您无法直接在 XRPL 协议上持有借贷头寸，因为该功能尚未激活。

换句话说，修复是在函数打开之前内置的。在软件开发中，这是正常情况，也是一个好兆头：在测试网络和审计中发现的错误在发布前被清除。对于您来说，这主要意味着您应该对今天的 XRPL 原生贷款广告优惠持怀疑态度。任何寻求加密资产收益的人目前都会在托管人和交易场所找到它，在任何情况下，它们的条款都值得仔细阅读，而不是任何有关尚未启用的协议功能的公告。

修改被阻止是指当服务器的软件版本不知道的规则在网络上激活时，服务器会陷入这种状态。该文档在这一点上是明确的：被阻止的服务器无法再验证账本，无法再提交或处理交易，无法再参与共识，也无法再对未来的修正案进行投票。它静止不动。

这就是截止日期的真正原因。任何运行节点的人都必须在激活之前切换到知道 fixCleanup3_3_0 的版本。我们查询的公共节点在测量时运行的是 3.3.0，并报告没有出现块。落后的服务器会在激活后立即报告，并且在应用程序运行失败时就会出现中断。

该文档还提到了许多人低估的一个属性：服务器始终遵循网络其余部分已激活的修正案，无论它如何投票。因此，否决并不能保护过时的服务器。只有更新才可以。