~$3950萬損失：Allbridge、Wanchain等｜BlockSec週報

在過去一週（2026/07/20 - 2026/07/26），以下 8 起重大安全事件值得關注，涉及總損失約 $39.5M。

Allbridge 事件發生於 7 月 19 日（UTC 17:51），未納入上週報告，此處補充收錄以求完整。

• Allbridge 入選原因：此事件展示了由 Solana 位置型帳戶模型所導致的帳戶別名（account-aliasing）漏洞。由於原始碼不可取得，該漏洞須從已部署的程式二進位檔重建還原。
• Zilliqa 入選原因：此事件揭露了一個長期未被發現的離鏈錢包實作漏洞，自 2019 年起便使使用舊版原生 ZIL 帳戶的用戶面臨私鑰洩露風險。
• Wanchain 入選原因：此事件展示了跨鏈橋在不破解密碼學的情況下如何被耗盡資產。簽名有效且驗證正確，然而非單射（non-injective）、無分隔符號的訊息編碼，使得針對 3,097.56 個代幣的授權，在 Cardano 上被重新解讀為 203,001,692.164714 個代幣的提領。
• Lien Finance 入選原因：此事件說明了若驗證僅比對數量是否相符、而未檢查匹配項目的身份與重複性，則可被繞過。

本週精選：Allbridge Core

本事件獲選精選的原因：帳戶別名（account-aliasing）模式適用於任何在兩個指令角色中接受相同可變帳戶的 Solana 程式。其底層機制——對同一狀態產生兩個可變視圖，且第二次寫入靜默覆蓋第一次——與經典的 ERC-20 自我轉帳漏洞（transferFrom 中 from == to）具有相同的結構。專案方的事後分析 [1] 提供了高層次摘要，但未詳述程式碼層面的機制。以下分析係從已部署的程式二進位檔重建，以填補此一空白。

2026 年 7 月 19 日（UTC 17:51），Solana 上的跨鏈橋協議 Allbridge Core 遭受攻擊，損失約 $1.65M（約 $1.12M USDC 及約 $539K USDT）。根本原因在於 swap 指令在接受同一個 Pool 帳戶同時充當傳送與接收角色時，未強制要求兩者為不同帳戶。當同一帳戶被傳入兩次時，一個角色的內部帳務更新會被另一個角色靜默覆蓋，而實際的代幣轉移早已完成結算。五次自我 swap 使 Pool 的記錄狀態產生足夠的扭曲，讓攻擊者得以將少量 USDT 輸入轉換為約 $2.24M USDC。

背景

Allbridge Core 是一個跨鏈橋，透過名為 vUSD 的內部帳務單位路由 swap。一次 swap 包含兩個帳務腳步：

來源代幣 -- swap_to_v_usd(send_pool) --> vUSD
vUSD    -- swap_from_v_usd(receive_pool) --> 目標代幣

vUSD 並非 SPL 代幣，它僅作為每個 Pool 鏈上資料中的一個欄位存在。每個 Pool 追蹤 token_balance、v_usd_balance 以及 reserves。傳送腳步將來源代幣從用戶轉移至傳送橋接金庫，增加傳送 Pool 的代幣端帳務，並計算 vUSD 輸出量。接收腳步將該 vUSD 加入接收 Pool，減少其代幣端帳務，並將目標代幣從接收橋接金庫轉移至用戶。

Solana 程式以位置陣列的形式從呼叫者接收帳戶。程式的指令處理器指定陣列中哪些位置對應哪些角色（send_pool、receive_pool、send_mint 等），但執行時期並不阻止呼叫者在兩個位置傳入相同的帳戶地址。當程式在兩個不同位置對帳戶進行反序列化時，每次反序列化會產生一個獨立的記憶體內物件，對一個物件的修改不會影響另一個物件。若同一帳戶被傳入兩次，兩個物件的起始資料相同，但只要其中一個被修改，兩者便會開始分歧。

當處理器執行完畢後，程式的退出邏輯（例如 Anchor 的 AccountsExit）會依固定順序將每個帳戶物件序列化回帳戶資料。若兩個物件對應同一帳戶，第二次序列化將完整覆蓋第一次。

漏洞分析

受影響的 Allbridge Core 部署版本之確切原始碼不可取得。本分析係從儲存於 ProgramData 中的 1,770,736 位元組 ELF 重建（SHA-256：40f776...346bb6）。最後部署插槽（204,727,029）早於攻擊插槽（433,941,722）。

