Robot thanh lý không có kéo, chỉ biết bê cả một thùng mang đi. Thấy <0-9>@BabylonLabs_io </0-9> mạng thử nghiệm hiện tại thiết kế mỗi Vault thành một UTXO độc lập, tôi mới hiểu ra: “song Vault” không phải là một lựa chọn gửi tiền đẹp mắt, mà là cách cắt nhỏ tổn thất khi thanh lý.
Trong DeFi thông thường, tài sản thế chấp có thể được cắt đi theo tỷ lệ, nhưng trong giao dịch Bitcoin thì chỉ có thể chi tiêu trọn vẹn một output. Giả sử trong vị thế có 0,4 BTC, khi thanh lý chỉ cần xử lý khoảng 0,25 BTC; nếu 0,4 BTC đều nhồi vào một Vault, thì giao thức cũng không thể cắt lấy đúng 0,25 từ đó—nó chỉ có thể đưa cả Vault vào diện thanh lý. Giá trị “thừa” không hề biến mất vô cớ: cơ chế công bằng sẽ trước hết giảm nghĩa vụ nợ còn lại cho người dùng, và khi còn dư thì mới hoàn trả bằng WBTC. Nhưng “nhận bù tương đương” và “BTC gốc vẫn nằm trong vị thế của chính mình” rõ ràng không phải là một chuyện.
Đó là lý do song Vault thực sự hữu dụng. Theo tham số của mạng thử nghiệm công khai hiện nay, hệ số thế chấp là 78%, hệ số sức khỏe mục tiêu là 1,24. Khi ước tính vị thế vừa chạm ngưỡng thanh lý, lượng mục tiêu dự kiến chiếm khoảng 62% giá trị BTC. Portal sẽ dựa vào tham số thời gian thực, xếp Vault “hy sinh” có quy mô lớn hơn lên trước, còn phần BTC còn lại sẽ được đưa vào Vault bảo vệ; quy trình thanh lý sẽ lần lượt kiểm tra từng Vault từ đầu danh sách, cái đầu tiên đủ dùng thì dừng, cái thứ hai tiếp tục được giữ lại trong vị thế.
Vì vậy nó không phải kiểu “vũ khí phòng chống thanh lý” tuyệt đối, mà giống như cánh cửa ngăn nước trong khoang tàu: sự cố vẫn gây mất mát, chỉ là hạn chế việc tổn thất nuốt trọn cả con tàu. Nếu giá lao dốc quá nhanh, kích thước Vault hy sinh không đủ, hoặc thứ tự sắp xếp bị đặt sai, hệ thống vẫn có thể tiếp tục lấy sang Vault tiếp theo; 62/38 cũng không phải công thức vĩnh viễn—khi tham số thay đổi thì phải xem lại cách Portal tách theo dữ liệu mới.
Tôi thà gọi thiết kế này là “quản lý độ phân mảnh tổn thất”. Thứ người vay thực sự cần để mắt không chỉ là hệ số sức khỏe, mà còn là kích thước Vault của mình và thứ tự sắp xếp. Bạn có sẵn sàng chấp nhận việc quản lý vị thế phức tạp hơn để giữ được Vault BTC gốc thứ hai không?
#baby $BABY
Trong DeFi thông thường, tài sản thế chấp có thể được cắt đi theo tỷ lệ, nhưng trong giao dịch Bitcoin thì chỉ có thể chi tiêu trọn vẹn một output. Giả sử trong vị thế có 0,4 BTC, khi thanh lý chỉ cần xử lý khoảng 0,25 BTC; nếu 0,4 BTC đều nhồi vào một Vault, thì giao thức cũng không thể cắt lấy đúng 0,25 từ đó—nó chỉ có thể đưa cả Vault vào diện thanh lý. Giá trị “thừa” không hề biến mất vô cớ: cơ chế công bằng sẽ trước hết giảm nghĩa vụ nợ còn lại cho người dùng, và khi còn dư thì mới hoàn trả bằng WBTC. Nhưng “nhận bù tương đương” và “BTC gốc vẫn nằm trong vị thế của chính mình” rõ ràng không phải là một chuyện.
Đó là lý do song Vault thực sự hữu dụng. Theo tham số của mạng thử nghiệm công khai hiện nay, hệ số thế chấp là 78%, hệ số sức khỏe mục tiêu là 1,24. Khi ước tính vị thế vừa chạm ngưỡng thanh lý, lượng mục tiêu dự kiến chiếm khoảng 62% giá trị BTC. Portal sẽ dựa vào tham số thời gian thực, xếp Vault “hy sinh” có quy mô lớn hơn lên trước, còn phần BTC còn lại sẽ được đưa vào Vault bảo vệ; quy trình thanh lý sẽ lần lượt kiểm tra từng Vault từ đầu danh sách, cái đầu tiên đủ dùng thì dừng, cái thứ hai tiếp tục được giữ lại trong vị thế.
Vì vậy nó không phải kiểu “vũ khí phòng chống thanh lý” tuyệt đối, mà giống như cánh cửa ngăn nước trong khoang tàu: sự cố vẫn gây mất mát, chỉ là hạn chế việc tổn thất nuốt trọn cả con tàu. Nếu giá lao dốc quá nhanh, kích thước Vault hy sinh không đủ, hoặc thứ tự sắp xếp bị đặt sai, hệ thống vẫn có thể tiếp tục lấy sang Vault tiếp theo; 62/38 cũng không phải công thức vĩnh viễn—khi tham số thay đổi thì phải xem lại cách Portal tách theo dữ liệu mới.
Tôi thà gọi thiết kế này là “quản lý độ phân mảnh tổn thất”. Thứ người vay thực sự cần để mắt không chỉ là hệ số sức khỏe, mà còn là kích thước Vault của mình và thứ tự sắp xếp. Bạn có sẵn sàng chấp nhận việc quản lý vị thế phức tạp hơn để giữ được Vault BTC gốc thứ hai không?
#baby $BABY
