Một công cụ AI mã nguồn mở không ai chú ý, đã cảnh báo về lỗ hổng 292 triệu USD của Kelp DAO cách 12 ngày trước

Tác giả: Zengineer

Biên dịch: Deep潮 TechFlow

Deep潮 giới thiệu: Ngày 18 tháng 4, Kelp DAO bị đánh cắp 292 triệu USD, là vụ DeFi lớn nhất từ đầu năm 2026 đến nay. Lỗ hổng không nằm trong mã hợp đồng thông minh, mà ở cấu hình nút xác thực LayerZero cross-chain bridge dạng 1-of-1 — một điểm yếu duy nhất có thể giả mạo tin nhắn xuyên chuỗi. 12 ngày trước, tác giả đã dùng công cụ kiểm tra an ninh mã nguồn mở do chính mình phát triển để quét Kelp, đã từng đánh dấu điểm rủi ro này. Bài viết này tổng kết toàn bộ quá trình tấn công, cũng thành thật tự phê bình về 3 điều công cụ đã làm chưa đúng lúc đó.

Kelp DAO là gì

Kelp DAO là một giao thức staking lại thanh khoản xây trên EigenLayer. Cơ chế như sau: người dùng gửi ETH hoặc token staking (stETH, ETHx) vào hợp đồng Kelp, hợp đồng sau đó ủy thác tài sản cho các nút vận hành của EigenLayer để thực hiện staking lại — đồng thời cung cấp an toàn cho nhiều dịch vụ AVS (Actively Validated Services, dịch vụ xác thực chủ động). Đổi lại, người dùng nhận được rsETH làm chứng chỉ. Khác với việc staking trực tiếp trên EigenLayer (tài sản bị khóa), rsETH là token có tính thanh khoản — có thể giao dịch, dùng làm tài sản thế chấp trong các giao thức vay như Aave, hoặc xuyên chuỗi.

Để thực hiện tính thanh khoản xuyên chuỗi này, Kelp dùng tiêu chuẩn OFT (Omnichain Fungible Token, token đồng nhất toàn chuỗi) của LayerZero để triển khai rsETH trên hơn 16 chuỗi. Khi bạn chuyển rsETH từ Ethereum sang một chuỗi Layer 2, mạng xác thực phi tập trung DVN (Decentralized Verifier Network) của LayerZero sẽ kiểm tra tính hợp lệ của tin nhắn xuyên chuỗi này. Kiến trúc cầu nối này chính là trung tâm của câu chuyện phía sau.

Kelp do Amitej Gajjala và Dheeraj Borra (trước đây là đồng sáng lập Stader Labs) khởi xướng, ra mắt tháng 12 năm 2023, TVL đạt đỉnh 2.09 tỷ USD, quản trị bằng token KERNEL theo hình thức multi-sig 6/8 và khóa thời gian 10 ngày để nâng cấp hợp đồng. Token quản trị này điều hành 3 dòng sản phẩm: Kelp, Kernel, Gain.

Vụ bị đánh cắp

Ngày 18 tháng 4 năm 2026, hacker rút ra 116,500 rsETH từ cầu nối xuyên chuỗi của Kelp DAO, trị giá khoảng 292 triệu USD — là vụ tấn công DeFi lớn nhất từ đầu năm 2026 đến nay. Nguyên nhân chính không phải do lỗ hổng hợp đồng thông minh, mà là vấn đề cấu hình: một thiết lập DVN dạng 1-of-1 (chỉ có 1 nút xác thực, chỉ cần 1 chữ ký là đủ) khiến hacker có thể giả mạo tin nhắn xuyên chuỗi bằng cách tấn công phá vỡ nút duy nhất này.

12 ngày trước, ngày 6 tháng 4, công cụ kiểm tra an ninh mã nguồn mở của tác giả đã từng đánh dấu điểm rủi ro này.

Nói rõ: vụ bị đánh cắp này là do người thật mất tiền thật. Người gửi WETH trong Aave hoặc các giao thức khác, không liên quan đến rsETH, đã bị phong tỏa tài khoản; nhiều LP trong các giao thức phải gánh chịu khoản nợ xấu mà họ không ký hợp đồng. Bài viết phân tích chuyện đã xảy ra, công cụ của chúng tôi đã phát hiện ra gì — nhưng cái giá thực tế người thiệt hại phải trả còn quan trọng hơn mọi bảng điểm rủi ro.