有漏洞的程式為 BrdgN2...ceWB。在攻擊交易的 Swap 指令（指令 3 至 7）中，四組傳送與接收帳戶對完全相同：

解析器包含 16 個已還原的 32 位元組比較，將每個角色與其預期的 mint、金庫、擁有者、PDA、授權方或 Token 程式綁定。然而，沒有任何比較強制要求 send_pool.key() != receive_pool.key()。兩個 Pool 角色在處理器執行前便已獨立反序列化。

已部署的 ELF 顯示兩個 Pool 的構建過程、傳送與接收的計算，以及兩個 Pool 的退出，均依固定順序執行：

L54249-L54252  function_9881(accounts[5])     -> 傳送 pool 本地物件
L54294-L54297  function_9881(accounts[6])     -> 接收 pool 本地物件

L74177-L74195  function_12623(send_pool)      -> swap_to_v_usd
L74368-L74389  function_12940(receive_pool)   -> swap_from_v_usd

L55932-L55936  function_8300(send_pool)       -> 完整 Pool 序列化
L55940-L55944  function_8300(receive_pool)    -> 完整 Pool 序列化

每次 function_9881 呼叫均分配一個獨立的 176 位元組本地 Pool 物件，並將解碼後的欄位複製其中。當帳戶金鑰相同時，兩個物件從相同的鏈上資料出發，但只要任一物件被修改，兩者便會分歧。

重建的偽 Rust 程式碼（已部署行為，非還原的原始碼）[2] [3]：

let mut send_pool = Account::<Pool>::try_from(&accounts[5])?;
let mut receive_pool = Account::<Pool>::try_from(&accounts[6])?;

require_keys_eq!(send_pool.mint, send_mint.key());
require_keys_eq!(receive_pool.mint, receive_mint.key());

// 金庫、擁有者、PDA、授權方及 Token 程式的綁定均已檢查。
// 缺少：require_keys_neq!(send_pool.key(), receive_pool.key());

token::transfer(send_user_token, send_bridge_token, amount)?;
let v_usd = swap_to_v_usd(&mut send_pool, amount)?;
let receive_amount =
    swap_from_v_usd(&mut receive_pool, v_usd, receive_amount_min)?;
token::transfer(receive_bridge_token, receive_user_token, receive_amount)?;

// 處理器返回後的 AccountsExit：
send_pool.exit(program_id)?;     // 第一次寫入
receive_pool.exit(program_id)?;  // 第二次寫入，覆蓋第一次

function_8300 從位置 0 開始寫入，並序列化所有 131 個已定義的 Pool 位元組。第一次退出寫入 send_pool；第二次退出將 receive_pool 寫入相同位元組。因此，帳戶的最終狀態是陳舊的接收端數值，而非兩個本地更新的合併結果。

SPL 代幣轉移是獨立的 CPI。它們在 Pool 退出之前更新由 SPL Token 程式擁有的金庫帳戶，因此第二次 Pool 序列化無法撤銷輸入的代幣轉移。每次別名化的 swap 因此將轉移的代幣留在金庫中，同時丟棄對應的傳送端 Pool 更新，接收端更新得以保留，使記錄的 Pool 狀態朝向更高的 v_usd_balance 和更低的代幣端帳務方向移動。

核心缺陷在於程式未檢查 send_pool 和 receive_pool 是否為不同帳戶。所有其他驗證（mint 綁定、金庫所有權、PDA 推導）均通過，因為兩個角色在正規情況下都合法地屬於同一個 Pool。

攻擊分析

以下分析基於交易 3LNLaG...Y39Q。

此次攻擊在一筆交易中完成，包含一次 Kamino 閃電借款、七筆 Allbridge Swap 指令，以及一次 Kamino 還款。

• 步驟 1：攻擊者從 Kamino 借入約 112 萬 USDC，並透過 Allbridge 兌換為約 94.9 萬 USDT（指令 1-2）。此第一次 swap 提供了後續自我 swap 所需的 USDT，並同時改變了 USDC 和 USDT Pool 的狀態。

• 步驟 2：攻擊者提交了五筆約 10 萬 USDT 的自我 swap，在傳送和接收兩端使用完全相同的 mint、Pool、金庫及用戶代幣帳戶（指令 3-7）。由於每次呼叫都是接收 Pool 最後序列化，持久化的帳務記錄了接收端的減少，但未記錄傳送端的增加。隨著扭曲的累積，觀察到的輸出逐次遞減：

