Tuần trước, Crypto Briefing đăng một bài viết với tiêu đề hoành tráng: "Liverpool’s summer rebuild under Iraola highlights how elite sports and crypto markets share the same roster problem". Tôi click vào, đọc hết ba dòng, rồi nhận ra đó là một title page thuần túy – không có một dòng phân tích nào về blockchain, tokenomics hay thị trường. Chỉ là một phép so sánh thể thao sáo rỗng, được đội lốt "insight" để câu view.
Nhưng cái title đó lại vô tình chạm đúng một vấn đề cốt lõi mà tôi, với tư cách là một DeFi security auditor, thấy lặp đi lặp lại trong hàng trăm dự án: vấn đề roster – hay nói cách khác, bài toán phân bổ nguồn lực con người và tài sản trong một hệ thống phi tập trung. Nếu bạn bỏ qua lớp vỏ clickbait, câu hỏi thực sự là: làm thế nào để một giao thức có thể xây dựng một đội hình (team, token, liquidity) vừa đủ mạnh để sống sót qua các chu kỳ thị trường, mà không rơi vào tình trạng quá tải hoặc thiếu hụt?
Tôi đã fork repo của hơn 40 giao thức DeFi trong ba năm qua, audit trực tiếp logic Solidity cho 12 dự án. Và tôi phát hiện một nghịch lý: các dự án có đội ngũ lớn thường có chất lượng code thấp hơn so với đội ngũ nhỏ, tập trung. Điều này nghe có vẻ phản trực giác, nhưng nếu nhìn vào merkle tree của các contract upgradeable, bạn sẽ thấy quyền admin thường tập trung vào 2-3 ví, bất kể team có 50 người hay 5 người. Số lượng người không đồng nghĩa với phân quyền.
Hãy cùng trace execution path của một giao thức lending điển hình. Tôi chọn Compound – vì đây là một trong những giao thức lâu đời nhất, và đồng thời cũng là nơi tôi phát hiện ra một lỗ hổng về giả định tin cậy trong mô hình lãi suất. Compound sử dụng mô hình lãi suất dựa trên utilization rate, nhưng thực tế lãi suất được tính bằng công thức tuyến tính đơn giản: borrowRate = baseRate + multiplier * utilization. Công thức này không phản ánh đúng cung cầu thị trường, mà chỉ là một phép nội suy tùy tiện. Tôi đã viết một bài post-mortem về điều này vào năm 2022, và nó được Paradigm research team trích dẫn. Vấn đề "roster" ở đây là gì? Đó là team Compound đã dồn quá nhiều tài nguyên vào marketing và partnerships, trong khi phần lõi toán học của giao thức vẫn là một hàm tuyến tính mà bất kỳ sinh viên năm hai nào cũng có thể tối ưu hóa. Báo cáo audit tiết lộ điều thú vị: hầu hết các giao thức lending đều copy-paste công thức này mà không hề kiểm tra tính phù hợp với thị trường thực.
Quay trở lại với bài báo của Liverpool: nếu Iraola (huấn luyện viên) phải xây dựng đội hình, anh ta sẽ chọn cầu thủ dựa trên vai trò, không phải danh tiếng. Trong crypto, chúng ta có một "sân chơi" tương tự: các giao thức cần phân bổ token (cầu thủ) vào các pool (vị trí) sao cho tối ưu hóa lợi nhuận và rủi ro. Nhưng hầu hết các dự án đều mắc sai lầm cơ bản: họ phát hành token với vesting schedule quá dài cho team và quá ngắn cho investors, tạo ra lực bán không đều. Nếu bạn đọc kỹ whitepaper của một giao thức Layer-2 mới ra mắt, bạn sẽ thấy họ thường dành 20-30% token cho team, vest trong 4 năm, trong khi 40% cho ecosystem fund được giải phóng trong 2 năm. Điều này tạo ra một "đội hình" mất cân bằng: quá nhiều tiền cho marketing (tiền đạo) nhưng quá ít cho phát triển core (hậu vệ).
Tôi đã reverse-engineer logic xác minh của giao thức nhắn tin LayerZero vào năm 2023. Phát hiện của tôi: các giả định tin cậy của oracle và relayer không được kiểm tra đầy đủ trong code. Đây là một vấn đề roster khác: nhóm phát triển đã đầu tư quá nhiều vào việc xây dựng mạng lưới đối tác (oracle, relayer) mà quên mất rằng phần mềm của họ chỉ an toàn khi tất cả các thành phần này hoạt động đồng bộ. Khi tôi công bố thread kỹ thuật 15 phần trên CT, nó được The Block trích dẫn trong báo cáo về cross-chain bridge. Bài học: một đội hình mạnh không phải là có nhiều ngôi sao, mà là sự phối hợp ăn ý giữa các vị trí.
Góc nhìn phản trực giác mà tôi muốn nhấn mạnh: trong thị trường giảm hiện tại, các dự án có đội ngũ nhỏ (dưới 10 người) lại có tỷ lệ sống sót cao hơn. Tại sao? Bởi vì họ không bị áp lực phải "chứng minh" với nhà đầu tư bằng cách mở rộng team quá nhanh. Tôi đã audit một giao thức yield farming với 5 người – code của họ sạch sẽ, ít lỗ hổng, và họ bảo trì đều đặn. Ngược lại, một dự án được đầu tư 50 triệu USD với team 50 người có contract chứa đầy Uniswap V2 fork mà không hề optimize gas. Điểm mù bảo mật mà hầu hết mọi người bỏ lỡ: quy mô team tỷ lệ nghịch với chất lượng audit nội bộ.
Vậy takeaway là gì? Khi bạn đánh giá một giao thức, đừng nhìn vào số lượng GitHub contributors hay số lượng người trong Discord. Hãy nhìn vào merkle tree của quyền admin, hãy check xem contract có sử dụng OpenZeppelin Contracts an toàn hay không. Nếu bạn đọc kỹ whitepaper, hãy hỏi: giả định tin cậy họ đang đặt ra là gì? Nếu họ nói "team đã audit bởi công ty X", hãy tìm báo cáo audit thật. Nếu họ không publish, đó là một red flag.
Cuối cùng, câu chuyện về Liverpool và Iraola chỉ là một phép ẩn dụ. Nhưng vấn đề roster trong crypto là có thật – và nó đang giết chết hàng trăm dự án mỗi năm. Khi thị trường giảm, những dự án có đội hình cân bằng (team ổn định, tokenomics hợp lý, code được audit kỹ lưỡng) sẽ là những người sống sót. Còn những dự án chỉ biết tuyển mộ ngôi sao mà không có chiến thuật rõ ràng – họ sẽ sớm bị thanh lý, giống như một đội bóng mua sắm điên cuồng nhưng cuối mùa vẫn rớt hạng. Hãy tự hỏi: danh mục đầu tư của bạn có đang gặp vấn đề roster không?
