僅供教育參考，不構成投資建議；投資可能產生損失。
直接答案
已啟用的模組是一條獨立授權路徑。在 Safe 類型的智慧帳戶中，獲准模組可呼叫 execTransactionFromModule，在不為該操作收集一般 M-of-N Owner 簽名的情況下執行 CALL 或 DELEGATECALL。因此，介面顯示的 Owner 門檻只描述一條執行路徑，並非帳戶的完整安全邊界。
模組可支援額度、定期付款、復原和協定操作等實用自動化。但其權限可能很廣：Safe 官方合約說明已啟用模組可以執行任意交易，並警告惡意模組可能接管 Safe。審查時必須檢查每個已啟用模組，不能只看 Owner 和門檻。
運作機制
Owner 先透過一般 Safe 交易授權 enableModule，帳戶再將模組寫入已啟用模組登錄。之後，該模組自行驗證呼叫者及規則，再呼叫 execTransactionFromModule；帳戶確認呼叫方已啟用後執行要求的操作。此時，安全性也取決於模組程式碼、設定、管理員、升級金鑰和外部相依項目。
交易 Guard 和 Module Guard 是兩種不同控制。交易 Guard 檢查一般 execTransaction 呼叫，Module Guard 則檢查模組發起的呼叫。Guard 可以拒絕執行，但故障或限制過度的 Guard 也可能造成阻斷服務。應確認安裝了哪種 Guard、它檢查什麼，以及如何復原或移除。
Fallback Handler 是另一個擴充點。當 calldata 與帳戶核心函式都不相符時，帳戶會將呼叫轉送給設定的 Handler，並在 calldata 後附加原始呼叫者位址。Handler 可增加簽名驗證和代幣回呼，但不安全的邏輯或設定也會新增權限與解析攻擊面。
範例
某金庫採用 3-of-5 Owner 門檻，並啟用額度模組處理日常付款。該額度模組可以升級，而升級管理員是單一熱錢包。如果該金鑰遭竊，攻擊者可能升級模組、呼叫模組執行路徑，並在未取得 3 個 Owner 簽名時轉走金庫資產。3-of-5 門檻本身未被更改，但不約束這條路徑。
審查應識別模組位址及已驗證實作、代理與管理員、支出上限、允許的目標和函式選擇器、是否允許 DELEGATECALL、已安裝的 Module Guard、Fallback Handler，以及停用模組所需的確切交易。每條部署鏈都應從帳戶合約和相關代理合約核驗這些值，不能只依賴錢包介面。
風險
- 權限風險： 有漏洞或惡意模組可能轉移資產、授權 spender、透過
DELEGATECALL改變帳戶狀態，或呼叫其他特權合約。功能受限的介面並不能證明鏈上權限同樣受限。 - 控制與升級風險： 模組代理、管理員、預言機、自動執行者或復原金鑰，可能讓表面上的 3-of-5 安排實際只由更少主體控制。應追蹤每條升級與設定路徑，直到最終簽名者和時間延遲。
- 可用性風險： 故障 Guard 可能阻止有效交易，而遭攻陷模組的行動速度可能快於 Owner 協調移除的速度。應測試停用與復原流程，監控模組、Guard 和 Handler 變更，並保留不依賴待移除元件的應變路徑。
常見誤解
- 誤解 1：「帳戶是 3-of-5，所以每筆轉帳都要 3 個簽名。」 門檻適用於一般 Owner 授權路徑；已啟用模組可以使用不同授權策略。
- 誤解 2：「一個 Guard 會保護所有執行路徑。」 一般交易 Guard 與 Module Guard 覆蓋不同入口，實際覆蓋範圍取決於已安裝合約及其規則。
- 誤解 3：「在介面移除模組就消除了風險。」 應在帳戶存在的每條鏈上核對鏈上已啟用模組登錄、Handler 和 Guard 儲存、代理實作及已送出的變更交易。
相關主題
來源
- Safe 模組 - Safe Ecosystem Foundation（查閱日期：2026-08-21）
- Safe Guard - Safe Ecosystem Foundation（查閱日期：2026-08-21）
- Safe Fallback Handler - Safe Ecosystem Foundation（查閱日期：2026-08-21）
- ModuleManager.sol - Safe Ecosystem Foundation（查閱日期：2026-08-21）