Báo cáo đầy đủ đăng trên GitHub, thời gian commit có thể xác minh công khai. Dưới đây là kể lại những gì chúng tôi đã phát hiện, những gì bỏ lỡ, và ý nghĩa của vụ việc đối với công cụ an ninh DeFi.

46 phút, chấn động DeFi

Vào 17:35 UTC ngày 18 tháng 4, hacker tấn công phá vỡ nút xác thực DVN độc lập đó, rồi “phê duyệt” một tin nhắn giả mạo xuyên chuỗi. Endpoint của LayerZero thấy DVN đã xác nhận, gửi tin qua lzReceive đến hợp đồng OFT của Kelp — hợp đồng làm theo, đã mint ra 116,500 rsETH trên mạng chính Ethereum. Tin nhắn tuyên bố các chuỗi khác đã khóa tài sản trị giá tương đương làm bảo đảm. Thực tế, các tài sản đó hoàn toàn không tồn tại.

Tiếp theo là một quy trình rửa tiền tiêu chuẩn của DeFi:

Dùng rsETH làm tài sản thế chấp gửi vào Aave V3, Compound V3, Euler

Dùng các tài sản không có bảo đảm này vay khoảng 236 triệu USD WETH

Tập trung khoảng 74,000 ETH, rút ra qua Tornado Cash

Sau 46 phút, lúc 18:21, hợp đồng của Kelp đã bị tạm dừng khẩn cấp và khóa multi-sig. Hacker sau đó hai lần truy đuổi (mỗi lần 40,000 rsETH, khoảng 100 triệu USD), đều bị revert — lần này, lệnh tạm dừng đã ngăn chặn được khoảng 200 triệu USD.

Tuy nhiên, phạm vi ảnh hưởng vẫn rất lớn. Aave V3 đã phải gánh khoản nợ xấu khoảng 177 triệu USD. Giá token AAVE giảm 10.27%. ETH giảm 3%. Tỷ lệ sử dụng WETH trên Aave lập tức đạt 100%, người gửi tiền vội vàng rút lui. Hơn 20 chuỗi L2 có rsETH, trong một đêm, đều trở thành tài sản có giá trị nghi vấn.

Ngày 6 tháng 4, báo cáo đã phát hiện gì

Đầu tháng 4, ngay sau khi Drift Protocol bị đánh cắp 285 triệu USD ngày 1 tháng 4, tôi đã viết một bộ khung đánh giá rủi ro kiến trúc AI mở, tên là crypto-project-security-skill — dựa trên dữ liệu công khai (DeFiLlama, GoPlus, Safe API, xác thực trên chuỗi) để đánh giá các giao thức DeFi. Nó không phải là công cụ quét mã hay xác thực hình thức. Sự kiện Drift giúp tôi nhận ra: nguyên nhân gây thiệt hại lớn nhất không nằm trong mã hợp đồng, mà ở các lỗ hổng quản trị, sơ suất cấu hình, điểm mù kiến trúc — những chỗ mà các công cụ quét mã không thể nhìn thấy. Vì vậy, tôi đã phát triển một công cụ đánh giá riêng các tầng này: cấu trúc quản trị, phụ thuộc oracle, cơ chế kinh tế, kiến trúc xuyên chuỗi, so sánh với các mô hình tấn công nổi tiếng như Drift, Euler, Ronin, Harmony, Mango.

Ngày 6 tháng 4, tôi đã thực hiện một cuộc kiểm tra toàn diện Kelp DAO. Báo cáo đầy đủ công khai trên GitHub, có dấu thời gian không thể chỉnh sửa.

Điểm tổng thể của báo cáo dành cho Kelp là 72/100 (nguy cơ trung bình). Sau này xem lại, điểm này còn quá cao — các lỗ hổng thông tin xuyên chuỗi chưa rõ ràng, đáng ra phải làm điểm số thấp hơn. Nhưng dù xếp mức trung bình, báo cáo vẫn chỉ rõ ra điểm tấn công thực tế đã bị khai thác sau này.

Dưới đây là phần trích đoạn trong báo cáo về “lỗ hổng thông tin” — liên quan đến cấu hình DVN của Kelp, chính là nguyên nhân dẫn đến vụ mất 292 triệu USD:

Chú thích hình: Trong phần “Lỗ hổng thông tin” của báo cáo ngày 6 tháng 4, cấu hình DVN không minh bạch bị chỉ rõ trực tiếp

Tiếp theo, đối chiếu từng điểm chúng tôi đã đánh dấu, và cách bị tấn công thực tế.

