Binance Square
传奇FEEHA
10.5k Bài đăng

传奇FEEHA

Sharing crypto basics, market updates, and Web3 insights in simple language. My goal is to make trading concepts easy to understand, provide clear explanations.
1.3K+ Đang theo dõi
15.0K+ Người theo dõi
8.6K+ Đã thích
Bài đăng
·
--
@babylonlabs_io Một điều về cấu trúc của bộ Universal Challenger này khiến tôi thấy hơi phản trực giác sau khi tôi thực sự ngồi xem nó cho đúng. Tài liệu làm rõ một điều rằng bộ này không được dự tính mở ra cho sự tham gia không cần cấp phép—tức là sự hạn chế là một phần của chính thiết kế chứ không phải là một giới hạn tạm thời chờ thêm thời gian để rồi cuối cùng sẽ nới lỏng. Ban đầu tôi tưởng đây là lối đi phổ biến mà nhiều hệ thống thường làm: bắt đầu với một nhóm được giới hạn, xây dựng sự tin cậy theo thời gian, rồi dần dần mở rộng sự tham gia khi mạng lưới lớn lên và lòng tin tự tích lũy. Nhưng mô hình này không vận hành như vậy. Những Universal Challengers mới gia nhập thông qua quản trị, bổ sung các nhà vận hành đã được thẩm định vào sổ đăng ký, chứ không phải thông qua việc bất kỳ ai tự gia nhập sau khi đã xây dựng danh tiếng ở nơi khác—dù họ đã tham gia trong hệ sinh thái rộng lớn bao lâu. Sự khác biệt đáng chú ý không chỉ là “đóng hôm nay so với mở ngày mai” như thể đây chỉ là một ảnh chụp ở giai đoạn sớm. Điều quan trọng là liệu tính “mở” ngay từ đầu có từng là một phần của kiến trúc hay không. Ở đây, mô hình tin cậy được xây dựng dựa trên một tập challenger được tuyển chọn, cố ý giới hạn phạm vi; việc mở rộng chỉ diễn ra thông qua quản trị chứ không phải thông qua lối vào không cần cấp phép—một lựa chọn chứ không phải một giai đoạn. #baby $BABY {future}(BABYUSDT)
@BabylonLabs_io Một điều về cấu trúc của bộ Universal Challenger này khiến tôi thấy hơi phản trực giác sau khi tôi thực sự ngồi xem nó cho đúng.

Tài liệu làm rõ một điều rằng bộ này không được dự tính mở ra cho sự tham gia không cần cấp phép—tức là sự hạn chế là một phần của chính thiết kế chứ không phải là một giới hạn tạm thời chờ thêm thời gian để rồi cuối cùng sẽ nới lỏng.

Ban đầu tôi tưởng đây là lối đi phổ biến mà nhiều hệ thống thường làm: bắt đầu với một nhóm được giới hạn, xây dựng sự tin cậy theo thời gian, rồi dần dần mở rộng sự tham gia khi mạng lưới lớn lên và lòng tin tự tích lũy.

Nhưng mô hình này không vận hành như vậy. Những Universal Challengers mới gia nhập thông qua quản trị, bổ sung các nhà vận hành đã được thẩm định vào sổ đăng ký, chứ không phải thông qua việc bất kỳ ai tự gia nhập sau khi đã xây dựng danh tiếng ở nơi khác—dù họ đã tham gia trong hệ sinh thái rộng lớn bao lâu.

Sự khác biệt đáng chú ý không chỉ là “đóng hôm nay so với mở ngày mai” như thể đây chỉ là một ảnh chụp ở giai đoạn sớm. Điều quan trọng là liệu tính “mở” ngay từ đầu có từng là một phần của kiến trúc hay không. Ở đây, mô hình tin cậy được xây dựng dựa trên một tập challenger được tuyển chọn, cố ý giới hạn phạm vi; việc mở rộng chỉ diễn ra thông qua quản trị chứ không phải thông qua lối vào không cần cấp phép—một lựa chọn chứ không phải một giai đoạn.

#baby
$BABY
·
--
Giảm giá
@babylonlabs_io Đó là con số mà tôi cứ quay lại. Trường OP_RETURN của Bitcoin bị giới hạn ở 80 byte. Không phải 800. Không phải 8.000. Là tám mươi. trong tài liệu cho biết một checkpoint thô của Babylon lớn hơn giới hạn đó. Nó chứa nhiều mảnh dữ liệu theo epoch, một mã băm commit, một bitmap chữ ký và chữ ký tổng hợp. Dữ liệu checkpoint đầy đủ không thể vừa vào một trường OP RETURN duy nhất. Vì vậy nó được chia ra. Hai giao dịch Bitcoin thay vì một cho mỗi checkpoint vĩnh viễn. Tôi cứ ngồi với chỉ riêng con số đó, tách rời khỏi cơ chế mà nó buộc phải thực hiện. 80 byte đủ nhỏ để gần như mọi thứ có ý nghĩa đều bị tràn. Nó không được thiết kế cho checkpoint hay các bằng chứng, hay bất cứ thứ gì Babylon đặc biệt cần. Giới hạn OP_RETURN của Bitcoin tồn tại để giữ dữ liệu on-chain tùy ý đủ nhỏ nhằm ngăn lạm dụng một loại output chỉ từng được định dùng để chứa một ít. Babylon không nhận được 80 byte vì 80 là con số hào phóng. Nó nhận được 80 vì đơn giản là đó là thứ vốn đã tồn tại từ nhiều năm trước, không thể thương lượng khi Babylon xuất hiện và cần chỗ bên trong nó. Ràng buộc của OP RETURN trên Bitcoin là một quy tắc mà Babylon phải làm việc trong phạm vi đó, không phải là một tham số mà nó có thể viết lại. Việc tách checkpoint tồn tại vì dữ liệu phải vừa với một giới hạn đã được định nghĩa từ rất lâu trước khi Babylon cần nó. Đây không phải là một phương án tạm thời chờ giải pháp gọn gàng hơn; đó là kết quả thực tế của việc xây dựng dựa trên một quy tắc Bitcoin cố định. #baby $BABY {future}(BABYUSDT)
@BabylonLabs_io Đó là con số mà tôi cứ quay lại. Trường OP_RETURN của Bitcoin bị giới hạn ở 80 byte.
Không phải 800. Không phải 8.000. Là tám mươi.

trong tài liệu cho biết một checkpoint thô của Babylon lớn hơn giới hạn đó. Nó chứa nhiều mảnh dữ liệu theo epoch, một mã băm commit, một bitmap chữ ký và chữ ký tổng hợp. Dữ liệu checkpoint đầy đủ không thể vừa vào một trường OP RETURN duy nhất.

Vì vậy nó được chia ra. Hai giao dịch Bitcoin thay vì một cho mỗi checkpoint vĩnh viễn.

