Avici 逾 60 萬美元加密卡資金流失，究竟發生了什麼？

2026 年 8 月 28 日，Solana 生態加密銀行 Avici 出現卡片抵押資金異常提領。早期鏈上追蹤顯示，流失金額約為 60 萬至 65.3 萬美元；部分報告後來追蹤到疑似攻擊者地址持有逾 100 萬美元資產。不過，這些數字可能反映攻擊進程中的不同時間點或不同資金流，不能直接相加，也不應全部視為最終損失。49 50 53

後續報告稱，Avici 的發卡合作夥伴 Rain 發現一個舊版 Solana 卡片合約存在漏洞，受影響合約已經升級。另有後續說法稱，最終核對損失為 500,859.22 美元，共有 1,685 名用戶受影響，Avici 承諾全額賠償。50 53 目前較穩妥的理解是：事件主要涉及用於存放卡片充值後餘額的獨立合約，而不是用戶平時存放其他 Solana 或 EVM 資產的自託管錢包。50 62

Avici 如何把加密貨幣連接到 Visa 消費？

Avici 採用的是「有抵押卡」模式，而不是一般銀行帳戶。按照其文件說明，流程大致如下：

1. 用戶把 USDC 存入貸款託管智能合約。
2. 存入的資產會為卡片建立相應的美元信用額度。
3. 用戶刷卡消費時，信用額度會相應減少。
4. 消費金額通常會在延遲結算後，從卡片合約中的 USDC 抵押資產變現扣除。35

Avici 文件亦表示，抵押合約部署在 EVM 網絡，但可透過自動跨鏈機制接收來自 Solana 的存款；卡片錢包與智能錢包分開，Visa 只有在證明確實發生卡片消費後，才能提取相應資金。33

這套設計的吸引力在於，用戶可以用加密資產進行日常支付，而不必把整個錢包交給交易所或銀行。然而，「自託管」並不代表支付流程中的每個環節都同樣簡單、獨立或沒有權限風險。當資金進入卡片餘額系統後，便會涉及專門的智能合約、跨鏈機制、發卡商、交易授權及結算流程。

事件說法如何逐步變化？

早期：卡片餘額出現未授權提領

8 月 28 日，Avici 承認卡片餘額提領出現問題；鏈上觀察者則發現資金流向疑似由攻擊者控制的地址。當時報導的金額從約 60 萬美元、65.3 萬美元，一直到逾 100 萬美元不等。49 51 54 58

在這個階段，公開資料尚不足以確認根本原因究竟是：

• 卡片抵押智能合約本身存在漏洞；
• 中繼器、通行金鑰、工作階段或帳戶抽象授權機制遭濫用；
• 管理員註冊或其他權限路徑被攻破；
• 用戶遭釣魚後簽署惡意交易；或
• 前端、後端、跨鏈服務或發卡合作夥伴的其他元件出現問題。

後續：Rain 指向舊版 Solana 卡片合約

較新的更新則稱，Rain 發現 Avici 及少數其他項目使用的舊版 Solana 卡片合約存在漏洞，相關合約已在多個項目中升級，當時也沒有再發現新的未授權活動。50 62

同一組後續報導表示，受影響的是存放充值後卡片餘額的獨立 Solana 合約；用戶自託管的 Solana 及 EVM 錢包則與卡片餘額隔離。50

另有報告稱，事件最終核對出 500,859.22 美元損失，涉及 1,685 名用戶，Avici 將為受影響用戶提供全額補償。53 這個數字比攻擊進行期間的鏈上估算更具體，但讀者仍應區分「即時追蹤到的資金流」和「事後核對出的損失總額」。

為什麼 Avici 釣魚網站的報導仍然重要？

合約漏洞的說法並不能排除另一條獨立的釣魚攻擊線索。8 月 28 日的報導指出，有假冒 Avici 的網站以空投或平台功能為誘餌，誘導用戶連接錢包並簽署交易；其中一個假網站據報造成逾 60 萬美元損失，當時並沒有公開證據證明 Avici 內部系統遭到入侵。2 4

這兩種情況不一定互相排斥。卡片餘額合約漏洞可能影響存放在卡片系統內的資金，而假冒網站則可能針對連接錢包並簽署惡意交易的用戶。若沒有完整的事件報告，逐一比對受影響地址、合約、交易指令與時間戳，就不能假設所有損失都由同一個原因造成。

