Web3 每週安全事件匯總 | 2026 年 3 月 2 日至 3 月 8 日

在過去的一週（2026/03/02 - 2026/03/08）中，BlockSec 檢測並分析七起攻擊事件，總估計損失約為 325 萬美元。下表總結了這些事件，後續章節提供了每個案例的詳細分析。

*BUBU2 事件在上週的報告中被遺漏，此處加入以求完整性。

1. BUBU2 事件

簡要總結

2026 年 3 月 1 日，BNB Chain 上的 BUBU2 代幣遭到攻擊，導致約 1.97 萬美元的損失。根本原因是代幣設計缺陷：合約中嵌入了一種隨時間累積的通貨緊縮機制，該機制在轉帳時會直接從 AMM 資金池的儲備中扣除代幣。攻擊發生前，合約所有者將觸發間隔縮短至一個極小值，導致數百輪的銷毀量在單次呼叫中累積並執行。攻擊者利用閃電貸觸發此機制，耗盡了資金池儲備並推高了代幣價格，隨後以扭曲的匯率進行反向交易獲利。

背景

BUBU2 是部署在 BNB Chain 上的通貨緊縮型 ERC-20 代幣協議。該協議嵌入了一個由 burnAndMintSwitch 控制的週期性通貨緊縮引擎：一旦由所有者通過 setBurnAndMintSwitch(true) 啟用，任何觸發 _update() 掛鉤的非豁免轉帳都將調用 _triggerDailyBurnAndMint()，該函數會根據自上次觸發以來經過的 TRIGGER_INTERVAL 週期數量，按比例銷毀交易對中的 BUBU2 餘額，並相應地同步儲備。

漏洞分析

根本原因是 BUBU2 代幣合約 (0x3fF3...ee52) 中的一個設計缺陷。該合約在其 _update() 掛鉤中嵌入了一個週期性通貨緊縮機制：當被觸發時，_triggerDailyBurnAndMint() 會計算自上次執行以來經過的 TRIGGER_INTERVAL 週期數量，並直接從交易對 (0x7745...cd2f) 中銷毀相應數量的 BUBU2，隨後執行 sync() 更新儲備。關鍵在於，所有者可以在沒有任何時間鎖 (timelock) 或最小界限保護的情況下重新配置 TRIGGER_INTERVAL。

攻擊前，所有者調用了 setBurnAndMintSwitch(true)，隨後調用了 setTriggerInterval(120)，將時間間隔從預設的 6 小時壓縮至 120 秒。由於 lastTriggerTime 仍停留在數小時前，下一次觸發計算出了數百輪的累計量，銷毀數量隨輪數線性擴張。這導致單次轉帳即從資金池中抽走了大量 BUBU2，導致資金池儲備崩潰，代幣價格暴漲約 11 倍。

攻擊分析

以下分析基於交易 0x1bc0...141c、0x191c...1ee4、0xd6e5...51a6。

• 步驟 1：代幣所有者先通過 setBurnAndMintSwitch(true) 啟用週期性通貨緊縮機制，隨後通過 setTriggerInterval(120) 將觸發間隔從 6 小時縮短至 120 秒。隨後攻擊者通過閃電貸借入 18 個 WBNB，並將其與資金池中的約 18,715,856 個 BUBU2 進行兌換。

• 步驟 2：攻擊者發起了一筆小額轉帳，觸發了 _triggerDailyBurnAndMint()。資金池的 BUBU2 餘額減少了約 1,025,988,664e18 個代幣，在執行 sync() 後，儲備中僅剩 6,493,352e18 個 BUBU2，這使得 BUBU2 的價格暴漲了約 200 倍。

• 步驟 3：攻擊者以暴漲後的價格將步驟 1 中獲得的 BUBU2 賣回給資金池，收到約 50 個 WBNB。歸還閃電貸後，淨利潤約為 32 個 WBNB。

結論

BUBU2 事件源於代幣合約中的嚴重設計缺陷。所有者配置了一個極不合理的 TRIGGER_INTERVAL，導致經過的時間累積成數百個執行輪次，並在一次呼叫中耗盡了交易對的儲備，引發 BUBU2 價格的劇烈波動。

為降低未來類似風險：

• 使用邊界限制或時間鎖保護 TRIGGER_INTERVAL 等關鍵參數。

• 限制或設定累計執行輪次的上限。

2. ACPRoute 事件

簡要總結

