ERC：抗脅迫保險庫 — 針對五美元扳手攻擊的支出限制、時間鎖與多重簽名方案

ERC 討論主題：抗脅迫金庫標準 (Coercion-Resistant Vault Standard)

更新日誌

2026-04-02: 初步草案，提交紀錄 (commit)

2026-04-02: 新增 ERC-20 代幣支持，具備獨立的單一代幣支出限制

2026-04-02: 新增 ERC-4337 智能帳戶實作 (IAccount, validateUserOp)

2026-04-02: 新增透過白名單目標進行的 DeFi 執行 (execute, executeBatch, approveToken)

2026-04-02: 新增具時間鎖的白名單管理

外部審查

截至 2026-04-02 尚無。

待解決問題

2026-04-02: 首次代幣支出限制配置應為立即生效還是需經過時間鎖？目前為了易用性設為立即生效，歡迎參與討論

2026-04-02: 轉帳手續費 (Fee-on-transfer) 與重定基數 (rebasing) 代幣的處理 —— 目前建議檢查實際收到的金額並使用封裝版本（例如 wstETH），追蹤議題

2026-04-02: 標準是否應定義建議的最短時間鎖持續時間（例如 24 小時）？

2026-04-02: 緊急社交恢復機制 —— 應留給具體實作還是納入標準？

---

問題

針對加密貨幣持有者的物理攻擊（「5 美元扳手攻擊」）在 2025 年增加了 169%，已有超過 70 起確認案例，導致超過 4,000 萬美元被盜（來源）。目前的自託管錢包允許立即且不可逆地訪問全部餘額，這使得加密貨幣持有者與傳統金融（銀行金庫設有延遲開啟功能）相比，顯得格外脆弱。

解決方案

一個針對 ERC-4337 智能帳戶錢包 的 ERC 標準，具備：

熱餘額 (Hot balance)：設有每週期支出限制（例如 0.5 ETH/24h）—— 立即執行，無摩擦

冷金庫 (Cold vault)：設有可配置的時間鎖（24-72h）—— 存放大部分資金

多簽繞過 (Multisig bypass)：透過 2-of-3 守護者進行合法的緊急訪問

可撤銷提款：在時間鎖窗口期間（由所有者或守護者）撤銷

具時間鎖的配置變更 —— 攻擊者無法強迫受害者提高限額

完整的 ERC-20 支持：具備獨立的單一代幣支出限制

DeFi 執行：透過白名單目標合約進行（授權 + 交換、流動性挖礦、質押）

批量操作：用於多步驟 DeFi 交互（在一次交易中完成原子化的授權 + 交換）

核心洞察

在受脅迫的情況下，受害者可以如實地說：「我現在只能轉給你 0.5 ETH。其餘的被鎖定 72 小時。你可以在鏈上驗證這一點。」

與脅迫/誘餌錢包不同，這不需要任何欺騙行為 —— 限制是可驗證的，受害者不需要在極度壓力下演戲。無論攻擊者的專業程度如何，該機制都能發揮作用。

這是一個智能帳戶，而非保險箱

該金庫實作了 IAccount (ERC-4337 v0.7)，並作為一個功能齊全的智能錢包運作：

UserOperations 由所有者的密鑰簽名，並透過鏈上 ECDSA 驗證

熱餘額操作像任何智能錢包一樣通過 EntryPoint 流轉

透過 execute() 和 executeBatch() 進行 DeFi 交互 —— 僅能調用白名單內的協議合約

透過 approveToken() 進行代幣授權 —— 僅限白名單內的支出者

向白名單添加新目標需要完整的時間鎖（攻擊者無法添加盜取合約並立即執行）

移除白名單目標是即時的（越嚴格 = 越安全）

資金對於日常支出和 DeFi 保持完全可用。保護機制僅限制在受脅迫情況下的行為。

介面架構

該標準定義了兩個介面：

ICoercionResistantVault —— 核心 ETH 支持、時間鎖、守護者、多簽、DeFi 執行

ICoercionResistantVaultTokens —— ERC-20 擴展，具備單一代幣支出限制

兩者共享相同的時間鎖時長、守護者設置、多簽配置和白名單。這種分離允許僅需 ETH 支持的簡化實作。

為什麼現有方法不足

方法	問題	本標準
脅迫/誘餌錢包	攻擊者可能知情並升級暴力	鏈上可驗證限制，無需欺騙
純多簽	日常使用存在摩擦	熱餘額 + DeFi 執行可即時運作
純時間鎖	無法立即支付任何款項	具速率限制的熱餘額供日常使用
硬體錢包	在物理脅迫下擁有完全訪問權	智能合約強制執行限制，不受環境影響

草案前置與參考實作

完整 ERC 草案 + Solidity 參考實作（ERC-4337 智能帳戶，約 700 行）：

https://github.com/DeFiRe-business/eip-proposal-5wrench

徵求回饋

相對於需要手動補充的固定「熱池」，每週期速率限制 (per-epoch rate limiting) 是否為正確的方法？

雙介面分離（核心 ETH + 代幣擴展）是否為正確的拆分方式？

首次代幣配置 應該是立即生效還是也需要時間鎖？

本標準是否應定義 建議的最短時間鎖（例如 24 小時）？

應如何處理 轉帳手續費 (fee-on-transfer) 和重定基數 (rebasing) 代幣？

標準是否應包含 緊急社交恢復 機制，還是留給實作方決定？

白名單 DeFi 執行 模型（execute + executeBatch + approveToken）是否為正確的抽象，還是應該更細粒度（例如針對每個函數選擇器）？

對於 ERC-4337 整合 有任何疑慮嗎 —— 特別是簽名驗證方法和 EntryPoint 的交互？

期待您的想法。

        1 則貼文 - 1 位參與者

        [閱讀完整主題](https://ethereum-magicians.org/t/erc-coercion-resistant-vault-spending-limits-timelock-multisig-against-5-wrench-attacks/28130)