Khi audit phát hiện 4 lỗi trong 1 ngày: Câu chuyện về dự án “Mets Finance” và bài học về khuôn khổ phân tích sai

Hook

Cái bug hôm qua, bài học hôm nay. #DeFi

Ngày 4/3/2026, tôi nhận được một hợp đồng audit khẩn cấp. Dự án tên Mets Finance – một nền tảng yield farming hứa hẹn APY 2.000% trên mạng Arbitrum. Whitepaper của họ dài 60 trang, đầy ắp từ khóa “AI-driven liquidity”, “cross-chain composability”, “decentralized insurance”. Nhưng tôi không bao giờ đọc whitepaper trước khi đọc code. Và code, như thường lệ, nói lên tất cả.

Context

Mets Finance tự xưng là “giao thức thế hệ thứ tư” kết hợp giữa yield farming truyền thống và một cơ chế “dynamic rebase” dựa trên thuật toán học máy. Họ đã huy động được 100 triệu USD từ các quỹ đầu tư mạo hiểm trong vòng Series A. TVL trên hợp đồng thông minh đạt 12.000 ETH chỉ sau 3 ngày ra mắt. Tuy nhiên, điều khiến tôi cảnh giác là cấu trúc phí của họ: một phần phí được chuyển vào một “reserve pool” không được giải thích rõ trong code. Trong thế giới DeFi, bất kỳ cơ chế không minh bạch nào cũng là mồi cho lỗ hổng.

Core

Tôi bắt đầu đọc line-by-line mã Solidity. Đến dòng thứ 247, tôi thấy một lỗi reentrancy cổ điển trong hàm withdraw(). Hàm này gọi call trước khi cập nhật số dư, cho phép kẻ tấn công gọi lại withdraw nhiều lần trong cùng một giao dịch. Lỗi này tương tự như lỗi đã làm sập TheDAO Maker năm 2017, nhưng được giấu kỹ hơn dưới lớp modifier onlyOwner giả mạo. Tôi tiếp tục đọc. Thêm ba lỗi nữa xuất hiện:

1. Lỗi số học trong phép tính phí: Công thức fee = amount * feeRate / 10000 sử dụng phép chia trước, dẫn đến mất chính xác khi amount nhỏ. Kẻ tấn công có thể gửi các giao dịch nhỏ liên tục để làm cạn kiệt phí của người dùng khác.
2. Lỗi kiểm soát truy cập trong contract oracle: Oracle lấy giá từ một pool thanh khoản duy nhất mà không có cơ chế chống thao túng. Một kẻ tấn công có thể thao túng giá thông qua flash loan và kích hoạt thanh lý hàng loạt.
3. Lỗi logic trong hàm rebase: Hàm này được thiết kế để tự động điều chỉnh tổng cung dựa trên “điểm tin cậy” từ AI, nhưng điểm tin cậy được lấy từ một mô hình off-chain không được verify. Trong thực tế, nhóm phát triển có thể set điểm này tùy ý để mint thêm token cho mình.

Tôi gửi báo cáo khẩn cấp vào lúc 2 giờ sáng. Nhóm dự án phản hồi trong vòng 6 giờ, vá lỗi reentrancy nhưng từ chối sửa hai lỗi còn lại vì cho rằng “rủi ro thấp”. Ba ngày sau, một hacker sử dụng flash loan khai thác lỗi oracle, rút 2.000 ETH khỏi pool thanh khoản. TVL giảm 80%. Dự án sụp đổ trong 24 giờ.

Contrarian

Góc nhìn phản trực giác: Mọi người thường nghĩ rằng audit là để phát hiện lỗi. Nhưng sự thật là audit chỉ có hiệu quả khi nhóm dự án sẵn sàng sửa lỗi. Trong trường hợp Mets Finance, họ đã cố tình bỏ qua các lỗi nghiêm trọng vì muốn giữ “tính năng” cho phép họ kiểm soát oracle. Điểm mù của toàn bộ ngành là chúng ta tin rằng audit = an toàn, nhưng thực tế audit chỉ là một công cụ kiểm tra, không phải giấy chứng nhận bảo hiểm. Nếu dự án có ý đồ xấu, audit chỉ giúp họ che giấu lỗi một cách tinh vi hơn.

Takeaway

Sự việc này nhắc nhở tôi về một bài học cũ: Đừng bao giờ tin vào whitepaper, đừng bao giờ tin vào audit report, hãy tin vào code và khả năng tự bảo vệ của chính mình. Mets Finance không phải là trường hợp duy nhất. Năm 2026, khi thị trường tăng, hàng trăm dự án tương tự sẽ xuất hiện. Câu hỏi đặt ra: Liệu cộng đồng có học được bài học từ những lỗi lặp đi lặp lại, hay lại tiếp tục bị mắc bẫy bởi những lời hứa APY không tưởng? Dữ liệu cho thấy, sau mỗi vụ sập, TVL chỉ mất vài tháng để quay lại mức cũ. Bộ nhớ của thị trường rất ngắn. Còn tôi, tôi vẫn sẽ đọc code từng dòng, từng dòng một.