Trong 7 ngày qua, tôi đã theo dõi một giao thức DeFi mới nổi trên Base chain mang tên 'GoldSnake' (Rắn Vàng). Khoảng 4.200 địa chỉ ví đã đổ vào pool thanh khoản của nó, với tổng TVL đạt 12.3 triệu USD vào ngày thứ 3. Đến ngày thứ 7, TVL giảm 40%, và 3 nhà cung cấp thanh khoản lớn rút vốn đồng loạt. Tôi mổ xẻ hợp đồng thông minh của GoldSnake, và phát hiện một hàm mint không được kiểm soát bởi bất kỳ access control nào – bất kỳ ai cũng có thể gọi nó để tạo token mới, miễn là trả một khoản phí nhỏ. Đây là dấu hiệu điển hình của một vụ rug-pull có chủ đích. Bài viết này sẽ phân tích chi tiết cơ chế kỹ thuật, tokenomics và mô hình lừa đảo của GoldSnake, dựa trên dữ liệu on-chain và kinh nghiệm điều tra của tôi từ năm 2017.
Context GoldSnake tự quảng cáo là một 'giao thức cho vay phi tập trung với lãi suất cố định 200% APR', hoạt động trên Base chain – một L2 do Coinbase hỗ trợ. Tôi đã từng audit nhiều dự án tương tự trong mùa hè DeFi năm 2020: Uniswap v2 thậm chí còn có backdoor nhỏ, chứ đừng nói đến những project 'farm and dump' mọc lên như nấm. GoldSnake thu hút người dùng Việt Nam bằng các video TikTok hứa hẹn 'lợi nhuận ổn định', nhưng không ai kiểm tra mã nguồn thực sự. Dự án này không có website chính thức, chỉ có một link Github với một file Solidity duy nhất – GoldSnake.sol. Tôi đã đọc file đó trong vòng 10 phút và tìm ra 3 lỗ hổng nghiêm trọng. Nhưng trước hết, hãy hiểu bối cảnh: Base chain đang ghi nhận lượng token rác tăng vọt trong quý 2/2025, với hơn 500 token mới được triển khai mỗi tuần, phần lớn là lừa đảo. Cơ sở hạ tầng L2 chưa có cơ chế sàng lọc tự động, biến nó thành nơi trú ẩn hoàn hảo cho kẻ xấu.
Core Insight: Mổ xẻ hợp đồng thông minh GoldSnake
Tôi clone repo GoldSnake từ Github (user: goldsnake_defi, repo: v1-core). Chỉ có 2 file: GoldSnake.sol và một file test rỗng. Hợp đồng chính có 287 dòng, sử dụng compiler 0.8.24. Dưới đây là phát hiện quan trọng:
1. Hàm mint không có Access Control Dòng 112-128: ``solidity function mint(address to, uint256 amount) external returns (bool) { _mint(to, amount); return true; } ` Không có modifier onlyOwner hay onlyMinter. Bất kỳ ai gọi hàm này đều có thể tạo token mới vào địa chỉ bất kỳ. Trong một giao thức cho vay, mint token không phải là hành vi bình thường – thông thường token được mint thông qua staking hoặc mint position. Nhưng ở đây không hề có logic kiểm tra. Tôi đã kiểm tra 10 block gần nhất (block 19,342,000 đến 19,342,010 trên Base), và thấy 3 giao dịch gọi mint` từ các địa chỉ không rõ ràng, mint ra tổng cộng 150,000 GOLD token mỗi lần. Không có sự kiện Burn nào tương ứng. Điều này cho thấy nhà phát triển đã tự mint token để bán ra thị trường.
2. Hàm withdraw không kiểm tra số dư thực tế Dòng 199-215: ``solidity function withdraw(uint256 amount) external { require(balanceOf(msg.sender) >= amount, "Insufficient balance"); _burn(msg.sender, amount); // Transfer underlying asset? Not implemented! } ` Hàm này chỉ burn token của người dùng, nhưng không thực sự chuyển tài sản gốc (ETH, USDC) ra khỏi pool. Nó chỉ ghi giảm số dư token, không hề gọi transfer hoặc send. Đây là một điểm yếu tử vong: người dùng nghĩ rằng họ đang rút tiền, nhưng thực tế chỉ mất token, còn tiền thật nằm im trong contract. Khi có người gọi withdraw`, số dư LP giảm nhưng pool thanh khoản thực tế không thay đổi, tạo ra chênh lệch giữa token đang lưu hành và tài sản thế chấp. (Ví dụ: tổng supply 10 triệu GOLD, nhưng pool chỉ có 300 ETH, thì mỗi GOLD chỉ có giá trị 0.00003 ETH, nhưng người dùng lại tưởng nó cao hơn).
3. Hàm setSwapRouter – backdoor admin Dòng 230-242: ``solidity function setSwapRouter(address _router) external { router = _router; } ` Không có modifier onlyOwner. Bất kỳ ai cũng có thể thay đổi router swap. Điều này cho phép kẻ tấn công chuyển hướng giao dịch swap đến một contract độc hại, nơi họ có thể ăn cắp toàn bộ tài sản. Tôi đã thử gọi hàm này qua Foundry và nó thành công. Trong thực tế, tôi tìm thấy 2 giao dịch gọi setSwapRouter` từ cùng một địa chỉ (0xABC…123) trong 3 ngày qua, đó là dấu hiệu cho thấy nhà phát triển đã thử nghiệm thay đổi router trước khi thực hiện hành vi độc hại.
Thử nghiệm trên môi trường fork Tôi chạy một fork Base chain tại block 19,342,000, triển khai GoldSnake contract y hệt. Tôi gọi mint từ một địa chỉ mới (không phải deployer) và thành công tạo ra 1 triệu GOLD. Sau đó tôi gọi withdraw với số lượng bất kỳ, contract burn token của tôi nhưng không trả lại ETH – đúng như dự đoán. Kết quả: GoldSnake không có bất kỳ cơ chế bảo vệ nào. Đây không phải là lỗi lập trình – đây là thiết kế cố tình lừa đảo.
Contrarian Angle: Tại sao phe bò vẫn có lý do để tin? Một số người cho rằng GoldSnake chỉ là dự án non trẻ chưa kịp fix bug, và giá trị thực sự nằm ở cộng đồng người dùng Việt Nam nhiệt tình. Họ chỉ ra rằng TVL tăng vọt từ 0 lên 12 triệu trong 3 ngày là tín hiệu cầu thực sự. Tuy nhiên, từ quan điểm kỹ thuật, tôi thấy không có bằng chứng nào cho thấy đội ngũ phát triển có ý định sửa lỗi. Họ đã ẩn danh (Github profile không có thông tin), không có audit từ bên thứ ba. Hơn nữa, 12 triệu TVL đến chủ yếu từ các địa chỉ ví mới được tạo trong vòng 24 giờ trước khi pool ra mắt – đó là dấu hiệu của wash trading hoặc airdrop farming. Phe bò có thể đúng nếu dự án nhận được đầu tư từ các quỹ lớn, nhưng tôi kiểm tra danh sách holder: top 10 nắm giữ 78% GOLD token, phần lớn là ví deployer. Đây không phải phân phối lành mạnh.
Takeaway Khi một dự án không có access control trên hàm mint, thì đó không phải là lỗi – đó là tính năng. GoldSnake sẽ sụp đổ trong vòng 2 tuần tới, khi pool thanh khoản cạn kiệt và nhà phát triển rút tiền. Tôi đã gửi báo cáo lên Coinbase Security và Base chain team, nhưng chưa có phản hồi. Nếu bạn đang hold GOLD, hãy rút ngay lập tức – nhưng nhớ rằng lệnh withdraw trong contract không trả lại tài sản thực. Cách duy nhất là bán token trên DEX trước khi thanh khoản biến mất. Câu hỏi thực sự là: Ai sẽ chịu trách nhiệm khi Base chain không có cơ chế sàng lọc? Liệu Coinbase có xây dựng công cụ phát hiện rug-pull tự động, hay tiếp tục để kẻ xấu lợi dụng?