Tôi cứ ngồi với chỉ riêng con số đó, tách rời khỏi cơ chế mà nó buộc phải thực hiện. 80 byte đủ nhỏ để gần như mọi thứ có ý nghĩa đều bị tràn. Nó không được thiết kế cho checkpoint hay các bằng chứng, hay bất cứ thứ gì Babylon đặc biệt cần. Giới hạn OP_RETURN của Bitcoin tồn tại để giữ dữ liệu on-chain tùy ý đủ nhỏ nhằm ngăn lạm dụng một loại output chỉ từng được định dùng để chứa một ít.

Babylon không nhận được 80 byte vì 80 là con số hào phóng. Nó nhận được 80 vì đơn giản là đó là thứ vốn đã tồn tại từ nhiều năm trước, không thể thương lượng khi Babylon xuất hiện và cần chỗ bên trong nó.

Ràng buộc của OP RETURN trên Bitcoin là một quy tắc mà Babylon phải làm việc trong phạm vi đó, không phải là một tham số mà nó có thể viết lại. Việc tách checkpoint tồn tại vì dữ liệu phải vừa với một giới hạn đã được định nghĩa từ rất lâu trước khi Babylon cần nó. Đây không phải là một phương án tạm thời chờ giải pháp gọn gàng hơn; đó là kết quả thực tế của việc xây dựng dựa trên một quy tắc Bitcoin cố định.

#baby $BABY
·
--
Tăng giá
🟩Buy now
0%
🟦Wait for a pullback
0%
🟨Take profits
0%
🟪Stay away
0%
0 phiếu bầu • Cuộc bỏ phiếu đã kết thúc
@babylonlabs_io Gần như đã chẳng buồn đọc phần chữ nhỏ về tái thế chấp (rehypothecation) trong tài liệu của Trustless Bitcoin Vaults (TBV) hôm nay—tôi đoán chắc nó cũng sẽ là kiểu nói mơ hồ “chúng tôi không làm điều đó”, như gần như mọi giao thức khác vẫn viết. Nhưng không hề mơ hồ. Cụm từ chính xác là “không thể bị tái thế chấp” và có điều gì đó trong cách diễn đạt cụ thể ấy khiến tôi dừng cuộn. Tôi đã thấy đủ nhiều vụ sụp đổ của DeFi được xây dựng trên đúng loại tài sản thế chấp này—âm thầm được tái sử dụng trong hậu trường, tính toán “đếm hơn một lần” cho tới khi nhạc dừng lại, và mọi người nhận ra cùng một Bitcoin đang đứng sau nhiều lời hứa cùng lúc. Cái từ “tái thế chấp” thật sự đã làm hại người ta. Vì vậy tôi đi tìm cơ chế thực sự đằng sau tuyên bố đó, không chỉ dừng lại ở câu chữ. Những gì tôi thấy: trong giao thức không có đường dẫn nào để BTC bị khóa có thể đi tới đâu khác ngoài đúng vị trí mà nó đang hỗ trợ. Không phải là một lựa chọn chính sách mà ai đó có thể lặng lẽ đảo ngược sau này. Đó là một sự thật mang tính cấu trúc về cách vault được xây dựng. Sự khác biệt đó đã làm tôi đọc lại toàn bộ trang theo một cách khác. Một lời hứa có thể “bẻ cong” dưới áp lực. Một bất khả thi mang tính cấu trúc thì không thể—chẳng có chỗ nào khác để BTC đi, dù bất cứ ai ở lớp phía trên có quyết định thế nào. Tôi bước vào với kỳ vọng lời văn khuôn sáo. Tôi rời đi với việc tin vào đúng một câu cụ thể hơn là tôi dự kiến khi bắt đầu. #baby $BABY {future}(BABYUSDT)
@BabylonLabs_io Gần như đã chẳng buồn đọc phần chữ nhỏ về tái thế chấp (rehypothecation) trong tài liệu của Trustless Bitcoin Vaults (TBV) hôm nay—tôi đoán chắc nó cũng sẽ là kiểu nói mơ hồ “chúng tôi không làm điều đó”, như gần như mọi giao thức khác vẫn viết.

Nhưng không hề mơ hồ. Cụm từ chính xác là “không thể bị tái thế chấp” và có điều gì đó trong cách diễn đạt cụ thể ấy khiến tôi dừng cuộn.

Tôi đã thấy đủ nhiều vụ sụp đổ của DeFi được xây dựng trên đúng loại tài sản thế chấp này—âm thầm được tái sử dụng trong hậu trường, tính toán “đếm hơn một lần” cho tới khi nhạc dừng lại, và mọi người nhận ra cùng một Bitcoin đang đứng sau nhiều lời hứa cùng lúc. Cái từ “tái thế chấp” thật sự đã làm hại người ta.

Vì vậy tôi đi tìm cơ chế thực sự đằng sau tuyên bố đó, không chỉ dừng lại ở câu chữ. Những gì tôi thấy: trong giao thức không có đường dẫn nào để BTC bị khóa có thể đi tới đâu khác ngoài đúng vị trí mà nó đang hỗ trợ. Không phải là một lựa chọn chính sách mà ai đó có thể lặng lẽ đảo ngược sau này. Đó là một sự thật mang tính cấu trúc về cách vault được xây dựng.

Sự khác biệt đó đã làm tôi đọc lại toàn bộ trang theo một cách khác. Một lời hứa có thể “bẻ cong” dưới áp lực. Một bất khả thi mang tính cấu trúc thì không thể—chẳng có chỗ nào khác để BTC đi, dù bất cứ ai ở lớp phía trên có quyết định thế nào.

Tôi bước vào với kỳ vọng lời văn khuôn sáo. Tôi rời đi với việc tin vào đúng một câu cụ thể hơn là tôi dự kiến khi bắt đầu.

#baby $BABY
@babylonlabs_io Theo tài liệu vaultBTC hoạt động như một token kế toán nội bộ, không phải thứ được giao dịch, chuyển nhượng hay có thị trường thứ cấp riêng. Sự khác biệt đó trở nên quan trọng hơn khi tôi thực sự ngồi xuống tìm hiểu. Trong hầu hết các hệ thống DeFi, token đại diện mới chính là mục tiêu — nó là thứ được lưu hành, được giao dịch và tạo ra thanh khoản ở nơi khác. vaultBTC trong Trustless Bitcoin Vaults (TBV) không làm điều đó. Nó tồn tại thuần túy để theo dõi trạng thái bên trong một tích hợp cụ thể. Nó chỉ di chuyển giữa các thành phần nội bộ của giao thức, không đi ra thị trường mở, không phải là một tài sản có thể giao dịch tự do để ai đó có thể đầu cơ. Đó là một ràng buộc có chủ đích, không phải một thiếu sót. Một token được thiết kế để không bao giờ rời khỏi hệ thống kế toán của chính nó sẽ loại bỏ hoàn toàn một nhóm rủi ro đi kèm với các token mà thực sự được giao dịch. Một token mà cố tình không thể lưu hành có khiến bạn thay đổi cách bạn nghĩ về ý nghĩa của “rủi ro” đối với nó không? #baby $BABY {future}(BABYUSDT)
@BabylonLabs_io Theo tài liệu vaultBTC hoạt động như một token kế toán nội bộ, không phải thứ được giao dịch, chuyển nhượng hay có thị trường thứ cấp riêng.