2026 年 3 月 2 日，Base 鏈上的 ACPRoute 協議遭到攻擊，導致約 5.8 萬美元的損失。根本原因是支付管理合約中的業務邏輯錯誤：工作狀態作為記憶體副本而非儲存參照載入，導致累計支付追蹤從未在鏈上持久化。這使得攻擊者能夠建立一個工作，在階段轉換期間觸發自動支付釋放，隨後通過無許可的領取函數再次領取同一筆託管資金。

背景

ACP（Agent Commerce Protocol）是一個用於客戶與服務提供者互動的模組化鏈上商業協議。它將活動分為三個層級：帳戶、工作與備忘錄。工作遵循固定的生命週期（REQUEST → NEGOTIATION → TRANSACTION → EVALUATION → COMPLETED），支付款項在 TRANSACTION 階段由 PaymentManager 合約託管。當工作達到 COMPLETED 時，協議通過 releasePayment() 函數將託管資金釋放給提供者。為防止重複領取，協議通過 Job 結構體中的 amountClaimed 欄位追蹤每個工作的累計支出。預計每次調用 releasePayment() 時都會將請求金額與 amountClaimed 進行比較，以確保資金僅被釋放一次。

漏洞分析

根本原因在於 PaymentManager 合約 (0x56c3...0684) 的 releasePayment() 函數，其中的工作狀態是以記憶體副本而非儲存參照載入的。儘管協議通過 amountClaimed 追蹤累計支出以防止重複領取，但遞增操作 job.amountClaimed += amount 僅在短暫的局部副本上進行，從未寫回鏈上儲存。因此，每次調用 releasePayment() 函數時，觀察到的 amountClaimed 始終為 0，這使得攻擊者在階段轉換自動觸發 releasePayment() 函數後，仍能再次呼叫 claimBudget() 函數並耗盡受害合約 (0x307e...d6e8) 的資金。

攻擊分析

以下分析基於交易 0xe94a...f9a0。

• 步驟 1：攻擊者通過閃電貸借入 97,000e6 個 USDC 作為後續攻擊的資本。

• 步驟 2：在回呼中，攻擊者在 ACPRouter 上調用 createJob() 函數，同時部署了一個全新的提供者合約 (0x1ee502dd...) 用於接收資金。

• 步驟 3：攻擊者重複調用 createMemo() 並執行提供者合約內部的 exec() 來推進工作階段，直到觸發 COMPLETED 階段轉換，該轉換自動調用 releasePayment() 並將全部餘額釋放給提供者合約。此時 amountClaimed 本應更新，但其在儲存中的值仍為 0。

• 步驟 4：攻擊者調用 claimBudget() 函數，並成功將託管的 97,000e6 個 USDC 作為利潤再次領取。

結論

該事件是由狀態持久性缺失導致的，使得託管資金能在同一個工作生命週期內被領取兩次。

為降低未來類似風險：

• 確保關鍵狀態變數（如 amountClaimed）使用儲存參照進行更新。

• 限制敏感的支付功能，或在執行前強制進行嚴格的狀態驗證。

3. sDOLA Llamalend 市場事件

簡要總結

2026 年 3 月 2 日，以太坊上的 sDOLA Llamalend 市場遭到攻擊，導致約 23.9 萬美元的損失。根本原因是價格操縱。具體來說，sDOLA 是一個 ERC4626 代幣，其價格可以通過 donate() 進行操縱。Llamalend 是一個基於 AMM 的借貸市場，由於 LLAMMA 的機制，即使在抵押品價格上漲時，用戶仍可能面臨清算。因此，攻擊者可以使用 donate() 推高 sDOLA 價格，將用戶的頭寸健康度推至零以下，然後清算這些用戶以獲利。

背景

LLAMMA（Lending-Liquidating AMM Algorithm）是 Curve 使用的一種基於 AMM 的借貸市場 [1]。與傳統借貸協議不同，LLAMMA 將用戶抵押品放入 AMM 中的價格帶。隨著預言機價格 $P_{oracle}P\_\{oracle\}$ 的移動，抵押品通過跨帶的套利交易在抵押品代幣與 crvUSD 之間逐步轉換（軟清算），從而逐步降低頭寸風險，而不是觸發突發清算。

若軟清算無法足夠快地降低頭寸風險，則會觸發硬清算 [2]，這是在頭寸健康度跌破零時觸發的。健康度計算方式為 get_x_down() [3]，它不僅僅是簡單的市值折價。相反，它會模擬用戶頭寸的回程轉換以評估其可回收價值。該回程轉換使用兩個不同的價格錨點：一個源自當前 $P_{oracle}P\_\{oracle\}$（隨即時預言機變動），另一個源自用戶的價格帶邊界（在創建頭寸時設定）。

