Hook
Tuần trước, trên diễn đàn governance của Frax, một đề xuất temperature check bất ngờ thu hút sự chú ý của tôi: cho phép người dùng rút ETH từ pool khóa sớm, với mức phạt 4% chuyển vào kho bạc. Thoạt nghe, đó có vẻ là một cứu cánh cho những ai đã khóa frxETH và nay muốn thoát ra. Nhưng nếu bạn từng audit hợp đồng thông minh như tôi, bạn sẽ nhìn thấy ngay một lớp rủi ro ẩn dưới lớp vỏ 'linh hoạt' này.
Context
Frax là một trong những giao thức DeFi kỳ cựu nhất, nổi tiếng với stablecoin FRAX và hệ sinh thái liquidity layer phức tạp. frxETH là token staking thanh khoản của Frax, tương tự stETH hay rETH. Điểm khác biệt: Frax có pool khóa frxETH - nơi người dùng gửi token để nhận yield cao hơn, nhưng không được rút trước hạn. Điều này giúp Frax quản lý thanh khoản hiệu quả, nhưng tạo ra nỗi thất vọng cho người dùng khi thị trường biến động. Đề xuất hiện tại muốn giải quyết vấn đề đó bằng một 'cửa thoát hiểm' có phí.
Core
Hãy nói về kỹ thuật. Đề xuất này chỉ là một sửa đổi nhỏ trong smart contract - thêm một hàm earlyRedeem() tính phí 4% và gửi tiền vào treasury. Nhưng nhỏ không có nghĩa là an toàn. Tôi đã từng kiểm tra mã nguồn của một giao thức tương tự, nơi lỗi tính toán phí do integer overflow đã khiến người dùng mất trắng. Frax sử dụng proxy pattern, nghĩa là contract có thể nâng cấp. Nếu multi-signature bị tấn công, kẻ tấn công có thể bật/tắt hàm rút sớm bất kỳ lúc nào. Đó là rủi ro trung tâm hóa mà cộng đồng cần đặt câu hỏi.
Về kinh tế, 4% là con số thú vị. Với lợi suất staking ETH hiện tại ~3-4%/năm, một người khóa frxETH trong 3 tháng sẽ kiếm được chưa đến 1%. Nếu rút sớm, 4% phạt sẽ nuốt chửng lợi nhuận và cả gốc. Điều này khiến pool khóa mất sức hút so với các đối thủ không khóa như Lido hay Rocket Pool. Nhưng Frax đặt cược rằng những ai cần thoát ra khẩn cấp sẽ chấp nhận trả giá. Trên thực tế, nếu thị trường sụp đổ, phí 4% có thể trở thành món hời so với mức giảm 30% của ETH. Vậy đây là một cái bẫy hay một phao cứu sinh?
Từ góc nhìn của một người từng xây dựng bot giao dịch quyền chọn, tôi thấy mô hình này giống như một quyền chọn bán (put) ngầm. Người dùng trả 4% để có quyền thoát ra trong tương lai. Đó là phí bảo hiểm. Nếu Frax định giá đúng, phí này sẽ phản ánh xác suất người dùng muốn rút. Nhưng 4% có vẻ hơi 'rẻ' so với biến động thị trường. Các mô hình Black-Scholes tôi sử dụng cho thấy, với implied volatility hiện tại ~60%, một quyền chọn bán 3 tháng đáng giá hơn 15%. Frax đang bán bảo hiểm giá rẻ.
Contrarian
Bạn nghĩ rằng đề xuất này sẽ làm tăng TVL của Frax? Sai. Trong ngắn hạn, có thể một số người dùng yên tâm hơn và khóa thêm ETH. Nhưng trong dài hạn, nó tạo ra một tiền lệ: Frax sẵn sàng thay đổi quy tắc giữa chừng. Điều này phá hủy lòng tin mà pool khóa vốn dựa vào. Những người khóa 1 năm vì tin rằng không thể rút sớm nay thấy Frax mở cửa sau - họ sẽ cảm thấy bị phản bội. Tôi đã chứng kiến điều tương tự ở một giao thức khác: khi cho phép rút sớm với phạt, dòng vốn ban đầu tăng, nhưng sau đó pool khóa tan rã vì mọi người đều chờ cơ hội rút. Họ gọi đó là 'Exit Game'.
Một quan điểm phản trực giác khác: 4% phạt đi vào treasury thực ra có thể gây hại cho Frax. Tại sao? Bởi vì treasury là tài sản chung của giao thức, nếu nó đầy lên từ phí, áp lực chi tiêu của đội ngũ sẽ tăng. Nhiều dự án DeFi đã sụp đổ vì quản lý treasury kém. Tôi cho rằng Frax nên đốt phí thay vì gửi vào treasury, để giảm cung và tạo giá trị trực tiếp cho holder FXS. Nhưng đó là chuyện khác.
Takeaway
Đề xuất này vẫn còn ở giai đoạn temperature check. Nếu bạn đang hold FXS, hãy đặt câu hỏi: liệu Frax có muốn trở thành giao thức linh hoạt hay giao thức đáng tin cậy? Hai mục tiêu đó xung đột nhau. Đối với tôi, một giao thức thay đổi luật chơi giữa chừng sẽ mất đi vũ khí mạnh nhất của DeFi - tính không thay đổi (immutability). Và nếu bạn hỏi tôi có ủng hộ không? Câu trả lời nằm ở hành động: mỗi lần bị gọi là 'con gái sao hiểu nổi quyền chọn', tôi lại mua thêm một hợp đồng quyền chọn. Lần này, tôi sẽ short frxETH.
Mỗi lần ai đó bảo rằng phí 4% là hợp lý, tôi lại tính toán delta của pool khóa. Mỗi lần thấy một 'cứu cánh' trong DeFi, tôi nhớ về bài học ICO 2017: đừng tin whitepaper, hãy tự audit code. Và lần này, code chưa có, nhưng tôi đã thấy trước kết cục.