Sự khác biệt đó trở nên quan trọng hơn khi tôi thực sự ngồi xuống tìm hiểu. Trong hầu hết các hệ thống DeFi, token đại diện mới chính là mục tiêu — nó là thứ được lưu hành, được giao dịch và tạo ra thanh khoản ở nơi khác. vaultBTC trong Trustless Bitcoin Vaults (TBV) không làm điều đó. Nó tồn tại thuần túy để theo dõi trạng thái bên trong một tích hợp cụ thể.

Nó chỉ di chuyển giữa các thành phần nội bộ của giao thức, không đi ra thị trường mở, không phải là một tài sản có thể giao dịch tự do để ai đó có thể đầu cơ.

Đó là một ràng buộc có chủ đích, không phải một thiếu sót. Một token được thiết kế để không bao giờ rời khỏi hệ thống kế toán của chính nó sẽ loại bỏ hoàn toàn một nhóm rủi ro đi kèm với các token mà thực sự được giao dịch.

Một token mà cố tình không thể lưu hành có khiến bạn thay đổi cách bạn nghĩ về ý nghĩa của “rủi ro” đối với nó không?
#baby $BABY
·
--
Tăng giá
Đã xác minh
@babylonlabs_io Theo tài liệu, nếu một vault hết hạn vì thiết lập off-chain không hoàn tất trong khung kích hoạt thì khoản phí peg cũng được hoàn lại. Chi tiết cụ thể đó đã thay đổi cách tôi đọc cấu trúc phí ở đây. Tôi đã giả định rằng phí peg chỉ đơn giản là chi phí để thử kích hoạt, có hoàn lại hay không tùy thuộc vào kết quả, theo cách mà hầu hết các loại phí vào cổng khác hoạt động. Nhưng nó không được cấu trúc như vậy. Phí này được gắn với việc kích hoạt thành công, chứ không gắn với chính hành động thử kích hoạt. Việc thiết lập thất bại mà không phải do lỗi của người gửi tiền sẽ không khiến họ phải trả tiền cho thứ thực tế đã không diễn ra. Điều tôi chưa cân nhắc là điều này chỉ đề cập đến việc hoàn phí chứ không phải thời gian chờ đợi trong quá trình thiết lập bị đình trệ. Hai chi phí thực sự khác nhau và chỉ một trong số đó có lộ trình khôi phục được ghi nhận. Việc được hoàn lại phí như vậy có làm thay đổi mức rủi ro mà bạn sẽ gắn với một lần kích hoạt không thành công không, hay việc mất thời gian quan trọng hơn đối với bạn theo cách nào đó? #baby $BABY {future}(BABYUSDT)
@BabylonLabs_io Theo tài liệu, nếu một vault hết hạn vì thiết lập off-chain không hoàn tất trong khung kích hoạt thì khoản phí peg cũng được hoàn lại.

Chi tiết cụ thể đó đã thay đổi cách tôi đọc cấu trúc phí ở đây. Tôi đã giả định rằng phí peg chỉ đơn giản là chi phí để thử kích hoạt, có hoàn lại hay không tùy thuộc vào kết quả, theo cách mà hầu hết các loại phí vào cổng khác hoạt động.

Nhưng nó không được cấu trúc như vậy. Phí này được gắn với việc kích hoạt thành công, chứ không gắn với chính hành động thử kích hoạt. Việc thiết lập thất bại mà không phải do lỗi của người gửi tiền sẽ không khiến họ phải trả tiền cho thứ thực tế đã không diễn ra.

Điều tôi chưa cân nhắc là điều này chỉ đề cập đến việc hoàn phí chứ không phải thời gian chờ đợi trong quá trình thiết lập bị đình trệ. Hai chi phí thực sự khác nhau và chỉ một trong số đó có lộ trình khôi phục được ghi nhận.

Việc được hoàn lại phí như vậy có làm thay đổi mức rủi ro mà bạn sẽ gắn với một lần kích hoạt không thành công không, hay việc mất thời gian quan trọng hơn đối với bạn theo cách nào đó?

#baby $BABY
·
--
Tăng giá
@babylonlabs_io Theo tài liệu về mô hình niềm tin của Trustless Bitcoin Vaults (TBV), phần niềm tin còn dư—những phần không bị loại bỏ hoàn toàn—rơi vào hai nhóm: quản trị và ứng phó khẩn cấp; các multisig. Trước khi đọc phần này, tôi đã coi “trustless” gần như là tuyệt đối. Nhưng không phải vậy. “Trustless” là cho cơ chế vận hành hằng ngày, với hai ngoại lệ hẹp được nêu tên rõ ràng đứng phía sau. Các multisig quản trị xử lý những thay đổi tham số ở cấp độ giao thức—những loại quyết định cần một thẩm quyền phối hợp thì mới có thể tồn tại. Các multisig ứng phó khẩn cấp là phương án dự phòng cho các tình huống thực sự thảm họa—thuộc phạm vi cụ thể của Hội đồng Bảo an. Điều tôi thấy đáng để cân nhắc, khi gọi tên rõ ràng hai nhóm này, là sự trung thực hơn so với hầu hết các hệ thống khác: chúng âm thầm có các điểm niềm tin còn dư tương tự nhưng không bao giờ gắn nhãn chúng. Việc nêu rõ các ngoại lệ có làm cho tuyên bố “trustless” tổng thể của bạn cảm thấy thuyết phục hơn không, hay nó chỉ đơn giản là dời chỗ để đặt nghi ngờ? #baby $BABY {future}(BABYUSDT)
@BabylonLabs_io Theo tài liệu về mô hình niềm tin của Trustless Bitcoin Vaults (TBV), phần niềm tin còn dư—những phần không bị loại bỏ hoàn toàn—rơi vào hai nhóm: quản trị và ứng phó khẩn cấp; các multisig.

Trước khi đọc phần này, tôi đã coi “trustless” gần như là tuyệt đối. Nhưng không phải vậy. “Trustless” là cho cơ chế vận hành hằng ngày, với hai ngoại lệ hẹp được nêu tên rõ ràng đứng phía sau.

Các multisig quản trị xử lý những thay đổi tham số ở cấp độ giao thức—những loại quyết định cần một thẩm quyền phối hợp thì mới có thể tồn tại. Các multisig ứng phó khẩn cấp là phương án dự phòng cho các tình huống thực sự thảm họa—thuộc phạm vi cụ thể của Hội đồng Bảo an.

