MICHAEL MOORE
7.6k Bài đăng
MICHAEL MOORE
Giao dịch mở
Trader thường xuyên
5.9 tháng
694 Đang theo dõi
15.9K+ Người theo dõi
5.0K+ Đã thích
Bài đăng
Danh mục đầu tư
Tất cả
Trích dẫn
Live
PINNED
Đã xác minh
Được rồi, cái này thực sự đã khiến tôi dừng lại giữa lúc lướt. Theo thông báo chính thức, testnet của DuskEVM đã đi vào hoạt động vào ngày 10 tháng 8. Hỗ trợ Solidity và Hardhat, phí gas được trả bằng DUSK, và việc thanh toán được định tuyến trở lại về DuskDS.
Tôi quay lại xem các bài đăng cũ để xem mảng quyền riêng tư của vấn đề này xếp chồng lên nhau như thế nào. Hedger, động cơ đứng sau phần giới thiệu hợp đồng thông minh bảo mật của Dusk, đã mở thử nghiệm alpha từ ngày 6 tháng 11 năm 2025. Đợt thử nghiệm đó chạy trên Sepolia—một mạng testnet Ethereum riêng—chứ không phải trên chuỗi của Dusk.
Tôi không nghĩ khoảng trống đó tự nó đã là vấn đề. Việc xây dựng lớp thực thi và lớp quyền riêng tư trên các nhánh tách biệt là một cách bình thường để thử nghiệm mật mã phức tạp trước khi hợp nhất vào môi trường vận hành.
Điều tôi nhận thấy là khác: thông báo ngày 10 tháng 8 hoàn toàn nói về công cụ EVM nói chung. Nó không nhắc đến Hedger, và tôi cũng không tìm được nguồn chính thức nào xác nhận khi nào—hoặc liệu—hai phần đó sẽ được gộp vào cùng một testnet.
Đây là ước tính của riêng tôi. Nếu testnet của DuskEVM đã hoạt động được ba ngày và dòng thời gian công khai của động cơ quyền riêng tư vẫn chưa thay đổi kể từ hồi tháng 11 năm ngoái, thì có khoảng chín tháng mà hai mảng chính về blockchain quyền riêng tư cho các ứng dụng tài chính chưa được cho thấy đang chạy trên cùng một “băng tải”.
Khả năng tương thích EVM, tự nó, đã giúp ích cho những người xây dựng. Solidity và Hardhat giúp giảm rào cản cho bất kỳ ai xuất phát từ Ethereum—và đó là tiến bộ thực sự, bất kể điều gì xảy ra với Hedger ở bước tiếp theo.
Tôi sẽ quay lại kiểm tra để xem cập nhật nào sẽ lấp đầy khoảng trống đó.
@Dusk #dusk $DUSK
Tôi quay lại xem các bài đăng cũ để xem mảng quyền riêng tư của vấn đề này xếp chồng lên nhau như thế nào. Hedger, động cơ đứng sau phần giới thiệu hợp đồng thông minh bảo mật của Dusk, đã mở thử nghiệm alpha từ ngày 6 tháng 11 năm 2025. Đợt thử nghiệm đó chạy trên Sepolia—một mạng testnet Ethereum riêng—chứ không phải trên chuỗi của Dusk.
Tôi không nghĩ khoảng trống đó tự nó đã là vấn đề. Việc xây dựng lớp thực thi và lớp quyền riêng tư trên các nhánh tách biệt là một cách bình thường để thử nghiệm mật mã phức tạp trước khi hợp nhất vào môi trường vận hành.
Điều tôi nhận thấy là khác: thông báo ngày 10 tháng 8 hoàn toàn nói về công cụ EVM nói chung. Nó không nhắc đến Hedger, và tôi cũng không tìm được nguồn chính thức nào xác nhận khi nào—hoặc liệu—hai phần đó sẽ được gộp vào cùng một testnet.
Đây là ước tính của riêng tôi. Nếu testnet của DuskEVM đã hoạt động được ba ngày và dòng thời gian công khai của động cơ quyền riêng tư vẫn chưa thay đổi kể từ hồi tháng 11 năm ngoái, thì có khoảng chín tháng mà hai mảng chính về blockchain quyền riêng tư cho các ứng dụng tài chính chưa được cho thấy đang chạy trên cùng một “băng tải”.
Khả năng tương thích EVM, tự nó, đã giúp ích cho những người xây dựng. Solidity và Hardhat giúp giảm rào cản cho bất kỳ ai xuất phát từ Ethereum—và đó là tiến bộ thực sự, bất kể điều gì xảy ra với Hedger ở bước tiếp theo.
Tôi sẽ quay lại kiểm tra để xem cập nhật nào sẽ lấp đầy khoảng trống đó.
@Dusk #dusk $DUSK
...........
MICHAEL MOORE
·
--
Thành thật mà nói, tôi đã dừng lại ở con số 93 USD được giấu trong whitepaper của Babylon.
Con số đó là chi phí on-chain cho nhánh “challenge path” trong TBV: khoản phí được trả khi ai đó thực sự phản đối một yêu cầu được khóa trên Bitcoin. Theo whitepaper, giao dịch này đã được kiểm thử trực tiếp trên mạng chính Bitcoin.
Điều khiến tôi dừng lại chính là câu nói ngay sau con số đó. Tài liệu nêu rằng khoản phí này hầu như không bao giờ được trả trong thực tế, vì một hệ thống vận hành đúng chuẩn thì sẽ không bao giờ phát sinh “challenge”.
Câu đó khiến tôi phải dừng. Hầu hết các dự án đều liệt kê chi phí rồi chuyển sang phần khác. Dự án này lại liệt kê một khoản chi phí, rồi lặng lẽ lập luận rằng khoản chi phí đó nên chỉ dừng ở lý thuyết nếu mọi thứ hoạt động như dự định.
Trong vận hành bình thường, phần “proof” sẽ luôn nằm ngoài chuỗi (off-chain). Nhánh 93 USD chỉ được kích hoạt khi một yêu cầu thực sự bị tranh chấp, và theo chính tài liệu đó, tranh chấp chỉ xảy ra nếu yêu cầu đó ngay từ đầu không hề hợp lệ.
Đó là một kiểu “niềm tin” khá cụ thể để đưa vào văn bản. Phần lớn các tài liệu kỹ thuật đều mô tả các chi phí trong trường hợp xấu nhất mà không nói rằng trường hợp xấu nhất đó nên hiếm khi xảy ra theo thiết kế.
Whitepaper nói rất rõ khoản phí đó “trả giá” cho điều gì. Nó chưa nói gì về việc ngoài đời thực đã có bao nhiêu lần người ta kiểm chứng rằng yêu cầu đó hầu như không bao giờ bị tranh chấp và do đó hầu như không bao giờ phải trả khoản phí này.
@BabylonLabs_io #baby $BABY
Con số đó là chi phí on-chain cho nhánh “challenge path” trong TBV: khoản phí được trả khi ai đó thực sự phản đối một yêu cầu được khóa trên Bitcoin. Theo whitepaper, giao dịch này đã được kiểm thử trực tiếp trên mạng chính Bitcoin.
Điều khiến tôi dừng lại chính là câu nói ngay sau con số đó. Tài liệu nêu rằng khoản phí này hầu như không bao giờ được trả trong thực tế, vì một hệ thống vận hành đúng chuẩn thì sẽ không bao giờ phát sinh “challenge”.
Câu đó khiến tôi phải dừng. Hầu hết các dự án đều liệt kê chi phí rồi chuyển sang phần khác. Dự án này lại liệt kê một khoản chi phí, rồi lặng lẽ lập luận rằng khoản chi phí đó nên chỉ dừng ở lý thuyết nếu mọi thứ hoạt động như dự định.
Trong vận hành bình thường, phần “proof” sẽ luôn nằm ngoài chuỗi (off-chain). Nhánh 93 USD chỉ được kích hoạt khi một yêu cầu thực sự bị tranh chấp, và theo chính tài liệu đó, tranh chấp chỉ xảy ra nếu yêu cầu đó ngay từ đầu không hề hợp lệ.
Đó là một kiểu “niềm tin” khá cụ thể để đưa vào văn bản. Phần lớn các tài liệu kỹ thuật đều mô tả các chi phí trong trường hợp xấu nhất mà không nói rằng trường hợp xấu nhất đó nên hiếm khi xảy ra theo thiết kế.
Whitepaper nói rất rõ khoản phí đó “trả giá” cho điều gì. Nó chưa nói gì về việc ngoài đời thực đã có bao nhiêu lần người ta kiểm chứng rằng yêu cầu đó hầu như không bao giờ bị tranh chấp và do đó hầu như không bao giờ phải trả khoản phí này.
@BabylonLabs_io #baby $BABY
$93 Điều Nên Gần Như Chưa Bao Giờ Phải Trả.
MICHAEL MOORE
·
--
Thành thật mà nói, tôi đã dừng lại ở con số 93 USD được giấu trong whitepaper của Babylon.
Con số đó là chi phí on-chain cho nhánh “challenge path” trong TBV: khoản phí được trả khi ai đó thực sự phản đối một yêu cầu được khóa trên Bitcoin. Theo whitepaper, giao dịch này đã được kiểm thử trực tiếp trên mạng chính Bitcoin.
Điều khiến tôi dừng lại chính là câu nói ngay sau con số đó. Tài liệu nêu rằng khoản phí này hầu như không bao giờ được trả trong thực tế, vì một hệ thống vận hành đúng chuẩn thì sẽ không bao giờ phát sinh “challenge”.
Câu đó khiến tôi phải dừng. Hầu hết các dự án đều liệt kê chi phí rồi chuyển sang phần khác. Dự án này lại liệt kê một khoản chi phí, rồi lặng lẽ lập luận rằng khoản chi phí đó nên chỉ dừng ở lý thuyết nếu mọi thứ hoạt động như dự định.
Trong vận hành bình thường, phần “proof” sẽ luôn nằm ngoài chuỗi (off-chain). Nhánh 93 USD chỉ được kích hoạt khi một yêu cầu thực sự bị tranh chấp, và theo chính tài liệu đó, tranh chấp chỉ xảy ra nếu yêu cầu đó ngay từ đầu không hề hợp lệ.
Đó là một kiểu “niềm tin” khá cụ thể để đưa vào văn bản. Phần lớn các tài liệu kỹ thuật đều mô tả các chi phí trong trường hợp xấu nhất mà không nói rằng trường hợp xấu nhất đó nên hiếm khi xảy ra theo thiết kế.
Whitepaper nói rất rõ khoản phí đó “trả giá” cho điều gì. Nó chưa nói gì về việc ngoài đời thực đã có bao nhiêu lần người ta kiểm chứng rằng yêu cầu đó hầu như không bao giờ bị tranh chấp và do đó hầu như không bao giờ phải trả khoản phí này.
@BabylonLabs_io #baby $BABY
Con số đó là chi phí on-chain cho nhánh “challenge path” trong TBV: khoản phí được trả khi ai đó thực sự phản đối một yêu cầu được khóa trên Bitcoin. Theo whitepaper, giao dịch này đã được kiểm thử trực tiếp trên mạng chính Bitcoin.
Điều khiến tôi dừng lại chính là câu nói ngay sau con số đó. Tài liệu nêu rằng khoản phí này hầu như không bao giờ được trả trong thực tế, vì một hệ thống vận hành đúng chuẩn thì sẽ không bao giờ phát sinh “challenge”.
Câu đó khiến tôi phải dừng. Hầu hết các dự án đều liệt kê chi phí rồi chuyển sang phần khác. Dự án này lại liệt kê một khoản chi phí, rồi lặng lẽ lập luận rằng khoản chi phí đó nên chỉ dừng ở lý thuyết nếu mọi thứ hoạt động như dự định.
Trong vận hành bình thường, phần “proof” sẽ luôn nằm ngoài chuỗi (off-chain). Nhánh 93 USD chỉ được kích hoạt khi một yêu cầu thực sự bị tranh chấp, và theo chính tài liệu đó, tranh chấp chỉ xảy ra nếu yêu cầu đó ngay từ đầu không hề hợp lệ.
Đó là một kiểu “niềm tin” khá cụ thể để đưa vào văn bản. Phần lớn các tài liệu kỹ thuật đều mô tả các chi phí trong trường hợp xấu nhất mà không nói rằng trường hợp xấu nhất đó nên hiếm khi xảy ra theo thiết kế.
Whitepaper nói rất rõ khoản phí đó “trả giá” cho điều gì. Nó chưa nói gì về việc ngoài đời thực đã có bao nhiêu lần người ta kiểm chứng rằng yêu cầu đó hầu như không bao giờ bị tranh chấp và do đó hầu như không bao giờ phải trả khoản phí này.
@BabylonLabs_io #baby $BABY
Đã xác minh
Thành thật mà nói, tôi đã dừng lại ở con số 93 USD được giấu trong whitepaper của Babylon.
Con số đó là chi phí on-chain cho nhánh “challenge path” trong TBV: khoản phí được trả khi ai đó thực sự phản đối một yêu cầu được khóa trên Bitcoin. Theo whitepaper, giao dịch này đã được kiểm thử trực tiếp trên mạng chính Bitcoin.
Điều khiến tôi dừng lại chính là câu nói ngay sau con số đó. Tài liệu nêu rằng khoản phí này hầu như không bao giờ được trả trong thực tế, vì một hệ thống vận hành đúng chuẩn thì sẽ không bao giờ phát sinh “challenge”.
Câu đó khiến tôi phải dừng. Hầu hết các dự án đều liệt kê chi phí rồi chuyển sang phần khác. Dự án này lại liệt kê một khoản chi phí, rồi lặng lẽ lập luận rằng khoản chi phí đó nên chỉ dừng ở lý thuyết nếu mọi thứ hoạt động như dự định.
Trong vận hành bình thường, phần “proof” sẽ luôn nằm ngoài chuỗi (off-chain). Nhánh 93 USD chỉ được kích hoạt khi một yêu cầu thực sự bị tranh chấp, và theo chính tài liệu đó, tranh chấp chỉ xảy ra nếu yêu cầu đó ngay từ đầu không hề hợp lệ.
Đó là một kiểu “niềm tin” khá cụ thể để đưa vào văn bản. Phần lớn các tài liệu kỹ thuật đều mô tả các chi phí trong trường hợp xấu nhất mà không nói rằng trường hợp xấu nhất đó nên hiếm khi xảy ra theo thiết kế.
Whitepaper nói rất rõ khoản phí đó “trả giá” cho điều gì. Nó chưa nói gì về việc ngoài đời thực đã có bao nhiêu lần người ta kiểm chứng rằng yêu cầu đó hầu như không bao giờ bị tranh chấp và do đó hầu như không bao giờ phải trả khoản phí này.
@BabylonLabs_io #baby $BABY
Con số đó là chi phí on-chain cho nhánh “challenge path” trong TBV: khoản phí được trả khi ai đó thực sự phản đối một yêu cầu được khóa trên Bitcoin. Theo whitepaper, giao dịch này đã được kiểm thử trực tiếp trên mạng chính Bitcoin.
Điều khiến tôi dừng lại chính là câu nói ngay sau con số đó. Tài liệu nêu rằng khoản phí này hầu như không bao giờ được trả trong thực tế, vì một hệ thống vận hành đúng chuẩn thì sẽ không bao giờ phát sinh “challenge”.
Câu đó khiến tôi phải dừng. Hầu hết các dự án đều liệt kê chi phí rồi chuyển sang phần khác. Dự án này lại liệt kê một khoản chi phí, rồi lặng lẽ lập luận rằng khoản chi phí đó nên chỉ dừng ở lý thuyết nếu mọi thứ hoạt động như dự định.
Trong vận hành bình thường, phần “proof” sẽ luôn nằm ngoài chuỗi (off-chain). Nhánh 93 USD chỉ được kích hoạt khi một yêu cầu thực sự bị tranh chấp, và theo chính tài liệu đó, tranh chấp chỉ xảy ra nếu yêu cầu đó ngay từ đầu không hề hợp lệ.
Đó là một kiểu “niềm tin” khá cụ thể để đưa vào văn bản. Phần lớn các tài liệu kỹ thuật đều mô tả các chi phí trong trường hợp xấu nhất mà không nói rằng trường hợp xấu nhất đó nên hiếm khi xảy ra theo thiết kế.
Whitepaper nói rất rõ khoản phí đó “trả giá” cho điều gì. Nó chưa nói gì về việc ngoài đời thực đã có bao nhiêu lần người ta kiểm chứng rằng yêu cầu đó hầu như không bao giờ bị tranh chấp và do đó hầu như không bao giờ phải trả khoản phí này.
@BabylonLabs_io #baby $BABY
Bước còn thiếu trước BitVM3.
Kiến trúc phía sau TBV.
Kiến trúc phía sau TBV.
MICHAEL MOORE
·
--
Thành thật mà nói, tôi đã dừng lại ở một ví dụ trong whitepaper của Babylon mà cảm thấy quá “sạch” để có thể là lời giải thực sự.
Một người vay sẽ khóa BTC để vay từ một bên cho vay trên Ethereum. Theo whitepaper, cả hai bên sẽ cùng ký trước một bộ các giao dịch Bitcoin ngay từ đầu, xác định chính xác thời điểm mỗi bên có thể nhận/chiếm số tiền.
Tôi kỳ vọng bài viết sẽ dừng ở đó và coi như đã giải quyết xong. Nhưng không phải vậy. Dòng tiếp theo nêu rằng cách ký trước này chỉ hoạt động với đúng một sự kiện kích hoạt cụ thể, và không thể mở rộng để áp dụng cho các điều kiện DeFi bất kỳ.
Chi tiết đơn lẻ đó đã khiến tôi chú ý. Một cơ chế được thiết kế để chứng minh tính không cần tin cậy (trustlessness) ngay lập tức, theo đúng lời của nó, rằng nó chỉ bao phủ một loại sự kiện cụ thể và không thể “kéo giãn” để xử lý các điều kiện bất kỳ.
Vì vậy mà BitVM3 tồn tại ngay trong phần thiết kế. Cũng theo tài liệu đó, nó tổng quát hóa ý tưởng này để đối phó với mọi bằng chứng về trạng thái ngoài chuỗi (off-chain), không chỉ một trigger được mã cứng, đồng thời loại bỏ nhu cầu để một bên đối tác phải luôn online.
Tôi đã ngồi suy nghĩ một lúc về trình tự của phần giải thích đó. Hầu hết các phiên bản TBV đều dẫn thẳng đến cơ chế hoàn chỉnh. Whitepaper đi qua phiên bản đơn giản, chỉ ra nơi nó đạt đến giới hạn, rồi sau đó giới thiệu bản sửa thật sự.
Hầu hết các bản tóm tắt đều nhảy thẳng tới BitVM3. Gần như không có bản nào đề cập tới việc trước đó điều gì phải bị bỏ lại. Với tôi, thứ tự đó vẫn là phần “thành thật” nhất trong thiết kế.
@BabylonLabs_io #baby $BABY
Một người vay sẽ khóa BTC để vay từ một bên cho vay trên Ethereum. Theo whitepaper, cả hai bên sẽ cùng ký trước một bộ các giao dịch Bitcoin ngay từ đầu, xác định chính xác thời điểm mỗi bên có thể nhận/chiếm số tiền.
Tôi kỳ vọng bài viết sẽ dừng ở đó và coi như đã giải quyết xong. Nhưng không phải vậy. Dòng tiếp theo nêu rằng cách ký trước này chỉ hoạt động với đúng một sự kiện kích hoạt cụ thể, và không thể mở rộng để áp dụng cho các điều kiện DeFi bất kỳ.
Chi tiết đơn lẻ đó đã khiến tôi chú ý. Một cơ chế được thiết kế để chứng minh tính không cần tin cậy (trustlessness) ngay lập tức, theo đúng lời của nó, rằng nó chỉ bao phủ một loại sự kiện cụ thể và không thể “kéo giãn” để xử lý các điều kiện bất kỳ.
Vì vậy mà BitVM3 tồn tại ngay trong phần thiết kế. Cũng theo tài liệu đó, nó tổng quát hóa ý tưởng này để đối phó với mọi bằng chứng về trạng thái ngoài chuỗi (off-chain), không chỉ một trigger được mã cứng, đồng thời loại bỏ nhu cầu để một bên đối tác phải luôn online.
Tôi đã ngồi suy nghĩ một lúc về trình tự của phần giải thích đó. Hầu hết các phiên bản TBV đều dẫn thẳng đến cơ chế hoàn chỉnh. Whitepaper đi qua phiên bản đơn giản, chỉ ra nơi nó đạt đến giới hạn, rồi sau đó giới thiệu bản sửa thật sự.
Hầu hết các bản tóm tắt đều nhảy thẳng tới BitVM3. Gần như không có bản nào đề cập tới việc trước đó điều gì phải bị bỏ lại. Với tôi, thứ tự đó vẫn là phần “thành thật” nhất trong thiết kế.
@BabylonLabs_io #baby $BABY
Đã xác minh
Thành thật mà nói, tôi đã dừng lại ở một ví dụ trong whitepaper của Babylon mà cảm thấy quá “sạch” để có thể là lời giải thực sự.
Một người vay sẽ khóa BTC để vay từ một bên cho vay trên Ethereum. Theo whitepaper, cả hai bên sẽ cùng ký trước một bộ các giao dịch Bitcoin ngay từ đầu, xác định chính xác thời điểm mỗi bên có thể nhận/chiếm số tiền.
Tôi kỳ vọng bài viết sẽ dừng ở đó và coi như đã giải quyết xong. Nhưng không phải vậy. Dòng tiếp theo nêu rằng cách ký trước này chỉ hoạt động với đúng một sự kiện kích hoạt cụ thể, và không thể mở rộng để áp dụng cho các điều kiện DeFi bất kỳ.
Chi tiết đơn lẻ đó đã khiến tôi chú ý. Một cơ chế được thiết kế để chứng minh tính không cần tin cậy (trustlessness) ngay lập tức, theo đúng lời của nó, rằng nó chỉ bao phủ một loại sự kiện cụ thể và không thể “kéo giãn” để xử lý các điều kiện bất kỳ.
Vì vậy mà BitVM3 tồn tại ngay trong phần thiết kế. Cũng theo tài liệu đó, nó tổng quát hóa ý tưởng này để đối phó với mọi bằng chứng về trạng thái ngoài chuỗi (off-chain), không chỉ một trigger được mã cứng, đồng thời loại bỏ nhu cầu để một bên đối tác phải luôn online.
Tôi đã ngồi suy nghĩ một lúc về trình tự của phần giải thích đó. Hầu hết các phiên bản TBV đều dẫn thẳng đến cơ chế hoàn chỉnh. Whitepaper đi qua phiên bản đơn giản, chỉ ra nơi nó đạt đến giới hạn, rồi sau đó giới thiệu bản sửa thật sự.
Hầu hết các bản tóm tắt đều nhảy thẳng tới BitVM3. Gần như không có bản nào đề cập tới việc trước đó điều gì phải bị bỏ lại. Với tôi, thứ tự đó vẫn là phần “thành thật” nhất trong thiết kế.
@BabylonLabs_io #baby $BABY
Một người vay sẽ khóa BTC để vay từ một bên cho vay trên Ethereum. Theo whitepaper, cả hai bên sẽ cùng ký trước một bộ các giao dịch Bitcoin ngay từ đầu, xác định chính xác thời điểm mỗi bên có thể nhận/chiếm số tiền.
Tôi kỳ vọng bài viết sẽ dừng ở đó và coi như đã giải quyết xong. Nhưng không phải vậy. Dòng tiếp theo nêu rằng cách ký trước này chỉ hoạt động với đúng một sự kiện kích hoạt cụ thể, và không thể mở rộng để áp dụng cho các điều kiện DeFi bất kỳ.
Chi tiết đơn lẻ đó đã khiến tôi chú ý. Một cơ chế được thiết kế để chứng minh tính không cần tin cậy (trustlessness) ngay lập tức, theo đúng lời của nó, rằng nó chỉ bao phủ một loại sự kiện cụ thể và không thể “kéo giãn” để xử lý các điều kiện bất kỳ.
Vì vậy mà BitVM3 tồn tại ngay trong phần thiết kế. Cũng theo tài liệu đó, nó tổng quát hóa ý tưởng này để đối phó với mọi bằng chứng về trạng thái ngoài chuỗi (off-chain), không chỉ một trigger được mã cứng, đồng thời loại bỏ nhu cầu để một bên đối tác phải luôn online.
Tôi đã ngồi suy nghĩ một lúc về trình tự của phần giải thích đó. Hầu hết các phiên bản TBV đều dẫn thẳng đến cơ chế hoàn chỉnh. Whitepaper đi qua phiên bản đơn giản, chỉ ra nơi nó đạt đến giới hạn, rồi sau đó giới thiệu bản sửa thật sự.
Hầu hết các bản tóm tắt đều nhảy thẳng tới BitVM3. Gần như không có bản nào đề cập tới việc trước đó điều gì phải bị bỏ lại. Với tôi, thứ tự đó vẫn là phần “thành thật” nhất trong thiết kế.
@BabylonLabs_io #baby $BABY
VaultBTC Không Phải Những Gì Bạn Nghĩ.
MICHAEL MOORE
·
--
Thú thật, tôi đã dừng lại ở một cái tên khiến tôi hoàn toàn hiểu nhầm ban đầu.
vaultBTC. Tôi cho rằng nó hoạt động giống như mọi token Bitcoin bọc mà tôi từng thấy trước đây: bạn mua, chuyển đi, giao dịch trên một thị trường thứ cấp. Theo hồ sơ chính thức của Babylon trên diễn đàn quản trị của Aave, giả định đó là sai.
Aave chỉ công nhận các token ERC-20 là tài sản thế chấp. Bitcoin gốc được khóa trong một Taproot UTXO hoàn toàn không phải là token ERC-20, vì vậy Babylon cần một giải pháp thay thế. Câu trả lời của họ là một biểu diễn dạng 1-1 trên Ethereum, được gọi là vaultBTC, được đúc ra hoàn toàn chỉ để giao thức cho vay có thể xác nhận rằng một vault cụ thể tồn tại.
Dưới đây là điều đã thay đổi cách tôi đọc toàn bộ thiết kế. Token đó chỉ có thể di chuyển giữa ba điểm cố định được xác định ngay trong chính phần tích hợp, không vượt ra ngoài chúng. Tôi đã kiểm tra nó khác gì so với các tài sản bọc thông thường, và khoảng cách là rất lớn: không có thị trường mở, không có chuyển động không bị giới hạn, không có giao dịch thứ cấp ở bất cứ đâu.
Tôi đã suy nghĩ về sự khác biệt đó một thời gian. Một token bọc thông thường phát huy giá trị nhờ việc có thể di chuyển giữa các ví và nền tảng mà không bị hạn chế. Babylon đã cố tình chặn con đường đó ở đây, chọn một thiết kế khó hơn chỉ để đảm bảo token không bao giờ trở thành một thứ có thể giao dịch thay thế cho “hàng thật”.
Chính giới hạn đó mới là thứ thực sự buộc thực thi quyền tự quản lý ở mức cơ chế, chứ không chỉ là một lời hứa trên giấy. Sẽ đơn giản hơn rất nhiều nếu để vaultBTC hoạt động giống như bất kỳ tài sản nào khác.
Tôi vẫn chưa thấy ai đặt câu hỏi rằng điều gì sẽ xảy ra với tính tương thích lồng ghép (composability) khi một token bị khóa chặt đến vậy. Điều đó giống như câu hỏi thực sự tiếp theo.
@BabylonLabs_io #baby $BABY
vaultBTC. Tôi cho rằng nó hoạt động giống như mọi token Bitcoin bọc mà tôi từng thấy trước đây: bạn mua, chuyển đi, giao dịch trên một thị trường thứ cấp. Theo hồ sơ chính thức của Babylon trên diễn đàn quản trị của Aave, giả định đó là sai.
Aave chỉ công nhận các token ERC-20 là tài sản thế chấp. Bitcoin gốc được khóa trong một Taproot UTXO hoàn toàn không phải là token ERC-20, vì vậy Babylon cần một giải pháp thay thế. Câu trả lời của họ là một biểu diễn dạng 1-1 trên Ethereum, được gọi là vaultBTC, được đúc ra hoàn toàn chỉ để giao thức cho vay có thể xác nhận rằng một vault cụ thể tồn tại.
Dưới đây là điều đã thay đổi cách tôi đọc toàn bộ thiết kế. Token đó chỉ có thể di chuyển giữa ba điểm cố định được xác định ngay trong chính phần tích hợp, không vượt ra ngoài chúng. Tôi đã kiểm tra nó khác gì so với các tài sản bọc thông thường, và khoảng cách là rất lớn: không có thị trường mở, không có chuyển động không bị giới hạn, không có giao dịch thứ cấp ở bất cứ đâu.
Tôi đã suy nghĩ về sự khác biệt đó một thời gian. Một token bọc thông thường phát huy giá trị nhờ việc có thể di chuyển giữa các ví và nền tảng mà không bị hạn chế. Babylon đã cố tình chặn con đường đó ở đây, chọn một thiết kế khó hơn chỉ để đảm bảo token không bao giờ trở thành một thứ có thể giao dịch thay thế cho “hàng thật”.
Chính giới hạn đó mới là thứ thực sự buộc thực thi quyền tự quản lý ở mức cơ chế, chứ không chỉ là một lời hứa trên giấy. Sẽ đơn giản hơn rất nhiều nếu để vaultBTC hoạt động giống như bất kỳ tài sản nào khác.
Tôi vẫn chưa thấy ai đặt câu hỏi rằng điều gì sẽ xảy ra với tính tương thích lồng ghép (composability) khi một token bị khóa chặt đến vậy. Điều đó giống như câu hỏi thực sự tiếp theo.
@BabylonLabs_io #baby $BABY
Đã xác minh
Thú thật, tôi đã dừng lại ở một cái tên khiến tôi hoàn toàn hiểu nhầm ban đầu.
vaultBTC. Tôi cho rằng nó hoạt động giống như mọi token Bitcoin bọc mà tôi từng thấy trước đây: bạn mua, chuyển đi, giao dịch trên một thị trường thứ cấp. Theo hồ sơ chính thức của Babylon trên diễn đàn quản trị của Aave, giả định đó là sai.
Aave chỉ công nhận các token ERC-20 là tài sản thế chấp. Bitcoin gốc được khóa trong một Taproot UTXO hoàn toàn không phải là token ERC-20, vì vậy Babylon cần một giải pháp thay thế. Câu trả lời của họ là một biểu diễn dạng 1-1 trên Ethereum, được gọi là vaultBTC, được đúc ra hoàn toàn chỉ để giao thức cho vay có thể xác nhận rằng một vault cụ thể tồn tại.
Dưới đây là điều đã thay đổi cách tôi đọc toàn bộ thiết kế. Token đó chỉ có thể di chuyển giữa ba điểm cố định được xác định ngay trong chính phần tích hợp, không vượt ra ngoài chúng. Tôi đã kiểm tra nó khác gì so với các tài sản bọc thông thường, và khoảng cách là rất lớn: không có thị trường mở, không có chuyển động không bị giới hạn, không có giao dịch thứ cấp ở bất cứ đâu.
Tôi đã suy nghĩ về sự khác biệt đó một thời gian. Một token bọc thông thường phát huy giá trị nhờ việc có thể di chuyển giữa các ví và nền tảng mà không bị hạn chế. Babylon đã cố tình chặn con đường đó ở đây, chọn một thiết kế khó hơn chỉ để đảm bảo token không bao giờ trở thành một thứ có thể giao dịch thay thế cho “hàng thật”.
Chính giới hạn đó mới là thứ thực sự buộc thực thi quyền tự quản lý ở mức cơ chế, chứ không chỉ là một lời hứa trên giấy. Sẽ đơn giản hơn rất nhiều nếu để vaultBTC hoạt động giống như bất kỳ tài sản nào khác.
Tôi vẫn chưa thấy ai đặt câu hỏi rằng điều gì sẽ xảy ra với tính tương thích lồng ghép (composability) khi một token bị khóa chặt đến vậy. Điều đó giống như câu hỏi thực sự tiếp theo.
@BabylonLabs_io #baby $BABY
vaultBTC. Tôi cho rằng nó hoạt động giống như mọi token Bitcoin bọc mà tôi từng thấy trước đây: bạn mua, chuyển đi, giao dịch trên một thị trường thứ cấp. Theo hồ sơ chính thức của Babylon trên diễn đàn quản trị của Aave, giả định đó là sai.
Aave chỉ công nhận các token ERC-20 là tài sản thế chấp. Bitcoin gốc được khóa trong một Taproot UTXO hoàn toàn không phải là token ERC-20, vì vậy Babylon cần một giải pháp thay thế. Câu trả lời của họ là một biểu diễn dạng 1-1 trên Ethereum, được gọi là vaultBTC, được đúc ra hoàn toàn chỉ để giao thức cho vay có thể xác nhận rằng một vault cụ thể tồn tại.
Dưới đây là điều đã thay đổi cách tôi đọc toàn bộ thiết kế. Token đó chỉ có thể di chuyển giữa ba điểm cố định được xác định ngay trong chính phần tích hợp, không vượt ra ngoài chúng. Tôi đã kiểm tra nó khác gì so với các tài sản bọc thông thường, và khoảng cách là rất lớn: không có thị trường mở, không có chuyển động không bị giới hạn, không có giao dịch thứ cấp ở bất cứ đâu.
Tôi đã suy nghĩ về sự khác biệt đó một thời gian. Một token bọc thông thường phát huy giá trị nhờ việc có thể di chuyển giữa các ví và nền tảng mà không bị hạn chế. Babylon đã cố tình chặn con đường đó ở đây, chọn một thiết kế khó hơn chỉ để đảm bảo token không bao giờ trở thành một thứ có thể giao dịch thay thế cho “hàng thật”.
Chính giới hạn đó mới là thứ thực sự buộc thực thi quyền tự quản lý ở mức cơ chế, chứ không chỉ là một lời hứa trên giấy. Sẽ đơn giản hơn rất nhiều nếu để vaultBTC hoạt động giống như bất kỳ tài sản nào khác.
Tôi vẫn chưa thấy ai đặt câu hỏi rằng điều gì sẽ xảy ra với tính tương thích lồng ghép (composability) khi một token bị khóa chặt đến vậy. Điều đó giống như câu hỏi thực sự tiếp theo.
@BabylonLabs_io #baby $BABY
MICHAEL MOORE
·
--
Thành thật mà nói, tôi đã dừng lại ở một con số vẫn còn khiến nó trông gần như không thật.
Chín nghìn satoshis.
Vào tháng 10 năm 2025, hai tháng sau khi whitepaper “Trustless Bitcoin Vaults” được phát hành, David Tse đã đăng thí nghiệm thực sự đầu tiên từ chính tài khoản của anh ấy. Không phải testnet. Không phải mô phỏng. Một giao dịch Bitcoin trực tiếp và một giao dịch Ethereum khớp tương ứng, cả hai đều hiển thị trên các trình khám phá công khai để bất kỳ ai cũng có thể kiểm tra.
Chín nghìn satoshis được khóa vào một vault. Chính xác một USDC được vay trên Morpho. Bitcoin gốc không bao giờ rời khỏi chuỗi Bitcoin, không bao giờ bị bọc (wrapped), không đi qua bên giám hộ (custodian).
Tôi tự mình vào kiểm tra cả hai liên kết giao dịch. Số tiền nhỏ bé đó là lần đầu tiên BTC gốc trở nên có thể dùng làm tài sản thế chấp cho khoản vay trên Ethereum mà không phải đánh đổi niềm tin theo kiểu thông thường.
Điều cứ quay trở lại ám ảnh tôi là khoảng cách giữa khoảnh khắc đó và nơi TBV đang đứng bây giờ. Cơ chế tương tự hiện đang chạy trên Aave V4 public testnet và nằm phía sau một tích hợp GoMining dự kiến, nói về quy mô lên tới một nghìn BTC.
Thí nghiệm đầu tiên đó được cố ý làm cực kỳ nhỏ. Công việc hiện tại rõ ràng đang nhắm đến quy mô lớn hơn nhiều. Liệu các giả định về niềm tin ban đầu có còn đúng khi kích thước tăng từ mức một đô la lên một quy mô có ý nghĩa hay không—đó vẫn là phần mà tôi chưa thấy được kiểm thử căng thẳng một cách đầy đủ trước công chúng.
@BabylonLabs_io #baby $BABY
Chín nghìn satoshis.
Vào tháng 10 năm 2025, hai tháng sau khi whitepaper “Trustless Bitcoin Vaults” được phát hành, David Tse đã đăng thí nghiệm thực sự đầu tiên từ chính tài khoản của anh ấy. Không phải testnet. Không phải mô phỏng. Một giao dịch Bitcoin trực tiếp và một giao dịch Ethereum khớp tương ứng, cả hai đều hiển thị trên các trình khám phá công khai để bất kỳ ai cũng có thể kiểm tra.
Chín nghìn satoshis được khóa vào một vault. Chính xác một USDC được vay trên Morpho. Bitcoin gốc không bao giờ rời khỏi chuỗi Bitcoin, không bao giờ bị bọc (wrapped), không đi qua bên giám hộ (custodian).
Tôi tự mình vào kiểm tra cả hai liên kết giao dịch. Số tiền nhỏ bé đó là lần đầu tiên BTC gốc trở nên có thể dùng làm tài sản thế chấp cho khoản vay trên Ethereum mà không phải đánh đổi niềm tin theo kiểu thông thường.
Điều cứ quay trở lại ám ảnh tôi là khoảng cách giữa khoảnh khắc đó và nơi TBV đang đứng bây giờ. Cơ chế tương tự hiện đang chạy trên Aave V4 public testnet và nằm phía sau một tích hợp GoMining dự kiến, nói về quy mô lên tới một nghìn BTC.
Thí nghiệm đầu tiên đó được cố ý làm cực kỳ nhỏ. Công việc hiện tại rõ ràng đang nhắm đến quy mô lớn hơn nhiều. Liệu các giả định về niềm tin ban đầu có còn đúng khi kích thước tăng từ mức một đô la lên một quy mô có ý nghĩa hay không—đó vẫn là phần mà tôi chưa thấy được kiểm thử căng thẳng một cách đầy đủ trước công chúng.
@BabylonLabs_io #baby $BABY
Đã xác minh
Thành thật mà nói, tôi đã dừng lại ở một con số vẫn còn khiến nó trông gần như không thật.
Chín nghìn satoshis.
Vào tháng 10 năm 2025, hai tháng sau khi whitepaper “Trustless Bitcoin Vaults” được phát hành, David Tse đã đăng thí nghiệm thực sự đầu tiên từ chính tài khoản của anh ấy. Không phải testnet. Không phải mô phỏng. Một giao dịch Bitcoin trực tiếp và một giao dịch Ethereum khớp tương ứng, cả hai đều hiển thị trên các trình khám phá công khai để bất kỳ ai cũng có thể kiểm tra.
Chín nghìn satoshis được khóa vào một vault. Chính xác một USDC được vay trên Morpho. Bitcoin gốc không bao giờ rời khỏi chuỗi Bitcoin, không bao giờ bị bọc (wrapped), không đi qua bên giám hộ (custodian).
Tôi tự mình vào kiểm tra cả hai liên kết giao dịch. Số tiền nhỏ bé đó là lần đầu tiên BTC gốc trở nên có thể dùng làm tài sản thế chấp cho khoản vay trên Ethereum mà không phải đánh đổi niềm tin theo kiểu thông thường.
Điều cứ quay trở lại ám ảnh tôi là khoảng cách giữa khoảnh khắc đó và nơi TBV đang đứng bây giờ. Cơ chế tương tự hiện đang chạy trên Aave V4 public testnet và nằm phía sau một tích hợp GoMining dự kiến, nói về quy mô lên tới một nghìn BTC.
Thí nghiệm đầu tiên đó được cố ý làm cực kỳ nhỏ. Công việc hiện tại rõ ràng đang nhắm đến quy mô lớn hơn nhiều. Liệu các giả định về niềm tin ban đầu có còn đúng khi kích thước tăng từ mức một đô la lên một quy mô có ý nghĩa hay không—đó vẫn là phần mà tôi chưa thấy được kiểm thử căng thẳng một cách đầy đủ trước công chúng.
@BabylonLabs_io #baby $BABY
Chín nghìn satoshis.
Vào tháng 10 năm 2025, hai tháng sau khi whitepaper “Trustless Bitcoin Vaults” được phát hành, David Tse đã đăng thí nghiệm thực sự đầu tiên từ chính tài khoản của anh ấy. Không phải testnet. Không phải mô phỏng. Một giao dịch Bitcoin trực tiếp và một giao dịch Ethereum khớp tương ứng, cả hai đều hiển thị trên các trình khám phá công khai để bất kỳ ai cũng có thể kiểm tra.
Chín nghìn satoshis được khóa vào một vault. Chính xác một USDC được vay trên Morpho. Bitcoin gốc không bao giờ rời khỏi chuỗi Bitcoin, không bao giờ bị bọc (wrapped), không đi qua bên giám hộ (custodian).
Tôi tự mình vào kiểm tra cả hai liên kết giao dịch. Số tiền nhỏ bé đó là lần đầu tiên BTC gốc trở nên có thể dùng làm tài sản thế chấp cho khoản vay trên Ethereum mà không phải đánh đổi niềm tin theo kiểu thông thường.
Điều cứ quay trở lại ám ảnh tôi là khoảng cách giữa khoảnh khắc đó và nơi TBV đang đứng bây giờ. Cơ chế tương tự hiện đang chạy trên Aave V4 public testnet và nằm phía sau một tích hợp GoMining dự kiến, nói về quy mô lên tới một nghìn BTC.
Thí nghiệm đầu tiên đó được cố ý làm cực kỳ nhỏ. Công việc hiện tại rõ ràng đang nhắm đến quy mô lớn hơn nhiều. Liệu các giả định về niềm tin ban đầu có còn đúng khi kích thước tăng từ mức một đô la lên một quy mô có ý nghĩa hay không—đó vẫn là phần mà tôi chưa thấy được kiểm thử căng thẳng một cách đầy đủ trước công chúng.
@BabylonLabs_io #baby $BABY
ONE CLOCK IS FIXED.
THE OTHER ISN'T EVEN RUNNING YET.
THE OTHER ISN'T EVEN RUNNING YET.
MICHAEL MOORE
·
--
Tôi đang xem lịch sử quản trị riêng của Babylon và một chi tiết đã thay đổi cách tôi đọc mọi ngày mở khóa trong tương lai.
Vào tháng 9 năm 2025, diễn đàn Foundation của Babylon đã đưa ra một đề xuất cắt lạm phát BABY từ 8% xuống 5,5%, chia phần thưởng theo một thiết kế đồng-cọc mới BTC-BABY. Kể từ đó, đề xuất đã được thông qua. Điều khiến tôi chú ý là dòng mà nhóm đã công khai đính kèm: đây được định khung là hạng mục đầu tiên trong một loạt điều chỉnh tokenomics được lên kế hoạch cụ thể vì Trustless Bitcoin Vaults (TBV) đang sẵn sàng.
Cách diễn đạt đó khiến tôi đi tìm cách TBV bản thân được cho là sẽ phản hồi lại vào $BABY . Theo Babylon's Vault First Roadmap, doanh thu tạo ra từ các tích hợp DeFi, chi phí lãi và phần thưởng phí thanh lý được dự định để lập trình mua và đốt BABY.
Whitepaper của TBV mô tả trực tiếp điều này: bên trúng thầu trong cuộc đấu giá đó nhận được BTC, và lượng BABY được chi ra sẽ bị đốt, không có bước nào nằm trong quyền quyết định của quỹ dự trữ.
Trong bản tóm tắt Founders Call của Babylon, nhóm nhấn mạnh rằng tạo giá trị là ưu tiên hàng đầu, với tokenomics được thiết kế để nắm bắt việc sử dụng thực tế thay vì tự tạo ra nó.
Chính là câu đó mà tôi cứ mãi suy nghĩ.
Theo tài liệu của chính Babylon, tổng quy mô của nhóm Team, Advisor và Early Investor cộng lại là 4,9 tỷ BABY, được phát hành theo các đợt chia đều mỗi tháng kể từ ngày 10/5/2026. Chia trên 36 tháng, đợt tiếp theo dự kiến vào ngày 10/8/2026 vào khoảng 136,11 triệu $BABY , vẫn đúng tiến độ bất chấp bất cứ điều gì khác.
Cơ chế đốt phụ thuộc vào khối lượng giao dịch thực tế của TBV, vẫn đang được hình thành trên testnet. Việc mở khóa không chờ con số đó tồn tại.
Vậy cái đồng hồ nào sẽ đuổi kịp cái còn lại trước?
#baby @BabylonLabs_io #baby
Vào tháng 9 năm 2025, diễn đàn Foundation của Babylon đã đưa ra một đề xuất cắt lạm phát BABY từ 8% xuống 5,5%, chia phần thưởng theo một thiết kế đồng-cọc mới BTC-BABY. Kể từ đó, đề xuất đã được thông qua. Điều khiến tôi chú ý là dòng mà nhóm đã công khai đính kèm: đây được định khung là hạng mục đầu tiên trong một loạt điều chỉnh tokenomics được lên kế hoạch cụ thể vì Trustless Bitcoin Vaults (TBV) đang sẵn sàng.
Cách diễn đạt đó khiến tôi đi tìm cách TBV bản thân được cho là sẽ phản hồi lại vào $BABY . Theo Babylon's Vault First Roadmap, doanh thu tạo ra từ các tích hợp DeFi, chi phí lãi và phần thưởng phí thanh lý được dự định để lập trình mua và đốt BABY.
Whitepaper của TBV mô tả trực tiếp điều này: bên trúng thầu trong cuộc đấu giá đó nhận được BTC, và lượng BABY được chi ra sẽ bị đốt, không có bước nào nằm trong quyền quyết định của quỹ dự trữ.
Trong bản tóm tắt Founders Call của Babylon, nhóm nhấn mạnh rằng tạo giá trị là ưu tiên hàng đầu, với tokenomics được thiết kế để nắm bắt việc sử dụng thực tế thay vì tự tạo ra nó.
Chính là câu đó mà tôi cứ mãi suy nghĩ.
Theo tài liệu của chính Babylon, tổng quy mô của nhóm Team, Advisor và Early Investor cộng lại là 4,9 tỷ BABY, được phát hành theo các đợt chia đều mỗi tháng kể từ ngày 10/5/2026. Chia trên 36 tháng, đợt tiếp theo dự kiến vào ngày 10/8/2026 vào khoảng 136,11 triệu $BABY , vẫn đúng tiến độ bất chấp bất cứ điều gì khác.
Cơ chế đốt phụ thuộc vào khối lượng giao dịch thực tế của TBV, vẫn đang được hình thành trên testnet. Việc mở khóa không chờ con số đó tồn tại.
Vậy cái đồng hồ nào sẽ đuổi kịp cái còn lại trước?
#baby @BabylonLabs_io #baby
Đúng một phần
Tôi đang xem lịch sử quản trị riêng của Babylon và một chi tiết đã thay đổi cách tôi đọc mọi ngày mở khóa trong tương lai.
Vào tháng 9 năm 2025, diễn đàn Foundation của Babylon đã đưa ra một đề xuất cắt lạm phát BABY từ 8% xuống 5,5%, chia phần thưởng theo một thiết kế đồng-cọc mới BTC-BABY. Kể từ đó, đề xuất đã được thông qua. Điều khiến tôi chú ý là dòng mà nhóm đã công khai đính kèm: đây được định khung là hạng mục đầu tiên trong một loạt điều chỉnh tokenomics được lên kế hoạch cụ thể vì Trustless Bitcoin Vaults (TBV) đang sẵn sàng.
Cách diễn đạt đó khiến tôi đi tìm cách TBV bản thân được cho là sẽ phản hồi lại vào $BABY . Theo Babylon's Vault First Roadmap, doanh thu tạo ra từ các tích hợp DeFi, chi phí lãi và phần thưởng phí thanh lý được dự định để lập trình mua và đốt BABY.
Whitepaper của TBV mô tả trực tiếp điều này: bên trúng thầu trong cuộc đấu giá đó nhận được BTC, và lượng BABY được chi ra sẽ bị đốt, không có bước nào nằm trong quyền quyết định của quỹ dự trữ.
Trong bản tóm tắt Founders Call của Babylon, nhóm nhấn mạnh rằng tạo giá trị là ưu tiên hàng đầu, với tokenomics được thiết kế để nắm bắt việc sử dụng thực tế thay vì tự tạo ra nó.
Chính là câu đó mà tôi cứ mãi suy nghĩ.
Theo tài liệu của chính Babylon, tổng quy mô của nhóm Team, Advisor và Early Investor cộng lại là 4,9 tỷ BABY, được phát hành theo các đợt chia đều mỗi tháng kể từ ngày 10/5/2026. Chia trên 36 tháng, đợt tiếp theo dự kiến vào ngày 10/8/2026 vào khoảng 136,11 triệu $BABY , vẫn đúng tiến độ bất chấp bất cứ điều gì khác.
Cơ chế đốt phụ thuộc vào khối lượng giao dịch thực tế của TBV, vẫn đang được hình thành trên testnet. Việc mở khóa không chờ con số đó tồn tại.
Vậy cái đồng hồ nào sẽ đuổi kịp cái còn lại trước?
#baby @BabylonLabs_io #baby
Vào tháng 9 năm 2025, diễn đàn Foundation của Babylon đã đưa ra một đề xuất cắt lạm phát BABY từ 8% xuống 5,5%, chia phần thưởng theo một thiết kế đồng-cọc mới BTC-BABY. Kể từ đó, đề xuất đã được thông qua. Điều khiến tôi chú ý là dòng mà nhóm đã công khai đính kèm: đây được định khung là hạng mục đầu tiên trong một loạt điều chỉnh tokenomics được lên kế hoạch cụ thể vì Trustless Bitcoin Vaults (TBV) đang sẵn sàng.
Cách diễn đạt đó khiến tôi đi tìm cách TBV bản thân được cho là sẽ phản hồi lại vào $BABY . Theo Babylon's Vault First Roadmap, doanh thu tạo ra từ các tích hợp DeFi, chi phí lãi và phần thưởng phí thanh lý được dự định để lập trình mua và đốt BABY.
Whitepaper của TBV mô tả trực tiếp điều này: bên trúng thầu trong cuộc đấu giá đó nhận được BTC, và lượng BABY được chi ra sẽ bị đốt, không có bước nào nằm trong quyền quyết định của quỹ dự trữ.
Trong bản tóm tắt Founders Call của Babylon, nhóm nhấn mạnh rằng tạo giá trị là ưu tiên hàng đầu, với tokenomics được thiết kế để nắm bắt việc sử dụng thực tế thay vì tự tạo ra nó.
Chính là câu đó mà tôi cứ mãi suy nghĩ.
Theo tài liệu của chính Babylon, tổng quy mô của nhóm Team, Advisor và Early Investor cộng lại là 4,9 tỷ BABY, được phát hành theo các đợt chia đều mỗi tháng kể từ ngày 10/5/2026. Chia trên 36 tháng, đợt tiếp theo dự kiến vào ngày 10/8/2026 vào khoảng 136,11 triệu $BABY , vẫn đúng tiến độ bất chấp bất cứ điều gì khác.
Cơ chế đốt phụ thuộc vào khối lượng giao dịch thực tế của TBV, vẫn đang được hình thành trên testnet. Việc mở khóa không chờ con số đó tồn tại.
Vậy cái đồng hồ nào sẽ đuổi kịp cái còn lại trước?
#baby @BabylonLabs_io #baby
MICHAEL MOORE
·
--
KHÔNG CÓ NGƯỜI GIỮ QUẢN. KHÔNG CÓ ỦY BAN. CHỈ CÓ BẠN.
Này, tôi đang tìm nhóm bên ngoài giám sát “cửa sổ thách thức” của TBV để xử lý các yêu cầu không hợp lệ. Thực tế là không có.
Temp Check chính thức của Babylon, được gửi đến diễn đàn quản trị của Aave vào ngày 25/05/2026, mô tả điều gì xảy ra khi ai đó cố gắng đổi (redeem) một vault TBV bằng một bằng chứng (proof) không hợp lệ. Yêu cầu đó có thể bị thách thức trong một khung thời gian nhất định. Điều làm tôi chú ý là ai là người có quyền đưa ra thách thức.
Chính người gửi tiền (depositor) luôn có thể tự mình đóng vai trò là người thách thức. Không phải là một lựa chọn dự phòng. Không phải là phương án thay thế nếu một nhóm được chỉ định nào đó không xuất hiện. Đây là mặc định, được tích hợp sẵn trong thiết kế ngay từ đầu.
Phần lớn các hệ thống kết nối Bitcoin với DeFi đều dựa vào một quyền ủy quyền cho đúng công việc này—một liên bang (federation), một multisig, hoặc một nhóm người ký (signers) có quyền tùy ý. Theo chính tài liệu đó, ở đây không có bất kỳ thứ nào trong số đó. Không có người giám hộ (custodian) nào nắm giữ một khóa. Không có ủy ban nào bỏ phiếu đối với BTC.
Sự vắng mặt này liên hệ trực tiếp với ý nghĩa thực sự của “tự lưu ký” (self-custody) trong ngữ cảnh này. Việc giữ khóa của chính bạn là một nửa của nó. Tự mình bảo vệ yêu cầu của chính mình—mà không cần bất kỳ ai khác phải trung thực hay sẵn sàng—là nửa còn lại mà hầu hết các bản giải thích bỏ qua hoàn toàn.
Tôi vẫn đang theo dõi khía cạnh thực tiễn. Việc tự đóng vai trò là người thách thức đồng nghĩa là phải có ai đó thực sự giám sát khung thời gian trong lúc một yêu cầu đang được xử lý. Liệu việc này cần phần mềm chuyên dụng hay có thể thực hiện thông qua một thứ đơn giản hơn thì chưa được công bố chi tiết.
Hệ quả thực sự thì khá rõ ràng. Bất kỳ ai gửi tiền vào TBV mà không tự kiểm tra vault của mình đều đang âm thầm quay lại với đúng kiểu phụ thuộc mà thiết kế này được tạo ra để loại bỏ.
$BABY #baby @BabylonLabs_io
Này, tôi đang tìm nhóm bên ngoài giám sát “cửa sổ thách thức” của TBV để xử lý các yêu cầu không hợp lệ. Thực tế là không có.
Temp Check chính thức của Babylon, được gửi đến diễn đàn quản trị của Aave vào ngày 25/05/2026, mô tả điều gì xảy ra khi ai đó cố gắng đổi (redeem) một vault TBV bằng một bằng chứng (proof) không hợp lệ. Yêu cầu đó có thể bị thách thức trong một khung thời gian nhất định. Điều làm tôi chú ý là ai là người có quyền đưa ra thách thức.
Chính người gửi tiền (depositor) luôn có thể tự mình đóng vai trò là người thách thức. Không phải là một lựa chọn dự phòng. Không phải là phương án thay thế nếu một nhóm được chỉ định nào đó không xuất hiện. Đây là mặc định, được tích hợp sẵn trong thiết kế ngay từ đầu.
Phần lớn các hệ thống kết nối Bitcoin với DeFi đều dựa vào một quyền ủy quyền cho đúng công việc này—một liên bang (federation), một multisig, hoặc một nhóm người ký (signers) có quyền tùy ý. Theo chính tài liệu đó, ở đây không có bất kỳ thứ nào trong số đó. Không có người giám hộ (custodian) nào nắm giữ một khóa. Không có ủy ban nào bỏ phiếu đối với BTC.
Sự vắng mặt này liên hệ trực tiếp với ý nghĩa thực sự của “tự lưu ký” (self-custody) trong ngữ cảnh này. Việc giữ khóa của chính bạn là một nửa của nó. Tự mình bảo vệ yêu cầu của chính mình—mà không cần bất kỳ ai khác phải trung thực hay sẵn sàng—là nửa còn lại mà hầu hết các bản giải thích bỏ qua hoàn toàn.
Tôi vẫn đang theo dõi khía cạnh thực tiễn. Việc tự đóng vai trò là người thách thức đồng nghĩa là phải có ai đó thực sự giám sát khung thời gian trong lúc một yêu cầu đang được xử lý. Liệu việc này cần phần mềm chuyên dụng hay có thể thực hiện thông qua một thứ đơn giản hơn thì chưa được công bố chi tiết.
Hệ quả thực sự thì khá rõ ràng. Bất kỳ ai gửi tiền vào TBV mà không tự kiểm tra vault của mình đều đang âm thầm quay lại với đúng kiểu phụ thuộc mà thiết kế này được tạo ra để loại bỏ.
$BABY #baby @BabylonLabs_io
Đã xác minh
KHÔNG CÓ NGƯỜI GIỮ QUẢN. KHÔNG CÓ ỦY BAN. CHỈ CÓ BẠN.
Này, tôi đang tìm nhóm bên ngoài giám sát “cửa sổ thách thức” của TBV để xử lý các yêu cầu không hợp lệ. Thực tế là không có.
Temp Check chính thức của Babylon, được gửi đến diễn đàn quản trị của Aave vào ngày 25/05/2026, mô tả điều gì xảy ra khi ai đó cố gắng đổi (redeem) một vault TBV bằng một bằng chứng (proof) không hợp lệ. Yêu cầu đó có thể bị thách thức trong một khung thời gian nhất định. Điều làm tôi chú ý là ai là người có quyền đưa ra thách thức.
Chính người gửi tiền (depositor) luôn có thể tự mình đóng vai trò là người thách thức. Không phải là một lựa chọn dự phòng. Không phải là phương án thay thế nếu một nhóm được chỉ định nào đó không xuất hiện. Đây là mặc định, được tích hợp sẵn trong thiết kế ngay từ đầu.
Phần lớn các hệ thống kết nối Bitcoin với DeFi đều dựa vào một quyền ủy quyền cho đúng công việc này—một liên bang (federation), một multisig, hoặc một nhóm người ký (signers) có quyền tùy ý. Theo chính tài liệu đó, ở đây không có bất kỳ thứ nào trong số đó. Không có người giám hộ (custodian) nào nắm giữ một khóa. Không có ủy ban nào bỏ phiếu đối với BTC.
Sự vắng mặt này liên hệ trực tiếp với ý nghĩa thực sự của “tự lưu ký” (self-custody) trong ngữ cảnh này. Việc giữ khóa của chính bạn là một nửa của nó. Tự mình bảo vệ yêu cầu của chính mình—mà không cần bất kỳ ai khác phải trung thực hay sẵn sàng—là nửa còn lại mà hầu hết các bản giải thích bỏ qua hoàn toàn.
Tôi vẫn đang theo dõi khía cạnh thực tiễn. Việc tự đóng vai trò là người thách thức đồng nghĩa là phải có ai đó thực sự giám sát khung thời gian trong lúc một yêu cầu đang được xử lý. Liệu việc này cần phần mềm chuyên dụng hay có thể thực hiện thông qua một thứ đơn giản hơn thì chưa được công bố chi tiết.
Hệ quả thực sự thì khá rõ ràng. Bất kỳ ai gửi tiền vào TBV mà không tự kiểm tra vault của mình đều đang âm thầm quay lại với đúng kiểu phụ thuộc mà thiết kế này được tạo ra để loại bỏ.
$BABY #baby @BabylonLabs_io
Này, tôi đang tìm nhóm bên ngoài giám sát “cửa sổ thách thức” của TBV để xử lý các yêu cầu không hợp lệ. Thực tế là không có.
Temp Check chính thức của Babylon, được gửi đến diễn đàn quản trị của Aave vào ngày 25/05/2026, mô tả điều gì xảy ra khi ai đó cố gắng đổi (redeem) một vault TBV bằng một bằng chứng (proof) không hợp lệ. Yêu cầu đó có thể bị thách thức trong một khung thời gian nhất định. Điều làm tôi chú ý là ai là người có quyền đưa ra thách thức.
Chính người gửi tiền (depositor) luôn có thể tự mình đóng vai trò là người thách thức. Không phải là một lựa chọn dự phòng. Không phải là phương án thay thế nếu một nhóm được chỉ định nào đó không xuất hiện. Đây là mặc định, được tích hợp sẵn trong thiết kế ngay từ đầu.
Phần lớn các hệ thống kết nối Bitcoin với DeFi đều dựa vào một quyền ủy quyền cho đúng công việc này—một liên bang (federation), một multisig, hoặc một nhóm người ký (signers) có quyền tùy ý. Theo chính tài liệu đó, ở đây không có bất kỳ thứ nào trong số đó. Không có người giám hộ (custodian) nào nắm giữ một khóa. Không có ủy ban nào bỏ phiếu đối với BTC.
Sự vắng mặt này liên hệ trực tiếp với ý nghĩa thực sự của “tự lưu ký” (self-custody) trong ngữ cảnh này. Việc giữ khóa của chính bạn là một nửa của nó. Tự mình bảo vệ yêu cầu của chính mình—mà không cần bất kỳ ai khác phải trung thực hay sẵn sàng—là nửa còn lại mà hầu hết các bản giải thích bỏ qua hoàn toàn.
Tôi vẫn đang theo dõi khía cạnh thực tiễn. Việc tự đóng vai trò là người thách thức đồng nghĩa là phải có ai đó thực sự giám sát khung thời gian trong lúc một yêu cầu đang được xử lý. Liệu việc này cần phần mềm chuyên dụng hay có thể thực hiện thông qua một thứ đơn giản hơn thì chưa được công bố chi tiết.
Hệ quả thực sự thì khá rõ ràng. Bất kỳ ai gửi tiền vào TBV mà không tự kiểm tra vault của mình đều đang âm thầm quay lại với đúng kiểu phụ thuộc mà thiết kế này được tạo ra để loại bỏ.
$BABY #baby @BabylonLabs_io
........... @BabylonLabs_io
MICHAEL MOORE
·
--
Này, tôi nhận thấy một điều gì đó trong thông báo về Sổ cái Babylon ngày 10 tháng 3 năm 2026 mà hầu hết các bài đưa tin đã bỏ sót hoàn toàn.
Mọi tiêu đề tôi thấy đều tập trung vào con số 8 triệu thiết bị. Tôi cứ nghĩ về việc những thiết bị đó thực sự làm gì tại thời điểm một kho tiền (vault) được thiết lập.
Khi ai đó tạo một TBV, các quy tắc sẽ được khóa lại vĩnh viễn: địa chỉ claimer, giao thức mục tiêu, điều kiện phát hành. Tôi không thể quay lại thay đổi bất kỳ thứ nào trong các thông số đó sau khi tạo. Đó là sự cam kết.
Nếu không có Clear Signing của Ledger, thì tôi sẽ thiết lập các tham số đó thông qua một trình duyệt và tin vào giao diện người dùng hiển thị cho tôi biết rằng tôi đang đồng ý với những gì. Còn với nó, mọi thứ tôi đang phê duyệt sẽ hiện trên màn hình phần cứng của tôi bằng ngôn ngữ rõ ràng trước khi tôi ký. Việc xác minh và việc khóa vĩnh viễn là cùng một thao tác.
Lời hứa tự quản (self-custody) trong TBV là việc BTC của tôi không bao giờ rời khỏi sự kiểm soát của tôi. Clear Signing mở rộng logic đó sang chính quá trình thiết lập. Tôi có thể đọc đúng những gì mình đang cam kết, trên một thiết bị mà tôi đang giữ, trước khi nó trở nên vĩnh viễn.
Bài blog ngày 10 tháng 3 của Babylon đã nêu kế hoạch triển khai H2 năm 2026 cho phần tích hợp này. Khung thời gian đó hiện đã mở.
Điều tôi chưa tìm thấy công khai là Clear Signing bao gồm toàn bộ việc tạo vault hay chỉ áp dụng cho các hành động sau khi thiết lập. Chi tiết phạm vi đó vẫn chưa được đề cập.
$BABY @BabylonLabs_io #baby
Mọi tiêu đề tôi thấy đều tập trung vào con số 8 triệu thiết bị. Tôi cứ nghĩ về việc những thiết bị đó thực sự làm gì tại thời điểm một kho tiền (vault) được thiết lập.
Khi ai đó tạo một TBV, các quy tắc sẽ được khóa lại vĩnh viễn: địa chỉ claimer, giao thức mục tiêu, điều kiện phát hành. Tôi không thể quay lại thay đổi bất kỳ thứ nào trong các thông số đó sau khi tạo. Đó là sự cam kết.
Nếu không có Clear Signing của Ledger, thì tôi sẽ thiết lập các tham số đó thông qua một trình duyệt và tin vào giao diện người dùng hiển thị cho tôi biết rằng tôi đang đồng ý với những gì. Còn với nó, mọi thứ tôi đang phê duyệt sẽ hiện trên màn hình phần cứng của tôi bằng ngôn ngữ rõ ràng trước khi tôi ký. Việc xác minh và việc khóa vĩnh viễn là cùng một thao tác.
Lời hứa tự quản (self-custody) trong TBV là việc BTC của tôi không bao giờ rời khỏi sự kiểm soát của tôi. Clear Signing mở rộng logic đó sang chính quá trình thiết lập. Tôi có thể đọc đúng những gì mình đang cam kết, trên một thiết bị mà tôi đang giữ, trước khi nó trở nên vĩnh viễn.
Bài blog ngày 10 tháng 3 của Babylon đã nêu kế hoạch triển khai H2 năm 2026 cho phần tích hợp này. Khung thời gian đó hiện đã mở.
Điều tôi chưa tìm thấy công khai là Clear Signing bao gồm toàn bộ việc tạo vault hay chỉ áp dụng cho các hành động sau khi thiết lập. Chi tiết phạm vi đó vẫn chưa được đề cập.
$BABY @BabylonLabs_io #baby
Đã xác minh
Này, tôi nhận thấy một điều gì đó trong thông báo về Sổ cái Babylon ngày 10 tháng 3 năm 2026 mà hầu hết các bài đưa tin đã bỏ sót hoàn toàn.
Mọi tiêu đề tôi thấy đều tập trung vào con số 8 triệu thiết bị. Tôi cứ nghĩ về việc những thiết bị đó thực sự làm gì tại thời điểm một kho tiền (vault) được thiết lập.
Khi ai đó tạo một TBV, các quy tắc sẽ được khóa lại vĩnh viễn: địa chỉ claimer, giao thức mục tiêu, điều kiện phát hành. Tôi không thể quay lại thay đổi bất kỳ thứ nào trong các thông số đó sau khi tạo. Đó là sự cam kết.
Nếu không có Clear Signing của Ledger, thì tôi sẽ thiết lập các tham số đó thông qua một trình duyệt và tin vào giao diện người dùng hiển thị cho tôi biết rằng tôi đang đồng ý với những gì. Còn với nó, mọi thứ tôi đang phê duyệt sẽ hiện trên màn hình phần cứng của tôi bằng ngôn ngữ rõ ràng trước khi tôi ký. Việc xác minh và việc khóa vĩnh viễn là cùng một thao tác.
Lời hứa tự quản (self-custody) trong TBV là việc BTC của tôi không bao giờ rời khỏi sự kiểm soát của tôi. Clear Signing mở rộng logic đó sang chính quá trình thiết lập. Tôi có thể đọc đúng những gì mình đang cam kết, trên một thiết bị mà tôi đang giữ, trước khi nó trở nên vĩnh viễn.
Bài blog ngày 10 tháng 3 của Babylon đã nêu kế hoạch triển khai H2 năm 2026 cho phần tích hợp này. Khung thời gian đó hiện đã mở.
Điều tôi chưa tìm thấy công khai là Clear Signing bao gồm toàn bộ việc tạo vault hay chỉ áp dụng cho các hành động sau khi thiết lập. Chi tiết phạm vi đó vẫn chưa được đề cập.
$BABY @BabylonLabs_io #baby
Mọi tiêu đề tôi thấy đều tập trung vào con số 8 triệu thiết bị. Tôi cứ nghĩ về việc những thiết bị đó thực sự làm gì tại thời điểm một kho tiền (vault) được thiết lập.
Khi ai đó tạo một TBV, các quy tắc sẽ được khóa lại vĩnh viễn: địa chỉ claimer, giao thức mục tiêu, điều kiện phát hành. Tôi không thể quay lại thay đổi bất kỳ thứ nào trong các thông số đó sau khi tạo. Đó là sự cam kết.
Nếu không có Clear Signing của Ledger, thì tôi sẽ thiết lập các tham số đó thông qua một trình duyệt và tin vào giao diện người dùng hiển thị cho tôi biết rằng tôi đang đồng ý với những gì. Còn với nó, mọi thứ tôi đang phê duyệt sẽ hiện trên màn hình phần cứng của tôi bằng ngôn ngữ rõ ràng trước khi tôi ký. Việc xác minh và việc khóa vĩnh viễn là cùng một thao tác.
Lời hứa tự quản (self-custody) trong TBV là việc BTC của tôi không bao giờ rời khỏi sự kiểm soát của tôi. Clear Signing mở rộng logic đó sang chính quá trình thiết lập. Tôi có thể đọc đúng những gì mình đang cam kết, trên một thiết bị mà tôi đang giữ, trước khi nó trở nên vĩnh viễn.
Bài blog ngày 10 tháng 3 của Babylon đã nêu kế hoạch triển khai H2 năm 2026 cho phần tích hợp này. Khung thời gian đó hiện đã mở.
Điều tôi chưa tìm thấy công khai là Clear Signing bao gồm toàn bộ việc tạo vault hay chỉ áp dụng cho các hành động sau khi thiết lập. Chi tiết phạm vi đó vẫn chưa được đề cập.
$BABY @BabylonLabs_io #baby
...........
MICHAEL MOORE
·
--
Tôi đang xem cấu trúc script thực tế @BabylonLabs_io uses trên Bitcoin và một lựa chọn có chủ đích bên trong nó dường như không xuất hiện trong bất kỳ thông báo nào.
Lựa chọn đó nằm ở nền tảng của cách một giao dịch staking được xây dựng. Babylon tắt hoàn toàn cách mặc định để chi tiêu một đầu ra Taproot, thay thế bằng một hằng số toán học cụ thể không có khóa riêng. Không ai sở hữu nó. Thậm chí ngay cả đội ngũ đứng sau nó.
Điều đó có nghĩa là BTC bị khóa trong một trong các vị thế này chỉ có thể rời đi thông qua ba điều kiện được viết trực tiếp trong script. Không tồn tại lối thoát nào khác.
Điều kiện thứ nhất giải phóng quỹ sau khi khoảng thời gian cam kết theo block kết thúc, chỉ cần chữ ký của chính bên staker. Điều kiện thứ hai cho phép rút sớm khỏi unbonding, nhưng chỉ với cùng khóa đó cộng thêm ngưỡng (threshold) của một ủy ban covenant. Điều kiện thứ ba là slashing, và nó hoạt động khác biệt so với cả hai điều kiện còn lại.
Tôi cứ quay lại với điều kiện thứ ba đó. Theo đặc tả riêng của Babylon, một nhà cung cấp finality cần phối hợp để ngăn việc xảy ra nó, nhưng sự phối hợp đó không cần thiết để kích hoạt. Nếu họ double-sign, khóa của họ sẽ tự động lộ ra và giao dịch đã được pre-signed sẽ tự thực thi.
Họ không có cách nào để ngăn chặn nó.
Điều khiến tôi chú ý là không có gì trong số này đòi hỏi phải sáng tạo ra điều gì mới. Babylon đã sử dụng Taproot đúng như các nhà phát triển của Bitcoin đã định nó được dùng.
Thứ tôi vẫn đang theo dõi là lớp covenant committee sẽ phát triển như thế nào. Tài liệu của chính họ đề cập đến việc vượt ra khỏi cấu trúc hiện tại khi chức năng gốc có thể được triển khai trực tiếp trên Bitcoin.
#baby $BABY
Lựa chọn đó nằm ở nền tảng của cách một giao dịch staking được xây dựng. Babylon tắt hoàn toàn cách mặc định để chi tiêu một đầu ra Taproot, thay thế bằng một hằng số toán học cụ thể không có khóa riêng. Không ai sở hữu nó. Thậm chí ngay cả đội ngũ đứng sau nó.
Điều đó có nghĩa là BTC bị khóa trong một trong các vị thế này chỉ có thể rời đi thông qua ba điều kiện được viết trực tiếp trong script. Không tồn tại lối thoát nào khác.
Điều kiện thứ nhất giải phóng quỹ sau khi khoảng thời gian cam kết theo block kết thúc, chỉ cần chữ ký của chính bên staker. Điều kiện thứ hai cho phép rút sớm khỏi unbonding, nhưng chỉ với cùng khóa đó cộng thêm ngưỡng (threshold) của một ủy ban covenant. Điều kiện thứ ba là slashing, và nó hoạt động khác biệt so với cả hai điều kiện còn lại.
Tôi cứ quay lại với điều kiện thứ ba đó. Theo đặc tả riêng của Babylon, một nhà cung cấp finality cần phối hợp để ngăn việc xảy ra nó, nhưng sự phối hợp đó không cần thiết để kích hoạt. Nếu họ double-sign, khóa của họ sẽ tự động lộ ra và giao dịch đã được pre-signed sẽ tự thực thi.
Họ không có cách nào để ngăn chặn nó.
Điều khiến tôi chú ý là không có gì trong số này đòi hỏi phải sáng tạo ra điều gì mới. Babylon đã sử dụng Taproot đúng như các nhà phát triển của Bitcoin đã định nó được dùng.
Thứ tôi vẫn đang theo dõi là lớp covenant committee sẽ phát triển như thế nào. Tài liệu của chính họ đề cập đến việc vượt ra khỏi cấu trúc hiện tại khi chức năng gốc có thể được triển khai trực tiếp trên Bitcoin.
#baby $BABY
Đã xác minh
Tôi đang xem cấu trúc script thực tế @BabylonLabs_io uses trên Bitcoin và một lựa chọn có chủ đích bên trong nó dường như không xuất hiện trong bất kỳ thông báo nào.
Lựa chọn đó nằm ở nền tảng của cách một giao dịch staking được xây dựng. Babylon tắt hoàn toàn cách mặc định để chi tiêu một đầu ra Taproot, thay thế bằng một hằng số toán học cụ thể không có khóa riêng. Không ai sở hữu nó. Thậm chí ngay cả đội ngũ đứng sau nó.
Điều đó có nghĩa là BTC bị khóa trong một trong các vị thế này chỉ có thể rời đi thông qua ba điều kiện được viết trực tiếp trong script. Không tồn tại lối thoát nào khác.
Điều kiện thứ nhất giải phóng quỹ sau khi khoảng thời gian cam kết theo block kết thúc, chỉ cần chữ ký của chính bên staker. Điều kiện thứ hai cho phép rút sớm khỏi unbonding, nhưng chỉ với cùng khóa đó cộng thêm ngưỡng (threshold) của một ủy ban covenant. Điều kiện thứ ba là slashing, và nó hoạt động khác biệt so với cả hai điều kiện còn lại.
Tôi cứ quay lại với điều kiện thứ ba đó. Theo đặc tả riêng của Babylon, một nhà cung cấp finality cần phối hợp để ngăn việc xảy ra nó, nhưng sự phối hợp đó không cần thiết để kích hoạt. Nếu họ double-sign, khóa của họ sẽ tự động lộ ra và giao dịch đã được pre-signed sẽ tự thực thi.
Họ không có cách nào để ngăn chặn nó.
Điều khiến tôi chú ý là không có gì trong số này đòi hỏi phải sáng tạo ra điều gì mới. Babylon đã sử dụng Taproot đúng như các nhà phát triển của Bitcoin đã định nó được dùng.
Thứ tôi vẫn đang theo dõi là lớp covenant committee sẽ phát triển như thế nào. Tài liệu của chính họ đề cập đến việc vượt ra khỏi cấu trúc hiện tại khi chức năng gốc có thể được triển khai trực tiếp trên Bitcoin.
#baby $BABY
Lựa chọn đó nằm ở nền tảng của cách một giao dịch staking được xây dựng. Babylon tắt hoàn toàn cách mặc định để chi tiêu một đầu ra Taproot, thay thế bằng một hằng số toán học cụ thể không có khóa riêng. Không ai sở hữu nó. Thậm chí ngay cả đội ngũ đứng sau nó.
Điều đó có nghĩa là BTC bị khóa trong một trong các vị thế này chỉ có thể rời đi thông qua ba điều kiện được viết trực tiếp trong script. Không tồn tại lối thoát nào khác.
Điều kiện thứ nhất giải phóng quỹ sau khi khoảng thời gian cam kết theo block kết thúc, chỉ cần chữ ký của chính bên staker. Điều kiện thứ hai cho phép rút sớm khỏi unbonding, nhưng chỉ với cùng khóa đó cộng thêm ngưỡng (threshold) của một ủy ban covenant. Điều kiện thứ ba là slashing, và nó hoạt động khác biệt so với cả hai điều kiện còn lại.
Tôi cứ quay lại với điều kiện thứ ba đó. Theo đặc tả riêng của Babylon, một nhà cung cấp finality cần phối hợp để ngăn việc xảy ra nó, nhưng sự phối hợp đó không cần thiết để kích hoạt. Nếu họ double-sign, khóa của họ sẽ tự động lộ ra và giao dịch đã được pre-signed sẽ tự thực thi.
Họ không có cách nào để ngăn chặn nó.
Điều khiến tôi chú ý là không có gì trong số này đòi hỏi phải sáng tạo ra điều gì mới. Babylon đã sử dụng Taproot đúng như các nhà phát triển của Bitcoin đã định nó được dùng.
Thứ tôi vẫn đang theo dõi là lớp covenant committee sẽ phát triển như thế nào. Tài liệu của chính họ đề cập đến việc vượt ra khỏi cấu trúc hiện tại khi chức năng gốc có thể được triển khai trực tiếp trên Bitcoin.
#baby $BABY
...........
MICHAEL MOORE
·
--
Tôi đã bắt gặp một đoạn trong bài blog ngày 25/6/2026 của Babylon đã thay đổi cách tôi nhìn toàn bộ dự án.
Đoạn đó nằm trong thông báo hợp tác Aegis. Gần phần cuối: “Beyond the initial product, this integration also shows how applications can build using TBV and Aave v4.”
Câu đó đã sắp xếp lại mọi thứ. TBV cộng với Aave V4 không phải chỉ là một kênh cho vay. Đó là một lớp mở để các giao thức DeFi khác có thể xây dựng trực tiếp trên đó.
Phần lớn cuộc thảo luận vẫn xoay quanh tính năng vay của Aave. Điều tôi thấy thú vị hơn là kiến trúc được thiết kế để có thể tái sử dụng, không bị ràng buộc ngay từ đầu vào một kết quả cụ thể.
Mẫu hình này đã hiện rõ. Aegis đang xây dựng tín dụng lãi suất cố định trên chính ngăn xếp đó, vào ngày 25/6/2026. GoMining đã phát triển một sản phẩm lợi suất khai thác sử dụng cùng hạ tầng, vào ngày 5/5/2026.
Hai kết quả hoàn toàn khác nhau. Cách nhau bảy tuần.
Tôi quay lại để xác nhận rằng “first” là có chủ ý. Bài đăng trên X của chính Babylon khi Aave V4 ra mắt đã nói: “The first TBV use case is native Bitcoin borrowing on Aave v4.” Điều đó là có chủ đích.
Bản đồ lộ trình Vault First từ tháng 10/2025 đã liệt kê nơi cuối cùng điều này dẫn tới: lending, stablecoins, PERP DEX. Nhịp triển khai ban đầu cho thấy danh sách đó không phải là giả định.
Điều tôi vẫn đang theo dõi là liệu lớp này có tiếp tục chỉ dành cho Ethereum hay không. Tài liệu chính thức cho biết giao thức vault hoạt động cho mọi blockchain. Có bao nhiêu mạng thực sự tích hợp là vẫn còn bỏ ngỏ.
$BABY #baby @BabylonLabs_io
Đoạn đó nằm trong thông báo hợp tác Aegis. Gần phần cuối: “Beyond the initial product, this integration also shows how applications can build using TBV and Aave v4.”
Câu đó đã sắp xếp lại mọi thứ. TBV cộng với Aave V4 không phải chỉ là một kênh cho vay. Đó là một lớp mở để các giao thức DeFi khác có thể xây dựng trực tiếp trên đó.
Phần lớn cuộc thảo luận vẫn xoay quanh tính năng vay của Aave. Điều tôi thấy thú vị hơn là kiến trúc được thiết kế để có thể tái sử dụng, không bị ràng buộc ngay từ đầu vào một kết quả cụ thể.
Mẫu hình này đã hiện rõ. Aegis đang xây dựng tín dụng lãi suất cố định trên chính ngăn xếp đó, vào ngày 25/6/2026. GoMining đã phát triển một sản phẩm lợi suất khai thác sử dụng cùng hạ tầng, vào ngày 5/5/2026.
Hai kết quả hoàn toàn khác nhau. Cách nhau bảy tuần.
Tôi quay lại để xác nhận rằng “first” là có chủ ý. Bài đăng trên X của chính Babylon khi Aave V4 ra mắt đã nói: “The first TBV use case is native Bitcoin borrowing on Aave v4.” Điều đó là có chủ đích.
Bản đồ lộ trình Vault First từ tháng 10/2025 đã liệt kê nơi cuối cùng điều này dẫn tới: lending, stablecoins, PERP DEX. Nhịp triển khai ban đầu cho thấy danh sách đó không phải là giả định.
Điều tôi vẫn đang theo dõi là liệu lớp này có tiếp tục chỉ dành cho Ethereum hay không. Tài liệu chính thức cho biết giao thức vault hoạt động cho mọi blockchain. Có bao nhiêu mạng thực sự tích hợp là vẫn còn bỏ ngỏ.
$BABY #baby @BabylonLabs_io
Đúng một phần
Tôi đã bắt gặp một đoạn trong bài blog ngày 25/6/2026 của Babylon đã thay đổi cách tôi nhìn toàn bộ dự án.
Đoạn đó nằm trong thông báo hợp tác Aegis. Gần phần cuối: “Beyond the initial product, this integration also shows how applications can build using TBV and Aave v4.”
Câu đó đã sắp xếp lại mọi thứ. TBV cộng với Aave V4 không phải chỉ là một kênh cho vay. Đó là một lớp mở để các giao thức DeFi khác có thể xây dựng trực tiếp trên đó.
Phần lớn cuộc thảo luận vẫn xoay quanh tính năng vay của Aave. Điều tôi thấy thú vị hơn là kiến trúc được thiết kế để có thể tái sử dụng, không bị ràng buộc ngay từ đầu vào một kết quả cụ thể.
Mẫu hình này đã hiện rõ. Aegis đang xây dựng tín dụng lãi suất cố định trên chính ngăn xếp đó, vào ngày 25/6/2026. GoMining đã phát triển một sản phẩm lợi suất khai thác sử dụng cùng hạ tầng, vào ngày 5/5/2026.
Hai kết quả hoàn toàn khác nhau. Cách nhau bảy tuần.
Tôi quay lại để xác nhận rằng “first” là có chủ ý. Bài đăng trên X của chính Babylon khi Aave V4 ra mắt đã nói: “The first TBV use case is native Bitcoin borrowing on Aave v4.” Điều đó là có chủ đích.
Bản đồ lộ trình Vault First từ tháng 10/2025 đã liệt kê nơi cuối cùng điều này dẫn tới: lending, stablecoins, PERP DEX. Nhịp triển khai ban đầu cho thấy danh sách đó không phải là giả định.
Điều tôi vẫn đang theo dõi là liệu lớp này có tiếp tục chỉ dành cho Ethereum hay không. Tài liệu chính thức cho biết giao thức vault hoạt động cho mọi blockchain. Có bao nhiêu mạng thực sự tích hợp là vẫn còn bỏ ngỏ.
$BABY #baby @BabylonLabs_io
Đoạn đó nằm trong thông báo hợp tác Aegis. Gần phần cuối: “Beyond the initial product, this integration also shows how applications can build using TBV and Aave v4.”
Câu đó đã sắp xếp lại mọi thứ. TBV cộng với Aave V4 không phải chỉ là một kênh cho vay. Đó là một lớp mở để các giao thức DeFi khác có thể xây dựng trực tiếp trên đó.
Phần lớn cuộc thảo luận vẫn xoay quanh tính năng vay của Aave. Điều tôi thấy thú vị hơn là kiến trúc được thiết kế để có thể tái sử dụng, không bị ràng buộc ngay từ đầu vào một kết quả cụ thể.
Mẫu hình này đã hiện rõ. Aegis đang xây dựng tín dụng lãi suất cố định trên chính ngăn xếp đó, vào ngày 25/6/2026. GoMining đã phát triển một sản phẩm lợi suất khai thác sử dụng cùng hạ tầng, vào ngày 5/5/2026.
Hai kết quả hoàn toàn khác nhau. Cách nhau bảy tuần.
Tôi quay lại để xác nhận rằng “first” là có chủ ý. Bài đăng trên X của chính Babylon khi Aave V4 ra mắt đã nói: “The first TBV use case is native Bitcoin borrowing on Aave v4.” Điều đó là có chủ đích.
Bản đồ lộ trình Vault First từ tháng 10/2025 đã liệt kê nơi cuối cùng điều này dẫn tới: lending, stablecoins, PERP DEX. Nhịp triển khai ban đầu cho thấy danh sách đó không phải là giả định.
Điều tôi vẫn đang theo dõi là liệu lớp này có tiếp tục chỉ dành cho Ethereum hay không. Tài liệu chính thức cho biết giao thức vault hoạt động cho mọi blockchain. Có bao nhiêu mạng thực sự tích hợp là vẫn còn bỏ ngỏ.
$BABY #baby @BabylonLabs_io
Đăng nhập để khám phá thêm nội dung