漏洞分析

受影響合約包括 crvUSD Controller (0xad44...fb86) 和 LLAMMA AMM (0x0079...a1f7)。受害合約是 sDOLA Llamalend 市場 (0x2b08...4fbe)。

sDOLA 是一種 ERC4626 金庫代幣，其份額價格由資產總額與份額總數的比率決定。由於任何人都可以調用 donate() 向金庫增加資產，份額價格可以在單筆交易內被操縱。這正是 LLAMMA 健康度函數所依賴的可操縱預言機。

如背景所述，get_x_down() 通過模擬兩類錨點的轉換來計算健康度：一類是源自 $P_{oracle}P\_\{oracle\}$ 的錨點（隨即時預言機動態變化），另一類是源自用戶價格帶邊界的錨點（創建頭寸時固定）。協議在讀取 $P_{oracle}P\_\{oracle\}$ 時沒有應用任何延遲或健全性檢查。因此，當預言機價格被抬高時，動態錨點上升，但靜態錨點保持不變。實際上，模擬過程以被操縱後的預言機價格將 crvUSD 轉換為抵押品，並以原始價格帶價格進行轉回，因此當兩個錨點之間的差距擴大時，評估出的可回收價值就會縮水。即使抵押品價格上漲，健康度也會被推至零以下。

攻擊分析

以下分析基於交易 0xb935...d8a4。

• 步驟 1：操縱 LLAMMA 狀態（進行大規模交換）移動 active_band 並將許多用戶推入僅持有 crvUSD 的狀態。

• 步驟 2：通過捐贈操縱 sDOLA 的價格，然後使用零額度交換 (swap(0)) 將被操縱的價格寫入 AMM 池中。

• Step 3：通過 users_to_liquidate() -> _health() -> get_x_down() 觸發健康度重新計算。

• Step 4：由於 get_x_down() 通過兩個分歧的價格錨點（現在已被抬高的動態錨點與未變的靜態錨點）計算可回收價值，回程轉換導致有效價值出現折損，許多頭寸跌破零健康度。

• Step 5：批量對這些用戶進行硬清算以獲利。

此外，追蹤資訊包含了兩次 create_loan() 調用。第一次貸款主要用於資助大規模 crvUSD 交換操作。第二次貸款用於獲取 crvUSD 以償還第一個頭寸的債務並回收資本。這兩筆貸款主要是融資/結算步驟，本身並非核心攻擊步驟。

結論

該事件屬於抵押品價格操縱攻擊。攻擊者在交易內操縱了 sDOLA 價格，並由於 LLAMMA 基於路徑的健康度機制，將用戶推向了清算條件。關鍵結論在於，即使抵押品價格上漲，頭寸仍可能被清算。建議的強化方案：

• 使用延遲價格或 TWAP 抵押品價格進行清算。

參考文獻

• [1] Curve crvUSD LLAMMA 文檔：https://dev.curve.finance/crvUSD/amm/#bands

• [2] Curve LLAMMA 清算說明：https://dev.curve.finance/crvUSD/llamma-explainer/#liquidation

• [3] Curve 穩定幣白皮書：https://docs.curve.finance/pdf/whitepapers/whitepaper_curve_stablecoin.pdf

4. The V4 Router by z0r0z 事件

簡要總結

2026 年 3 月 3 日，以太坊上的 V4 Router by z0r0z 遭到攻擊，導致約 4.2 萬美元的損失。攻擊源於 swap() 中的認證邏輯缺陷，路由合約依賴內聯彙編中的固定 calldata 偏移量來驗證支付者是否與 msg.sender 相符。由於 ABI 編碼對動態類型不保證固定的佈局，攻擊者得以構造非標準但有效的 calldata 來繞過檢查，冒充先前已授權的受害者作為支付者，並將交換輸出重定向至攻擊者控制的地址。

背景

該協議繼承自 Uniswap v4 Router 並重寫了部分方法。本質上，它充當一個交換路由，允許用戶無需直接與對應池互動，而是將路由作為統一入口使用。

漏洞分析

根本原因在於 V4 Router 合約 (0x0000...ce97) 中的業務邏輯錯誤。受害合約為 0x65a8...7675。swap() 函數接受兩個參數：data (bytes) 和 deadline (uint256)。在函數內部，一項授權檢查使用內聯彙編區塊來比較 calldataload(164) 與 caller()，確保 data 中編碼的支付者與 msg.sender 匹配。該協議假定 bytes 偏移量始終為 0x40，將支付者置於字節位置 164 (0xa4)。

