Drift 2.8 億美元損失，問題在治理

Drift Protocol 這次不是單純被打穿合約。估計損失約 2.8 億美元，攻擊點落在治理控制、簽核流程，還有一堆人會忽略的營運細節。講白了，攻擊者沒硬撞牆，反而是從門禁系統下手。

這件事發生在 Solana 生態。它的速度很快，交易也很便宜。問題是，速度一快，管理失誤也會跟著放大。對 DeFi 團隊來說，這不是單一漏洞，而是控制面失守。

Drift 先在 X 上說明事件。從時間線看，攻擊像是先準備，再收網。這種手法很煩，因為它不是靠一個 bug。它靠的是你平常覺得沒事的流程。

攻擊怎麼進來的

Drift 是做永續合約交易的平台。它依賴合約，也依賴鏈下協調。這次看起來，攻擊者碰到的是 durable nonce 和多簽流程。這兩個東西本來是為了方便管理。結果一旦設計不好，就會變成入口。

durable nonce 的用途，是讓交易先簽好，再晚點送出。對正常維運很方便。可是一旦有人能提前佈局，就能把交易藏起來，等時機成熟再一次放出。這種做法很像把炸藥先埋好，再找時間按鈕。

多簽也一樣。multisig 的設計目的是分散風險。可是假如簽署者、nonce、或權限切換被拿下，整個流程就會變成攻擊者的工具。Drift 表示，目前沒有看到 smart contract 本身有 bug，也沒有跡象顯示 seed phrase 直接外洩。

• 估計損失：約 2.8 億美元
• 攻擊面：治理與簽核，不是核心合約邏輯
• 執行方式：先準備，再在短時間內收割
• 鏈上環境：Solana
• 控制點：Security Council 多簽與 nonce 帳戶

時間線很像預謀

Drift 公布的時間線，看起來很不妙。3 月 23 日，四個 durable nonce 帳戶被建立。兩個跟多簽成員有關，另外兩個則掌握在攻擊者手上。這代表攻擊者不是臨時起意，而是先把可用的控制點放進去。

到了 3 月 27 日，Drift 做了 Security Council 相關的成員變更。這類操作平常很正常。可是在這種事件裡，任何權限輪替都可能變成空窗。攻擊者只要提前摸清流程，就能在切換時重新卡進來。

3 月 30 日，又有一個 durable nonce 帳戶在更新後的多簽下建立。接著 4 月 1 日，先跑了一次正常測試交易。大約一分鐘後，兩筆預簽交易被觸發。這段節奏很關鍵。攻擊者不是亂打。他是在等系統自己把門打開。

Drift 在公開說明裡也提到這次事件的複雜性：

“This was a highly sophisticated operation that appears to have involved…” — Drift Protocol on X

這句話雖然沒寫完，但意思很明白。這不是普通偷幣。這更像是一次針對控制流程的長期操作。

為什麼損失會擴得這麼大

一旦攻擊者拿到管理權，後面就快了。Drift 說，借貸倉位、vault 存款、交易資金都受影響。攻擊者移除了提領限制，還塞進惡意資產。這一步很狠，因為它直接把防線拆掉。

這種情況在 DeFi 很常見。只要 control plane 被拿走，攻擊者就不必慢慢找 bug。他可以直接改規則、關掉保護、把錢搬走。你可以把它想成，不是偷鑰匙，而是整組換鎖。

Drift 也說，不是所有資產都中招。沒有存進 Drift 的 DSOL 還是安全的，包括質押到 Drift validator 的代幣。保險基金則先被撤出並保護起來。這些細節很重要，因為它顯示事件範圍很大，但不是整個系統全滅。

• 借貸倉位受影響
• vault 存款受影響
• 交易資金受影響
• 未存入 Drift 的 DSOL 仍安全
• 保險基金先被轉移保護

跟其他 DeFi 事故比，差在哪

DeFi 以前也出過很多事，但這次要分到另一類。像 Euler 2023 年的損失，核心在 smart contract 邏輯缺陷。Wormhole 的大案，則是跨鏈驗證模型出問題。Drift 這次比較像治理失守，不是程式碼直接爆炸。

這個差異很重要。因為很多團隊只做 code audit。可是如果你的系統依賴少數簽署者、nonce 流程，或延遲執行，那社交工程、流程濫用、權限切換失誤，全都算攻擊面。講白了，最弱的地方常常不是合約，而是流程。

我把幾種常見失敗方式整理一下：

• 程式碼漏洞：攻擊者直接打爆合約邏輯
• 橋接漏洞：攻擊者利用跨鏈驗證或訊息處理
• 治理漏洞：攻擊者拿下簽署者、權限或管理路徑
• Drift 這案：看起來就是治理與管理控制被盯上

所以這起事件不只跟 Solana 有關。任何用 multisig、延遲執行、或委派管理權的專案，都得重新看自己的控制面。你以為在管人，其實是在管錢。

這件事放到產業脈絡裡看

DeFi 走到今天，大家很會談審計、形式驗證、bug bounty。這些都重要，沒人否認。可是真正出事時，常常不是合約那一層先炸，而是權限、流程、和人為操作先出包。這是很現實的問題。

尤其在高頻交易、借貸、衍生品這幾類產品裡，管理動作本來就很多。像 signer 變更、金庫調整、風控參數更新，這些都需要速度。可是一旦速度壓過審核，風險就會累積。很多團隊嘴上說去中心化，實際上還是靠少數人按鈕。

這也是為什麼這類事件會讓人不舒服。因為它不是技術人員最愛講的那種「一行程式碼寫錯」。它更像是組織流程、權限設計、和應急機制一起失靈。說真的，這比單純 bug 更難修。

接下來該看什麼

Drift 表示已經凍結剩餘功能，移除被入侵的錢包，還在跟資安公司、交易所、橋接服務和執法單位合作追查資產。完整事後報告應該很快會出來。這份報告很重要，因為它能看出到底是哪個環節先鬆掉。

我覺得這次會逼更多團隊重做治理設計。像是縮短簽核有效時間、限制高額管理動作、增加 signer 變更的人工確認，還有把 nonce 流程拆得更細。這些都不酷，但很實用。安全本來就不帥，出事才知道有沒有做。

如果你在做 DeFi，我會直接問一個問題：你的程式碼過了審計，那控制面呢？如果答案很模糊，那就麻煩了。下一次出事，可能不是合約被打穿，而是你自己把門打開。