五次呼叫共將約 50 萬 USDT 轉入金庫，並返還約 9.38 萬 USDT。Pool 記錄的 token_balance 隨每次呼叫下降，而真實金庫餘額則持續增長，擴大了下一步驟可利用的差距。

• 步驟 3：攻擊者僅投入約 3,990 USDT（指令 8）。已扭曲的 USDT Pool 產生了約 224 萬 vUSD，USDC Pool 將其轉換為約 224 萬 USDC。膨脹的 vUSD 輸出之所以可能，是因為在五輪被丟棄的傳送端更新後，Pool 記錄的代幣餘額遠低於其實際金庫餘額。

• 步驟 4：攻擊者償還了約 112 萬 USDC Kamino 閃電貸本金及約 11.2 USDC 手續費（指令 9）。攻擊者最終餘額為約 112 萬 USDC 及約 53.9 萬 USDT。

結論

此次事件的根本原因是缺少對 send_pool 和 receive_pool 是否指向不同帳戶的驗證。單一可變 Pool 被反序列化為兩個本地帳務物件，在 Token 程式已完成金庫轉移結算後，第二次完整序列化覆蓋了第一次，使 Pool 的記錄帳務與實際金庫餘額脫節。帳戶別名、ELF 控制流、序列化順序、交易日誌及金庫餘額均支持同一機制 [1]。

對於 Solana 程式，任何在兩個或更多可變角色中接受相同帳戶類型的指令，應強制要求唯一性（require_keys_neq!），或在退出前合併所有修改。Anchor 框架的 #[account] 約束系統預設不強制跨角色的唯一性，因此必須明確加入此檢查。一般模式——對同一狀態產生兩個可變視圖，且第二次寫入靜默覆蓋第一次——可出現於任何由程式自行管理序列化順序的場合。

參考資料

• [1] Allbridge Core，技術事後分析：Solana Pool Swap 漏洞利用
• [2] Allbridge Core JS SDK，Solana Swap 帳戶介面（bridge.json）
• [3] Allbridge Core EVM 合約，Pool 帳務參考（Pool.sol）

本週更多事件

Zilliqa Ledger 錢包

2026 年 7 月 20 日，Zilliqa 觀察到鏈上活動顯示舊版原生 ZIL 帳戶正遭受主動攻擊，已知損失約 $400K。根本原因是 Zilliqa Ledger 應用程式 EC-Schnorr 簽名路徑中存在偏置隨機數：隨機數生成程式碼在模數化約後，從 40 位元組緩衝區複製了錯誤的 32 位元組，導致最高有效 64 位元固定為零。攻擊者只需取得同一帳戶的數個公開簽名，即可透過格（lattice）方法還原私鑰並清空帳戶。

背景

Zilliqa 原生交易使用基於 secp256k1 的 EC-Schnorr 簽名。每次簽名時，簽署者必須採樣一個全新、全寬度、不可預測的臨時隨機數 $kk$，其中 （secp256k1 曲線階數）。簽名流程產生承諾值 $Q=\text{compress}(kG)Q\; =\; \backslash text\{compress\}(kG)$、挑戰值 $r=\text{SHA256}(Q\mathrm{\parallel }\text{publicKey}\mathrm{\parallel }\text{msg})Nr\; =\; \backslash text\{SHA256\}(Q\; \backslash |\; \backslash text\{publicKey\}\; \backslash |\; \backslash text\{msg\})\; \backslash bmod\; N$，以及響應值 $s=k-r\cdot xNs\; =\; k\; -\; r\; \backslash cdot\; x\; \backslash bmod\; N$，其中 $xx$ 為私鑰。一旦廣播，$(r,s)(r,\; s)$ 即為公開資訊。

線性關係 $s=k-rxNs\; =\; k\; -\; rx\; \backslash bmod\; N$ 是關鍵所在。正確的實作之所以安全，是因為每個 $kk$ 都是全新且均勻分布的。若隨機數存在偏置或過小，每個公開簽名都會洩露關於同一私鑰的資訊。

漏洞分析

