錢包可遷移，也要有人負責停止授權

分析 | 2026年10月14日。

10月13日公告預告將進一步完善控制功能。然而，Privy的XRPL文件已經描述了政策執行能力。這些資料尚未明確界定實際推出範圍。規格說明並不能證明某個應用程式已啟用哪些功能。更持久的問題是：當所有者遷移錢包、失去存取權限或停止自動支出時，控制權如何變化？本文將這幾種情況分開分析，因為其中一種展示成功，並不代表其他情況也能順利處理。

匯出是一場遷移測試

Privy的匯出指南說明，匯出途徑取決於錢包的建立環境。對產品團隊而言，有用的測試不應止於找到匯出按鈕。可以設定一位虛構的所有者，讓他先完成一筆獲准付款，再於測試環境中改用另一個介面。他是否仍能辨識自己的帳戶、理解其權限，並完成同樣獲准的操作？

然後測試限制。要求新介面執行一個原有安排會拒絕的操作，記錄限制是被保留、消失，還是需要重新建立。這是一項建議採用的驗收測試，並非斷言某個實作允許繞過限制。可遷移性的承諾應同時說明所有者獲得了什麼，以及哪些責任會隨之轉移。

這項區別具有商業意義。清楚的退出流程可能降低對單一應用程式的依賴；但若防護措施的變化解釋不清，也可能增加所有者的操作負擔。僅統計匯出次數，無法看見這種取捨。

恢復應還原正確的權限

XRPL的金鑰管理指南要求在停用主金鑰之前，先具備另一種授權方式。我們提出的更廣泛設計問題是：恢復流程到底恢復了什麼？恢復登入、恢復簽署能力，以及恢復修改權限的權力，應分別評估。

設想所有者遺失了一台裝置，而代理仍獲准執行操作。恢復演練應確認誰能介入、需要提供什麼證據，以及哪些舊權限仍然有效。還應測試失敗情境：只知道帳戶名稱，卻缺少必要證明的人，不應取得控制權。

一份有用的完成紀錄應同時展示兩個結果：合法所有者能夠再次操作，而計畫廢止的權限確實已不能使用。只恢復便利性，卻不核對第二個結果，測試就不完整。

明確誰能停止支出

Privy的控制模型將錢包所有權賦予一把金鑰或達到核准門檻的一組金鑰。接下來，我們建議追問一個人的責任問題：出了狀況，誰負責使用這項權力？

對於一個假設的代理錢包，應記錄誰能申請支出、誰能修改限額，以及誰能終止授權。這些角色可以重合，但重合應是有意的設計。財務人員能夠觀察活動，並不應被誤認為他們有權叫停活動。

最能說明問題的演練，應從撤回授權之後開始。用原來的權限提交一個新請求，並驗證它被拒絕。同時，單獨檢查那些已經簽署或提交的請求，而不要假定一則撤銷成功的訊息就解決了此前所有操作。測試應區分阻止新的授權操作與調查既有工作。

衡量能否安全地失敗

這些演練提出了一個比功能清單更有價值的採購問題：預期的所有者，能否在更換介面、失去存取權限和撤回委託時繼續掌控錢包？

可信的答案應包含測試結果、明確的負責人和清楚的限制，也應說明哪些保護被保留、哪些被有意替換，以及哪些依賴另一方在線可用。這些證據才能讓可遷移性具有實際意義，避免恢復淪為空泛承諾，也避免停止授權成為無人負責的工作。