Điều tôi thấy đáng để cân nhắc, khi gọi tên rõ ràng hai nhóm này, là sự trung thực hơn so với hầu hết các hệ thống khác: chúng âm thầm có các điểm niềm tin còn dư tương tự nhưng không bao giờ gắn nhãn chúng.

Việc nêu rõ các ngoại lệ có làm cho tuyên bố “trustless” tổng thể của bạn cảm thấy thuyết phục hơn không, hay nó chỉ đơn giản là dời chỗ để đặt nghi ngờ?
#baby $BABY
·
--
Tăng giá
🚨 Tín hiệu giao dịch ESPUSDT Giá vào: Giá thị trường hiện tại 🎯 TP: +8% đến +12% 🛑 SL: -4% Động lượng đang tăng dần và bên mua bắt đầu tham gia. Quản lý rủi ro là ưu tiên hàng đầu—luôn tuân thủ mức cắt lỗ và không bao giờ sử dụng đòn bẩy quá mức. Ai tham gia setup này với mình? #BinanceSquareTalks #CryptoTrading. #FutureTarding $ESP $EPIC
🚨 Tín hiệu giao dịch ESPUSDT

Giá vào: Giá thị trường hiện tại
🎯 TP: +8% đến +12%
🛑 SL: -4%

Động lượng đang tăng dần và bên mua bắt đầu tham gia. Quản lý rủi ro là ưu tiên hàng đầu—luôn tuân thủ mức cắt lỗ và không bao giờ sử dụng đòn bẩy quá mức.

Ai tham gia setup này với mình?

#BinanceSquareTalks #CryptoTrading. #FutureTarding
$ESP
$EPIC
·
--
Tăng giá
@babylonlabs_io Theo chính bộ tài liệu của Babylon, các chức năng cốt lõi của BABY có thể quy về ba điều: quản trị và bảo mật bằng gas—token dùng để thực hiện giao dịch quyết định các tham số và đảm bảo lớp đặt cược (staking) của mạng—tất cả gói gọn trong một. Tôi đã vô thức xếp chúng vào cùng một nhãn mơ hồ là tiện ích (utility) mà không tách bạch đúng cách. Thực ra chúng là những công việc hoàn toàn khác nhau. Gas là khoản phí cho các giao dịch trên mạng. Governance là chức năng bỏ phiếu để quyết định giao thức sẽ làm gì tiếp theo. Security là chức năng staking: BABY bị khóa và chịu rủi ro để giúp bảo vệ chuỗi—cùng lớp kinh tế rộng hơn mà Trustless Bitcoin Vaults (TBV) đứng song song. Một người nắm giữ chỉ để staking lấy lợi suất bảo mật sẽ có mối quan hệ với BABY khác với người trả gas hoặc người bỏ phiếu theo các đề xuất. Cùng một token. Ba loại phơi nhiễm (exposure) khác nhau, ba lý do riêng biệt khiến ai đó có thể thực sự đang nắm giữ nó. Tôi vẫn chưa tìm được phần phân rã cho thấy hoạt động hiện tại phân bổ bao nhiêu trong từng hạng mục so với những hạng mục còn lại. #baby $BABY {future}(BABYUSDT)
@BabylonLabs_io Theo chính bộ tài liệu của Babylon, các chức năng cốt lõi của BABY có thể quy về ba điều: quản trị và bảo mật bằng gas—token dùng để thực hiện giao dịch quyết định các tham số và đảm bảo lớp đặt cược (staking) của mạng—tất cả gói gọn trong một.

Tôi đã vô thức xếp chúng vào cùng một nhãn mơ hồ là tiện ích (utility) mà không tách bạch đúng cách. Thực ra chúng là những công việc hoàn toàn khác nhau.

Gas là khoản phí cho các giao dịch trên mạng. Governance là chức năng bỏ phiếu để quyết định giao thức sẽ làm gì tiếp theo. Security là chức năng staking: BABY bị khóa và chịu rủi ro để giúp bảo vệ chuỗi—cùng lớp kinh tế rộng hơn mà Trustless Bitcoin Vaults (TBV) đứng song song.

Một người nắm giữ chỉ để staking lấy lợi suất bảo mật sẽ có mối quan hệ với BABY khác với người trả gas hoặc người bỏ phiếu theo các đề xuất. Cùng một token. Ba loại phơi nhiễm (exposure) khác nhau, ba lý do riêng biệt khiến ai đó có thể thực sự đang nắm giữ nó.

Tôi vẫn chưa tìm được phần phân rã cho thấy hoạt động hiện tại phân bổ bao nhiêu trong từng hạng mục so với những hạng mục còn lại.

#baby $BABY
·
--
Tăng giá
COTIUSDT Cập nhật TP/SL Thiết lập COTIUSDT long đã diễn ra đúng như kế hoạch. Lệnh tuân thủ vùng vào lệnh, đạt đến mục tiêu và đóng với mức lợi nhuận +59,37% khi sử dụng đòn bẩy 10x. Chi tiết giao dịch Vào lệnh: 0.0131978 Thoát lệnh: 0.0139935 Kết quả: +59,37% Hướng: Long Đạt TP ✅ Một lời nhắc tốt rằng kỷ luật quan trọng hơn việc cố bám theo mọi biến động. Hãy vào lệnh với một kế hoạch: xác định Take Profit (TP) và Stop Loss (SL) trước khi mở lệnh và để quản lý rủi ro làm việc đó. Không phải mọi giao dịch đều là một chiến thắng, nhưng sự nhất quán đến từ việc bám sát chiến lược chứ không phải cảm xúc. $COTI $UAI $PTB #BinanceFutures #CryptoTrading. #RiskManagement
COTIUSDT Cập nhật TP/SL

Thiết lập COTIUSDT long đã diễn ra đúng như kế hoạch. Lệnh tuân thủ vùng vào lệnh, đạt đến mục tiêu và đóng với mức lợi nhuận +59,37% khi sử dụng đòn bẩy 10x.

Chi tiết giao dịch
Vào lệnh: 0.0131978
Thoát lệnh: 0.0139935
Kết quả: +59,37%
Hướng: Long
Đạt TP ✅

Một lời nhắc tốt rằng kỷ luật quan trọng hơn việc cố bám theo mọi biến động. Hãy vào lệnh với một kế hoạch: xác định Take Profit (TP) và Stop Loss (SL) trước khi mở lệnh và để quản lý rủi ro làm việc đó.

Không phải mọi giao dịch đều là một chiến thắng, nhưng sự nhất quán đến từ việc bám sát chiến lược chứ không phải cảm xúc.

