#baby $BABY Khi tôi khoanh tròn một từ trong phần “mô tả khoản vay chính thức”, tôi mới nhận ra rằng sự “đơn giản” của TBV ngay từ bản thân nó đã là một ranh giới: trên Babylon Core Spoke, hồ sơ thế chấp chỉ có một loại.
@BabylonLabs_io mô tả rất cụ thể: hệ số thế chấp của vị thế hiện tại là cố định, vì khu vực cho vay cốt lõi chỉ có BTC làm tài sản thế chấp; nếu một thị trường đồng thời chấp nhận nhiều loại tài sản thế chấp, thì phải tính theo hệ số gia quyền cho từng loại tài sản. Vì vậy, TBV thiếu đi một lớp điều kiện xác định tham số—người dùng nhìn vào độ lành mạnh sẽ dễ giải thích hơn, và giao thức cũng không cần xử lý trước mức độ rủi ro gia quyền giữa một rổ tài sản.
Nhưng sự gọn gàng này không phải miễn phí. Một người đi vay chỉ nắm giữ BTC sẽ dễ hiểu quy tắc hơn; còn người trong tay vừa có stablecoin, vừa có ETH hoặc các tài sản khác thì lại không thể đưa chúng cùng lúc vào một vị thế để phân tán áp lực do sự biến động của một loại tài sản thế chấp. Muốn tăng biên an toàn, phần lớn họ chỉ có thể giảm nợ hoặc tăng BTC.
Những kịch bản chịu áp lực không cần thị trường phức tạp. Người dùng đã có một khoản vay có thế chấp bằng BTC, sau đó muốn bổ sung đảm bảo bằng một tài sản khác, nhưng lại phát hiện tài sản đó không thể được đưa vào cùng một hồ sơ thế chấp. Lúc này, vấn đề không phải là anh ta không hiểu độ lành mạnh, mà là sản phẩm hoàn toàn không cung cấp cho anh ta lựa chọn tài sản thế chấp thứ hai. Hiệu quả sử dụng vốn và cách tính rủi ro đều bị “khóa” ở phía BTC.
Vì thế, đánh giá của tôi về thiết kế hiện tại của TBV là: nó ưu tiên xây dựng mô hình thế chấp đơn lẻ, dễ đọc và dễ kiểm soát, nhưng điều đó vẫn chưa đủ để chứng minh rằng nó phù hợp với nhóm người đi vay rộng hơn. Điều đáng theo dõi sau $BABY không phải là liệu bảng tham số có dài hơn hay không, mà là khi xuất hiện tài sản thế chấp mới, giao thức có thể giải thích quy tắc gia quyền rõ ràng như hiện tại hay không.
@BabylonLabs_io mô tả rất cụ thể: hệ số thế chấp của vị thế hiện tại là cố định, vì khu vực cho vay cốt lõi chỉ có BTC làm tài sản thế chấp; nếu một thị trường đồng thời chấp nhận nhiều loại tài sản thế chấp, thì phải tính theo hệ số gia quyền cho từng loại tài sản. Vì vậy, TBV thiếu đi một lớp điều kiện xác định tham số—người dùng nhìn vào độ lành mạnh sẽ dễ giải thích hơn, và giao thức cũng không cần xử lý trước mức độ rủi ro gia quyền giữa một rổ tài sản.
Nhưng sự gọn gàng này không phải miễn phí. Một người đi vay chỉ nắm giữ BTC sẽ dễ hiểu quy tắc hơn; còn người trong tay vừa có stablecoin, vừa có ETH hoặc các tài sản khác thì lại không thể đưa chúng cùng lúc vào một vị thế để phân tán áp lực do sự biến động của một loại tài sản thế chấp. Muốn tăng biên an toàn, phần lớn họ chỉ có thể giảm nợ hoặc tăng BTC.
Những kịch bản chịu áp lực không cần thị trường phức tạp. Người dùng đã có một khoản vay có thế chấp bằng BTC, sau đó muốn bổ sung đảm bảo bằng một tài sản khác, nhưng lại phát hiện tài sản đó không thể được đưa vào cùng một hồ sơ thế chấp. Lúc này, vấn đề không phải là anh ta không hiểu độ lành mạnh, mà là sản phẩm hoàn toàn không cung cấp cho anh ta lựa chọn tài sản thế chấp thứ hai. Hiệu quả sử dụng vốn và cách tính rủi ro đều bị “khóa” ở phía BTC.
Vì thế, đánh giá của tôi về thiết kế hiện tại của TBV là: nó ưu tiên xây dựng mô hình thế chấp đơn lẻ, dễ đọc và dễ kiểm soát, nhưng điều đó vẫn chưa đủ để chứng minh rằng nó phù hợp với nhóm người đi vay rộng hơn. Điều đáng theo dõi sau $BABY không phải là liệu bảng tham số có dài hơn hay không, mà là khi xuất hiện tài sản thế chấp mới, giao thức có thể giải thích quy tắc gia quyền rõ ràng như hiện tại hay không.