要点:
- XRPL 开发者提议赋予发行方控制代币阻止权限
- XLS-87 引入 TokenPreauth 和 TokenBlock 两种交易类型
- 执行仍未完成,主网激活尚未确认
XRP Ledger(XRPL)开发者正在推进新的代币授权和阻止控制,可能允许发行方阻止特定账户获取其数字资产,为在 XRPL 上构建的机构再添一项潜在合规功能。
10 月 16 日的一项代码提案在 XLS-87 标准下引入了两种交易类型:TokenPreauth 和 TokenBlock。相关改动主要针对多用途代币(Multi-Purpose Tokens,MPTs),而非普通的 XRP 转账。
该提案目前仍处于草案开发阶段。现有实现只能创建和管理权限记录,但当账户尝试获取代币时,尚未真正执行这些限制。
XRPL 开发者引入 TokenPreauth 和 TokenBlock
根据修订后的 XLS-87 规范,代币发行方将获得两种互补方式来管理哪些账户可以持有其资产。
TokenPreauth 允许发行方提前批准某个特定账户,使其能够接收需要授权的 MPT 发行。这可以免去该账户自我授权持有代币时,另行提交发行方批准交易的需要。
TokenBlock 则相反,允许发行方禁止某个特定账户获取其代币。
拟议中的限制不只适用于直接转账。未来的执行代码还计划覆盖通过支付、去中心化交易所交易、支票、托管、自动做市商和金库获取代币的情况。

重要的是,阻止现有持有人并不会自动冻结其当前余额。该规范区分了“阻止进一步获取代币”和“限制已持有代币”这两种情况。
该提案为 XRPL 正在发展的机构控制机制再添一层,其中包括基于凭证的交易和流动性基础设施访问控制。
为什么代币阻止对机构资产很重要
银行和代币化资产发行方通常需要比无许可区块链转账模型更强的控制能力,来决定谁可以接收受监管金融工具。
例如,发行代币化证券的机构可能需要批准符合条件的投资者,或阻止指定地址继续获取额外持仓。
XLS-87 将为发行方提供一种方式,可直接通过账本条目表达部分限制,而不必完全依赖应用层检查。
这一设计也建立在 XRPL 现有的权限委托架构之上,该架构支持在不共享账户主密钥的情况下分离操作职责。
根据该提案,发行方可以委托代币管理交易。一个权限范围尤其狭窄的 TokenBlockCreate 允许授权操作员阻止账户,但不赋予其解除这些限制的能力。
不过,这些控制并不会自动构成对证券法或客户身份识别要求的合规。机构仍需配套适当的开户注册、监控和法律保障措施。
XLS-87 仍需执行代码和验证者批准
10 月 16 日的拉取请求仅代表实现过程中的一个阶段。
开发者已单独提出所需的账本条目,后续改动还必须确保被阻止的账户无法通过其他代币获取机制绕过限制。
当前代码明确允许被阻止账户自行授权,因为执行功能尚未实现。
这使 XLS-87 不同于即将于 10 月 23 日进行的 XRPL 升级;后者涉及对现有功能的修复,并且已经进入修订激活窗口。
XLS-87 目前没有确认的主网激活日期,也没有完成验证者批准流程。
其开发还与另一项独立的借贷修订并行推进,后者同样需要获得验证者支持,相关功能才可能投入运行。
对投资者而言,这一区别很重要,因为协议开发活动并不自动转化为 XRP 的即时需求。
不过,XRPL 不断扩展的代币基础设施,包括拟议中的机构借贷和发行方控制权限,显示出其正朝着适配受监管金融应用的更广泛方向发展。
Marcus Hale
Marcus Hale 是一名加密货币和金融市场撰稿人,报道比特币、以太坊、数字资产、监管、ETF 以及机构采用。他的作品聚焦可能影响市场的进展、投资者趋势,以及塑造加密经济的更广泛力量。












