XRPL 清理修正案的票數正好維持在啟動所需的門檻，而擬議的借貸修正案票數仍遠低於所需支持度。截至 10 月 18 日，XRPL Dashboard 監測的 35 個驗證節點中有 29 個支持 fixCleanup3_4_0。該修正案需要嚴格超過 80% 的批准率，因此 29 票是最低門檻；35 票中的 28 票並不足夠。修正案是 XRP Ledger 採納新規則的方式，因此這一票數決定了這批修復能否如期生效。

自 10 月 9 日起，該儀表板已記錄到過半數支持，並預測若支持度在兩週期間內保持不變，修正案將於 10 月 23 日約 09:34 UTC 啟動。該儀表板形容此修正案「沒有多餘的票數」。

該修正案包含約 25 項修復，其中八項涉及金庫與借貸。其他變更影響自動做市商（AMM）、信任線、非同質化代幣（NFT）、多用途代幣、託管、贊助簽名與權限委託。

XRPL 借貸機制的設計運作方式

擬議的 XRPL 借貸系統將透過金庫連接存款人、貸款經紀人與借款人。存款人將單一資產存入單一資產金庫（Single Asset Vault），經紀人則從該資金池安排固定期限、無抵押貸款。借款人按約定條款還款，詳見 XR 借貸文檔。

帳本將管理這些貸款，但承作審核將在鏈下進行。當前設計也不包括自動化的鏈上抵押品清算。Coindoo 先前曾發布對該提案的概述（Coindoo）。與所有 XRPL 功能一樣，借貸系統只能透過修正案投票上線：在其相關修正案通過同樣的超級多數門檻與 14 天等待期之前，金庫與經紀人的設計仍只是提案，而非帳本的實際功能。

票數狀態與啟動時間表

支持 fixCleanup3_4_0 的 29 票之所以重要，是因為 XRPL 修正案流程要求獲得超過 80% 受信任驗證節點的多數支持。儀表板監測 35 個驗證節點，因此門檻為 29 票。

此流程已經顯示失去多數會如何影響啟動時間表。PermissionDelegationV1_1 於 9 月 23 日跌至 35 票中的 28 票。BatchV1_1 在 9 月 25 日的一次表決中失去多數，重置了其兩週啟動時鐘，之後才於 10 月 9 日啟用。根據官方修正案流程，失去所需多數會重置兩週期限。

借貸修正案仍需 8 至 10 票額外支持，隨後還需 14 天等待期。因此，最早也要到 11 月初才可能啟動。

驗證節點票數方面還有一項注意事項。10 月 8 日在 rippled GitHub 儲存庫提交的一份報告指出，版本 3.4.1 在驗證節點輪替其簽名金鑰並從門檻中被移除後，會停止計算該節點的票數。報告者觀察到的是 33 個驗證與 26 的門檻，而非 35 與 28，並指出沒有任何修正案的結果因此改變，Unchained 報導。截至 10 月 9 日，相關補丁仍在審查中。

fixCleanup3_4_0 的變更內容

這項清理修正案的範圍不僅限於借貸更新。根據 XRPL 修正案清單，其約 25 項內容包括以下變更：

• 信任線： 發行方對传入信任線的封鎖也將適用於掛單（offers）。因此，當相關传入信任線被封鎖時，帳戶將無法再透過掛單接收代幣。
• AMM 追回（clawback）： 當四捨五入將金額降至零時，追回操作將不再在未收回任何資產的情況下銷毀持有人的流動池代幣。
• 託管（escrow）： 當帳戶持有人的餘額處於儲備金門檻時，取消或完成還代幣的託管將不再失敗。
• 簽名： 贊助方與交易對手方的簽名將使用不同的前綴，防止為某一角色建立的簽名被當作另一角色重放。

這些變更載於 xrpld 3.4.0 發行說明。它們還影響一項於 10 月 8 日上線的功能。XRPL 文檔建議在清理修正案啟用之前，不要委託細粒度的 PaymentBurn 權限，因為持有該權限的受託人可能能夠建立新的信任線代幣或多用途代幣，而不僅僅是銷毀它們，據 Unchained 報導。清理修正案會拒絕會將零餘額轉為新增發行的僅限 PaymentBurn 的付款。

對金庫存款與會計的影響