相關的隨機數生成路徑引入自 Zilliqa Ledger 應用程式的提交「根據 Ledger 團隊審查修復錯誤」。預期流程為：生成 40 位元組的隨機數，對曲線階數 $NN$ 取模，並將所得純量作為 $kk$。生成一個較寬的隨機整數並對曲線階數取模，本身並無問題。缺陷出現在複製至隨機數緩衝區的步驟：

unsigned char nonce[size+8];
cx_rng(nonce, size+8);
cx_math_modm(nonce, size+8, (unsigned WIDE char *) PIC(domain->n), size);
os_memcpy(T->K, nonce, size);

cx_math_modm 執行後，32 位元組的純量結果右對齊於 40 位元組緩衝區中。os_memcpy(T->K, nonce, size) 複製前 size（32）個位元組，保留了開頭 8 個零填充位元組，並丟棄最後 8 個位元組的熵值。因此，生成的隨機數滿足 ，而非 。

這意味著每個隨機數有 64 位元固定為零。由 Schnorr 響應方程式 $k_i=s_i+r_{i}xNk\_i\; =\; s\_i\; +\; r\_i\; x\; \backslash bmod\; N$ 可知，每個簽名提供一個公開的模線性關係，且結果受 $2^{192}2^\{192\}$ 的上界約束。這構成一個隱藏數問題（Hidden Number Problem，HNP）實例。只需約四個或更多來自同一金鑰的受影響簽名，標準格規約演算法即可在商用硬體上數秒內還原私鑰 [1]。

此缺陷自 2019 年起存在於 Zilliqa Ledger 應用程式的每個發布版本中，直至 2026 年 7 月事件被發現為止 [2]。

本事件不提供攻擊分析。攻擊完全在鏈下執行：攻擊者利用格規約方法，從鏈上公開的簽名還原私鑰，再簽署標準轉帳交易。沒有需要分析的多步驟鏈上攻擊序列。

結論

此次事件由離鏈簽名實作缺陷引起，而非鏈上智能合約漏洞。Zilliqa Ledger 應用程式產生的 EC-Schnorr 簽名，其隨機數被限制在 ，在同一帳戶發起數筆原生交易後，洩露了足夠的結構化資訊以還原私鑰。

主要緩解措施是金鑰退役，而非僅更新 Ledger 應用程式。修正後的應用程式可防止產生新的弱化簽名，但無法抹去已記錄在鏈上的公開簽名。任何已產生足夠多易受攻擊簽名的受影響金鑰，都必須視為已洩露 [2]。

對於錢包與協議團隊：將隨機數的生成與編碼視為安全關鍵程式碼，在適用情況下優先採用經充分審查的標準進行確定性隨機數生成，並為受影響用戶提供協調一致的遷移路徑，同時考量到攻擊者可能已持有相同私鑰而搶先操作的風險。

參考資料

• [1] Boneh 與 Venkatesan，計算金鑰最高有效位元的困難性（HNP）
• [2] Zilliqa Ledger 事件中心

Wanchain Cardano 跨鏈橋

2026 年 7 月 20 日，Wanchain Cardano 跨鏈橋因 Cardano TreasuryCheck Plutus 驗證器中存在非單射訊息編碼，損失約 5.152 億 NIGHT（約 $500K）[1]。專案方的事後分析 [2] 描述了高層次機制，但未提供位元組層面的編碼細節或程式碼；以下分析重建了完整的碰撞過程。橋接節點的簽名有效且驗證正確，但無分隔符號的可變長度欄位拼接允許攻擊者移動兩個相鄰數字欄位之間的位元組邊界，將針對 3,097.56 NIGHT 的授權重新解讀為提領 203,001,692.164714 NIGHT。

背景

受影響的元件是 Wanchain 的 Cardano 跨鏈金庫系統。來源鏈用戶銷毀或鎖定代幣，橋接節點對從贖回者欄位解析的授權訊息進行簽名，並將已簽名的證明提交至 Cardano TreasuryCheck Plutus 驗證器以從金庫釋放資產。

漏洞分析

TreasuryCheck 驗證器對 14 個解析後的贖回者欄位的原始拼接結果驗證橋接節點簽名：

hashRedeemer = sha3_256 $ mconcat
  [ toPkhPay, toPkhStk, policy, assetName
  , packInteger amount, packInteger adaAmount
  , txHash, packInteger index, packInteger mode
  , uniqueId, packInteger txType, packInteger ttl
  , packInteger outputCount, userData
  ]

