doyouknowthis

Blog riêng của Babylos có một bài đăng mà tôi không ngờ tới: một dự án giải thích chính sản phẩm của mình, đồng thời mời công khai để chấm điểm sản phẩm đó—Trustless Bitcoin Vaults (TBV)—kèm theo một danh sách kiểm tra các điểm yếu có thể có. #baby

SCRIPT là khung gồm sáu hạng mục rủi ro cho mọi giải pháp Bitcoin làm tài sản thế chấp. Sovereignty (Chủ quyền): người nắm giữ có giữ quyền sở hữu cho tới khi bị thanh lý không. Clarity (Sự rõ ràng): các quy tắc xử lý trước khi cam kết là gì, có rõ ràng và mang tính khách quan không. Reuse Prohibited (Không được tái sử dụng): việc thế chấp lại (rehypothecation) bị cấm nếu không có sự đồng ý.

Isolation (Cách ly): tài sản thế chấp của từng người được giữ riêng. Permissionless (Không cần cấp phép): liệu bên thứ ba có thể kiểm duyệt hệ thống hay không. Transparency (Minh bạch): mọi vị thế đều có thể được kiểm toán trên chuỗi khối (onchain). Bài blog nêu thẳng rằng người nắm giữ Bitcoin và các ứng dụng có thể dùng SCRIPT để đánh giá mọi giải pháp tài sản thế chấp bằng Bitcoin, bao gồm cả Babylons.$BABY

Tôi không ngờ một công ty lại công bố một khung có tác dụng tô vẽ thiết kế của chính họ. Khung này cung cấp cho bạn đúng sáu câu hỏi để kiểm tra xem thiết kế đó—của họ hay của bất kỳ ai khác—có thực sự đứng vững hay không.

Càng dành thời gian với danh sách đó, nó càng giống như một tín hiệu về mức độ tin cậy đi kèm một chi phí: một vài trong sáu mục có vẻ khá dễ để TBV vượt qua, còn một hoặc hai mục lại thực sự khiến người ta thấy khó chịu. Một rubric mà sản phẩm của bạn sẽ dễ dàng đạt được một cách tầm thường thì không đáng để công bố.

Tôi vẫn chưa tự mình đưa TBV qua tất cả sáu hạng mục. Có thể mọi thứ đều “sạch”. Có thể một hạng mục nào đó sẽ trả về kèm dấu hoa thị—và tôi nghi ngờ việc tìm ra điều đó chính là lý do khung này được công bố.#DoYouKnowThis
@BabylonLabs_io
$BANK $UAI

Tối qua tôi quay lại phần DEX của whitepaper dành cho những kẻ đứng sau, nghĩ rằng nó chỉ là logic margin của Lendings được gắn nhãn lại. Nó gần hơn tôi kỳ vọng nhưng không giống hệt.$BABY

@BabylonLabs_io A một trader gửi BTC IN vào một Trustless Bitcoin Vaults (TBV) vault, tương tự như cho vay. Metadata của vault được đồng bộ sang một chain tương thích perps thông qua hạ tầng light client và collBTC được đúc ở đó. Nhưng thay vì làm tài sản đảm bảo cho một khoản vay (Loan), nó trở thành margin cho các vị thế long hoặc short, với “margin engine” của Protocol theo dõi PnL và các ngưỡng rủi ro trực tiếp.

Việc settlement phản chiếu mô hình redemption của phần lending: đốt token margin, nộp một bằng chứng cho vault, chờ hết thời gian timeout rồi nhận lại BTC. Việc liquidation cũng hoạt động tương tự từ phía bên kia: liquidator mua và đốt collBTC khi vị thế rơi xuống dưới các ngưỡng duy trì (maintenance).

Tôi đã giả định rằng việc tái sử dụng primitive vault trên cả lending stablecoins và perps có nghĩa là profile rủi ro về cơ bản là giống nhau ở mọi nơi. Nhưng perps có biến động PnL mà một vị thế lending với một khoản Loan cố định không có.