$COTI $UAI $PTB
#BinanceFutures #CryptoTrading. #RiskManagement
Đã xác minh
@babylonlabs_io Theo tài liệu tích hợp ví riêng của Babylon, nếu một người nắm giữ BABY không thực hiện bất kỳ hành động nào đối với một đề xuất, quyền biểu quyết của bạn sẽ tự động được ủy quyền cho trình xác thực (validator) của bạn. Các quyết định được đưa ra tại đây cũng lan sang môi trường của Trustless Bitcoin Vaults (TBV). Vì vậy, “không bỏ phiếu” không phải là một chi tiết phụ. Không bỏ phiếu không có nghĩa là giữ thái độ trung lập. Người khác sẽ bỏ phiếu thay bạn. Dựa trên sự đánh giá của họ. Không phải của bạn. Một người nắm giữ không đồng ý với validator của họ nhưng lại không có thời gian để bỏ phiếu thì không bảo vệ được vị thế của mình bằng cách im lặng. Sự im lặng trao quyết định cho sự cân nhắc của người khác. Đây là mẫu quản trị dân chủ lỏng (liquid democracy) chuẩn trên các chuỗi Cosmos, được thiết kế để đảm bảo đạt được ngưỡng cần thiết (quorum). Phần dưới đây làm điều đó trở nên sắc nét hơn. Một người nắm giữ có thể ghi đè phiếu bầu mặc định của validator, nhưng chỉ bằng cách bỏ phiếu trước khi thời hạn kết thúc. Với một đề xuất khẩn cấp có khung thời gian chỉ là một ngày, khả năng ghi đè đó có thể đóng lại trước khi ai đó kịp kiểm tra — ngay cả khi họ thỉnh thoảng vẫn theo dõi. Một khoảng thời gian ghi đè bị thu hẹp sẽ khiến bạn cân nhắc kiểm tra nghiêm túc hơn không? #baby $BABY {future}(BABYUSDT)
@BabylonLabs_io Theo tài liệu tích hợp ví riêng của Babylon, nếu một người nắm giữ BABY không thực hiện bất kỳ hành động nào đối với một đề xuất, quyền biểu quyết của bạn sẽ tự động được ủy quyền cho trình xác thực (validator) của bạn.

Các quyết định được đưa ra tại đây cũng lan sang môi trường của Trustless Bitcoin Vaults (TBV). Vì vậy, “không bỏ phiếu” không phải là một chi tiết phụ.

Không bỏ phiếu không có nghĩa là giữ thái độ trung lập. Người khác sẽ bỏ phiếu thay bạn. Dựa trên sự đánh giá của họ. Không phải của bạn.

Một người nắm giữ không đồng ý với validator của họ nhưng lại không có thời gian để bỏ phiếu thì không bảo vệ được vị thế của mình bằng cách im lặng. Sự im lặng trao quyết định cho sự cân nhắc của người khác.

Đây là mẫu quản trị dân chủ lỏng (liquid democracy) chuẩn trên các chuỗi Cosmos, được thiết kế để đảm bảo đạt được ngưỡng cần thiết (quorum).

Phần dưới đây làm điều đó trở nên sắc nét hơn. Một người nắm giữ có thể ghi đè phiếu bầu mặc định của validator, nhưng chỉ bằng cách bỏ phiếu trước khi thời hạn kết thúc. Với một đề xuất khẩn cấp có khung thời gian chỉ là một ngày, khả năng ghi đè đó có thể đóng lại trước khi ai đó kịp kiểm tra — ngay cả khi họ thỉnh thoảng vẫn theo dõi.

Một khoảng thời gian ghi đè bị thu hẹp sẽ khiến bạn cân nhắc kiểm tra nghiêm túc hơn không?

#baby $BABY
·
--
Giảm giá
Đúng một phần
@babylonlabs_io Theo chính tài liệu của Babylon Cơ chế thanh toán công bằng của Trustless Bitcoin Vaults (TBV) trong quá trình thanh lý cung cấp hai lộ trình thanh toán khác nhau và tôi muốn thực sự hiểu điều gì quyết định lộ trình nào được áp dụng thay vì coi đó là một quy trình không phân biệt. Lộ trình thứ nhất là thanh toán trực tiếp nợ: bên thanh lý sẽ trả những gì người vay còn nợ và như vậy sẽ hoàn tất vị thế. Lộ trình thứ hai là thanh toán cho bên thanh lý bằng WBTC. Tôi đã quay lại và thực sự tìm thấy logic kích hoạt mà tôi đã bỏ sót lần đầu. Theo tài liệu, điều này phụ thuộc vào việc thanh lý một phần hay thanh lý toàn bộ. Trong trường hợp phổ biến là thanh lý một phần, mọi phần dư sẽ được hoàn trả dưới dạng thanh toán thêm nợ. Trong trường hợp thanh lý toàn bộ, cụ thể là khi toàn bộ khoản nợ còn tồn đọng đã được chính hoạt động thanh lý chi trả đầy đủ, thì WBTC sẽ được dùng cho phần thanh toán còn lại. Điều này thực sự giải quyết câu hỏi mà trước đó tôi cảm thấy còn bỏ ngỏ. Không phải là hai lộ trình tùy ý được chọn một cách khó đoán, mà là một sự tách nhánh khá rõ ràng dựa trên việc đến thời điểm hoàn tất thanh lý thì vẫn còn nợ cần được bù hay nợ đã được tính toán đầy đủ. Những gì tôi chưa cân nhắc trước đây là việc này có nghĩa là phần lớn các đợt thanh lý là thanh lý một phần thay vì thanh lý toàn bộ, nên thường sẽ được giải quyết thông qua cách trả nợ đơn giản, còn WBTC là trường hợp ngoại lệ thay vì là một lựa chọn thay thế có mức độ phổ biến tương đương. Việc biết logic kích hoạt có tính hệ thống như vậy liệu có làm bạn cân nhắc thay đổi trọng lượng bạn đặt vào lập luận về tính công bằng ở đây không? #baby $BABY {future}(BABYUSDT)
@BabylonLabs_io Theo chính tài liệu của Babylon Cơ chế thanh toán công bằng của Trustless Bitcoin Vaults (TBV) trong quá trình thanh lý cung cấp hai lộ trình thanh toán khác nhau và tôi muốn thực sự hiểu điều gì quyết định lộ trình nào được áp dụng thay vì coi đó là một quy trình không phân biệt.

Lộ trình thứ nhất là thanh toán trực tiếp nợ: bên thanh lý sẽ trả những gì người vay còn nợ và như vậy sẽ hoàn tất vị thế. Lộ trình thứ hai là thanh toán cho bên thanh lý bằng WBTC.

Tôi đã quay lại và thực sự tìm thấy logic kích hoạt mà tôi đã bỏ sót lần đầu. Theo tài liệu, điều này phụ thuộc vào việc thanh lý một phần hay thanh lý toàn bộ. Trong trường hợp phổ biến là thanh lý một phần, mọi phần dư sẽ được hoàn trả dưới dạng thanh toán thêm nợ.

Trong trường hợp thanh lý toàn bộ, cụ thể là khi toàn bộ khoản nợ còn tồn đọng đã được chính hoạt động thanh lý chi trả đầy đủ, thì WBTC sẽ được dùng cho phần thanh toán còn lại.

