如果你有在關注 DeFi 借貸賽道，最近這則新聞應該讓不少人皺眉頭——Cronos 鏈上的 Tectonic 借貸協議在 8 月底遭到駭客攻擊，總借款金額高達 1.2 億美元。雖然官方後續啟動了回滾機制想辦法補救，但最終仍有約 920 萬美元的資金「順利」被轉到鏈外。這到底是怎麼發生的？讓我們把整件事攤開來看。
攻擊發生了什麼？先講結論
老實說，這次的攻擊手法不算新穎，但執行得相當精準。根據 Cronos 官方在 9 月初發布的事後報告，駭客利用了 Tectonic 協議的價格餵價漏洞，透過不斷「借新還舊」的操作循環，硬是把擔保品的價值給灌水了。
攻擊者只用了 500 萬美元的初始資金，透過 98 次循環借貸操作，硬是把 TONIC（協議的原生代幣）價格拉高了將近 300 倍。這種操作讓協議誤以為擔保品價值暴增，於是核准了超額借款。
攻擊時間線整理
- 8月30日 12:49 UTC：Tectonic 協議偵測到異常活動
- 8月30日 14:32:47 UTC：Cronos 驗證者緊急暫停網路
- 8月30日 23:49:01 UTC：區塊生產恢復，帳戶餘額回滾至攻擊前
920 萬美元為何追不回來？
這是很多人心中的疑問。官方不是說回滾了 1.112 億美元嗎？沒錯，回滾機制確實把大部分被操縱的借款給逆轉了，但問題在於——資金轉移的速度比驗證者反應還快。
從攻擊開始到網路暫停，中間大約有 2 小時的窗口期。在這段時間裡，駭客已經把價值約 919 萬美元的穩定幣、比特幣、以太坊和其他資產透過 11 筆交易轉出了 Cronos 鏈。區塊鏈數據公司 Bitquery 的追蹤顯示，其中部分資金後續被轉到了以太坊網路。
這就是區塊鏈「不可逆」特性殘酷的一面：一旦交易確認且跨鏈轉移完成，即使網路暫停也沒辦法直接沒收那些已經離開的資產。
攻擊手法關鍵： TONIC 代幣的操控
這次攻擊的核心，其實是對 TONIC 代幣價格的操控。Tectonic 協議的價格餵價機制會參考 TONIC 的市場價格來評估擔保品價值，而 TONIC 本身就是一個交易深度非常薄的代幣。
駭客看準了這一點，先用少量資金在短時間內大量買入 TONIC，硬生生把價格拉高 300 倍。由於價格暴漲，協議誤以為用戶的 TONIC 擔保品價值暴增，於是核准了巨額借款——這就是典型的「價格操控 + 借貸協議漏洞」組合攻擊。
對 Cronos 生態的影響與後續觀察
這次事件的受影響金額從一開始估計的 7500 萬美元，最終上修到 1.204 億美元，可見問題的嚴重性。雖然官方啟動了回滾機制，但 7.6% 的資金（920萬美元）已經無法追回。
對投資人來說，這裡有幾個值得記住的教訓：
- 借貸協議的擔保品定價機制很容易成為攻擊目標，特別是那些依賴單一代幣價格的協議
- 流動性低的代幣更容易被操控，用作擔保品時風險極高
- 網路暫停機制雖然能阻止進一步損失，但無法挽回已經轉出的資金
這類事件，以後還會發生嗎？
老實說，只要有 DeFi 借貸協議存在，這類攻擊就不會消失。2026 年的 DeFi 市場雖然已經比 2026、2026 年成熟太多，但價格操控、閃電貸攻擊、預言機漏洞等問題仍層出不窮。
對一般投資人而言，與其期待「絕對安全」的協議，不如學會分散風險——不要把全部資金壓在單一借貸平台上，也不要使用流動性極差的代幣作為主要擔保品。
FAQ 常見問題
Cronos 是什麼區塊鏈？
Cronos 是一條由 Crypto.com 團隊主導開發的 Layer-1 區塊鏈，目標是提供快速、低成本的 DeFi 與 NFT 應用場景。
Tectonic 協議是做什麼的？
Tectonic 是建立在 Cronos 鏈上的借貸協議，用戶可以存入加密資產作為擔保品，然後借出其他資產——有點像區塊鏈版本的銀行借貸。
資金追不回來，投資人該怎麼辦？
根據目前的官方公告，受影響的用戶可能需要等待後續的補救方案。建議持續關注 Cronos 官方社群公告，並且做好資產分散，避免把雞蛋放在同一個籃子裡。
這筆損失誰該負責？
目前官方尚未公布具體的責任歸屬與補償細節。DeFi 協議的特性是「代碼即法律」，投資人在使用前必須自行承擔智能合約風險，這也是區塊鏈投資的基本原則。
資料來源與利益揭露
本文資料來源主要為 Cointelegraph 報導（2026年9月8日）與 Cronos 官方事後報告。Bitquery 提供區塊鏈數據追蹤資訊。由於原始攻擊發生於 2026年8月30日，部分細節（如實際轉移金額）可能因區塊鏈分析工具的追蹤方式不同而略有差異，本文已盡力呈現已確認的事實與官方說明。
本網站與文中提及的任何平台並無合作關係或聯盟行銷安排，投資人請自行判斷風險。
如果你想了解如何在 DeFi 環境下降低類似風險，我們整理了一份借貸協議安全性評估清單，有興趣的讀者可以進一步探索。
🔍 相關標籤
#DeFi #監管