目前仍欠缺哪些關鍵資料？

現有公開紀錄仍未完整交代以下問題：

• 具體存在漏洞的合約版本及部署地址；
• 攻擊所使用的指令或完整交易流程；
• 攻擊者是否取得未授權管理員權限，或利用了其他授權路徑；
• 受影響帳戶及餘額的完整清單；
• 監控系統如何發現異常，以及合約升級所花時間；
• 賠償流程、資格與涵蓋範圍；
• 用戶是否需要更換通行金鑰、工作階段、委派權限或其他錢包憑證。

Rain 對舊版卡片合約漏洞的歸因，是目前相當重要的解釋，但不能延伸成「所有與 Avici 有關的錢包流失都由同一漏洞造成」。要釐清這點，仍需要一份可供外部檢視的完整事後檢討報告。

受影響用戶現在應該怎麼做？

1. 暫停使用可疑連結及受影響卡片合約

不要透過私訊、廣告、社交平台留言或所謂空投公告中的連結，連接 Avici 或卡片相關合約。若必須查詢進度，請使用自行儲存的官方網址，或透過獨立核實過的官方支援管道。

2. 分清楚「授權問題」和「私鑰已外洩」

如果你曾輸入助記詞、暴露私鑰、安裝不受信任的錢包擴充功能，或簽署不明交易，應考慮在乾淨的裝置或錢包環境中建立全新錢包，並轉移仍然安全的資產。

撤銷代幣授權無法修復已外洩的助記詞或簽署金鑰。若金鑰已經失守，只做撤銷授權並不足夠。

3. 逐一檢查各網絡的權限

對於 EVM 錢包：

• 檢查代幣額度及支出者授權；
• 撤銷不熟悉或無限額的支出授權；
• 若錢包支援帳戶抽象，亦檢查可疑的工作階段金鑰或委派權限。

對於 Solana 錢包：

• 檢查近期已簽署的交易；
• 檢查陌生委派者、已連接的應用程式及活躍工作階段；
• 不要以為一般「撤銷代幣授權」工具就能找出所有相關權限。

Solana 的授權模型與 EVM 並不完全相同，因此兩者不能用同一套檢查方式一概而論。

4. 保存證據

保存錢包地址、交易簽名、可疑網址、截圖、時間，以及導致你連接或簽署交易的訊息或廣告。這些資料有助 Avici 的已驗證支援團隊、錢包服務商或調查人員判斷事件究竟涉及釣魚，還是合約層面的問題。

5. 提防「退款」與「追回資金」騙局

不要簽署陌生帳戶傳來的「驗證」、「退款」或「恢復資金」交易。已知受害者往往會成為冒充客服或資金追回專家的下一輪詐騙目標。

Avici 對「自託管」安全性的啟示

自託管改變的是風險結構，而不是讓風險消失。用戶或許不必把資產的單方面控制權交給中心化託管機構，但仍可能受到錢包軟件、智能合約、跨鏈橋、中繼器、通行金鑰、委派權限、前端介面、發卡商及結算流程影響。

2026 年的 Coldcard 盜竊事件正好說明另一種風險：報導指約 500 個錢包在約 25 分鐘內合共失去約 594 BTC，問題源於硬件錢包韌體削弱了產生錢包種子所需的隨機性，而不是 Bitcoin 底層密碼學被破解。30

Coldcard 代表的是硬件及金鑰生成層面的失效；Avici 則凸顯智能合約、授權、介面及合作夥伴基礎設施的風險。至於近期其他協議或節點軟件漏洞，例如 Core Lightning 相關報告，現有資料不足以證明它們與 Avici 存在技術或營運上的直接關聯。

因此，重點不是自託管必然不安全，也不是中心化託管就一定更安全，而是要看完整的交易路徑。使用加密卡前，至少應確認：哪些資產留在普通錢包、哪些資產會移入卡片或託管合約、誰能授權提領、合約升級由誰管理，以及合作夥伴或合約出問題時會怎樣處理。

對自託管支付產品而言，安全性取決於整條鏈路，而不只是錢包標示上的「由你控制」。