Điều này thực sự giải quyết câu hỏi mà trước đó tôi cảm thấy còn bỏ ngỏ. Không phải là hai lộ trình tùy ý được chọn một cách khó đoán, mà là một sự tách nhánh khá rõ ràng dựa trên việc đến thời điểm hoàn tất thanh lý thì vẫn còn nợ cần được bù hay nợ đã được tính toán đầy đủ.

Những gì tôi chưa cân nhắc trước đây là việc này có nghĩa là phần lớn các đợt thanh lý là thanh lý một phần thay vì thanh lý toàn bộ, nên thường sẽ được giải quyết thông qua cách trả nợ đơn giản, còn WBTC là trường hợp ngoại lệ thay vì là một lựa chọn thay thế có mức độ phổ biến tương đương. Việc biết logic kích hoạt có tính hệ thống như vậy liệu có làm bạn cân nhắc thay đổi trọng lượng bạn đặt vào lập luận về tính công bằng ở đây không?

#baby $BABY
·
--
Tăng giá
Đã xác minh
@babylonlabs_io Trustless là lợi ích mà tôi tiếp tục thử nghiệm đối chiếu với các phần khác nhau về cách Trustless Bitcoin Vaults (TBV) thực sự tự theo dõi, và phần mà tôi tìm hiểu hôm nay lại được lấy trực tiếp từ tài liệu nội bộ của Babylon về Vigilante Checkpointing Monitor—một tiến trình nền mà có lẽ hầu như chẳng ai nghĩ tới. Theo tài liệu đó, trình giám sát liên tục kiểm tra hai thứ riêng biệt. Thứ nhất là liệu bản ghi nội bộ của Babylon về chuỗi Bitcoin có thực sự khớp với những gì đang diễn ra trên Bitcoin hay không (kiểm tra tính nhất quán). Thứ hai là liệu dữ liệu checkpoint hợp lệ có được báo cáo kịp thời hay không—được tài liệu mô tả như một bài kiểm tra “liveness”, khác với việc chỉ kiểm tra tính đúng đắn. Việc kiểm tra thứ hai lại quan trọng vì một hệ thống về mặt kỹ thuật có thể có dữ liệu đúng nhưng vẫn khiến bạn thất bại thông qua độ trễ. Nếu một điều đúng bị giữ lại đủ lâu thì nó hoạt động gần như tương đương với việc bị che giấu hoàn toàn. Tôi nói thật là một trình giám sát như vậy, theo cách mà nó được mô tả trong tài liệu, sẽ phát hiện vấn đề sau khi vấn đề đã bắt đầu xảy ra chứ không phải trước đó. Đó là phát hiện chứ không phải phòng ngừa, và việc phát hiện chỉ hiệu quả khi nó thực sự đang chạy và ai đó đang chú ý khi nó gắn cờ cảnh báo. Trustless không có nghĩa là không thể xảy ra sai sót. Theo cách Babylon tự diễn đạt, điều đó có nghĩa là khi có chuyện xảy ra, sẽ có một cách được ghi nhận để nó trở nên hiển thị. Biết rằng đằng sau hệ thống có giám sát chủ động được ghi tài liệu như vậy có làm thay đổi mức độ xác minh độc lập mà bạn vẫn muốn tự làm không? #baby $BABY {future}(BABYUSDT)
@BabylonLabs_io Trustless là lợi ích mà tôi tiếp tục thử nghiệm đối chiếu với các phần khác nhau về cách Trustless Bitcoin Vaults (TBV) thực sự tự theo dõi, và phần mà tôi tìm hiểu hôm nay lại được lấy trực tiếp từ tài liệu nội bộ của Babylon về Vigilante Checkpointing Monitor—một tiến trình nền mà có lẽ hầu như chẳng ai nghĩ tới.

Theo tài liệu đó, trình giám sát liên tục kiểm tra hai thứ riêng biệt. Thứ nhất là liệu bản ghi nội bộ của Babylon về chuỗi Bitcoin có thực sự khớp với những gì đang diễn ra trên Bitcoin hay không (kiểm tra tính nhất quán). Thứ hai là liệu dữ liệu checkpoint hợp lệ có được báo cáo kịp thời hay không—được tài liệu mô tả như một bài kiểm tra “liveness”, khác với việc chỉ kiểm tra tính đúng đắn.

Việc kiểm tra thứ hai lại quan trọng vì một hệ thống về mặt kỹ thuật có thể có dữ liệu đúng nhưng vẫn khiến bạn thất bại thông qua độ trễ. Nếu một điều đúng bị giữ lại đủ lâu thì nó hoạt động gần như tương đương với việc bị che giấu hoàn toàn.

Tôi nói thật là một trình giám sát như vậy, theo cách mà nó được mô tả trong tài liệu, sẽ phát hiện vấn đề sau khi vấn đề đã bắt đầu xảy ra chứ không phải trước đó. Đó là phát hiện chứ không phải phòng ngừa, và việc phát hiện chỉ hiệu quả khi nó thực sự đang chạy và ai đó đang chú ý khi nó gắn cờ cảnh báo.

Trustless không có nghĩa là không thể xảy ra sai sót. Theo cách Babylon tự diễn đạt, điều đó có nghĩa là khi có chuyện xảy ra, sẽ có một cách được ghi nhận để nó trở nên hiển thị. Biết rằng đằng sau hệ thống có giám sát chủ động được ghi tài liệu như vậy có làm thay đổi mức độ xác minh độc lập mà bạn vẫn muốn tự làm không?

#baby $BABY
·
--
Tăng giá
@babylonlabs_io Tự lưu trữ là lợi ích mà tôi cứ quay lại mỗi khi nghĩ về việc Trustless Bitcoin Vaults (TBV) thực sự đang cung cấp: bạn có khóa của bạn, Bitcoin của bạn, trong suốt thời gian—không có ngoại lệ nào được giấu đâu đó trong phần chữ nhỏ. Điều khiến tôi tin vào tuyên bố đó thay vì chỉ đơn giản chấp nhận, là việc hiểu một chút về những gì đang diễn ra bên dưới nó, dựa trên cách tài liệu chính thức của Babylon mô tả thiết kế. Bitcoin dùng làm đảm bảo cho một vị thế vẫn ở ngay trên mạng Bitcoin; nó không bao giờ được bàn giao cho một bên lưu ký, không bao giờ được gộp chung với quỹ của người khác, và cũng không bao giờ được bọc dưới một dạng biểu diễn riêng biệt trên một chuỗi khác. Các quy tắc quy định khi nào và bằng cách nào nó có thể di chuyển đều được ký trước và được thực thi thông qua các bằng chứng mật mã, thay vì dựa vào sự tùy ý của một bên. Sự khác biệt đó quan trọng vô cùng đối với tôi. Không phải là có một bên thứ ba đứng ra để được “tin cậy” là sẽ hành xử trung thực. Mà là các điều kiện chi tiêu đã được cố định bằng mật mã ngay từ đầu. Tôi nói thẳng nhé: tự lưu trữ giúp bảo vệ Bitcoin khỏi một bên lưu ký. Nó không bảo vệ bất cứ ai khỏi việc mất chính khóa của mình, hoặc khỏi lỗi trong phần mềm—vẫn đang được gắn nhãn beta. Đây là những rủi ro khác nhau, và tôi không nghĩ phần “bốn lợi ích” thể hiện luôn làm rõ đủ sự khác biệt đó. Hiện testnet công khai đã hoạt động; nếu bạn muốn tự mình chứng kiến điều này, bạn có thể xem trực tiếp. Nếu bạn biết chính xác cơ chế này, nó có làm bạn cảm thấy thoải mái hơn với tuyên bố tự lưu trữ không, hay kết quả quan trọng hơn với bạn so với cách thức? #baby $BABY {future}(BABYUSDT)
@BabylonLabs_io Tự lưu trữ là lợi ích mà tôi cứ quay lại mỗi khi nghĩ về việc Trustless Bitcoin Vaults (TBV) thực sự đang cung cấp: bạn có khóa của bạn, Bitcoin của bạn, trong suốt thời gian—không có ngoại lệ nào được giấu đâu đó trong phần chữ nhỏ.

