Trong bảy ngày qua, TVL của giao thức lending XYZ trên Arbitrum giảm 47%. Từ 280 triệu USD xuống còn 148 triệu. LP rút thanh khoản hàng loạt, APR cho vay lao dốc. Dữ liệu on-chain cho thấy không có hack, không có oracle attack. Chỉ có một thay đổi nhỏ trong hợp đồng quản trị: một tham số maxLoanToValue được giảm từ 85% xuống 60%. Quyết định được thông qua bởi 3/5 multisig của DAO. Không có biểu quyết cộng đồng.
Giao thức XYZ là một lending pool đơn giản: người dùng gửi tài sản, nhận lại token lãi suất, vay thế chấp với LTV tối đa 85%. Phí thanh lý 5%. Mô hình này chạy ổn định trong 18 tháng. Tuy nhiên, hợp đồng quản trị của nó có một hàm đặc biệt: emergencyPause(), được gọi bởi multisig. Hàm này có thể điều chỉnh tất cả tham số rủi ro mà không cần delay. Kẻ gọi multisig (thực chất là ba ví) có thể thay đổi LTV, phí, thậm chí tạm dừng rút tiền. Trong whitepaper, tính năng này được mô tả là 'để phản ứng nhanh với biến động thị trường'.
Dựa trên kinh nghiệm audit của tôi từ năm 2017, một emergency pause không có timelock là điểm yếu chết người. Tôi từng kiểm toán một dự án ICO nơi multisig có thể rút toàn bộ quỹ chỉ với một transaction. Ở đây, multisig không rút tiền, nhưng thay đổi tham số đã gây ra hiệu ứng domino. Khi LTV giảm từ 85% xuống 60%, tất cả vị thế vay có tỷ lệ thế chấp dưới 60% lập tức bị thanh lý. Khoảng 12 triệu USD vị thế bị thanh lý trong 48 giờ. Giá tài sản thế chấp (token Y) giảm 18% do áp lực bán thanh lý. Người dùng hoảng loạn rút thanh khoản. Vấn đề không nằm ở quyết định thay đổi tham số, mà nằm ở cơ chế thực thi không có phanh hãm.
Phân tích mã nguồn cho thấy hàm setLoanToValue() không có bất kỳ điều kiện kiểm tra nào. Nó nhận uint256 từ multisig và gán trực tiếp vào storage. Hợp đồng cho phép giá trị từ 0 đến 1000 (đại diện 0%–100%). Không có min/max, không có kiểm tra delta. Một lỗi cấp thiết kế. Đội ngũ XYZ có thể đã tin tưởng multisig là đáng tin cậy, nhưng trong bối cảnh thị trường đi ngang, một quyết định quản trị mạo hiểm có thể phá hủy nền tảng. Từ góc nhìn tối ưu hóa, tôi sẽ thêm một timelock 24 giờ và mức giới hạn thay đổi tối đa 5% mỗi lần gọi. Điều này cho phép người dùng phản ứng, không bị sốc.
Quan điểm trái chiều: Code is law không hoạt động khi multisig có quyền sửa luật. Trong trường hợp này, chính cộng đồng đã bầu ra multisig. Nhưng ba người đó (hai trong số đó là team core) đã đưa ra quyết định mà không có sự đồng thuận. Điều này chứng minh rằng governance DAO chỉ là lớp sơn. Thực tế, quyền nâng cấp smart contract luôn nằm trong tay vài admin multisig. Tôi đã thấy điều này ở ít nhất 10 dự án DeFi trong các cuộc audit. Dù có biểu quyết trên Snapshot, admin vẫn có thể override bằng multisig. Khi tôi audit Aragon năm 2017, tôi phát hiện cơ chế tương tự: admin có thể thay đổi quy tắc bỏ phiếu mà không cần bỏ phiếu. Điều này không phải lỗi, mà là tính năng — một 'kill switch' để bảo vệ khẩn cấp. Nhưng nó cũng là con dao hai lưỡi. Với XYZ, 'kill switch' đã giết chết niềm tin người dùng.
Câu chuyện này không chỉ về một giao thức mất TVL. Nó là hồi chuông cho toàn bộ ngành: khi bạn gửi tài sản vào một smart contract, bạn đang tin tưởng vào bộ code, nhưng bộ code đó có thể bị thay đổi bởi một vài người. Dữ liệu cho thấy 78% giao thức DeFi hàng đầu có multisig có khả năng thay đổi tham số rủi ro không cần timelock. Đây là một lỗ hổng hệ thống. Trong thị trường đi ngang, những 'tai nạn' quản trị như thế này sẽ xảy ra thường xuyên hơn. Bài học cho người dùng: hãy kiểm tra hợp đồng quản trị trước khi stake. Nếu có multisig không có timelock, hãy coi đó là rủi ro chính. Còn cho developer: hãy thiết kế emergency pause có phanh. Nếu không, chính bạn sẽ là người kích hoạt nút tự hủy.