XRPL Commons 於1月27日通過 X 帖文確認,在 Devnet 上完成完整的端到端測試後,已投票贊成兩項關鍵的 XRP Ledger 修正案。該組織批准了 XLS-80 下的許可域和 XLS-81 下的許可 DEX,這是在2026年1月23日舉行的治理投票之後做出的決定。
這項決定標誌著在不改變 XRPL 開放和去中心化設計的情況下,朝著實現受監管金融活動邁出了一步。
這些修正案旨在支持需要合規控制的機構,例如身份驗證和受限交易對手訪問。XRPL Commons 表示,其投票是基於成功的測試結果和在 Devnet 部署期間觀察到的運營穩定性。
許可域允許運營商在 XRP Ledger 上定義受控環境。域運營商決定哪些憑證有效,持有這些憑證的帳戶會自動獲得訪問權限。
這種結構使得在保持核心賬本無需許可的同時,能夠應用如 KYC 檢查等監管要求。
許可 DEX 通過引入域限制訂單簿來擴展原生 XRP Ledger 去中心化交易所。只有同一許可域內的成員才能相互交易,確保所有參與者都符合預定義的合規條件。
這些修正案引入了三種報價類型。開放報價遵循現有的 XRP Ledger DEX 行為。許可報價將交易限制在單個域內。混合報價允許交易首先在域內匹配,然後再訪問公開市場流動性。
所有功能都依賴於 XLS-70 憑證,該憑證提供了一種鏈上方法來驗證帳戶屬性,例如合規狀態。
XRPL Commons 在 Devnet 中手動測試了新功能的完整生命週期。這涉及憑證的創建和撤銷、域的管理,以及開放、許可和混合 DEX 交易。
測試確定,每當憑證發生變更時,域的成員資格會自動刷新,非成員不被允許進入受限訂單簿。
正確地,混合模式首先提供域流動性,然後再求助於開放 DEX。過期的憑證會自動撤銷,並按預期拒絕未經授權的交易。每個 XLS-70、XLS-80 和 XLS-81 都按規定運作。
在初始測試期間發現的一個操作問題是 IOU 配置。為了能夠使用正確的交易路由,發行方需要啟用 DefaultRipple,用戶需要創建信任線,發行方需要清除信任線上的 NoRipple 標誌。
未能執行此步驟會導致交易失敗,配置準確性對機構來說非常重要。
XRPL Commons 表示支持這些修正案,因為它在合規性和去中心化之間提供了合理的權衡。
其功能使其可用於以下用例:穩定幣外匯、薪資、國際商業結算和企業資金管理。
儘管流動性僅限於域內,且沒有交易可以跨越許可環境,但據稱這是為了滿足監管期望而有意做出的權衡。獲得批准後,XRP Ledger 朝著成為鏈上金融的監管就緒結算層又邁進了一步。
另請閱讀:XRP Ledger 速度達到2025年峰值,ETF 流入接近10億美元