Điều khiến tôi tin vào tuyên bố đó thay vì chỉ đơn giản chấp nhận, là việc hiểu một chút về những gì đang diễn ra bên dưới nó, dựa trên cách tài liệu chính thức của Babylon mô tả thiết kế.

Bitcoin dùng làm đảm bảo cho một vị thế vẫn ở ngay trên mạng Bitcoin; nó không bao giờ được bàn giao cho một bên lưu ký, không bao giờ được gộp chung với quỹ của người khác, và cũng không bao giờ được bọc dưới một dạng biểu diễn riêng biệt trên một chuỗi khác.

Các quy tắc quy định khi nào và bằng cách nào nó có thể di chuyển đều được ký trước và được thực thi thông qua các bằng chứng mật mã, thay vì dựa vào sự tùy ý của một bên.

Sự khác biệt đó quan trọng vô cùng đối với tôi. Không phải là có một bên thứ ba đứng ra để được “tin cậy” là sẽ hành xử trung thực. Mà là các điều kiện chi tiêu đã được cố định bằng mật mã ngay từ đầu.

Tôi nói thẳng nhé: tự lưu trữ giúp bảo vệ Bitcoin khỏi một bên lưu ký. Nó không bảo vệ bất cứ ai khỏi việc mất chính khóa của mình, hoặc khỏi lỗi trong phần mềm—vẫn đang được gắn nhãn beta. Đây là những rủi ro khác nhau, và tôi không nghĩ phần “bốn lợi ích” thể hiện luôn làm rõ đủ sự khác biệt đó.

Hiện testnet công khai đã hoạt động; nếu bạn muốn tự mình chứng kiến điều này, bạn có thể xem trực tiếp. Nếu bạn biết chính xác cơ chế này, nó có làm bạn cảm thấy thoải mái hơn với tuyên bố tự lưu trữ không, hay kết quả quan trọng hơn với bạn so với cách thức?

#baby $BABY
🔹 CAP
100%
🔹 BSB
0%
🔹 ON
0%
1 phiếu bầu • Cuộc bỏ phiếu đã kết thúc
·
--
Giảm giá
@babylonlabs_io Có một chi tiết trong cách Trustless Bitcoin Vaults (TBV) xử lý quyết toán thanh lý mà tôi thấy thật sự được suy nghĩ kỹ về cơ chế thanh toán công bằng. Khi một vị thế bị thanh lý, sẽ có hai điều khác nhau có thể xảy ra để đảm bảo người cho vay được hoàn trả: khoản nợ còn lại của người đi vay được thanh toán trực tiếp hoặc bên thanh lý nhận một khoản chi trả dưới dạng biểu diễn Bitcoin được bọc (wrapped Bitcoin). Con đường nào thực sự áp dụng phụ thuộc vào hoàn cảnh thanh lý cụ thể. Điểm nổi bật với tôi là từ “công bằng” gắn với cơ chế này. Nó gợi ý rằng cấu trúc thanh toán được thiết kế với mục tiêu đảm bảo không bên gửi tiền hay bên thanh lý nào bị lợi thế một cách không công bằng chỉ vì con đường quyết toán nào được kích hoạt trong trường hợp cụ thể của họ. Một sự thanh lý được giải quyết thông qua việc hoàn trả nợ trực tiếp sẽ không nên khiến ai đó bị thiệt hại một cách đáng kể hơn so với trường hợp được giải quyết thông qua khoản chi trả bằng WBTC, với mọi yếu tố khác là như nhau. Thành thật mà nói, tôi thấy mức độ chú ý này thực sự khiến tôi yên tâm. Cơ chế thanh lý là một trong những nơi mà những sơ suất thiết kế nhỏ có xu hướng tạo ra sự bất công có thể định lượng được đối với một ai đó, và có vẻ chi tiết cụ thể này đã được cân nhắc kỹ lưỡng thay vì bị xem như một ý tưởng phát sinh sau khi đã thiết kế luồng chính. Testnet công khai đang hoạt động nếu bạn muốn xem cơ chế công bằng này thực sự diễn ra như thế nào trong một kịch bản thanh lý mô phỏng. #baby $BABY {future}(BABYUSDT)
@BabylonLabs_io Có một chi tiết trong cách Trustless Bitcoin Vaults (TBV) xử lý quyết toán thanh lý mà tôi thấy thật sự được suy nghĩ kỹ về cơ chế thanh toán công bằng.

Khi một vị thế bị thanh lý, sẽ có hai điều khác nhau có thể xảy ra để đảm bảo người cho vay được hoàn trả: khoản nợ còn lại của người đi vay được thanh toán trực tiếp hoặc bên thanh lý nhận một khoản chi trả dưới dạng biểu diễn Bitcoin được bọc (wrapped Bitcoin). Con đường nào thực sự áp dụng phụ thuộc vào hoàn cảnh thanh lý cụ thể.

Điểm nổi bật với tôi là từ “công bằng” gắn với cơ chế này. Nó gợi ý rằng cấu trúc thanh toán được thiết kế với mục tiêu đảm bảo không bên gửi tiền hay bên thanh lý nào bị lợi thế một cách không công bằng chỉ vì con đường quyết toán nào được kích hoạt trong trường hợp cụ thể của họ. Một sự thanh lý được giải quyết thông qua việc hoàn trả nợ trực tiếp sẽ không nên khiến ai đó bị thiệt hại một cách đáng kể hơn so với trường hợp được giải quyết thông qua khoản chi trả bằng WBTC, với mọi yếu tố khác là như nhau.