金庫份額是價值跟隨金庫所持資產的多用途代幣。帳本還會追蹤被標記為減損貸款的「未實現損失」。在金庫文檔的範例中，一個持有 100 萬美元、有 90 萬美元未實現損失的金庫，其贖回兌換率為 0.1。

清理修正案對這部分系統做了三項變更。存款、贖回與追回採用更精確的四捨五入，有助於保持金庫的總資產、可用資產與份額供應量一致。從完全減損的金庫進行固定份額贖回時，可能轉移零資產而非失敗。該交易會在未收回任何資金的情況下完成，發行說明並未解釋為何以此行為取代失敗。

該修正案還變更了貸款逾期、減損與違約檢查。必須在到期日嚴格過後才能將貸款標記為逾期或違約，也就是說貸款不能在到期日當天被標記。

這是針對相關程式碼的第四個清理修正案。XRPL 金庫文檔指出，fixCleanup3_1_3 至 fixCleanup3_4_0 在系統 2025 年審計後，各自對金庫行為進行了精度、四捨五入或正確性修復。

LendingProtocolV1_1 下的利息與贖回

隨版本 3.4.0 推出的 LendingProtocolV1_1 變更了金庫的利息計算方式。在此之前，金庫在貸款放款時即將全部應計利息計為收入，若借款人停止還款則必須沖銷該收入。

借貸文檔給出的範例涉及一個有 99,000 個可用代幣、以及一筆 1,000 個代幣並附帶 90 個代幣應計利息的款的金庫。在先前的方法下，該金庫的總資產報告為 100,090。在現金基礎會計下，只有當還款實際交付時才計入利息。因此份價格不會因已排定但未收到的收入而上調，損失也顯得較小，因為只有本金處於風險之中。

同一修正案還新增了封閉式金庫。它們按照建立時固定且不可更改的日期經歷三個階段。一旦 V1.1 啟用，新的貸款經紀人只能使用封閉式金庫，據 XRPL 單一資產金庫文檔。

金庫採用哪種會計模式取決於其建立時間。在 V1.1 啟用前建立的金庫將永久保留較早的利息模式，即使在 V1.1 啟用之後亦然。文檔也允許兩項修正案啟動之間存在時間差。在 10 月 18 日的快照中，LendingProtocol 與 V1.1 各獲 19 票，但相同的票數並不保證它們會同時啟動。

首損資本與貸款違約

經紀人可以提供可選的首損資本，但兩項設定限制了違約後有多少該資本能觸及金庫。CoverRateMinimum 規定必須覆蓋的債務比例，而 CoverRateLiquidation 則限制貸款違約時該最低覆蓋額中有多少會送入金庫。

在 XRPL 借貸協議文檔的範例中，經紀人提供 1,000 個代幣的覆蓋資本，而一筆 1,090 個代幣的貸款違約。當兩項比率均設為 10% 時，僅有 10.9 個代幣的覆蓋資本被動用，金庫承擔 1,079.1 個代幣的損失。覆蓋比率由經紀人設定，因此實際的資金池可能使用不同的參數。

若可用覆蓋資本低於所需最低額，經紀人將無法發放新貸款，且其費用會被撥入覆蓋資本。這限制了新的風險敞口，但不會迫使現有借款人還款。

資產發行方也保留某些控制權。若金庫的資產被凍結，贖回只能支付給發行方。發行方還可以將金庫份額追回為發送給自己的資產。被凍結的借款人無法進行付款，但凍結並不會取消債務。

需關注的日期與事項

若所有 29 個支持驗證節點在完整啟動窗口內維持其票數，清理修正案預計於 10 月 23 日約 09:34 UTC 啟動。任何一個驗證節點撤回支持都會重置兩週期限，正如 PermissionDelegationV1_1 與 BatchV1_1 先前的情況。

借貸修正案需要 29 票，隨後是 14 天等待期，使其最早可能的啟動時間落在 11 月。LendingProtocol 與 V1.1 之間的啟動時間差也同樣重要，因為在該時間差內建立的金庫將保留較舊的利息計模式。

最後，擬議的計票補丁仍然相關。它將防止驗證節點在輪替簽名金鑰後從票數計算中消失。

本文僅供參考，不構成財務或投資建議。修正案的時間表可能變動，借貸涉及信用與流動性風險。

來源：Coindoo