然而，ABI 編碼並不保證此佈局：動態參數僅在頭部存儲一個偏移量，該偏移量合法地可以指向 calldata 中的任何對齊位置。通過構造一種有效的非標準編碼，將 bytes 偏移量移動到 0xc0，攻擊者可以在頭部和實際尾部之間插入任意填充。攻擊者將自己的地址置於字節位置 164 以通過彙編檢查，而重定位後的尾部中真實的 bytes 負載則將受害者的地址編碼為支付者。通過選擇先前已授權過路由的受害者，並將接收者設定為自己的地址，攻擊者即可重定向交換輸出並竊取資金。

攻擊分析

以下分析基於交易 0xfe34...466a。

• 步驟 1：選定一個先前已授權過路由的用戶作為目標。

• 步驟 2：構造 calldata 以繞過授權檢查。

• 步驟 3：在 data 中指定受害者為支付者，設定攻擊者自己的地址為代幣接收者，從而竊取受害者的資產。

結論

此事件是由於在交換路徑的授權中使用硬編碼的 calldata 偏移量所致。由於 ABI 對動態類型的編碼不保證固定佈局，攻擊者通過非標準但有效的 calldata 繞過了檢查，冒充已授權受害者作為支付者，並重定向了交換結果。

為降低未來類似風險：

• 切勿依賴動態 ABI 編碼參數的硬編碼 calldata 偏移量。

• 使用標準 ABI 解碼來解碼和驗證結構化輸入，而非手動進行位置假設。

• 確保實際支付者、接收者和代幣流向與預期的調用者及執行上下文始終保持一致。

5. The BitcoinReserveOffering 合約事件

簡要總結

2026 年 3 月 5 日，以太坊上的 BitcoinReserveOffering 合約遭到攻擊，損失約 270 萬美元。根本原因是業務邏輯缺陷：在處理完整的 ERC-3525 SFT 存款時，鑄造邏輯在單次調用中被執行了兩次，一次是在轉帳回呼中，另一次是在主流程中。攻擊者通過多次銷毀與鑄造循環，利用此雙重鑄造行為，指數級擴張了其 BRO 代幣餘額，並隨後將多餘部分兌換為 SolvBTC 以獲利。

背景

BitcoinReserveOffering 是一個將 ERC-3525 SFT 頭寸轉換為可轉讓 ERC-20 BRO 代幣的封裝合約。用戶可以調用 mint() 函數存入合規的 SFT，合約會根據配置的匯率鑄造相應數量的 BRO。如果用戶僅存入 SFT 的一部分價值，合約會將指定數量轉移到其內部持有的頭寸中，並鑄造相應價值的 BRO。如果用戶存入的是完整 SFT，合約會將完整代幣轉入封裝合約，並根據 SFT 的總價值鑄造 BRO。用戶隨後可以調用 burn() 函數將 BRO 贖回為對應的 ERC-3525 SFT 頭寸。

漏洞分析

根本原因是 BitcoinReserveOffering 合約 (0x15f7...cfcf) 在 mint() 函數中處理完整的 ERC-3525 SFT 存款時兩次執行了鑄造邏輯。具體來說，在 amount_ == sftBalance 分支中，mint() 調用 ERC3525TransferHelper.doSafeTransferIn() 將整個 SFT 安全地轉移到合約中，這觸發了 onERC721Received() 回呼。在此回呼內部，合約已經計算出 SFT 的價值並向發送者鑄造了 BRO。在回呼返回後，mint() 繼續執行，再次使用相同的 amount_ 計算價值，並執行了第二次 _mint(msg.sender, value) 操作。這種雙重鑄造行為使得攻擊者能夠通過銷毀-鑄造循環不斷膨脹其 BRO 餘額。

攻擊分析

以下分析基於交易 0x44e6...958d。

• 步驟 1：攻擊者將 135e18 個 BRO 代幣轉入攻擊合約作為種子資本。

• 步驟 2：攻擊者執行以下循環：

1. 將 135e18 個 BRO 代幣封裝為一個 SFT 代幣。

2. 以完整的 SFT 價值調用 mint()，這會觸發 onERC721Received() 回呼並鑄造 135e18 個 BRO；隨後外部的 mint() 繼續執行並再次調用 _mint()，導致總計鑄造了 270e18 個 BRO。

