XRPL 开发分支新增 LendingProtocolV1_2 提案，借贷协议迎来重要迭代

XRP Ledger（XRPL）的开发分支中现已列出 LendingProtocolV1_2。这是一个尚未获得支持的新修正案，其层级位于 LendingProtocolV1_1 及原始 LendingProtocol 条目之上。相关的标准工作提出了一项对贷款创建方式的重大变更：在贷款生效之前，贷款的“设置”与“接受”将通过两个独立的交易分别处理。

这一添加表明，XRP Ledger 的借贷实现正处于发布前的修订阶段，而非仅仅是对核心功能集的简单扩展。目前该工作仍处于开发状态，开发分支中的列表存在并不能作为其在账本上已部署或激活的证据。

V1_2 提案的定位与迭代性质

该功能在 XRPLF/rippled 开发分支的功能定义中被列为 LendingProtocolV1_2。其位置高于早期的 V1_1 和原始 LendingProtocol 修正案，明确表明代码库正在追踪借贷协议的连续修订版本。

“尚未支持”（not-yet-supported）的状态是 V1_2 近期状态的核心特征。尽管该修正案正在作为协议变更进行准备，但在所引用的分支中，它尚未进入受支持的部署状态；修正案是 rippled 代码库中表示 XRPL 协议变更的机制。

命名方式也暗示了工作的迭代性质。V1_2 并非用一个无关的提议取代现有的借贷工作，而是作为一系列特定于借贷的修订的一部分，紧随原始修正案和 V1_1 之后。

两步式贷款创建：设置与接受分离

根据 XLS-65/66 标准工作，LendingProtocolV1_2 引入了两步式贷款创建流程。拟议的 LoanSet 交易用于建立贷款条款，而 LoanAccept 交易则用于单独接受该贷款；只有在完成接受步骤后，贷款才会正式生效。

这种分离是 V1_2 附带的核心功能优化。它改变了提议贷款达到活跃状态的序列，将贷款条款的创建（设置）与后续的接受行为区分开来。

Coin Brief 的一份独立报告同样将此修正案描述为启动前对借贷实现的细化工作，引用了其中提到的两步式贷款创建及相关借贷交易变更。然而，标准提案才是记录所述交易结构的主要依据。

虽然这种分离流程对于协议如何处理安排转变为活期贷款的方式可能特别相关，但现有资料并未设定最终的发布时间表，也未确立当前提案形式即为最终定稿。

代码工作重点：经纪商域名与金库会计

INFTF 的镜像对比记录显示了截至 10 月 14 日针对 LendingProtocolV1_2 的 rippled 变更。这些变更增加并测试了针对贷款经纪商域名的门控行为、固定精度金库会计以及分离的 LoanSet/LoanAccept 交易流程。

这份记录表明，V1_2 既是一项实施工作，也是一项标准层面的提案。其功能门控将经纪商域名的行为与修正案绑定，而会计工作则涵盖了借贷和金库相关的计算。

这些记录并未量化会计变化对用户或流动性提供者的影响。此外，也没有显示生产环境的 rollout（推出）；开发分支仍将 LendingProtocolV1_2 列为尚未支持。

阶段性借贷发布的延伸

原始的 LendingProtocol 已进入发布于 2026 年 1 月的 rippled 3.1.0 版本。随后的发行版记录了额外的借贷和金库修复措施，确立了协议的阶段性路径，而非单一的静态实现。

LendingProtocolV1_2 现在增加了另一个 distinct 阶段：一个单独的修正案、一个关于两步式贷款创建的标准提案，以及涵盖经纪商域名、金库会计和交易流程测试的实施工作。这一序列与所提供的发行和开发记录一致，表明借贷功能在其最初引入后仍在持续调整。

对于关注该功能的 XRPL 参与者来说，当前需要关注的即时发展是 V1_2 是否能超越其当前的未支持列表状态。在目前可用的代码和标准材料中，其目的被狭义地定义为：在借贷系统向前推进之前，修订贷款创建流程并纳入相关的实施修复。