packInteger 使用的整數編碼為可變長度，且拼接過程沒有長度前綴、類型分隔符號或領域分離的類型化序列化。不同的語義元組因此可以產生相同的已簽名位元組字串。

在典型攻擊中，橋接節點簽署了一筆正常的提領：

amount    = 3097560000     -> packInteger = b8a103c0
adaAmount = 1206800        -> packInteger = 126a10
組合                                       = b8a103c0126a10

攻擊者提交的 Cardano 贖回者解析為：

amount    = 203001692164714 -> packInteger = b8a103c0126a
adaAmount = 16              -> packInteger = 10
組合                                        = b8a103c0126a10

兩個位元組序列完全相同。簽名檢查通過，Cardano 合約將贖回者解讀為一筆比授權金額大約 65,000 倍的提領。

攻擊分析

以下分析參考 Cardano 交易 0a4861...2ea1 及 BSC 來源交易 0xe90111...d5f26b。

• 步驟 1：攻擊者創建了外觀正常的來源鏈橋接請求。以典型案例為例，BSC 交易銷毀了 3,110 NIGHT，Wanchain API 記錄預期的 Cardano 接收金額為 3,097.56 NIGHT [3]。

• 步驟 2：橋接節點對從原始拼接欄位構建的授權雜湊值進行簽名。

• 步驟 3：攻擊者在保持已簽名位元組序列不變的情況下，更改了 Cardano 贖回者中 amount 與 adaAmount 之間的邊界。

• 步驟 4：Cardano TreasuryCheck 驗證器將贖回者解析為高價值提領，並成功驗證了被重用的簽名。該交易向攻擊者支付了 203,001,692.164714 NIGHT。

• 步驟 5：相同模式在多筆 Cardano 交易中重複，最終總計提領約 515,206,545.426856 NIGHT（約 $500K）。

結論

沒有任何密碼學被破解。簽署者產生了有效簽名，TreasuryCheck 驗證器也正確驗證了它們。缺陷在於訊息的構建方式：hashRedeemer 將 14 個可變長度欄位折疊為一個位元組字串，沒有任何分隔符號或長度前綴，使得編碼具有非單射性。不同的欄位元組可以產生相同的原像、相同的雜湊值，以及相同的有效簽名。

修復方法是使已簽名的編碼具有單射性，使得任何給定的位元組字串只能由唯一的欄位元組生成。固定寬度整數編碼或為每個欄位加上長度前綴，可以固定攻擊者所移動的邊界。使用標準的結構化編碼器同樣可以達到此效果，且更難出錯。通用原則：對規範序列化的結果進行簽名，而非對原始拼接進行簽名。這與 Solidity 中使用帶有可變長度參數的 abi.encodePacked 屬於同一類漏洞，不同的輸入元組可以產生相同的位元組序列。此問題適用於任何從可變長度欄位組裝的已簽名訊息，對於構建和解析訊息的各方在不同系統中運作的跨鏈橋而言尤為相關。

參考資料

• [1] BlockSec Phalcon 關於 Wanchain 漏洞利用的貼文
• [2] Wanchain Cardano-BNB Chain 跨鏈橋事件事後分析
• [3] 典型 BSC 交易的 Wanchain 狀態 API 記錄

Lien Finance

2026 年 7 月 24 日，以太坊上的去中心化債券 OTC 協議 Lien Finance 遭受攻擊，損失約 $542K USDC。根本原因是債券兌換函式中的驗證缺陷：它僅檢查輸入與輸出組之間共享債券的總數是否相符，但未追蹤哪些特定債券被匹配。這使得攻擊者得以繞過所有輸入債券的銷毀步驟，同時鑄造一個無抵押品的債券，並透過協議的 OTC 池換取真實的 USDC。

背景

Lien Finance 是一個 DeFi 協議，以 ETH 為抵押發行有抵押債券。其 BondMakerCollateralizedEth 合約允許用戶鎖定 ETH 作為抵押品來鑄造債券代幣。債券的收益由 fnMap 定義，這是一個分段線性函式，將到期時的抵押品價格映射至該債券的支付金額。

有意義的單位是債券組。registerNewBondGroup() 驗證一個組中所有債券的收益，在其組合 fnMap 的每個斷點上加總等於 ETH 價格。滿足此條件的組恰好重組一個單位的抵押品。這也是為何各組可以互換：任何兩個滿足此條件的組價值相同，exchangeEquivalentBonds() 的轉換路徑依賴此保證。