3. 將 270e18 個 BRO 代幣轉回一個 SFT 代幣。

• 步驟 3：重複步驟 2 共 22 次後，攻擊者累積了約 567,758,816e18 個 BRO 代幣，最終贖回為 38e18 個 SolvBTC 以獲利。

結論

此事件是由於完整存入 SFT 時的雙重鑄造導致，使得攻擊者能夠通過重複的銷毀-鑄造循環指數級提升其 BRO 餘額，並將超額部分贖回為 SolvBTC。

為降低未來類似風險：

• 確保每次存款操作僅進行一次資產結算。

• 添加不變量檢查，防止鑄造金額超過底層存入價值。

6. MoltEVM 事件

簡要總結

2026 年 3 月 7 日，Base 鏈上的 MoltEVM 協議遭到攻擊，損失約 12.7 萬美元。根本原因是代幣合約中的訪問控制邏輯錯誤：特權鑄造函數受限於一個僅檢查調用者是否具有特定介面的修飾器，而該檢查可以被輕易偽造。攻擊者部署了一個惡意合約繞過了檢查，鑄造了大量代幣，並將其拋售進流動性池中獲利。

背景

MoltEVM 是部署在 Base 上的一種實驗性 ERC-20 代幣協議，探索了一種自我複製的代幣模型。該系統允許代幣在達到特定儲備閾值時生成新的子代幣（"Moltling" 代幣）。當新的 Moltling 創建時，初始供應量通過 mintFromSpawner() 函數分配，並自動提供流動性以建立交易市場。這種設計使得協議能夠自主擴展其代幣譜系，每一代代幣都有能力產生更多後裔。

漏洞分析

漏洞存在於 MoltEVM 合約 (0x225d...501f) 的 mintFromSpawner() 和 setExemptFromSpawner() 函數的訪問控制邏輯中。這兩個函數都依賴 onlySpawnerToken 修飾器，旨在限制對協議生成的合法 Moltling 合約的調用。

然而，該修飾器僅執行了兩個薄弱的檢查：驗證 msg.sender 是否為合約，以及對調用者執行 initialized() 是否返回 true。由於任何實現相同介面的任意合約都可以輕易滿足這些條件，因此該檢查並不能提供對合法生成代幣的有意義認證。

結果，攻擊者可以部署一個僅單純實現返回 true 的 initialized() 函數的極簡合約。一旦部署，該惡意合約即可自由調用 mintFromSpawner() 鑄造任意數量的代幣，還可以調用 setExemptFromSpawner() 將攻擊者控制的地址加入白名單。這有效地授予了攻擊者對鑄造路徑的完全控制權，並允許新鑄造的代幣被拋售到流動性池中以獲取利潤。

攻擊分析

以下分析基於交易 0x10b7...e03d。

• 步驟 1：攻擊者部署了一個簡單的合約，其中實現了單個硬編碼返回 true 的 initialized() 函數，這足以通過 onlySpawnerToken 修飾器的檢查。

• 步驟 2：攻擊者的合約調用了受相同脆弱的 onlySpawnerToken 修飾器保護的 setExemptFromSpawner() 函數，將攻擊者地址加入稅收豁免白名單。這確保了隨後的大規模拋售不會觸發賣出稅或內部轉換邏輯，從而實現利潤最大化。

• 步驟 3：攻擊者針對 mEVM 重複了 setExemptFromSpawner() + mintFromSpawner() 的函數序列，隨後對包括 CSPAWN、CCUTTL、LWORM 和 NHYDRA 在內的多個 Moltling 子代幣進行了同樣的操作，進行跨目標批量鑄造，並將其拋售至相應的流動性池中提取利潤。

結論

此事件是由於特權鑄造和配置函數的訪問控制不足所致，使得攻擊者能夠冒充合法生成器並鑄造任意代幣獲利。

為降低未來類似風險：

• 對特權鑄造或配置函數實施嚴格的訪問控制。

• 避免依賴容易被偽造的合約檢查進行授權。

• 通過顯式白名單或受信任的合約註冊表來驗證調用者身份。

7. LEDS 事件

簡要總結

2026 年 3 月 8 日，BNB Chain 上的 LEDS 代幣遭到攻擊，導致約 6.4 萬美元的損失。根本原因是業務邏輯缺陷：代幣合約暴露了多個獨立的通貨緊縮機制，每個機制都可以直接從流動性對中銷毀代幣，且均未受到訪問控制或冷卻時間的保護。攻擊者在單筆交易內串聯了所有銷毀路徑，將交易對的 LEDS 儲備消耗至幾乎為零，同時保留了 WBNB 儲備，隨後通過反向交易耗盡不平衡的資金池獲利。

