7 ngày. Một giao thức DeFi mất 40% thanh khoản. Không phải do rug pull, không phải do hack oracle. Chỉ từ một dòng code trong contract dynamic fee. Bạn có tin không?
Mỗi lần kiểm toán là một lần tôi đặt câu hỏi: "Tại sao họ lại viết cái này?"
Câu chuyện bắt đầu vào tháng 10/2026. Một dự án AMM mới nổi, tự xưng là "thế hệ thứ ba" với cơ chế phí động thích ứng thị trường. Họ nói: "Khi thị trường đi ngang, phí thấp để khuyến khích giao dịch; khi biến động, phí cao để bảo vệ LP." Nghe có vẻ hợp lý. Nhưng tôi nhìn vào mã nguồn, và một điều gì đó không ổn.
Context: Cơ chế dynamic fee trong AMM không mới. Uniswap V3 đã có ý tưởng này qua tick spacing, nhưng nó được cố định tại mỗi pool. Các giao thức sau này như PancakeSwap hay Trader Joe đã thử nghiệm thay đổi phí theo thời gian thực dựa trên độ biến động giá, khối lượng giao dịch, hoặc thanh khoản. Ý tưởng rất đẹp: tối ưu lợi nhuận cho LP. Nhưng code là một chuyện, thực thi là chuyện khác.
Dự án này, tạm gọi là "FlexSwap", triển khai một contract DynamicFeePool kế thừa từ Uniswap V2. Họ thêm một hàm updateFee(uint256 newFee) được gọi bởi một oracle bên ngoài mỗi 15 phút. Oracle này đọc giá từ Chainlink và tính toán phí dựa trên một công thức độc quyền. Nghe có vẻ an toàn? Sai.
Core: Tôi bắt đầu trace từng dòng. Contract có một mapping feeHistory lưu trữ các mức phí theo block. Khi oracle gọi updateFee, nó cập nhật biến toàn cục currentFee. Nhưng vấn đề nằm ở chỗ: logic kiểm tra trong hàm swap và removeLiquidity sử dụng currentFee mà không có bất kỳ xác thực nào về tính hợp lệ của giá trị. Trong thị trường đi ngang, oracle trả về mức phí thấp, khoảng 0.05%. Mọi thứ hoạt động tốt.
Đến một ngày, oracle bị tắc nghẽn mạng do một đợt spam trên Ethereum. Nó không thể cập nhật trong 30 phút. Giá trị currentFee vẫn là 0.05%. Nhưng kẻ tấn công đã lợi dụng điều này: họ gửi một giao dịch swap với lượng lớn token, khiến pool mất cân bằng tạm thời. Sau đó, họ gọi removeLiquidity ngay lập tức, nhưng vì hàm removeLiquidity tính phí dựa trên currentFee tại thời điểm gọi (vẫn là 0.05%), trong khi thực tế thị trường đã biến động mạnh, giá trị thanh khoản bị định giá sai. Kết quả: họ rút được nhiều hơn số LP đáng lẽ được hưởng, khiến pool mất 40% thanh khoản chỉ trong 7 ngày.
Ai đó sẽ nói: "Lỗi do oracle chứ không phải do contract." Sai. Contract đáng lẽ phải có cơ chế fallback: nếu oracle không cập nhật trong một khoảng thời gian, hãy revert giao dịch hoặc sử dụng phí mặc định cao hơn. Nhưng họ không làm. Họ tin tưởng mù quáng vào oracle.
Mỗi lần kiểm toán là một lần tôi đặt câu hỏi: "Tại sao họ lại bỏ qua tính bất định của thế giới thực?"
Contrarian: Điều trớ trêu là dynamic fee được quảng cáo như một tính năng bảo vệ LP. Nhưng trong thực tế, nó tạo ra một vector tấn công mới: độ trễ oracle. Trong thị trường đi ngang, khi thanh khoản khan hiếm, mọi người đổ xô vào các pool "phí thấp" để farm yield. Họ nghĩ rằng dynamic fee sẽ tự động điều chỉnh để bảo vệ họ. Nhưng họ không biết rằng chính cơ chế này lại là con ngựa Trojan.
Takeaway: Lần tới, khi bạn thấy một giao thức tự hào về dynamic fee, hãy hỏi: "Nếu oracle của bạn hỏng, ai sẽ trả tiền?" Trong thế giới crypto, không có gì là tự động an toàn. Mỗi dòng code đều có thể là một cái bẫy. Và tôi, với tư cách một auditor, chỉ có thể nói: hãy đọc mã nguồn trước khi gửi LP của bạn vào.
Đây không phải là một bài học mới. Nhưng nó lặp lại mỗi chu kỳ. Và tôi vẫn viết, vẫn audit, vẫn đặt câu hỏi. Bởi vì mỗi lần kiểm toán là một lần tôi đặt câu hỏi: "Còn bao nhiêu lỗ hổng nữa đang chờ được khai thác?"