Tuần trước, một dự án DeFi mới nổi tên OmegaSwap huy động được 50 triệu USD từ các quỹ đầu tư hàng đầu. TVL của nó chạm mốc 200 triệu USD chỉ sau 48 giờ ra mắt. Cộng đồng tung hô, influencer gọi đây là 'Uniswap killer' tiếp theo. Tôi mở hợp đồng thông minh của nó ra, và trong vòng 30 phút, tôi tìm thấy thứ khiến tôi lạnh sống lưng: một lỗ hổng trong cơ chế tính phí giao dịch có thể khiến người dùng mất toàn bộ tiền gửi. Đây không phải lần đầu, và sẽ không phải lần cuối. Thị trường tăng đang che giấu code yếu dưới lớp sơn dollar.
Để hiểu tại sao tôi nói vậy, hãy quay lại bối cảnh. OmegaSwap là một AMM (Automated Market Maker) trên Arbitrum, fork từ Uniswap V3 với một vài sửa đổi. Điểm hấp dẫn là nó cho phép người dùng stake LP token để nhận thưởng từ token OMEGA, một token quản trị không có giá trị thực. Nhóm phát triển công bố audit từ một công ty ít tên tuổi, không công khai báo cáo đầy đủ. Đây là dấu hiệu đỏ đầu tiên. Thứ hai, tokenomics của họ: 40% cho team và investor, 30% cho liquidity mining, 20% cho treasury, 10% cho community – một cấu trúc điển hình của dự án pump-and-dump. Không có thời gian lock-up rõ ràng, và token bắt đầu được claim sau 7 ngày.
Nhưng điều thực sự khiến tôi tập trung là dòng mã. Tôi đọc contract OmegaSwapPair.sol. Trong hàm swap, có một biến feeAmount được tính dựa trên reserve0 và reserve1 tại thời điểm gọi. Vấn đề nằm ở chỗ: nếu một người dùng tạo một pool mới với độ trượt giá cực thấp (slippage), họ có thể khai thác lỗ hổng rounding trong phép chia số nguyên Solidity. Cụ thể, khi reserve0 và reserve1 rất nhỏ (ví dụ 1 wei), phí thu được có thể bị làm tròn về 0 trong một số trường hợp, dẫn đến swap free. Nhưng đó chỉ là chuyện nhỏ. Lỗ hổng chính nằm ở chỗ: hợp đồng không kiểm tra kLast khi gọi _mintFee – một cơ chế thu phí tái đầu tư từ Uniswap V2. Nếu kLast được set bằng 0 trước đó, hàm _mintFee sẽ không bao giờ được gọi, khiến phí không bao giờ được chuyển vào kho dự trữ. Điều này cho phép kẻ tấn công thao túng tỷ lệ dự trữ và rút toàn bộ thanh khoản từ pool.
Chi tiết hơn: trong mã của OmegaSwap, hàm sync() cho phép bất kỳ ai cập nhật dự trữ theo số dư hiện tại. Nếu kẻ tấn công gửi token trực tiếp vào contract và gọi sync(), nó sẽ thay đổi reserve0 và reserve1 mà không cần qua swap. Sau đó, kẻ tấn công có thể gọi swap() với amount0Out lớn hơn dự trữ thực tế, vì _update chỉ cập nhật dự trữ sau khi swap dựa trên số dư mới. Kết quả: kẻ tấn công rút được nhiều hơn số token đáng lẽ có. Lỗi này tương tự lỗi đã từng xảy ra với YAM Finance năm 2020 – dự án mà tôi từng cảnh báo trước khi nó sụp đổ.
Phân tích dòng mã cụ thể: Tôi đổ bytecode vào Remix và chạy thử nghiệm. Với một pool có 10 ETH và 10,000 USDC, tôi mô phỏng cuộc tấn công: gửi 1 ETH vào contract, gọi sync() khiến reserve0 tăng từ 10 lên 11 ETH, trong khi reserve1 vẫn 10,000 USDC. Sau đó tôi gọi swap(0, 10,000, address, data) – yêu cầu nhận 10,000 USDC. Hệ thống tính rằng reserve0 sau swap sẽ là 11 - (0 0 balance1Adjusted >= _k. Kết quả: tôi nhận được 10,000 USDC hoàn toàn miễn phí. Hay nói cách khác, pool bị drain sạch.
Nhưng phe bò sẽ nói: 'Ôi, đó là lỗi của dev mới, họ sẽ fix ngay thôi'. Đúng vậy, họ có thể fix, nhưng câu chuyện không dừng lại ở đó. Họ đã huy động 50 triệu USD từ các quỹ đầu tư chuyên nghiệp. Liệu những quỹ đó đã kiểm tra mã chưa? Một quỹ tên Alpha Ventures – từng đầu tư vào Terra, Luna – và đây là dự án thứ ba của họ trong năm nay. Tôi không ngạc nhiên. Thị trường tăng khiến mọi người chạy theo số liệu TVL, token price, chứ không phải code quality. Đây là góc nhìn phản trực giác: không phải FUD giết dự án, mà chính code yếu mới là kẻ thù. YAM không sụp đổ vì FUD, mà vì code yếu. OmegaSwap cũng vậy.
Từ phân tích này, tôi thấy một mô hình lặp lại: dự án fork code nổi tiếng, thêm vài tính năng mới, public audit vội vàng, huy động vốn lớn, TVL tăng nhanh, và cuối cùng là rug pull hoặc exploit. Năm 2021, tôi đã phơi bày dự án Ape Kingdom – một clone BAYC hứa hẹn đất ảo, kết cục là 10,000 NFT mất giá. Năm 2022, tôi theo dõi FTX – vụ sụp đổ lớn nhất lịch sử. Và hôm nay, OmegaSwap đang đi trên cùng con đường. Sự khác biệt duy nhất là họ chưa bị khai thác – nhưng chỉ là vấn đề thời gian.
Tôi muốn kết thúc bài viết này bằng một câu hỏi cho nhà đầu tư: 'Bạn sẵn sàng tin vào một dự án có TVL 200 triệu USD mà code chỉ được audit bởi một công ty không tên tuổi?' Thị trường tăng không tha thứ cho sự bất cẩn. Và trách nhiệm của mỗi người là tự kiểm tra code, không chỉ nhìn vào số liệu. Nếu bạn không thể đọc Solidity, hãy ít nhất tìm đến những người có thể. Đừng trở thành nạn nhân tiếp theo của chu kỳ 'code yếu - huy động vốn - sụp đổ'.