XRP Ledger两项代币授权修正案待决 主网启用前仍需合并
XRP Ledger开发者正在审查修正案PR #8648与PR #8650:前者收紧AMM流动性代币的授权检查,后者封堵带残余余额信任线的接收漏洞,均需超过80%验证节点支持两周方可启用。
AI 摘要AI
- XRP Ledger两项修正案PR #8648与#8650于10月27日提交,截至11月2日仍待审
- 配套讨论帖#8649与#8651已关闭,仅两项窄范围修正案继续推进
- 链上数据显示24小时内XRP转移规模达18亿枚
- Ripple于11月1日从托管账户解锁10亿枚XRP
两项待审,两项已关闭
XRP Ledger(瑞波账本)的开发者目前仍需就两项修正案提案作出决定,这两项提案旨在收紧发行方要求授权的代币的接收规则,且均未进入主网生效阶段。这两份提案于10月27日(星期二)提交至XRP Ledger基金会服务器软件代码库,编号分别为PR #8648和PR #8650,截至11月2日(星期一)仍处于待审状态。配套讨论帖#8649和#8651已经关闭,目前活跃的推进轨道只剩这两项范围更窄的修正案。
第一项提案#8648针对自动做市商池的流动性提供者代币。根据提案,当一个账户即将收到此类LP代币时,系统必须检查构成该资金池的两种资产的授权要求,任何一种资产未经授权都会阻断接收。流动性提供者目前向这些资金池存入资金,TVL记录的是锁定的总价值,而提案文本指出,仅在存入时验证授权,可能无法阻止LP代币的后续转移。因此这项检查的范围不止于存入,还覆盖支付、交易挂单、通过dApp执行的非同质化代币出售以及AMM拍卖出价,堵住LP代币可以流动的每一条路径。
第二项提案#8650处理的是已带有余额的信任线。现行规则下,支付路径上的授权检查仅在余额为零时才生效,这意味着一个从未获得授权的账户,只要持有少量残余代币,就可以继续接收代币。该修正案将阻断这些后续接收,同时保留赎回路径,即把已有余额退还给发行方的通道。这种更窄的范围也是它与已关闭的#8649的区别所在:后者是一个更宽泛的提案,原本会限制未授权余额的一切使用。
Require Auth与80%验证节点门槛
两项提案都建立在Require Auth这一发行方设置之上。该设置将代币标记为仅限获得授权者持有。官方账本文档写明,账户的信任线必须先获得授权,才能持有此类代币;信任线是账户与代币发行方之间在链上的关系。未经授权的信任线意味着发行方尚未通过该持有者的审查,无论发行方采用何种筛选流程。这套机制只适用于已发行代币;XRP价格背后的原生资产无需发行方把关,这一区分使账本的代币经济与其基础货币保持独立。对持有者进行筛选的发行方,其中包括筹备收益型稳定币的平台,正是依靠这一设置控制谁能接收其资产,这也是此次审查的接收路径带有合规分量的原因。
修正案的启用遵循固定流程。修正案改变交易处理规则,官方文档要求:修正案必须随某次软件版本发布,并在两周内获得超过80%可信验证节点的支持,方能生效。两项新提案均与fixCleanup3_5_0修正案相关联,因此其命运取决于该版本的发布周期。时间安排可能中途变动:fixCleanup3_4_0的预计启用日期已在同样的验证节点支持条件下从10月23日推迟至11月4日。待审状态意味着这对提案仍处于审查阶段,维护者会阅读代码、提出修改意见,并判断其逻辑是否应纳入候选发布版本。从合并代码、纳入发布,到验证节点投票,每一环都在提案与主网规则之间。
#8650补上的合规缺口
#8650修补的残余余额缺口是一个现实存在的合规漏洞,而非纸上谈兵:按现行规则,一个未获授权却持有残余代币的账户可以继续接收代币,这正是使用Require Auth的发行方极力避免的结果。选择较窄的修复方案而非已被关闭的宽泛提案,可以在封住接收通道的同时保持赎回流程畅通,代价是将未授权余额的其他用途留待下一轮处理。两项提案同时进入审查,也让修复方案保持一致,因为#8648的资金池级检查与#8650的余额级规则服务于同一个发行方控制目标。账本活动在同期持续:据报道24小时内出现18亿枚XRP的转移,Ripple于11月1日从托管解锁10亿枚XRP,而Ripple自身也将RLUSD的直接赎回置于门控之后,这一切与发行方主导的管控正在塑造这条账本相一致。剩下的工作在开发者手中:合并两份拉取请求,随版本发布,然后在两周内获得超过80%验证节点的支持。下一个发布周期结束之前,不会有任何修正案生效。
本文由人工智能辅助生成、经 AI 审核,并在 COINOTAG 编辑监督 下发布。