Phát hiện 1: Cấu hình DVN không minh bạch (cảnh báo sớm)

Báo cáo: 「Cấu hình LayerZero DVN (bộ xác thực của các chuỗi, yêu cầu ngưỡng) chưa được công khai」

Thực tế xảy ra: Kelp dùng cấu hình DVN dạng 1-of-1. Một nút duy nhất. Một điểm yếu duy nhất. Hacker chỉ cần tấn công phá vỡ nút này là có thể giả mạo tin xuyên chuỗi. Nếu cấu hình là 2-of-3 (được khuyến nghị tối thiểu trong ngành), hacker phải tấn công phá vỡ nhiều xác thực viên độc lập cùng lúc.

Điều cần làm rõ: Đây là vấn đề của Kelp, không phải của LayerZero. LayerZero là hạ tầng — cung cấp khung DVN, còn mỗi giao thức tự chọn cấu hình: số nút xác thực (1-of-1, 2-of-3, 3-of-5…), dùng nút của ai, ngưỡng của từng chuỗi. Khi Kelp triển khai cầu OFT, chọn cấu hình 1-of-1. LayerZero hoàn toàn hỗ trợ 2-of-3 hoặc cao hơn — chỉ là Kelp không bật.

Ví dụ: AWS cung cấp MFA (xác thực đa yếu tố). Nếu tài khoản của bạn bị xâm nhập vì chưa bật MFA, đó là lỗi của bạn, không phải của AWS. LayerZero đặt cơ chế an toàn đó ra đó, Kelp không dùng.

Báo cáo của chúng tôi lúc đó không thể xác định chính xác ngưỡng DVN (vì Kelp chưa từng tiết lộ), nhưng rõ ràng liệt kê cấu hình không minh bạch này thành lỗ hổng chưa giải quyết và rủi ro. Không tiết lộ rõ ràng chính là một dấu hiệu đỏ.

Phát hiện 2: Điểm yếu đơn điểm trên 16 chuỗi (trực tiếp)

Báo cáo: 「Điểm yếu đơn điểm của LayerZero DVN có thể ảnh hưởng đến 16 chuỗi hỗ trợ rsETH」

Thực tế: Tin giả mạo đã thành công trên mạng chính Ethereum, lan sang tất cả các chuỗi khác đã triển khai rsETH. LayerZero đã chủ động tạm dừng tất cả cầu OFT từ Ethereum ra ngoài. Người nắm giữ rsETH trên hơn 20 chuỗi L2, trong một đêm, không rõ còn bảo đảm hay không.

Đây là rủi ro hệ thống của đa chuỗi: rsETH cùng lúc trên Arbitrum, Optimism, Base, Scroll… nhưng tất cả giá trị đều dựa vào tài sản trên mạng chính Ethereum. Khi cầu nối chính bị tấn công, tất cả các chuỗi L2 chứa rsETH đều mất bảo đảm — người nắm giữ không thể rút, cũng không thể xác minh giá trị token của mình còn hay không. Các dịch vụ như earnETH của Lido (dưới dạng rsETH), cầu của Ethena qua LayerZero — đều bị tạm dừng. V phạm vi ảnh hưởng vượt xa Kelp.

Phát hiện 3: Kiểm soát quản trị xuyên chuỗi chưa xác thực (vấn đề liên quan)

Báo cáo: 「Chưa xác minh quyền kiểm soát quản trị cấu hình LayerZero OFT của các chuỗi — đặc biệt: quyền này có thuộc về multi-sig 6/8 và khóa thời gian 10 ngày, hay do các khóa quản trị riêng biệt kiểm soát」

Thực tế: Cấu hình DVN rõ ràng không nằm dưới quản trị chặt chẽ của core protocol. Nếu việc thay đổi cấu hình cầu nối cũng do multi-sig 6/8 và khóa thời gian 10 ngày kiểm soát, thì cấu hình 1-of-1 cần 6 trong 8 người đồng ý — cấu hình này khó mà không có ai quản lý.

Điều này hé lộ một điểm mù quản trị phổ biến: nhiều giao thức đặt quy trình nâng cấp hợp đồng chính có multi-sig và khóa thời gian, nhưng các thay đổi vận hành — như cấu hình cầu nối, tham số oracle, quản lý whitelist — thường chỉ có một admin key kiểm soát. Kelp quản trị theo chuẩn hàng đầu (6/8 multi-sig + 10 ngày khóa), nhưng các biện pháp bảo vệ này không mở rộng tới điểm tấn công lớn nhất: cầu xuyên chuỗi.