背景

LEDS 是 BNB Chain 上一種具有內置轉帳費機制的通貨緊縮代幣。其 _transfer() 實現了多種銷毀機制，旨在逐步減少供應並支撐代幣價格：一個每日銷毀函數 triggerDailyBurnAndMint()，一個通過 stor_18 累積的延遲拋售銷毀，以及一個在交換接收者設定為 PancakeSwap Router 時銷毀代幣至 0xdead 的特殊分支。該代幣還具備一個 deposit() 函數，用戶可發送 BNB 以鑄造 LEDS 並提供流動性，獲得可通過分發合約領取的 LP 獎勵。

漏洞分析

根本原因是 LEDS 代幣合約 (0xfb62...a48f) 中的業務邏輯錯誤。受害者是 LEDS/WBNB 對 (0xd109...6f3f)。該代幣實現了多種通貨緊縮機制：triggerDailyBurnAndMint()、SELL 路徑 stor_18 累積以及 _transfer() 中的 To == Router 分支。每一種機制都會獨立地從流動性池中移除 LEDS 並調用 sync() 更新儲備。

雖然這些機制單獨作用時可作為漸進式通貨緊縮工具，但它們可以在單筆交易內串聯起來，進而複合其效果。此外，公共函數 0x17a06174() 允許任何人在無訪問權限控制或速率限制的情況下隨意沖刷全部累積的 stor_18 餘額。通過順序堆疊這些銷毀路徑，攻擊者可以將資金池的 LEDS 儲備降低至幾乎為零，而同時保留 WBNB 儲備不變，這種極端的價格偏差可通過反向交換進行獲利。

攻擊分析

以下分析基於交易 0x2608...79da。

• 步驟 1：攻擊者通過閃電貸（Moolah + Venus 抵押借貸 + Aave + PancakeSwap V4）獲得了大量 WBNB。

• 步驟 2：執行多次 deposit() 調用以累積 LP 獎勵，隨後觸發 triggerDailyBurnAndMint()，銷毀部分 LEDS 並向分發器發送獎勵，減少了池中的 LEDS 儲備。

• Step 3：調用函數 0xde1b1942() 領取累積的 LEDS 代幣獎勵。

• Step 4：賣出領取的 LEDS 以換取 WBNB。由於賣出後資金池的 LEDS 餘額超過了閾值，轉帳金額被累積進入 stor_18（等待銷毀）。

• Step 5：通過 PancakeSwap 買入 LEDS，並將接收者設為 Router 地址。這觸發了 _transfer() 中的特殊分支，將買入的 LEDS 直接從資金池銷毀至 0xdead，進一步減少了池中的 LEDS 儲備。

• Step 6：調用函數 0x17a06174()，將整個 stor_18 餘額（步驟 4 中累積的）從資金池銷毀至 0xdead 並調用 sync()，使池中的 LEDS 儲備崩潰至僅 2 wei。

• Step 7：執行反向交換，從嚴重失衡的資金池中耗盡 WBNB，歸還所有閃電貸，獲利 104.56 個 WBNB (6.4 萬美元)。

結論

此事件是由多個未受防護的通貨緊縮機制串聯所致，這些機制可在單筆交易中被連鎖觸發，從而災難性地耗盡流動性池的儲備。

對於實現通貨緊縮或自動銷毀機制的任何代幣合約，開發者應：

• 切勿在沒有適當訪問控制、速率限制或冷卻時間強制執行的情況下暴露從資金池銷毀的功能。

• 避免允許在單筆交易內按順序觸發多個獨立的銷毀機制。

關於 BlockSec

BlockSec 是全方位的區塊鏈安全與加密貨幣合規提供商。我們建立產品與服務，幫助客戶在協議與平台的生命週期內執行程式碼審計（包含智慧合約、區塊鏈與錢包）、即時攔截攻擊、分析事件、追蹤非法資金並滿足 AML/CFT 義務。

BlockSec 已在各大著名會議上發表多篇區塊鏈安全論文，報導過多起 DeFi 應用零日攻擊事件，攔截過多次黑客攻擊成功挽救超過 2,000 萬美元資產，並保障了數十億美元的加密資產。

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

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

• 🔗 BlockSec 審計服務 : 提交請求

• 🔗 Phalcon 安全應用程式: 預約演示

• 🔗 Phalcon 合規服務