債券與組的註冊均為無許可制：任何地址皆可透過提供到期日和任意 fnMap 來註冊新債券，任何地址也可將任意已註冊的債券 ID 列表註冊為一個組，僅受收益加總檢查的約束。

漏洞分析

有漏洞的合約為 0xDA6F...BEf0 及 0x8432...7de0。

當一個債券同時出現在輸入組和輸出組中時，銷毀後立即重新鑄造屬於無謂的操作。exceptionBonds 參數命名這些債券，以便兌換過程可以跳過兩個步驟。函式以單一計數器 exceptionCount 來執行此操作：在掃描輸入組時每次匹配遞增一次，在掃描輸出組時每次匹配遞減一次，始終未記錄哪個 bondID 被匹配。

這意味著輸入組 [BondA, BondB] 和輸出組 [BondC, BondA, BondA]，搭配 exceptionBonds = [BondA, BondB]，可以通過驗證。計數器在輸入端達到 2（BondA 和 BondB 各匹配一次），並在輸出端歸零，但兩次遞減都來自 BondA 的兩個條目。兌換不銷毀任何債券，僅鑄造 BondC：在沒有消耗任何輸入的情況下創建輸出組代幣。

攻擊分析

攻擊分為兩筆交易：步驟 1 發生於 0xe8689a...284d0f，步驟 2-5 發生於 0xb96d57...48e0e7。

• 步驟 1：攻擊者三次呼叫無許可的 registerNewBond()，定義了具有相同到期日的 BondA、BondB 和 BondC。BondA 和 BondB 是槓桿做多，在 $3,200 以下均等分配抵押品，其收益加總等於 ETH 價格，滿足 _assertBondGroup() 的要求。BondC 是深度價外 LBT，行使價為 $3,200，現貨價為 $1,870：內在價值為零，但作為選擇權仍有約 $7.64/IMT 的時間價值。

• 步驟 2：攻擊者註冊了兩個債券組。registerNewBondGroup([BondA, BondB]) 返回組 36（輸入），registerNewBondGroup([BondC, BondA, BondA]) 返回組 37（輸出）。BondC 的平坦零收益不影響斷點加總，因此其存在不破壞等價條件。BondA 在組 37 中被列出兩次，這正是使兌換通過驗證的關鍵所在。

• 步驟 3：攻擊者呼叫 exchangeEquivalentBonds(inputGroup = 36, outputGroup = 37, amount = 6968565865905, exceptionBonds = [BondA, BondB])。掃描輸入組：BondA 和 BondB 各匹配一個例外，均跳過銷毀，exceptionCount 達到 2。掃描輸出組：BondC 無匹配並被鑄造，隨後 BondA 的兩個條目各匹配一個例外，計數器歸零。

• 步驟 4：攻擊者透過協議的 OTC 池（GeneralizedDotc）將鑄造的 BondC 出售換取 USDC，獲得 532,144 USDC。

• 步驟 5：攻擊者對第二個 BondMakerCollateralizedEth 合約重複相同模式，使總獲利達到約 542,144.63 USDC。

結論

exceptionBonds 機制原本設計為跳過共享債券的重新鑄造，但透過在輸出組中重複一個 bondID，可以將其套用於所有輸入債券。這破壞了債券代幣只能透過 issueNewBonds() 對應已存入抵押品才能創建的不變量。修復方法是追蹤哪些特定 bondID 已被匹配（例如使用位元圖或集合），確保每個例外在兩個組中各被消耗恰好一次。

關於 BlockSec

BlockSec 是一家全方位的區塊鏈安全與加密資產合規提供商。我們構建產品與服務，協助客戶進行程式碼審計（包含智能合約、區塊鏈及錢包）、即時攔截攻擊、分析事件、追蹤非法資金，以及滿足反洗錢/反恐融資（AML/CFT）義務，貫穿協議與平台的完整生命週期。

BlockSec 已在頂級會議上發表多篇區塊鏈安全論文，通報了數起 DeFi 應用的零日攻擊，阻止了多起駭客攻擊並成功搶救逾 2,000 萬美元，並為數十億美元的加密資產提供安全保障。

• 官方網站：https://blocksec.com/

• 官方 Twitter 帳號：https://twitter.com/BlockSecTeam

• 🔗 BlockSec 審計服務 ：提交申請

• 🔗 Phalcon Security APP：預約示範

• 🔗 Phalcon Compliance