Thành thật mà nói, tôi thấy mức độ chú ý này thực sự khiến tôi yên tâm. Cơ chế thanh lý là một trong những nơi mà những sơ suất thiết kế nhỏ có xu hướng tạo ra sự bất công có thể định lượng được đối với một ai đó, và có vẻ chi tiết cụ thể này đã được cân nhắc kỹ lưỡng thay vì bị xem như một ý tưởng phát sinh sau khi đã thiết kế luồng chính.

Testnet công khai đang hoạt động nếu bạn muốn xem cơ chế công bằng này thực sự diễn ra như thế nào trong một kịch bản thanh lý mô phỏng.

#baby $BABY
·
--
Tăng giá
Ý tưởng giao dịch DEXE/USDT 📈 DEXE đang cho thấy dấu hiệu mạnh lên và có thể tạo ra cơ hội giao dịch ngắn hạn nếu đà tiếp tục. 🎯 Chốt lời (TP): • TP1: +5% • TP2: +10% • TP3: +15% 🛑 Cắt lỗ (SL): • -3% dưới giá vào của bạn hoặc dưới mức hỗ trợ gần nhất. Quản lý rủi ro cũng quan trọng như việc tìm đúng điểm vào lệnh. Hãy chờ xác nhận, bám sát kế hoạch giao dịch của bạn và tránh các quyết định theo cảm xúc. $DEXE {future}(DEXEUSDT) #dexe #cryptotrading #BinanceSquare #dyor
Ý tưởng giao dịch DEXE/USDT 📈
DEXE đang cho thấy dấu hiệu mạnh lên và có thể tạo ra cơ hội giao dịch ngắn hạn nếu đà tiếp tục.
🎯 Chốt lời (TP):
• TP1: +5%
• TP2: +10%
• TP3: +15%
🛑 Cắt lỗ (SL):
• -3% dưới giá vào của bạn hoặc dưới mức hỗ trợ gần nhất.
Quản lý rủi ro cũng quan trọng như việc tìm đúng điểm vào lệnh. Hãy chờ xác nhận, bám sát kế hoạch giao dịch của bạn và tránh các quyết định theo cảm xúc.
$DEXE
#dexe #cryptotrading #BinanceSquare #dyor
·
--
Tăng giá
@babylonlabs_io Có một cơ chế trong các Kho Vàng Bitcoin Không Cần Tin (Trustless Bitcoin Vaults - TBV) giải quyết một hạn chế mà tôi chưa thực sự cân nhắc kỹ cho đến khi đọc trực tiếp về nó, đó là thực tế rằng một kho vàng là không thể chia nhỏ. Một kho vàng là một đầu ra (output) Bitcoin. Bạn không thể thanh lý một phần 10% của nó theo cách mà tài sản thế chấp gộp (pooled collateral) trong DeFi truyền thống có thể được thanh lý từng phần. Mặc định thì “tất cả hoặc không gì cả”, điều này tạo ra một bài toán thanh lý khó hơn một cách đáng kể so với hầu hết các giao thức cho vay. Biện pháp giảm thiểu được ghi nhận là chiến lược hai kho vàng. Người gửi tách BTC thế chấp của họ ra hai kho vàng riêng thay vì chỉ dùng một kho vàng: một kho vàng nhỏ hơn đóng vai trò hi sinh và một kho vàng lớn hơn được bảo vệ. Nếu giá biến động bất lợi cho vị thế, kho vàng hi sinh được thiết kế để hấp thụ sự kiện thanh lý đầu tiên. Kho vàng được bảo vệ chỉ bị đụng tới nếu giá tiếp tục đi xa hơn qua điểm mà chỉ riêng kho vàng hi sinh là đủ để khôi phục hệ số sức khỏe (health factor) an toàn. Điều tôi thấy thực sự “đáng nghĩ ngợi” ở đây là nó không phải đang giải quyết tính không thể chia nhỏ ở cấp độ giao thức. Thay vào đó, nó cung cấp cho người gửi một công cụ để tự tái tạo điều gì đó giống như thanh lý một phần thông qua cách họ cấu trúc thế chấp của chính mình, mà không cần giao thức nền tảng phải hỗ trợ việc chi tiêu một phần của bất kỳ kho vàng đơn lẻ nào. Testnet công khai đã hoạt động nếu bạn muốn thực sự xem cách tiếp cận hai kho vàng này hoạt động khi có một biến động giá được mô phỏng. #baby $BABY
@BabylonLabs_io Có một cơ chế trong các Kho Vàng Bitcoin Không Cần Tin (Trustless Bitcoin Vaults - TBV) giải quyết một hạn chế mà tôi chưa thực sự cân nhắc kỹ cho đến khi đọc trực tiếp về nó, đó là thực tế rằng một kho vàng là không thể chia nhỏ.

Một kho vàng là một đầu ra (output) Bitcoin. Bạn không thể thanh lý một phần 10% của nó theo cách mà tài sản thế chấp gộp (pooled collateral) trong DeFi truyền thống có thể được thanh lý từng phần. Mặc định thì “tất cả hoặc không gì cả”, điều này tạo ra một bài toán thanh lý khó hơn một cách đáng kể so với hầu hết các giao thức cho vay.

Biện pháp giảm thiểu được ghi nhận là chiến lược hai kho vàng. Người gửi tách BTC thế chấp của họ ra hai kho vàng riêng thay vì chỉ dùng một kho vàng: một kho vàng nhỏ hơn đóng vai trò hi sinh và một kho vàng lớn hơn được bảo vệ.

Nếu giá biến động bất lợi cho vị thế, kho vàng hi sinh được thiết kế để hấp thụ sự kiện thanh lý đầu tiên. Kho vàng được bảo vệ chỉ bị đụng tới nếu giá tiếp tục đi xa hơn qua điểm mà chỉ riêng kho vàng hi sinh là đủ để khôi phục hệ số sức khỏe (health factor) an toàn.

Điều tôi thấy thực sự “đáng nghĩ ngợi” ở đây là nó không phải đang giải quyết tính không thể chia nhỏ ở cấp độ giao thức. Thay vào đó, nó cung cấp cho người gửi một công cụ để tự tái tạo điều gì đó giống như thanh lý một phần thông qua cách họ cấu trúc thế chấp của chính mình, mà không cần giao thức nền tảng phải hỗ trợ việc chi tiêu một phần của bất kỳ kho vàng đơn lẻ nào.

Testnet công khai đã hoạt động nếu bạn muốn thực sự xem cách tiếp cận hai kho vàng này hoạt động khi có một biến động giá được mô phỏng.

#baby $BABY
Đăng nhập để khám phá thêm nội dung
Tham gia cùng người dùng tiền mã hóa toàn cầu trên Binance Square
⚡️ Nhận thông tin mới nhất và hữu ích về tiền mã hóa.
💬 Được tin cậy bởi sàn giao dịch tiền mã hóa lớn nhất thế giới.
👍 Khám phá những thông tin chuyên sâu thực tế từ những nhà sáng tạo đã xác minh.
Email / Số điện thoại
Sơ đồ trang web
Tùy chọn Cookie
Điều khoản & Điều kiện