攻擊者不需要私鑰，也不需要騙使用者簽名。他只需要一個公開合約呼叫、一段偽造 calldata，和三分鐘等待時間。
來源：Federico 的 X Article〈The Gnosis Pay hack: A deep dive〉2026 年 6 月 1 日，Gnosis Pay 使用者的金融卡連動錢包遭到攻擊。Federico 與 Moneda 團隊在 X Article 中估計，攻擊影響約 1,000 到 5,000 名使用者，鏈上可驗證交易約 34,000 筆，損失約 116 萬到 120 萬美元。
真正值得看的是攻擊路徑。這不是私鑰外洩，不是釣魚簽名，也不是使用者按錯按鈕。攻擊者從公開鏈上找到受害者的 Delay Module 位址，送出一筆合約呼叫，讓受害者自己的 Safe 在三分鐘後執行轉帳。
關鍵不是「卡片被盜刷」，而是自託管卡片後面的合約授權層被打開。
Gnosis Pay 的卡片連動 Safe 需要同時滿足兩件事：使用者刷卡時，付款網路要能在幾秒內完成授權；使用者又不能把同一筆資金在鏈上立刻轉走，形成雙花。Delay Module 的任務是把使用者主動發起的鏈上提款延遲三分鐘，讓卡片授權和自託管提款不會互相踩到。
這個設計防的是雙花，不是偷竊。攻擊者利用底層 Modifier 漏洞，把任意轉帳排進受害者的 Delay Module。三分鐘冷卻時間沒有阻止攻擊，只是讓攻擊者等三分鐘再執行。
初步討論容易把矛頭指向 Delay Module。但 Federico 的拆解指出，問題落在 Zodiac Modifier base class 的 SignatureChecker。它支援 EIP-1271 合約簽名，卻在一次 staticcall 中丟掉 success flag，只檢查回傳資料前四個 bytes 是否等於 magic value。
Safe v1.3.0 的 fallback handler 在特定呼叫鏈下產生 revert payload。這段 payload 剛好是 0x1626ba7e，等於 EIP-1271 的 magic value。兩個元件各自看起來合理，疊在一起就變成可利用路徑。
這也是事件範圍比 Gnosis Pay 更大的原因。任何繼承 Zodiac Modifier、Delay 1.1、Roles v2 或自訂 Modifier 的合約，如果把 Safe 設為 privileged caller，都要檢查同一條攻擊向量。
穩定幣金融卡很難做。刷卡場景要求兩秒內完成授權；鏈上自託管要求使用者不交出私鑰；支付公司還要避免使用者先刷卡、再立刻把鏈上餘額轉走。Delay Module 是為了這個現實而生。
但這次事件說明，延遲不是撤銷權。當惡意交易被排入 queue，使用者若沒有即時警報、沒有可操作的 veto、沒有把卡片可用額度限制在隔離帳戶內，三分鐘只是一個攻擊者也願意等待的倒數計時。
延遲只能把資金移動往後推。它不會自動辨識惡意交易，也不會在使用者睡覺時替他拒絕提款。
冷卻期要搭配即時通知、可達成的撤銷路徑、每日限額，以及把卡片餘額和主要資產切開。
這篇 X Article 的語氣不是否定 Gnosis Pay。相反地，它承認穩定幣卡片要同時接上支付網路、智能帳戶和使用者自託管，本來就很難。真正的教訓是：如果一個模組會成為整個使用者群的共同部署模式，它就不能只靠「理論上有 cooldown」來承擔安全責任。
三分鐘延遲不是防盜機制。它只是把立即失竊，變成三分鐘後失竊。
自託管支付的安全感，不能只來自「我還握有私鑰」。也要來自每一個被授權移動資金的合約路徑。
選完之後，分享你的判斷
Federico 的 X Article 包含完整 calldata、Gnosis Chain 交易、EIP-1271 驗證路徑與復現指令。這個頁面整理的是核心閱讀版本。
閱讀原始 X Article →喜歡這種分析嗎？
從穩定幣、智能錢包到鏈上安全，用台灣讀者看得懂的語言，把複雜的產業變局說清楚。目前已有超過 2 萬位讀者訂閱。
免費訂閱區塊勢 →也可以直接付費支持，解鎖每週完整文章