Coldcard 事件之後，一個問題再次被提出：如果硬體錢包也會出錯，甚至可能從生成金鑰的那一刻就留下隱患，我們為什麼還要自己保管資產？
我們的判斷是：自託管仍然重要。它讓用戶掌握鏈上操作的最終授權，並在平台或服務失效時保留獨立遷移的可能。Coldcard 沒有改變這種價值，卻讓我們重新審視「如何安全地擁有控制權」。
安全不能只看一個標籤
根據 Coldcard 官方公告和 Block 的技術分析，一處韌體整合錯誤讓部分設備沒有按預期使用硬體隨機數，而是走到了可預測的軟體隨機數路徑。表面上正常的助記詞，可能從金鑰生成階段就沒有達到應有的安全水平。
在不少公開案例中，用戶沒有點擊釣魚連結，也沒有洩露助記詞，只是按照產品的預設流程建立錢包。問題發生在金鑰生成的源頭，之後再謹慎保管，也無法補上這個缺口。
這次事件打破了一個常見的認知捷徑：硬體、離線或開源都能提升安全，但沒有一個標籤可以單獨成為安全結論。普通用戶也不可能逐行審計韌體。讓預設路徑可靠，本來就是安全產品應當承擔的責任。
事件發生後，OKX 表示平台出現大量資金流入。CZ 隨後引用一組歷史數據，提出「從統計上看，把資產存在交易所比自託管更安全」。這句話會獲得認同，並不奇怪。
成熟的託管機構可以投入更多資源，建立專業的安全和恢復體系。對缺少金鑰管理經驗的人來說，由機構承擔這部分工作，確實可能降低個人獨自管理金鑰的難度和風險。承認這一點，並不會削弱自託管的價值，反而能讓討論回到真實的用戶處境。
但歷史損失數字很難直接給出今天的答案。CZ 引用的 River 研究也說明，早期 BTC 永久丟失的數據難以準確歸因，其中絕大部分發生在 2020 年以前；交易所損失同樣無法完整統計，部分賠付也沒有扣除。這些累計數字還沒有按資產規模和持有時間調整。它們說明兩種方式都發生過巨大損失，卻不足以衡量今天的實際風險。
更重要的是，這種比較通常只統計「資產有沒有丟」，卻很少回答「需要時能否取出」以及「平台出問題後能否離開」。託管可以降低個人管理金鑰的壓力，也會讓用戶依賴機構持續營運、履行兌付義務和提供帳戶存取。
自託管保留的是另一條路
自託管本質上是一種控制權安排。對常見的自託管帳戶而言，用戶掌握私鑰或完成簽名所需的關鍵條件，錢包開發者和其他服務方不能單方面完成有效授權。
只要用戶仍持有有效的金鑰或備份，即使原來的錢包停止服務，通常也能透過相容工具恢復帳戶；當用戶需要轉移資產或使用鏈上應用時，也不必先等待某個平台開放提現。
這條獨立路徑，就是自託管最重要的價值。
它當然有邊界。網路和合約規則仍可能影響資產使用。自託管所保留的，是鏈上操作的最終授權不必完全依賴單一機構，而不是對所有外部條件的絕對控制。
這種價值在平台正常運行時並不明顯。它有點像備份：不會讓日常操作更快，卻會在原有路徑失效時，決定用戶是否還有選擇。
因此，託管和自託管並不存在適用於所有人的統一答案。對暫時沒有能力安全管理金鑰的人來說，選擇經過審慎評估的託管服務是合理的；對希望減少單一機構依賴的人來說，建立一條可以獨立恢復和遷移的路徑同樣重要。關鍵不是站在哪一邊，而是清楚自己把什麼風險交了出去，又留下了什麼能力。
控制權不該成為用戶一個人的負擔
用戶控制私鑰，不代表產品方可以少承擔安全責任。普通用戶無法驗證一台設備從金鑰生成到韌體建構的完整過程。產品需要驗證關鍵路徑，讓異常及時暴露，並在問題發生後透明回應。安全應該來自可靠的預設設計，不能依賴用戶發現隱藏的技術風險。
用戶同樣需要確認備份確實能夠恢復，在簽名前弄清自己授權了什麼，並提前了解主要工具失效後如何遷移。但這些能力可以逐步建立。自託管不應該是一場要求所有人立即轉移全部資產的資格考試，也不應該要求每個人都成為密碼學專家。
對 imToken 而言，支援自託管，要從把這種選擇做得更可靠開始。用戶需要看得懂自己正在授權什麼，知道如何恢復，也應當在需要時能夠遷移到相容工具。只有這樣，控制權才不只是一句口號。
Coldcard 事件沒有讓自託管變得不再重要，相反它讓安全責任變得更加具體。下一階段要解決的問題，是如何在保留用戶控制權的同時，讓安全、恢復和使用體驗變得更加可靠。
用戶可以選擇託管，也可以在需要時離開託管；可以掌握控制權，也不必獨自承擔所有複雜度。這才是 Coldcard 之後，我們重新討論自託管的意義。