Phát hiện 4: Mô phỏng mô hình tấn công Ronin/Harmony (trực tiếp)

Báo cáo: 「Các ví dụ lịch sử liên quan đến an toàn cầu. Việc triển khai LayerZero của Kelp trên 16 chuỗi mang tính phức tạp vận hành tương tự Ronin」

Thực tế: Đường tấn công gần như sao chép hoàn toàn kịch bản Ronin — phá vỡ xác thực cầu nối, giả mạo tin nhắn, rút sạch tài sản. Công cụ của chúng tôi dùng mô-đun nhận dạng mô hình tấn công, so sánh kiến trúc giao thức với các mô hình tấn công lịch sử, xác định đây là một trong các hướng tấn công nguy hiểm nhất.

Lịch sử: Năm 2022, Ronin bị tấn công 5 trong 9 xác thực viên, mất 625 triệu USD; cùng năm, Horizon của Harmony bị tấn công 2 trong 5 xác thực viên, mất 100 triệu USD. Trường hợp của Kelp còn nghiêm trọng hơn — chỉ có 1 xác thực viên, mức độ bảo vệ cực thấp. Công cụ có thể phát hiện rủi ro này vì nó tự động so sánh kiến trúc giao thức với các mô hình tấn công lịch sử, chứ không chỉ dựa vào mã.

Phát hiện 5: Không có quỹ bảo hiểm (làm tăng thiệt hại)

Báo cáo: 「Giao thức hiện không có quỹ bảo hiểm riêng, cũng không có cơ chế chia sẻ thiệt hại để hấp thụ các khoản phạt」

Thực tế: Không có quỹ dự phòng, thiệt hại 292 triệu USD bị các giao thức phía dưới gánh hết. Khoản dự trữ thu hồi của Aave chỉ đủ để gỡ 30% khoản nợ xấu 177 triệu USD. Các LP trong các giao thức khác, không ký hợp đồng với rsETH, phải chịu thiệt hại lớn nhất.

Hacker dùng rsETH làm tài sản thế chấp gửi vào Aave V3, Compound V3, Euler, rồi vay WETH thật. Khi rsETH bị xác nhận không có bảo đảm, các vị thế này trở thành nợ xấu không thể thanh lý — tài sản thế chấp thành giấy lộn, nhưng WETH đã mất. Tỷ lệ WETH trên Aave lập tức đạt 100%, người gửi tiền muốn rút cũng không được. Nếu bạn là người gửi WETH trên Aave, dù chưa từng dùng rsETH, cũng bị ảnh hưởng. Các hợp đồng bảo hiểm của Kelp và Nexus Mutual chỉ bảo vệ một số sản phẩm nhất định, không bao gồm rủi ro chính của giao thức rsETH.

Điều này thể hiện trách nhiệm chưa rõ ràng của cả hai phía. Phía Kelp: một giao thức quản lý 1.3 tỷ USD TVL, không có quỹ bảo hiểm, không có cơ chế hấp thụ thiệt hại. Khi cầu bị tấn công, không có gì để giảm thiểu thiệt hại. Phía Aave: chấp nhận rsETH làm tài sản thế chấp, nhưng không đánh giá đúng rủi ro cấu hình cầu nối xuyên chuỗi. Các tham số rủi ro của Aave (LTV, ngưỡng thanh lý) thiết kế cho biến động giá bình thường, không tính đến rủi ro “cầu bị tấn công khiến tài sản thế chấp mất giá trong một đêm”. Khoản dự trữ thu hồi không đủ để gỡ 30% nợ xấu. Về bản chất, đây là thất bại trong định giá rủi ro: Aave coi rsETH như một tài sản biến động bình thường, trong khi thực tế nó mang theo rủi ro tail của cầu nối bị tấn công. Sự phối hợp của hai bên đã làm trầm trọng thêm thiệt hại — Kelp không có quỹ bảo hiểm để ngăn chặn tài sản thế chấp xấu, Aave chưa có mô hình rủi ro đủ tinh vi để hạn chế rủi ro này trong kịch bản xấu.

Chúng tôi đã sai ở đâu

Có 3 điều đáng làm tốt hơn:

Đánh giá rủi ro còn quá cao. Chúng tôi xếp rủi ro cầu nối xuyên chuỗi là “trung bình”. Trong báo cáo, 5 lỗ hổng thông tin chưa rõ ràng có 3 liên quan đến cấu hình LayerZero, phù hợp với các mô hình tấn công Ronin/Harmony — đáng ra phải xếp là “cao” hoặc “nghiêm trọng”. Không minh bạch chính là tín hiệu cảnh báo lớn hơn.

Chúng tôi chưa thể xuyên thấu cấu hình. Báo cáo liên tục yêu cầu Kelp tiết lộ ngưỡng DVN, nhưng chúng tôi không thể xác minh độc lập. Đây chính là điểm mù cấu trúc mà các công cụ kiểm tra mã không thể nhìn thấy: tập trung vào logic mã, không thể phát hiện rủi ro cấu hình. Chúng tôi đã đánh dấu vấn đề, nhưng chưa thể trả lời rõ.

Chúng tôi chưa kiểm tra trên chuỗi. Cấu hình DVN thực ra có thể đọc trực tiếp qua hợp đồng EndpointV2 của LayerZero. Chúng tôi hoàn toàn có thể truy vấn registry ULN302 để xác minh ngưỡng DVN của Kelp, thay vì coi là “chưa công khai”. Nếu kiểm tra lúc đó, sẽ thấy rõ cấu hình 1-of-1, không cần Kelp tiết lộ. Đây là hướng cải thiện cụ thể nhất của công cụ: trong bước đánh giá xuyên chuỗi, thêm xác minh cấu hình DVN trên chuỗi.

Phát hiện chưa đủ cụ thể, chưa đủ hành động. Việc nói “cấu hình DVN chưa tiết lộ” chỉ là quan sát thiếu dữ liệu — không dự đoán được tấn công. Các rủi ro như tập trung oracle, phụ thuộc cầu nối, thiếu bảo hiểm đều phổ biến trong nhiều giao thức cross-chain. Công cụ đã đánh dấu điểm không minh bạch của Kelp, nhưng cũng từng phát hiện các mô hình tương tự ở hàng chục giao thức chưa bị tấn công. Trong bối cảnh chưa có tỷ lệ báo động giả, tuyên bố “chúng tôi đã dự đoán” là phóng đại. Thật ra, chúng tôi đã đặt ra những câu hỏi đúng mà ít ai để ý, và một trong số đó đúng vào điểm then chốt.

Về “minh bạch có trách nhiệm”

Câu hỏi công bằng: nếu ngày 6 tháng 4 chúng tôi đã đánh dấu các rủi ro này, tại sao chưa kịp thông báo Kelp trước khi bị tấn công ngày 18 tháng 4?

Chúng tôi không thông báo. Lý do: báo cáo chỉ phát hiện ra sự thiếu minh bạch — “cấu hình DVN chưa công khai”, chứ không phải là lỗ hổng cụ thể có thể khai thác. Chúng tôi không biết cấu hình là 1-of-1, chỉ biết là không rõ. Không có dữ liệu cụ thể để tiết lộ. “Cầu của bạn không có tài liệu” là một quan sát quản trị, chứ không phải báo cáo bug bounty phù hợp.

Xem lại, chúng tôi hoàn toàn có thể liên hệ trực tiếp với đội ngũ Kelp, hỏi về ngưỡng DVN của họ. Cuộc trao đổi đó có thể giúp tiết lộ cấu hình 1-of-1, thúc đẩy sửa chữa. Chúng tôi đã không làm vậy. Đây là bài học: dù phát hiện có vẻ mơ hồ, không phù hợp để công khai, thì hỏi riêng vẫn đáng giá.

Về ý nghĩa của vụ việc đối với DeFi

Kelp bị đánh cắp — giống Drift cách đây 17 ngày — không phải do lỗ hổng mã hợp đồng. Các công cụ tự động như Slither, Mythril, hay GoPlus cũng không thể phát hiện. Lỗ hổng nằm trong cấu hình triển khai, thiếu sót quản trị, quyết định kiến trúc — nằm trên mã nguồn.

Điều này chính là chủ đề chính của crypto-project-security-skill:

An toàn giao thức không chỉ là mã nguồn. Một giao thức có thể có Solidity hoàn hảo, được kiểm tra 5 lần bởi các công ty hàng đầu, thưởng bug 250.000 USD — nhưng vẫn bị mất 292 triệu USD vì cấu hình xác thực cầu nối.

Công cụ này đã mở mã nguồn trên GitHub — ai cũng có thể xem xét phương pháp, chạy thử hoặc cải tiến.