Tôi thực sự cho rằng đây là lựa chọn thiết kế thú vị hơn: một primitive tài sản thế chấp có thể hỗ trợ những “dạng rủi ro” khác nhau một cách thực sự thay vì cần một thiết kế vault riêng cho từng trường hợp sử dụng.

Phần này được mô tả như một thiết kế đề xuất trong whitepaper, chứ chưa được xác nhận rằng triển khai “liVe” ở bất kỳ đâu. Vì vậy, điều tôi chưa xử lý được là liệu việc theo dõi PnL của các margin engine có chạy hoàn toàn onchain hay dựa vào một thành phần offchain—tài liệu không nêu chi tiết.#DoYouKnowThis
$EUL $BANK
#baby

Đọc phần tích hợp Neynar Farcaster trong báo cáo Q4 2025 và dừng lại ở một giả định được gói sẵn trong đó: việc dễ dàng bỏ qua các tín hiệu về uy tín xã hội, độ xác thực tài khoản, ngưỡng mức độ tương tác, như là đầu vào cho một công cụ vận hành chính sách nằm sát cạnh lĩnh vực tuân thủ.

Các khung tuân thủ truyền thống vẽ ra một đường ranh khá rõ ràng: KYC xác minh danh tính pháp lý; sàng lọc trừng phạt đối chiếu các danh sách của chính phủ; AML theo dõi các mẫu giao dịch để phát hiện rửa tiền; các typology (mẫu nhận diện) là không có. Tất cả những điều này về truyền thống không đưa các chỉ số tương tác trên mạng xã hội hoặc các điểm uy tín theo từng nền tảng làm đầu vào cho một quyết định tuân thủ.

Tích hợp Newtons Neynar cho phép xác minh theo chính sách các danh tính Farcaster, cho phép các ứng dụng thực thi các hàng rào bảo vệ (guardrails) trên chuỗi liên quan đến các tín hiệu danh tính xã hội như: độ xác thực của tài khoản, uy tín, hoặc các ngưỡng tương tác trước khi thực hiện giao dịch.

Vậy trường hợp sử dụng thực sự để đưa các tín hiệu xã hội vào một công cụ chính sách cùng với việc kiểm tra trừng phạt là gì?

Cách diễn giải hợp lý nhất là chống Sybil và phòng chống spam hơn là tuân thủ theo nghĩa truyền thống—tương tự như cách tích hợp Human Passport trong phân tích trước đó sử dụng các tín hiệu hành vi để phát hiện Sybil. Một ứng dụng có thể muốn chặn quyền truy cập vào một tính năng dựa trên việc: đây có phải là một tài khoản thực sự đã được thiết lập hay không, thay vì: người này có bị trừng phạt hay không. Cả hai đều là các hàng rào bảo vệ. Chỉ một trong số đó là tuân thủ theo nghĩa quy định.

Tôi thực sự nghĩ rằng việc gộp cả hai dưới một “công cụ vận hành chính sách” sẽ mở rộng những gì Newton đang làm theo một cách dễ bị bỏ sót nếu bạn chỉ theo dõi các thông báo khung tuân thủ. Newton không chỉ là một công cụ tuân thủ quy định thuần túy; đó là một hệ thống hàng rào bảo vệ trước giao dịch nói chung, và việc xác minh danh tính xã hội là một nhóm hàng rào bảo vệ—nằm sát cạnh nhưng khác biệt so với các hạng mục như trừng phạt và KYC.

Điều tôi chưa kịp làm rõ là liệu việc gộp “công cụ vận hành chính sách tuân thủ” và “hệ thống hàng rào bảo vệ chung” dưới cùng một sản phẩm có gây nhầm lẫn cho các nhà đánh giá tổ chức hay không—nhất là những người đang tìm kiếm hạ tầng tuân thủ quy định
$EVAA $LAB #DoYouKnowThis
@NewtonProtocol $NEWT #Newt