𝐒𝐨𝐟𝐥𝐞𝐢𝐫𝐞 $𝐒𝐅𝐋𝐑: Việc ra mắt thất bại do phí và thanh khoản, không phải bị tấn công – Đây là bản ghi lại việc thiết lập lại 1. Điều gì đã xảy ra: Đây không phải là một vụ hack. Không có khóa riêng nào bị đánh cắp, không hợp đồng nào bị kẻ tấn công khai thác, và không có “script bán nội bộ” nào được chạy chống lại cộng đồng. Điều xảy ra là một lỗi cấu hình tại thời điểm ra mắt. Một phần lớn nguồn cung đã được đặt vào các hợp đồng khóa/ưu tiên của Streamflow. Trên Streamflow, các khoản khóa token sẽ kèm theo phí 0,5% token, ngoài phí tạo SOL nhỏ. Phí này không phải là lý thuyết — nó là một phần trong cách định giá sản phẩm khóa. Khi thị trường mở, phí này tương tác với một vấn đề thứ hai: thanh khoản cực kỳ mỏng so với FDV. - FDV (định giá khi pha loãng hoàn toàn) là giá × tổng nguồn cung, bao gồm cả các token chưa lưu hành. - Thanh khoản là vốn thực tế nằm trong pool có khả năng hấp thụ giao dịch mua/bán mà không khiến giá sụp đổ. Nếu FDV lớn mà pool nhỏ, ngay cả một lệnh bán tự động nhỏ cũng có thể làm sụp đổ biểu đồ. Đó chính xác là điều mà thông báo đầu tiên đã mô tả: 0,5% nguồn cung bị khóa đã bị thanh lý tự động ngay khi mở cửa do thanh khoản quá thấp so với FDV. Vì vậy, trình tự xảy ra như sau: 1. Các khoản khóa được tạo với cấu trúc phí khóa tiêu chuẩn của Streamflow. 2. Thị trường mở với độ sâu không đủ. 3. Cấu hình phí/ưu tiên buộc các token được đưa vào thị trường ngay lập tức. 4. Thanh khoản mỏng biến sự kiện phí thành sự kiện biểu đồ. Đây là lỗi vận hành và thông số. Thông báo đầu tiên đã chấp nhận hoàn toàn trách nhiệm về điều này. 2. Vì sao điều này quan trọng hơn “biểu đồ trông xấu” Trong một đợt ra mắt lành mạnh, nguồn cung bị khóa phải được loại khỏi thị trường. Các khoản khóa tồn tại để người nắm giữ có thể xác minh rằng các token của đội ngũ, quỹ hoặc đang chờ giải phóng sẽ không được bán ra ngay ngày đầu tiên. Khi cơ sở hạ tầng khóa tự thân giới thiệu một phí token phải được thanh toán tại thời điểm tạo hoặc mở, hai điều sau phải đúng nếu không thiết kế sẽ thất bại: 1. Ai đó đã nạp trước phí theo cách không bán vào pool mới. 2. Pool đủ sâu để bất kỳ lệnh bán dư thừa nào cũng không định giá thị trường. Cả hai điều kiện đều không được đáp ứng. Thanh khoản thấp so với FDV là sự không phù hợp kinh điển trong các đợt ra mắt: thị trường được định giá như thể toàn bộ nguồn cung đều có giá trị, nhưng chỉ một lượng nhỏ mới thực sự có thể giao dịch. Bất kỳ người bán ép buộc nào — do phí, sniper, lỗi thêm LP, hoặc giải phóng — đều sẽ trở thành người định giá. Đó là lý do vì sao thông báo đầu tiên gọi đây là một sự tính toán sai nghiêm trọng về thông số cấu hình, chứ không phải một vụ khai thác bí ẩn. 3. Vì sao đội ngũ không “sửa chữa biểu đồ hiện tại” Sau khi xem xét các lựa chọn suốt đêm, thông báo thứ hai đã từ chối một giải pháp tạm thời cho token hiện tại. Sửa chữa một bản in đầu tiên bị hỏng thường chỉ giúp những người sai: - Sniper / bot MEV đã mua lợi thế chênh lệch. - Nhà cung cấp thanh khoản muộn và người bán trong giờ đầu tiên đã ghi nhận tổn thất. - Người nắm giữ ngày đầu tiên đã mua theo đúng kế hoạch ra mắt sẽ bị buộc phải cạnh tranh với một biểu đồ hiện đã ghi lại thất bại đó. Một bản sửa chữa giữ nguyên cùng một mint, cùng các hợp đồng ưu tiên và cùng sổ lệnh bị nhiễm độc sẽ không khôi phục lại bề mặt phát hiện giá sạch sẽ. Nó chủ yếu sẽ chuyển giá trị còn lại về phía những người nhanh nhất khi phí chạm vào pool. Đó chính là lý do được nêu rõ để tạo ra một token mới thay vì thực hiện một sửa chữa mang tính hình thức.