Thời gian

12 ngày. Các tín hiệu đã có từ lâu. Vấn đề là: làm thế nào để hệ sinh thái xây dựng được công cụ có thể phát hiện các tín hiệu này trước khi cầu nối khác sụp đổ.

Bạn có thể làm gì

Nếu bạn đang nắm giữ tài sản trong các giao thức DeFi có cầu nối xuyên chuỗi:

Tự chạy một lần kiểm tra. Công cụ là mã nguồn mở. Không cần tin chúng tôi — tự xác minh.

Kiểm tra cấu hình xác thực cầu nối. Nếu một giao thức không muốn tiết lộ ngưỡng DVN, coi đó là dấu hiệu đỏ. Báo cáo của chúng tôi làm như vậy, và chứng minh đúng.

Đừng nghĩ rằng kiểm tra mã nguồn là đủ. Kelp đã có hơn 5 lần kiểm tra mã bởi các công ty uy tín (Code4rena, SigmaPrime, MixBytes). Kiểm tra mã truyền thống không nhằm mục đích phát hiện rủi ro cấu hình như ngưỡng DVN — đó là phân tích khác, không phải trách nhiệm của các công ty kiểm toán.

Đánh giá bảo hiểm. Nếu một giao thức không có quỹ bảo hiểm, và bạn là LP trong nền tảng cho vay chấp nhận token của nó làm tài sản thế chấp, thì bạn đang gián tiếp bảo hiểm cho nó. Lần này, người gửi WETH trên Aave đã học bài đắt giá nhất.

Bức tranh lớn hơn: AI Agent như một lớp an toàn

Bài viết này nói về một công cụ và một vụ bị đánh cắp. Nhưng ý tưởng lớn hơn là: AI Agent có thể trở thành lớp an toàn độc lập cho nhà đầu tư DeFi.

Mô hình an toàn truyền thống trong crypto: giao thức thuê các công ty kiểm toán, các công ty kiểm toán kiểm tra mã, rồi phát báo cáo. Mô hình này có điểm mù — vụ Kelp chính là ví dụ, nó tập trung vào mã đúng đắn, bỏ qua các rủi ro về cấu hình, quản trị, kiến trúc.

Claude Code và các công cụ kỹ năng như vậy mang đến một hướng đi khác: bất kỳ ai cũng có thể dùng dữ liệu công khai, trong vài phút, chạy một đánh giá rủi ro AI hỗ trợ cho bất kỳ giao thức nào. Bạn không cần bỏ ra 200.000 USD thuê kiểm toán. Bạn không cần biết đọc Solidity. Bạn để agent so sánh kiến trúc giao thức với các mô hình tấn công đã biết, nó sẽ giúp bạn đặt ra các câu hỏi cần thiết trước khi gửi tiền.

Điều này không thay thế kiểm toán chuyên nghiệp — nhưng giảm ngưỡng cho việc thực hiện thẩm định sơ bộ, để mọi người đều có thể dùng. Một LP đang cân nhắc đầu tư vào một giao thức staking lại mới, giờ có thể chạy một audit defi, nhận một báo cáo đánh giá cấu trúc về quản trị, oracle, cầu nối, cơ chế kinh tế. Đây là bước chuyển thực sự trong việc tự bảo vệ của các nhà đầu tư nhỏ lẻ và trung bình.

Báo cáo của Kelp còn chưa hoàn hảo. Nó xếp rủi ro cầu nối là trung bình, đáng ra phải là nghiêm trọng. Nó chưa xuyên thấu cấu hình. Nhưng nó đã đặt ra đúng câu hỏi — nếu đội ngũ Kelp hoặc bất kỳ LP nào nghiêm túc xem xét các vấn đề này, thiệt hại 292 triệu USD hoàn toàn có thể tránh khỏi.

Tham khảo

CoinDesk: 2026 年最大加密攻击——Kelp DAO 被盗 2.92 亿美元

Crypto Briefing: Kelp DAO 遭 2.92 亿美元桥接攻击

DL News: 黑客攻击 DeFi 协议 Kelp DAO，损失约 3 亿美元

Bitcoin.com： ZachXBT 披露 KelpDAO 2.8 亿美元以上攻击事件

鉅亨網：2.93 亿美元的漏洞不在程式码里

Aave 在 X 上的官方声明

Kelp DAO 完整安全报告（2026 年 4 月 6 日）

crypto-project-security-skill 源代码