Pham Kim 26
26 Bài đăng
Pham Kim 26
110 Đang theo dõi
19 Người theo dõi
21 Đã thích
Bài đăng
Trong một thời gian dài, tôi cứ nghĩ “escrow” giống như một từ an toàn mơ hồ, một khái niệm mà Binance P2P nhắc tới mà tôi không thật sự hiểu cơ chế hoạt động của nó. Mãi đến khi tôi giao dịch đủ để thấy nó vận hành ra sao, nó mới trở thành phần của hệ thống mà tôi tin tưởng nhất.
Khi người bán tạo hoặc chấp nhận một lệnh trên Binance P2P, tài sản crypto được bán sẽ không nằm tự do trong ví của họ trong suốt quá trình giao dịch; ngay khi lệnh được mở, nó sẽ bị khóa trong escrow. Trong khoảng thời gian đó, cả hai bên đều không thể truy cập vào tài sản. Người mua không thể nhận được tài sản cho đến khi người bán tự tay “thả” (release) nó, và người bán cũng không thể rút lại hoặc dùng số tiền đó ở nơi khác khi tài sản đang bị khóa. Cơ chế duy nhất này là thứ làm phần còn lại của hệ thống vận hành được: người mua có thể gửi tiền một cách an toàn vì người bán không thể “biến mất” mang theo cả tiền lẫn tài sản crypto, và người bán có thể chờ xác nhận thanh toán mà không lo tài sản sẽ tự động di chuyển. Kết hợp với xác minh KYC, chat trong ứng dụng và tùy chọn khiếu nại tranh chấp, escrow tạo thành “xương sống” mang tính cấu trúc cho việc vì sao giao dịch Binance P2P hoạt động an toàn như vậy—miễn là giao dịch diễn ra hoàn toàn trong nền tảng.
Việc hiểu điều này đã thay đổi cách tôi giao dịch theo vài cách cụ thể. Tôi ngừng lo lắng về việc liệu người bán có thể bỏ chạy với tiền của tôi hay không, vì tài sản crypto luôn bị khóa bất kể thế nào. Thay vào đó, tôi tập trung vào những phần mà escrow không thể bao phủ: kiểm tra hồ sơ của đối tác trước khi bắt đầu, xác nhận việc thanh toán thực sự đã được chuyển/hoàn tất trước khi yêu cầu thả lệnh, và theo dõi các dấu hiệu cảnh báo như sự vội vàng bất thường. Tôi cũng ghi chú đơn giản về số thứ tự lệnh (order number) và thời điểm (timestamp) cho mọi giao dịch tôi hoàn tất, đề phòng sau này cần đối chiếu chi tiết. Nếu việc thả lệnh có vẻ bị chậm vượt quá thời gian bình thường, tôi liên hệ bộ phận hỗ trợ của Binance thay vì tự cho rằng điều tệ nhất sẽ xảy ra, vì họ có thể xem trạng thái escrow trực tiếp.
@Binance Vietnam #BinanceP2PAnToan
$TUT $BLUAI
Khi người bán tạo hoặc chấp nhận một lệnh trên Binance P2P, tài sản crypto được bán sẽ không nằm tự do trong ví của họ trong suốt quá trình giao dịch; ngay khi lệnh được mở, nó sẽ bị khóa trong escrow. Trong khoảng thời gian đó, cả hai bên đều không thể truy cập vào tài sản. Người mua không thể nhận được tài sản cho đến khi người bán tự tay “thả” (release) nó, và người bán cũng không thể rút lại hoặc dùng số tiền đó ở nơi khác khi tài sản đang bị khóa. Cơ chế duy nhất này là thứ làm phần còn lại của hệ thống vận hành được: người mua có thể gửi tiền một cách an toàn vì người bán không thể “biến mất” mang theo cả tiền lẫn tài sản crypto, và người bán có thể chờ xác nhận thanh toán mà không lo tài sản sẽ tự động di chuyển. Kết hợp với xác minh KYC, chat trong ứng dụng và tùy chọn khiếu nại tranh chấp, escrow tạo thành “xương sống” mang tính cấu trúc cho việc vì sao giao dịch Binance P2P hoạt động an toàn như vậy—miễn là giao dịch diễn ra hoàn toàn trong nền tảng.
Việc hiểu điều này đã thay đổi cách tôi giao dịch theo vài cách cụ thể. Tôi ngừng lo lắng về việc liệu người bán có thể bỏ chạy với tiền của tôi hay không, vì tài sản crypto luôn bị khóa bất kể thế nào. Thay vào đó, tôi tập trung vào những phần mà escrow không thể bao phủ: kiểm tra hồ sơ của đối tác trước khi bắt đầu, xác nhận việc thanh toán thực sự đã được chuyển/hoàn tất trước khi yêu cầu thả lệnh, và theo dõi các dấu hiệu cảnh báo như sự vội vàng bất thường. Tôi cũng ghi chú đơn giản về số thứ tự lệnh (order number) và thời điểm (timestamp) cho mọi giao dịch tôi hoàn tất, đề phòng sau này cần đối chiếu chi tiết. Nếu việc thả lệnh có vẻ bị chậm vượt quá thời gian bình thường, tôi liên hệ bộ phận hỗ trợ của Binance thay vì tự cho rằng điều tệ nhất sẽ xảy ra, vì họ có thể xem trạng thái escrow trực tiếp.
@Binance Vietnam #BinanceP2PAnToan
$TUT $BLUAI
"Tôi lỡ gửi thêm cho bạn, bạn có thể hoàn lại phần chênh lệch ngay lập tức không?" Tin nhắn đó đến sau bốn phút trong một giao dịch trên Binance P2P, và đây là một trong những màn lừa đảo khá tinh ranh mà tôi từng gặp.
Cách thức hoạt động như sau: người mua gửi thông báo chuyển tiền với số tiền cao hơn thực tế mà đơn hàng yêu cầu, rồi yêu cầu người bán hoàn lại phần chênh lệch đã bị trả thừa trực tiếp qua một lần chuyển riêng, kèm theo giọng điệu gấp gáp và gây khó xử cho họ. Mấu chốt là khoản thanh toán ban đầu hoặc thậm chí không hề đến, hoặc đến muộn theo một phương thức có thể đảo ngược, trong khi khoản tiền hoàn lại của người bán thì lại được gửi đi ngay bằng tiền thật. Nếu người bán vội vàng để lịch sự vì nghĩ rằng đó là sự nhầm lẫn, họ sẽ gửi tiền thật đi trong khi nhận lại không có gì, hoặc nhận được một khoản thanh toán rồi sau đó bị thu hồi.
Thực tế, Binance P2P có kênh chính thức cho đúng tình huống này. Nếu người mua thực sự chuyển dư tiền, cách đúng là trao đổi qua chat chính thức và giải quyết phần tiền dư thông qua kháng nghị/appeal nếu cần, tuyệt đối không hoàn lại bằng một khoản chuyển riêng gửi ngoài phạm vi đơn hàng. Tôi nói thẳng điều đó với người mua, mở ứng dụng ngân hàng kiểm tra và xác nhận là chưa có khoản thanh toán nào về cả, rồi từ chối hoàn trả bất cứ thứ gì. Anh ta thì sốt ruột, sau đó im lặng, và cuối cùng đơn hàng tự hết hạn.
Thứ khiến chiêu lừa này hiệu quả là nó nghe rất hợp lý. Không ai muốn tỏ ra khó khăn với những gì trông giống như một sai sót chân thành, và kẻ lừa đảo dựa vào phản xạ lịch sự đó nhiều hơn là dựa vào bất kỳ mánh kỹ thuật nào.
Từ ngày đó, tôi có một nguyên tắc: mọi yêu cầu liên quan đến hoàn tiền, một lần thanh toán thứ hai, hoặc việc chuyển tiền ra ngoài chính đơn hàng đều được xem là dấu hiệu đỏ ngay lập tức—không có ngoại lệ dù tin nhắn có lịch sự hay xin lỗi đến đâu. Hệ thống ký quỹ (escrow) và kháng nghị của Binance P2P tồn tại chính xác để người bán không phải tự đưa ra phán đoán đó một mình dưới áp lực, và việc sử dụng chúng sẽ tốt hơn nhiều so với cố tỏ ra là người biết điều trước một yêu cầu đáng ngờ.
@Binance Vietnam #BinanceP2PAnToan
$ACE
Cách thức hoạt động như sau: người mua gửi thông báo chuyển tiền với số tiền cao hơn thực tế mà đơn hàng yêu cầu, rồi yêu cầu người bán hoàn lại phần chênh lệch đã bị trả thừa trực tiếp qua một lần chuyển riêng, kèm theo giọng điệu gấp gáp và gây khó xử cho họ. Mấu chốt là khoản thanh toán ban đầu hoặc thậm chí không hề đến, hoặc đến muộn theo một phương thức có thể đảo ngược, trong khi khoản tiền hoàn lại của người bán thì lại được gửi đi ngay bằng tiền thật. Nếu người bán vội vàng để lịch sự vì nghĩ rằng đó là sự nhầm lẫn, họ sẽ gửi tiền thật đi trong khi nhận lại không có gì, hoặc nhận được một khoản thanh toán rồi sau đó bị thu hồi.
Thực tế, Binance P2P có kênh chính thức cho đúng tình huống này. Nếu người mua thực sự chuyển dư tiền, cách đúng là trao đổi qua chat chính thức và giải quyết phần tiền dư thông qua kháng nghị/appeal nếu cần, tuyệt đối không hoàn lại bằng một khoản chuyển riêng gửi ngoài phạm vi đơn hàng. Tôi nói thẳng điều đó với người mua, mở ứng dụng ngân hàng kiểm tra và xác nhận là chưa có khoản thanh toán nào về cả, rồi từ chối hoàn trả bất cứ thứ gì. Anh ta thì sốt ruột, sau đó im lặng, và cuối cùng đơn hàng tự hết hạn.
Thứ khiến chiêu lừa này hiệu quả là nó nghe rất hợp lý. Không ai muốn tỏ ra khó khăn với những gì trông giống như một sai sót chân thành, và kẻ lừa đảo dựa vào phản xạ lịch sự đó nhiều hơn là dựa vào bất kỳ mánh kỹ thuật nào.
Từ ngày đó, tôi có một nguyên tắc: mọi yêu cầu liên quan đến hoàn tiền, một lần thanh toán thứ hai, hoặc việc chuyển tiền ra ngoài chính đơn hàng đều được xem là dấu hiệu đỏ ngay lập tức—không có ngoại lệ dù tin nhắn có lịch sự hay xin lỗi đến đâu. Hệ thống ký quỹ (escrow) và kháng nghị của Binance P2P tồn tại chính xác để người bán không phải tự đưa ra phán đoán đó một mình dưới áp lực, và việc sử dụng chúng sẽ tốt hơn nhiều so với cố tỏ ra là người biết điều trước một yêu cầu đáng ngờ.
@Binance Vietnam #BinanceP2PAnToan
$ACE
Tôi coi một giao dịch P2P Binance đã hết hạn hoặc bị hủy là một mốc ranh giới “cứng”. Nếu tiền được chuyển đi sau mốc đó, tôi không khôi phục lại thỏa thuận cũ bằng cách thỏa thuận riêng. Giá được báo có thể đã thay đổi, ký quỹ có thể không còn bảo vệ cho việc chuyển tiền như dự định, và mốc thời gian của lệnh có thể không còn hỗ trợ hành động mà bên đối tác hiện muốn thực hiện.
Với vai trò người mua, tôi kiểm tra thời gian đếm ngược thanh toán trước khi gửi tiền. Tôi chỉ sử dụng thụ hưởng hiển thị trong lệnh đang hoạt động, thanh toán từ tài khoản khớp với tên đã được xác minh của tôi, và chỉ đánh dấu đã thanh toán sau khi tôi thật sự chuyển đúng số tiền. Nếu lệnh đóng trước, tôi không chuyển tiền và yêu cầu người bán tự phát hành theo cách thủ công. Nếu đã xảy ra thanh toán muộn hoặc thanh toán trùng lặp, tôi liên hệ với Bộ phận Hỗ trợ của Binance.
Với vai trò người bán, tôi xác minh trạng thái của lệnh trước khi nhả (phát hành) crypto. Việc người mua nói rằng “đã thanh toán” không làm hồi phục một giao dịch đã bị hủy. Tôi mở tài khoản ngân hàng hoặc ứng dụng thanh toán của mình, xác định người gửi, đối chiếu số tiền và xác nhận liệu tiền đã được chuyển/ghi nhận (settled) hay chưa. Tôi giữ crypto chưa bị đụng đến trong khi mô tả vấn đề về thời điểm trong cuộc chat của lệnh Binance hoặc trong kênh Hỗ trợ chính thức. Tôi không hoàn tiền sang một tài khoản mới do bên kia cung cấp vội trong tin nhắn gấp gáp, vì điều đó có thể tách khoản hoàn từ đúng người trả ban đầu.
Danh sách cảnh báo của tôi bao gồm các yêu cầu tiếp tục ở nơi khác, mở một lệnh mới nhưng tính một khoản thanh toán cũ, chấp nhận người gửi từ bên thứ ba, hoặc nhả lệnh theo mức giá đã hết hạn. Tôi lưu số lệnh cũ, mốc thời gian, đoạn chat, mã giao dịch thanh toán (payment transaction ID) và bất kỳ số lệnh mới nào. Các liên kết đó quan trọng nếu cần kháng nghị hoặc quá trình xem xét của Hỗ trợ.
KYC, ký quỹ, chat và phần Kháng nghị bảo vệ một giao dịch nền tảng được xác định rõ. Chúng không phải là sự đảm bảo toàn diện cho các thỏa thuận “bên ngoài” được lắp ghép sau khi lệnh kết thúc. Tôi tôn trọng trạng thái của lệnh nhiều như tôi tôn trọng số tiền thanh toán. Trình tự của tôi là: lệnh đang hoạt động, khớp danh tính, tài khoản được chỉ định, tiền đã được ghi nhận, và đã xác nhận nhả hàng. Nếu đồng hồ làm gãy chuỗi đó, tôi sẽ dừng lại và để Bộ phận Hỗ trợ của Binance hướng dẫn bước tiếp theo.
@Binance Vietnam #BinanceP2PAnToan
$BLESS
Với vai trò người mua, tôi kiểm tra thời gian đếm ngược thanh toán trước khi gửi tiền. Tôi chỉ sử dụng thụ hưởng hiển thị trong lệnh đang hoạt động, thanh toán từ tài khoản khớp với tên đã được xác minh của tôi, và chỉ đánh dấu đã thanh toán sau khi tôi thật sự chuyển đúng số tiền. Nếu lệnh đóng trước, tôi không chuyển tiền và yêu cầu người bán tự phát hành theo cách thủ công. Nếu đã xảy ra thanh toán muộn hoặc thanh toán trùng lặp, tôi liên hệ với Bộ phận Hỗ trợ của Binance.
Với vai trò người bán, tôi xác minh trạng thái của lệnh trước khi nhả (phát hành) crypto. Việc người mua nói rằng “đã thanh toán” không làm hồi phục một giao dịch đã bị hủy. Tôi mở tài khoản ngân hàng hoặc ứng dụng thanh toán của mình, xác định người gửi, đối chiếu số tiền và xác nhận liệu tiền đã được chuyển/ghi nhận (settled) hay chưa. Tôi giữ crypto chưa bị đụng đến trong khi mô tả vấn đề về thời điểm trong cuộc chat của lệnh Binance hoặc trong kênh Hỗ trợ chính thức. Tôi không hoàn tiền sang một tài khoản mới do bên kia cung cấp vội trong tin nhắn gấp gáp, vì điều đó có thể tách khoản hoàn từ đúng người trả ban đầu.
Danh sách cảnh báo của tôi bao gồm các yêu cầu tiếp tục ở nơi khác, mở một lệnh mới nhưng tính một khoản thanh toán cũ, chấp nhận người gửi từ bên thứ ba, hoặc nhả lệnh theo mức giá đã hết hạn. Tôi lưu số lệnh cũ, mốc thời gian, đoạn chat, mã giao dịch thanh toán (payment transaction ID) và bất kỳ số lệnh mới nào. Các liên kết đó quan trọng nếu cần kháng nghị hoặc quá trình xem xét của Hỗ trợ.
KYC, ký quỹ, chat và phần Kháng nghị bảo vệ một giao dịch nền tảng được xác định rõ. Chúng không phải là sự đảm bảo toàn diện cho các thỏa thuận “bên ngoài” được lắp ghép sau khi lệnh kết thúc. Tôi tôn trọng trạng thái của lệnh nhiều như tôi tôn trọng số tiền thanh toán. Trình tự của tôi là: lệnh đang hoạt động, khớp danh tính, tài khoản được chỉ định, tiền đã được ghi nhận, và đã xác nhận nhả hàng. Nếu đồng hồ làm gãy chuỗi đó, tôi sẽ dừng lại và để Bộ phận Hỗ trợ của Binance hướng dẫn bước tiếp theo.
@Binance Vietnam #BinanceP2PAnToan
$BLESS
Hãy nói rằng mô hình quản trị của Babylon là công bằng và hợp lý, thì người ta sẽ gật đầu đồng tình; hãy nói rằng đó là một sự không khớp về cấu trúc và người ta cũng sẽ gật đầu đồng tình với điều đó. Cả hai phản ứng đều đang đáp lại cùng một lựa chọn thiết kế có thật.
Những người nắm giữ token BABY là nhóm bỏ phiếu cho các đề xuất Babylon Genesis—đó là thiết lập tiêu chuẩn cho một chuỗi Cosmos SDK, trong đó token bản địa mang quyền quản trị; phù hợp với cách mà về cơ bản mọi chuỗi tương đương trong hệ sinh thái này vận hành. Còn những người stake BTC—những người thực sự khóa lượng giá trị hàng tỷ đô la Bitcoin để cung cấp bảo mật mà Babylon bán ra cho các mạng bên ngoài—không có một cuộc bỏ phiếu on-chain tương đương dựa trên chính vị thế BTC đó. Về mặt thuần túy kiến trúc, điều này là hợp lý: người stake BTC tương tác với chính blockchain của Bitcoin, chứ không phải Babylon Genesis, nên việc chuyển quyền quản trị qua token bản địa là thiết kế thông lệ. Nhưng về góc độ động lực, nó lại có vẻ kỳ lạ: nhóm phải chịu rủi ro bị cắt phạt và bị khóa vốn thực sự lại có ít tiếng nói chính thức hơn so với nhóm nắm giữ một token mà, tính đến giữa năm 2026, đang giao dịch với chỉ một phần nhỏ giá trị mà những người stake BTC—tập thể—đang cung cấp.
Cộng đồng Babylon chắc chắn đã tự nhận ra sự căng thẳng này. Đã có đề xuất đồng-staking BTC-BABY được đưa ra với mục đích cụ thể là căn chỉnh động lực giữa hai nhóm stake và giảm lạm phát—điều chỉ xảy ra khi đã tồn tại một bất đồng thực sự trực tiếp về cách chia hiện tại.
Thiết kế quản trị của Babylon là điều có thể bảo vệ được, không hẳn là đúng một cách hiển nhiên. Việc định tuyến các phiếu bầu qua BABY phù hợp với thực hành chuẩn của Cosmos SDK, nhưng nó để những người stake BTC—nhóm cung cấp vốn bảo mật trị giá nhiều tỷ đô la—trở nên thiếu quyền lực chính thức trực tiếp, một sự căng thẳng mà chính đề xuất đồng-staking của dự án gợi ý rằng nội bộ vẫn chưa hoàn toàn được giải quyết.
@BabylonLabs_io $BABY #baby
$BLESS
Những người nắm giữ token BABY là nhóm bỏ phiếu cho các đề xuất Babylon Genesis—đó là thiết lập tiêu chuẩn cho một chuỗi Cosmos SDK, trong đó token bản địa mang quyền quản trị; phù hợp với cách mà về cơ bản mọi chuỗi tương đương trong hệ sinh thái này vận hành. Còn những người stake BTC—những người thực sự khóa lượng giá trị hàng tỷ đô la Bitcoin để cung cấp bảo mật mà Babylon bán ra cho các mạng bên ngoài—không có một cuộc bỏ phiếu on-chain tương đương dựa trên chính vị thế BTC đó. Về mặt thuần túy kiến trúc, điều này là hợp lý: người stake BTC tương tác với chính blockchain của Bitcoin, chứ không phải Babylon Genesis, nên việc chuyển quyền quản trị qua token bản địa là thiết kế thông lệ. Nhưng về góc độ động lực, nó lại có vẻ kỳ lạ: nhóm phải chịu rủi ro bị cắt phạt và bị khóa vốn thực sự lại có ít tiếng nói chính thức hơn so với nhóm nắm giữ một token mà, tính đến giữa năm 2026, đang giao dịch với chỉ một phần nhỏ giá trị mà những người stake BTC—tập thể—đang cung cấp.
Cộng đồng Babylon chắc chắn đã tự nhận ra sự căng thẳng này. Đã có đề xuất đồng-staking BTC-BABY được đưa ra với mục đích cụ thể là căn chỉnh động lực giữa hai nhóm stake và giảm lạm phát—điều chỉ xảy ra khi đã tồn tại một bất đồng thực sự trực tiếp về cách chia hiện tại.
Thiết kế quản trị của Babylon là điều có thể bảo vệ được, không hẳn là đúng một cách hiển nhiên. Việc định tuyến các phiếu bầu qua BABY phù hợp với thực hành chuẩn của Cosmos SDK, nhưng nó để những người stake BTC—nhóm cung cấp vốn bảo mật trị giá nhiều tỷ đô la—trở nên thiếu quyền lực chính thức trực tiếp, một sự căng thẳng mà chính đề xuất đồng-staking của dự án gợi ý rằng nội bộ vẫn chưa hoàn toàn được giải quyết.
@BabylonLabs_io $BABY #baby
$BLESS
Các cầu nối giúp kết nối Bitcoin với một blockchain khác thường dựa vào một nhóm được cấp phép để bắt gian lận: một nhóm người giám sát được trả phí, có nhiệm vụ phát hiện nếu ai đó cố gắng đòi BTC mà họ không được nhận. Nhóm đó tự thân đã là một giả định về niềm tin, và tài liệu “vault” (kho tiền) của Babylon, phát hành vào tháng 8 năm 2025, chỉ ra rằng hiện không có cách nào để xây một cầu nối Bitcoin hoàn toàn phi tín nhiệm bằng ngôn ngữ kịch bản của Bitcoin như nó tồn tại ngày nay, vì Bitcoin vẫn thiếu các opcode hợp ước (covenant) như OP-CAT.
Các “Trustless Bitcoin Vaults” (vault Bitcoin phi tín nhiệm) xử lý khoảng trống đó theo cách khác. Các yêu cầu hoàn trả và thanh lý đối với TBV được xác minh thông qua các bằng chứng không kiến thức về điều gì đã xảy ra trên chuỗi chủ, gắn với hai nhánh Aave v4 chuyên biệt: Babylon Core Lending Spoke và BTC Vault Swap Spoke. Mọi yêu cầu thiếu một bằng chứng hợp lệ đều có thể bị phản biện trong một “khung thời gian đưa ra bằng chứng gian lận” trước khi được xác nhận. Thiết kế của Babylon đi xa hơn đa số ở chỗ đảm bảo rằng người gửi tiền luôn đủ điều kiện để tự mình đóng vai trò là người phản biện, vì vậy việc bảo vệ BTC không nhất thiết phải phụ thuộc vào việc cần một người giám sát trả phí xuất hiện đúng lúc.
Lựa chọn đó có một cái giá thực sự. Cho phép người gửi tiền trở thành tuyến phòng thủ cuối cùng đồng nghĩa an toàn một phần phụ thuộc vào việc người dùng có thực sự theo dõi các vị thế đang mở hay không, trên một hệ thống chỉ mới tồn tại trên public testnet kể từ ngày 2 tháng 6 năm 2026—một gánh nặng lớn hơn nhiều so với việc chỉ cần bấm “approve” một lần rồi bỏ đi.
Babylon không chỉ loại bỏ một ủy ban ký tên khỏi TBV, mà còn đẩy việc bắt gian lận xuống cho người nắm rủi ro lớn nhất: người gửi tiền. Đây là một sự đánh đổi có chủ ý giữa sự tiện lợi và tính “thuần” về mặt kiến trúc, và nó chỉ mang lại lợi ích cho những người dùng hiểu họ đang bảo vệ điều gì.
@BabylonLabs_io $BABY #baby
$BLESS
Các “Trustless Bitcoin Vaults” (vault Bitcoin phi tín nhiệm) xử lý khoảng trống đó theo cách khác. Các yêu cầu hoàn trả và thanh lý đối với TBV được xác minh thông qua các bằng chứng không kiến thức về điều gì đã xảy ra trên chuỗi chủ, gắn với hai nhánh Aave v4 chuyên biệt: Babylon Core Lending Spoke và BTC Vault Swap Spoke. Mọi yêu cầu thiếu một bằng chứng hợp lệ đều có thể bị phản biện trong một “khung thời gian đưa ra bằng chứng gian lận” trước khi được xác nhận. Thiết kế của Babylon đi xa hơn đa số ở chỗ đảm bảo rằng người gửi tiền luôn đủ điều kiện để tự mình đóng vai trò là người phản biện, vì vậy việc bảo vệ BTC không nhất thiết phải phụ thuộc vào việc cần một người giám sát trả phí xuất hiện đúng lúc.
Lựa chọn đó có một cái giá thực sự. Cho phép người gửi tiền trở thành tuyến phòng thủ cuối cùng đồng nghĩa an toàn một phần phụ thuộc vào việc người dùng có thực sự theo dõi các vị thế đang mở hay không, trên một hệ thống chỉ mới tồn tại trên public testnet kể từ ngày 2 tháng 6 năm 2026—một gánh nặng lớn hơn nhiều so với việc chỉ cần bấm “approve” một lần rồi bỏ đi.
Babylon không chỉ loại bỏ một ủy ban ký tên khỏi TBV, mà còn đẩy việc bắt gian lận xuống cho người nắm rủi ro lớn nhất: người gửi tiền. Đây là một sự đánh đổi có chủ ý giữa sự tiện lợi và tính “thuần” về mặt kiến trúc, và nó chỉ mang lại lợi ích cho những người dùng hiểu họ đang bảo vệ điều gì.
@BabylonLabs_io $BABY #baby
$BLESS
Alpha season rồi các con vk ơi, Top gain toàn coin alpha thế này 🤣🤣🤣
$BLESS $memes
$BLESS $memes
Tôi đã thấy mọi người dùng LBTC, SolvBTC và Babylon thay thế cho nhau trong cùng một câu, như thể chúng là 3 tên gọi cho một sản phẩm. Đây là sự nhầm lẫn có thể hiểu được. Cả 3 đều xuất hiện trong cùng các cuộc trò chuyện BTCFi, cả 3 đều truy về việc bitcoin được staking thông qua giao thức của Babylon, và cả 3 đều được quảng bá như những cách để biến bitcoin nhàn rỗi thành tài sản sinh lời.
Chúng không phải là một thứ giống nhau, và sự khác biệt sẽ quan trọng nếu bạn quan tâm đến việc mình thực sự đang đặt niềm tin vào điều gì. LBTC của Lombard được phát hành và chuộc lại bởi một Security Consortium bao gồm các nút tổ chức như Galaxy và Wintermute—một nhóm bên mà bạn đang tin để vận hành quy trình đó một cách trung thực. Solv's SolvBTC định tuyến thông qua Staking Abstraction Layer riêng của họ, còn stBTC của Lorenzo được phát hành bởi các Staking Agents được chỉ định, chịu trách nhiệm staking quỹ của người dùng và báo cáo các bằng chứng (proofs) trở lại. Mỗi bên trong số đó là một công ty riêng, xếp chồng các giả định về mức độ tin cậy của chính họ lên giao thức staking nền tảng của Babylon. Các Trustless Bitcoin Vaults (TBV) của Babylon là một câu chuyện hoàn toàn khác: đó là một “primitive” của bên thứ nhất, nơi BTC được lưu trong một vault tự quản (self-custodial), vault đã được ký trước (pre-signed) và được khóa truy cập bằng các bằng chứng zero-knowledge, không có consortium hay staking agent nào “đúc” bất cứ thứ gì thay cho bạn.
Babylon là lớp thanh toán và bảo mật nằm bên dưới LBTC, SolvBTC và stBTC—không phải là một cách đổi thương hiệu (rebrand) của bất kỳ cái nào trong số đó—and TBV là sản phẩm riêng của Babylon, nằm cạnh các lớp bọc (wrappers) đó chứ không nằm bên trong chúng.
@BabylonLabs_io $BABY #baby
$WMTX
Chúng không phải là một thứ giống nhau, và sự khác biệt sẽ quan trọng nếu bạn quan tâm đến việc mình thực sự đang đặt niềm tin vào điều gì. LBTC của Lombard được phát hành và chuộc lại bởi một Security Consortium bao gồm các nút tổ chức như Galaxy và Wintermute—một nhóm bên mà bạn đang tin để vận hành quy trình đó một cách trung thực. Solv's SolvBTC định tuyến thông qua Staking Abstraction Layer riêng của họ, còn stBTC của Lorenzo được phát hành bởi các Staking Agents được chỉ định, chịu trách nhiệm staking quỹ của người dùng và báo cáo các bằng chứng (proofs) trở lại. Mỗi bên trong số đó là một công ty riêng, xếp chồng các giả định về mức độ tin cậy của chính họ lên giao thức staking nền tảng của Babylon. Các Trustless Bitcoin Vaults (TBV) của Babylon là một câu chuyện hoàn toàn khác: đó là một “primitive” của bên thứ nhất, nơi BTC được lưu trong một vault tự quản (self-custodial), vault đã được ký trước (pre-signed) và được khóa truy cập bằng các bằng chứng zero-knowledge, không có consortium hay staking agent nào “đúc” bất cứ thứ gì thay cho bạn.
Babylon là lớp thanh toán và bảo mật nằm bên dưới LBTC, SolvBTC và stBTC—không phải là một cách đổi thương hiệu (rebrand) của bất kỳ cái nào trong số đó—and TBV là sản phẩm riêng của Babylon, nằm cạnh các lớp bọc (wrappers) đó chứ không nằm bên trong chúng.
@BabylonLabs_io $BABY #baby
$WMTX
Thông báo huy động vốn là tin tức crypto dễ bị thổi phồng nhất, nên tôi cố gắng đọc chúng theo góc nhìn chúng báo hiệu điều gì về mức độ quyết tâm, chứ không coi đó là bằng chứng rằng sản phẩm tự thân đã thành công. Bảng cổ phần của Babylon cho tôi rất nhiều thứ để phân tích.
Danh sách bao gồm Polychain Capital, Hack VC, Paradigm, Galaxy Digital và một khoản đầu tư 15 triệu đô la từ a16z crypto cụ thể, cùng với nhiều quỹ khác. Đây thực sự là một “dàn ghế sâu” các nhà đầu tư—những người hiểu rõ hạ tầng crypto đủ để đã nói “không” với rất nhiều bản chào DeFi Bitcoin cạnh tranh. Việc đặt cược vào tài sản thế chấp native BTC, được cung cấp thông qua Trustless Bitcoin Vaults và Aave v4 thay vì mô hình bọc token (wrapped) hay mô hình cầu nối (bridged), là một lựa chọn luận điểm thực sự trong số nhiều phương án thay thế.
Tuy vậy, tôi vẫn sẽ không để điều đó thay thế cho bằng chứng rằng sản phẩm hoạt động tốt cho những người không được trả tiền để sử dụng nó. Hoạt động trên testnet gắn với các chiến dịch khuyến khích cho bạn biết rất ít về nhu cầu xuất phát tự nhiên, và mọi giao thức tôi đã theo dõi qua nhiều năm đều buộc phải chứng minh “khoảng trống” đó được lấp đầy sau khi mainnet đi vào hoạt động—khi phần thưởng cạn dần và chỉ còn chính cơ chế của sản phẩm để tự biện minh cho việc người dùng tiếp tục dùng.
Niềm tin về vốn từ các nhà đầu tư nghiêm túc là một tín hiệu thật về đội ngũ và luận điểm. Nó không phải là tín hiệu về việc liệu một người nắm giữ Bitcoin không có động lực từ chiến dịch có chọn Babylon thay vì chỉ đơn giản giữ BTC và không làm gì với nó hay không. Điểm chứng minh thứ hai đó vẫn chưa xảy ra.
@BabylonLabs_io $BABY #baby
$GIGGLE
Danh sách bao gồm Polychain Capital, Hack VC, Paradigm, Galaxy Digital và một khoản đầu tư 15 triệu đô la từ a16z crypto cụ thể, cùng với nhiều quỹ khác. Đây thực sự là một “dàn ghế sâu” các nhà đầu tư—những người hiểu rõ hạ tầng crypto đủ để đã nói “không” với rất nhiều bản chào DeFi Bitcoin cạnh tranh. Việc đặt cược vào tài sản thế chấp native BTC, được cung cấp thông qua Trustless Bitcoin Vaults và Aave v4 thay vì mô hình bọc token (wrapped) hay mô hình cầu nối (bridged), là một lựa chọn luận điểm thực sự trong số nhiều phương án thay thế.
Tuy vậy, tôi vẫn sẽ không để điều đó thay thế cho bằng chứng rằng sản phẩm hoạt động tốt cho những người không được trả tiền để sử dụng nó. Hoạt động trên testnet gắn với các chiến dịch khuyến khích cho bạn biết rất ít về nhu cầu xuất phát tự nhiên, và mọi giao thức tôi đã theo dõi qua nhiều năm đều buộc phải chứng minh “khoảng trống” đó được lấp đầy sau khi mainnet đi vào hoạt động—khi phần thưởng cạn dần và chỉ còn chính cơ chế của sản phẩm để tự biện minh cho việc người dùng tiếp tục dùng.
Niềm tin về vốn từ các nhà đầu tư nghiêm túc là một tín hiệu thật về đội ngũ và luận điểm. Nó không phải là tín hiệu về việc liệu một người nắm giữ Bitcoin không có động lực từ chiến dịch có chọn Babylon thay vì chỉ đơn giản giữ BTC và không làm gì với nó hay không. Điểm chứng minh thứ hai đó vẫn chưa xảy ra.
@BabylonLabs_io $BABY #baby
$GIGGLE
Các nhà đầu tư nắm giữ Bitcoin lẻ không phải là nhóm khán giả duy nhất mà Babylon nghĩ tới khi thiết kế Trustless Bitcoin Vaults, và tôi cho rằng đây là phần ít được để ý trong câu chuyện này. Babylon đang hợp tác với Utila, một nền tảng ví MPC dành cho tổ chức được hơn 300 tổ chức tin cậy, bao gồm các sàn giao dịch, công ty lưu ký, quỹ phòng hộ và ngân hàng, để mang tính năng vay mượn dựa trực tiếp trên Bitcoin được hậu thuẫn (native Bitcoin-backed borrowing) với Aave v4 tới các khách hàng tổ chức của Utila.
Chi tiết này thay đổi cách tôi nghĩ về việc ai sẽ là bên đi đầu khi công nghệ này được triển khai. Người nắm giữ cá nhân quan tâm đến việc tự lưu ký vì cả lý do triết học lẫn thực tiễn, nhưng các tổ chức lại có một bộ yêu cầu hoàn toàn khác, thường nghiêm ngặt hơn, xoay quanh rủi ro đối tác, xác nhận lưu ký và các kiểm soát vận hành. Một tổ chức nắm giữ một lượng lớn Bitcoin theo dạng native đã từng phải đối mặt với lựa chọn không mấy dễ chịu: để nó ở trạng thái nhàn rỗi và không sinh lợi, hoặc giao cho bên lưu ký và chấp nhận rủi ro đối tác chỉ để tiếp cận các thị trường cho vay. Mục tiêu đề xuất của Babylon với các nền tảng như Utila là việc vay mượn được hậu thuẫn trực tiếp bằng BTC sẽ loại bỏ sự đánh đổi đó mà không buộc các tổ chức từ bỏ mô hình lưu ký vận hành mà họ đã tin tưởng.
Việc vay mượn dựa trên Bitcoin được hậu thuẫn trực tiếp thông qua Trustless Bitcoin Vaults của Babylon đã hoạt động trên mạng thử nghiệm công khai với Aave v4 ngay hôm nay. Những tích hợp cho tổ chức như trường hợp này vẫn được mô tả là sẽ đến trong vài tháng tới thay vì đang diễn ra ngay lúc này. Khoảng trống giữa thông báo và dòng chảy tích hợp trực tiếp của tổ chức là điều đáng theo dõi sát sao.
Tôi cứ tự hỏi liệu các tổ chức có thực sự triển khai một quy mô đáng kể vào một hệ thống vẫn đang ở giai đoạn testnet và vẫn chờ phê duyệt quản trị của Aave về các tham số rủi ro cuối cùng hay không, hay điều này chỉ trở thành khối lượng thực sự khi mainnet được kích hoạt. Thông báo thì rẻ. Dòng vốn tổ chức xuất hiện mới là tín hiệu.
@BabylonLabs_io $BABY #baby
$COTI
Chi tiết này thay đổi cách tôi nghĩ về việc ai sẽ là bên đi đầu khi công nghệ này được triển khai. Người nắm giữ cá nhân quan tâm đến việc tự lưu ký vì cả lý do triết học lẫn thực tiễn, nhưng các tổ chức lại có một bộ yêu cầu hoàn toàn khác, thường nghiêm ngặt hơn, xoay quanh rủi ro đối tác, xác nhận lưu ký và các kiểm soát vận hành. Một tổ chức nắm giữ một lượng lớn Bitcoin theo dạng native đã từng phải đối mặt với lựa chọn không mấy dễ chịu: để nó ở trạng thái nhàn rỗi và không sinh lợi, hoặc giao cho bên lưu ký và chấp nhận rủi ro đối tác chỉ để tiếp cận các thị trường cho vay. Mục tiêu đề xuất của Babylon với các nền tảng như Utila là việc vay mượn được hậu thuẫn trực tiếp bằng BTC sẽ loại bỏ sự đánh đổi đó mà không buộc các tổ chức từ bỏ mô hình lưu ký vận hành mà họ đã tin tưởng.
Việc vay mượn dựa trên Bitcoin được hậu thuẫn trực tiếp thông qua Trustless Bitcoin Vaults của Babylon đã hoạt động trên mạng thử nghiệm công khai với Aave v4 ngay hôm nay. Những tích hợp cho tổ chức như trường hợp này vẫn được mô tả là sẽ đến trong vài tháng tới thay vì đang diễn ra ngay lúc này. Khoảng trống giữa thông báo và dòng chảy tích hợp trực tiếp của tổ chức là điều đáng theo dõi sát sao.
Tôi cứ tự hỏi liệu các tổ chức có thực sự triển khai một quy mô đáng kể vào một hệ thống vẫn đang ở giai đoạn testnet và vẫn chờ phê duyệt quản trị của Aave về các tham số rủi ro cuối cùng hay không, hay điều này chỉ trở thành khối lượng thực sự khi mainnet được kích hoạt. Thông báo thì rẻ. Dòng vốn tổ chức xuất hiện mới là tín hiệu.
@BabylonLabs_io $BABY #baby
$COTI
Việc thanh lý trên Bitcoin gặp vấn đề về thời điểm mà các đợt thanh lý trên Ethereum không gặp. Việc chuộc BTC gốc từ một vault chạy theo nhịp thanh toán riêng của Bitcoin, và không có cách nào để ép nhanh hơn mà không trao cho ai đó quyền giám quản đối với các đồng coin—điều này sẽ làm hỏng toàn bộ mục đích thiết kế ngay từ đầu.
Câu trả lời của Babylon và Aave là tách hai sự kiện này ra. Khi một vault bị thanh lý, nó sẽ được hoán đổi ngay sang WBTC, vì vậy vị thế của bên cho vay được thanh toán ngay lập tức theo dòng thời gian của Ethereum. Còn việc chuộc lại BTC gốc thực sự sẽ diễn ra riêng rẽ sau đó, theo nhịp của Bitcoin, mà không làm chậm tiến độ xử lý khoản vay của bất kỳ ai khác trên thị trường. Ở đây còn có một lợi ích thứ hai nữa. Hiện tại, Aave đang nắm giữ gần 5 tỷ đô la nguồn cung WBTC mà Babylon đã mô tả là đang được sử dụng chưa hiệu quả ở phía bên đi vay, nên việc chuyển việc thanh toán thanh lý thông qua đó cũng giúp đưa một phần lượng WBTC nhàn rỗi đó quay trở lại hoạt động.
Phương án thay thế sẽ là buộc mọi đợt thanh lý phải chờ xác nhận Bitcoin bản địa và logic chuộc từ chính vault trước khi bên cho vay nhìn thấy bất kỳ sự giải quyết nào. Cách này “thuần triết” hơn về mặt triết lý, không có tài sản bọc nào (wrapped) bị chạm tới ở bất kỳ thời điểm nào, nhưng đồng nghĩa với việc các đợt thanh lý sẽ diễn ra với tốc độ của Bitcoin đúng vào khoảnh khắc mà tốc độ là thứ bảo vệ bên cho vay khỏi các khoản lỗ tiếp theo.
Babylon không phải “không dùng wrap” hoàn toàn từ đầu đến cuối; nó “không dùng wrap” cho con đường mà đa số người dùng thực sự sẽ đi. Ở giai đoạn thanh lý cụ thể, Babylon đã chọn tốc độ cho bên cho vay thay vì sự thuần khiết cho lối thoát của bên đi vay—một sự đánh đổi có thể bảo vệ được, nhưng dù sao thì vẫn là một sự đánh đổi.
@BabylonLabs_io $BABY #baby
$BANK
Câu trả lời của Babylon và Aave là tách hai sự kiện này ra. Khi một vault bị thanh lý, nó sẽ được hoán đổi ngay sang WBTC, vì vậy vị thế của bên cho vay được thanh toán ngay lập tức theo dòng thời gian của Ethereum. Còn việc chuộc lại BTC gốc thực sự sẽ diễn ra riêng rẽ sau đó, theo nhịp của Bitcoin, mà không làm chậm tiến độ xử lý khoản vay của bất kỳ ai khác trên thị trường. Ở đây còn có một lợi ích thứ hai nữa. Hiện tại, Aave đang nắm giữ gần 5 tỷ đô la nguồn cung WBTC mà Babylon đã mô tả là đang được sử dụng chưa hiệu quả ở phía bên đi vay, nên việc chuyển việc thanh toán thanh lý thông qua đó cũng giúp đưa một phần lượng WBTC nhàn rỗi đó quay trở lại hoạt động.
Phương án thay thế sẽ là buộc mọi đợt thanh lý phải chờ xác nhận Bitcoin bản địa và logic chuộc từ chính vault trước khi bên cho vay nhìn thấy bất kỳ sự giải quyết nào. Cách này “thuần triết” hơn về mặt triết lý, không có tài sản bọc nào (wrapped) bị chạm tới ở bất kỳ thời điểm nào, nhưng đồng nghĩa với việc các đợt thanh lý sẽ diễn ra với tốc độ của Bitcoin đúng vào khoảnh khắc mà tốc độ là thứ bảo vệ bên cho vay khỏi các khoản lỗ tiếp theo.
Babylon không phải “không dùng wrap” hoàn toàn từ đầu đến cuối; nó “không dùng wrap” cho con đường mà đa số người dùng thực sự sẽ đi. Ở giai đoạn thanh lý cụ thể, Babylon đã chọn tốc độ cho bên cho vay thay vì sự thuần khiết cho lối thoát của bên đi vay—một sự đánh đổi có thể bảo vệ được, nhưng dù sao thì vẫn là một sự đánh đổi.
@BabylonLabs_io $BABY #baby
$BANK
Nói “Bitcoin plus DeFi” với hầu hết người bản địa trong giới crypto và bộ não họ sẽ lập tức liên tưởng đến một cây cầu hoặc một sidechain. Bọc coin lại, gửi nó sang bên kia, tin vào một tập hợp validator hoặc một multisig ở đầu nhận, và hi vọng bản thân cây cầu không bao giờ trở thành tiêu đề vì lý do sai. Nhiều năm các vụ khai thác cầu đã huấn luyện phản xạ đó—và có lý do chính đáng.
Trustless Bitcoin Vaults (kho tiền Bitcoin không cần tin cậy) lại thường bị nhét vào đúng cái “giỏ” suy nghĩ đó một cách liên tục, và đó là nhầm lẫn. Thiết kế của Babylon không hề chuyển BTC ra khỏi mạng Bitcoin. Thay vào đó, đồng coin được khóa trong một Taproot UTXO theo các điều kiện do script cưỡng chế, và nó vẫn ở đó xuyên suốt toàn bộ vòng đời vay mượn. Ethereum chỉ “nhìn thấy” một bằng chứng mật mã về trạng thái đã bị khóa đó thông qua một light client, chứ không hề nắm giữ (custody) chính tài sản. Không có một chuỗi thực thi riêng giữ một “bể” BTC được cầu nối như mô hình sidechain sẽ cần. Kiến trúc spoke của Aave v4 sau đó định tuyến việc vay mượn dựa trên bằng chứng này, chứ không dựa trên một token được cầu nối đang nằm trong dự trữ của ai đó.
Gọi đây là “chỉ là một cây cầu khác” là bỏ lỡ khác biệt kỹ thuật thực sự và, thành thật mà nói, đã xem nhẹ bài toán khó hơn mà Babylon chọn để giải. Cầu chuyển giá trị. Còn đây chuyển bằng chứng về giá trị trong khi đồng coin vẫn nằm đúng vị trí ban đầu.
Babylon không phải một cây cầu Bitcoin hay một sidechain khoác lên nhãn hiệu mới—theo thiết kế này, đồng coin không rời khỏi mạng Bitcoin. Thứ đi sang Ethereum là một bằng chứng về trạng thái đã bị khóa, không phải chính tài sản. Và chính sự khác biệt đó là lý do cốt lõi khiến rủi ro kiểu “custody theo kiểu cầu” không áp dụng ở đây như ở những nơi khác.
@BabylonLabs_io $BABY #baby
$DEXE $BANK
Trustless Bitcoin Vaults (kho tiền Bitcoin không cần tin cậy) lại thường bị nhét vào đúng cái “giỏ” suy nghĩ đó một cách liên tục, và đó là nhầm lẫn. Thiết kế của Babylon không hề chuyển BTC ra khỏi mạng Bitcoin. Thay vào đó, đồng coin được khóa trong một Taproot UTXO theo các điều kiện do script cưỡng chế, và nó vẫn ở đó xuyên suốt toàn bộ vòng đời vay mượn. Ethereum chỉ “nhìn thấy” một bằng chứng mật mã về trạng thái đã bị khóa đó thông qua một light client, chứ không hề nắm giữ (custody) chính tài sản. Không có một chuỗi thực thi riêng giữ một “bể” BTC được cầu nối như mô hình sidechain sẽ cần. Kiến trúc spoke của Aave v4 sau đó định tuyến việc vay mượn dựa trên bằng chứng này, chứ không dựa trên một token được cầu nối đang nằm trong dự trữ của ai đó.
Gọi đây là “chỉ là một cây cầu khác” là bỏ lỡ khác biệt kỹ thuật thực sự và, thành thật mà nói, đã xem nhẹ bài toán khó hơn mà Babylon chọn để giải. Cầu chuyển giá trị. Còn đây chuyển bằng chứng về giá trị trong khi đồng coin vẫn nằm đúng vị trí ban đầu.
Babylon không phải một cây cầu Bitcoin hay một sidechain khoác lên nhãn hiệu mới—theo thiết kế này, đồng coin không rời khỏi mạng Bitcoin. Thứ đi sang Ethereum là một bằng chứng về trạng thái đã bị khóa, không phải chính tài sản. Và chính sự khác biệt đó là lý do cốt lõi khiến rủi ro kiểu “custody theo kiểu cầu” không áp dụng ở đây như ở những nơi khác.
@BabylonLabs_io $BABY #baby
$DEXE $BANK
Babylon quảng bá giao thức staking của mình dựa trên việc không có bên thứ ba giữ hộ, không công ty nào nắm giữ BTC của bạn, và không có nhà điều hành cầu có thể biến mất cùng với tiền. Ủy ban công ước đặt cạnh lời chào này hơi “khó xử”. Đây là một nhóm đa chữ ký gồm các bên ngoài, chữ ký của họ về mặt pháp lý là bắt buộc trước khi một giao dịch unbonding (gỡ khóa) hoặc slashing (phạt) trở nên hợp lệ—một cấu trúc M-trong-N được thực thi trực tiếp bên trong script của Bitcoin. Trong tài liệu testnet do chính mạng lưới công bố, ủy ban này có tổng cộng 9 thành viên, và 3 trong số 9 ghế—chiếm trọn một phần ba—được vận hành ngay bởi chính Babylon Foundation.
Một bên mà bạn không lựa chọn, nắm giữ một phần quyền ký có ý nghĩa cần thiết để chuyển tiền của bạn qua một lộ trình đã được phê duyệt, là một dạng phơi nhiễm đối tác, ngay cả khi hẹp hơn so với việc một bên giữ hộ nắm giữ trực tiếp các khóa của bạn. Bài blog của chính Babylon Foundation thừa nhận điều này ở một phiên bản trực tiếp: mô tả giả định về niềm tin đằng sau kiểu ủy ban này được rút gọn thành “sự trung thực tồn tại”, nghĩa là chỉ cần một người ký trung thực là đủ, thay vì bị loại bỏ hoàn toàn, và đề xuất các công ước crypto-kinh tế có thể bị slashing như giải pháp cuối cùng.
Babylon chưa đạt được “niềm tin bên thứ ba bằng không” mà phần định vị không-giữ-hộ hàm ý, ít nhất là cho đến nay; bởi ủy ban công ước là một sự phụ thuộc thực sự và Foundation nằm ở bên trong đó. Thứ họ đã xây dựng là một sự phụ thuộc hẹp hơn so với bên giữ hộ, kèm theo kế hoạch riêng để thu hẹp nó hơn nữa. Đó là hai tuyên bố khác nhau, và chỉ có một trong số chúng là hoàn toàn đúng ở thời điểm hiện tại.
@BabylonLabs_io $BABY #baby
$LAB
Một bên mà bạn không lựa chọn, nắm giữ một phần quyền ký có ý nghĩa cần thiết để chuyển tiền của bạn qua một lộ trình đã được phê duyệt, là một dạng phơi nhiễm đối tác, ngay cả khi hẹp hơn so với việc một bên giữ hộ nắm giữ trực tiếp các khóa của bạn. Bài blog của chính Babylon Foundation thừa nhận điều này ở một phiên bản trực tiếp: mô tả giả định về niềm tin đằng sau kiểu ủy ban này được rút gọn thành “sự trung thực tồn tại”, nghĩa là chỉ cần một người ký trung thực là đủ, thay vì bị loại bỏ hoàn toàn, và đề xuất các công ước crypto-kinh tế có thể bị slashing như giải pháp cuối cùng.
Babylon chưa đạt được “niềm tin bên thứ ba bằng không” mà phần định vị không-giữ-hộ hàm ý, ít nhất là cho đến nay; bởi ủy ban công ước là một sự phụ thuộc thực sự và Foundation nằm ở bên trong đó. Thứ họ đã xây dựng là một sự phụ thuộc hẹp hơn so với bên giữ hộ, kèm theo kế hoạch riêng để thu hẹp nó hơn nữa. Đó là hai tuyên bố khác nhau, và chỉ có một trong số chúng là hoàn toàn đúng ở thời điểm hiện tại.
@BabylonLabs_io $BABY #baby
$LAB
Phần lớn các chuỗi Proof of Stake neo bảo mật vào chỉ một tài sản. Các trình xác thực (validator) đặt cược token gốc, hành vi sai phạm bị trừng phạt bằng cơ chế cắt phạt (slashing) trên chính token đó, và “trọng lượng kinh tế” của hệ thống nằm ở một con số: bao nhiêu token đó đang được khóa.
Babylon Genesis vận hành đồng thời hai “làn” bảo mật riêng biệt. Validators của CometBFT bảo vệ chuỗi thông qua ủy quyền BABY, trong khi một nhóm hoàn toàn khác—các nhà cung cấp tính cuối cùng (finality providers)—bảo vệ chuỗi thông qua ủy quyền Bitcoin. Cả hai làn đều có thể bị cắt phạt độc lập nếu người tham gia của từng làn có hành vi sai phạm. Chuỗi cấp vốn cho cả hai bên từ cùng một “nguồn giếng”: BABY mang mức lạm phát hằng năm 8%, được chia đúng một nửa—4% chảy đến các staker BABY và 4% còn lại đến các staker Bitcoin—chia đều thay vì một bên phải bù đắp cho bên kia. Việc đăng ký một khoản stake cũng chạy thông qua một giao dịch của Cosmos SDK, tiêu thụ BABY chỉ như phí gas, vì bản thân BABY chưa bao giờ được phát hành dưới dạng một ERC-20.
Quyết định vận hành hai làn thay vì một là một canh bạc rằng “trọng lượng kinh tế” của Bitcoin và “trọng lượng kinh tế” của BABY đều là cần thiết và không bên nào đủ một mình. Chỉ neo vào BABY sẽ khiến bảo mật crypto-economics gắn với một token còn non, thanh khoản mỏng; còn chỉ neo vào cơ chế ủy quyền Bitcoin sẽ khiến cơ chế đồng thuận thiếu một token mà người nắm giữ được khuyến khích để quản trị trực tiếp chính chuỗi.
Babylon không chọn giữa bảo mật của Bitcoin hay sự phù hợp động lực (incentive alignment) của BABY—nó cấp vốn cho cả hai cùng lúc bằng phần thưởng lạm phát chia đều. Điều đó cho thấy một đội ngũ không sẵn sàng đặt toàn bộ ngân sách bảo mật của chuỗi vào một tài sản duy nhất, ngay cả khi một trong hai tài sản đó có giá trị lớn hơn rất nhiều so với tài sản còn lại.
@BabylonLabs_io $BABY #baby
$PIEVERSE
Babylon Genesis vận hành đồng thời hai “làn” bảo mật riêng biệt. Validators của CometBFT bảo vệ chuỗi thông qua ủy quyền BABY, trong khi một nhóm hoàn toàn khác—các nhà cung cấp tính cuối cùng (finality providers)—bảo vệ chuỗi thông qua ủy quyền Bitcoin. Cả hai làn đều có thể bị cắt phạt độc lập nếu người tham gia của từng làn có hành vi sai phạm. Chuỗi cấp vốn cho cả hai bên từ cùng một “nguồn giếng”: BABY mang mức lạm phát hằng năm 8%, được chia đúng một nửa—4% chảy đến các staker BABY và 4% còn lại đến các staker Bitcoin—chia đều thay vì một bên phải bù đắp cho bên kia. Việc đăng ký một khoản stake cũng chạy thông qua một giao dịch của Cosmos SDK, tiêu thụ BABY chỉ như phí gas, vì bản thân BABY chưa bao giờ được phát hành dưới dạng một ERC-20.
Quyết định vận hành hai làn thay vì một là một canh bạc rằng “trọng lượng kinh tế” của Bitcoin và “trọng lượng kinh tế” của BABY đều là cần thiết và không bên nào đủ một mình. Chỉ neo vào BABY sẽ khiến bảo mật crypto-economics gắn với một token còn non, thanh khoản mỏng; còn chỉ neo vào cơ chế ủy quyền Bitcoin sẽ khiến cơ chế đồng thuận thiếu một token mà người nắm giữ được khuyến khích để quản trị trực tiếp chính chuỗi.
Babylon không chọn giữa bảo mật của Bitcoin hay sự phù hợp động lực (incentive alignment) của BABY—nó cấp vốn cho cả hai cùng lúc bằng phần thưởng lạm phát chia đều. Điều đó cho thấy một đội ngũ không sẵn sàng đặt toàn bộ ngân sách bảo mật của chuỗi vào một tài sản duy nhất, ngay cả khi một trong hai tài sản đó có giá trị lớn hơn rất nhiều so với tài sản còn lại.
@BabylonLabs_io $BABY #baby
$PIEVERSE
Tôi từng nghĩ ông tôi sẽ không bao giờ xoay sở được ứng dụng ngân hàng qua điện thoại; ông ấy đã dành sáu mươi năm để viết séc bằng tay. Rồi tôi chứng kiến ông kiểm tra số dư ngay giữa cuộc trò chuyện mà không nhìn xuống. Tôi đã đánh giá thấp khả năng một hệ thống cũ có thể thích nghi, và Bitcoin cũng bị đánh giá thấp theo cách tương tự.
Giả định phổ biến là Bitcoin, do thiếu các hợp đồng thông minh kiểu Ethereum, nên đơn giản không thể đóng vai trò tài sản thế chấp DeFi “native” nếu trước hết không được bọc thành một token trên một chuỗi khác—một cách khắc phục trong nhiều năm đã tạo ra hàng tỷ vụ khai thác (exploits), bởi vì nó thường đồng nghĩa với việc phải tin tưởng một bên lưu ký ở đâu đó.
Các kho lưu trữ (vault) của Babylon được xây dựng riêng để thách thức giả định đó. BTC được khóa trong một UTXO chịu sự điều phối bởi các quy tắc mật mã được đặt sẵn và các giao dịch đã được ký trước (pre-signed). Việc mở khóa cần phải gửi một bằng chứng kiến thức-không (zero-knowledge proof) thay vì chữ ký của bên lưu ký. Bitcoin “native” đã bị khóa đó sau đó hoạt động như tài sản thế chấp cho việc cho vay hoặc phát hành stablecoin trên các chuỗi bên ngoài, bao gồm Ethereum và Cosmos, mà không cần đúc (mint) một token bọc nào cả. Toàn bộ cơ chế chạy ngay trên Bitcoin như nó tồn tại hiện nay, không cần thêm opcode mới, không cần soft fork để làm cho bất kỳ điều nào trong số này trở nên khả thi.
Ngôn ngữ lập trình (scripting) của Bitcoin thực sự còn hạn chế hơn so với Ethereum. Sự hạn chế đó đã định hình cách Babylon phải xây dựng: ưu tiên các nhánh giao dịch được ký trước và việc xác minh bằng chứng diễn ra ngoài chuỗi (off-chain) thay vì logic linh hoạt kiểu “luôn bật trên chuỗi” mà Ethereum cho phép. “Hạn chế” không đồng nghĩa với “không thể”, và thiết kế của vault là bằng chứng rằng giới hạn này có thể được kỹ thuật hóa để vượt qua chứ không chỉ đơn thuần là bỏ qua bằng một lớp bọc.
Bitcoin không cần phải trở thành Ethereum để tham gia vào vai trò tài sản thế chấp DeFi; nó chỉ cần một kiến trúc khác, và các vault của Babylon cho thấy điều đó trông như thế nào.
@BabylonLabs_io $BABY #baby
$DEXE
Giả định phổ biến là Bitcoin, do thiếu các hợp đồng thông minh kiểu Ethereum, nên đơn giản không thể đóng vai trò tài sản thế chấp DeFi “native” nếu trước hết không được bọc thành một token trên một chuỗi khác—một cách khắc phục trong nhiều năm đã tạo ra hàng tỷ vụ khai thác (exploits), bởi vì nó thường đồng nghĩa với việc phải tin tưởng một bên lưu ký ở đâu đó.
Các kho lưu trữ (vault) của Babylon được xây dựng riêng để thách thức giả định đó. BTC được khóa trong một UTXO chịu sự điều phối bởi các quy tắc mật mã được đặt sẵn và các giao dịch đã được ký trước (pre-signed). Việc mở khóa cần phải gửi một bằng chứng kiến thức-không (zero-knowledge proof) thay vì chữ ký của bên lưu ký. Bitcoin “native” đã bị khóa đó sau đó hoạt động như tài sản thế chấp cho việc cho vay hoặc phát hành stablecoin trên các chuỗi bên ngoài, bao gồm Ethereum và Cosmos, mà không cần đúc (mint) một token bọc nào cả. Toàn bộ cơ chế chạy ngay trên Bitcoin như nó tồn tại hiện nay, không cần thêm opcode mới, không cần soft fork để làm cho bất kỳ điều nào trong số này trở nên khả thi.
Ngôn ngữ lập trình (scripting) của Bitcoin thực sự còn hạn chế hơn so với Ethereum. Sự hạn chế đó đã định hình cách Babylon phải xây dựng: ưu tiên các nhánh giao dịch được ký trước và việc xác minh bằng chứng diễn ra ngoài chuỗi (off-chain) thay vì logic linh hoạt kiểu “luôn bật trên chuỗi” mà Ethereum cho phép. “Hạn chế” không đồng nghĩa với “không thể”, và thiết kế của vault là bằng chứng rằng giới hạn này có thể được kỹ thuật hóa để vượt qua chứ không chỉ đơn thuần là bỏ qua bằng một lớp bọc.
Bitcoin không cần phải trở thành Ethereum để tham gia vào vai trò tài sản thế chấp DeFi; nó chỉ cần một kiến trúc khác, và các vault của Babylon cho thấy điều đó trông như thế nào.
@BabylonLabs_io $BABY #baby
$DEXE
Một người chủ nhà mà tôi từng thuê cứ liên tục tăng tổng số căn hộ của tòa nhà bằng cách chuyển các phòng kho thành studio—về mặt kỹ thuật là tạo thêm nguồn cung, về mặt kỹ thuật là tạo thêm doanh thu, và về mặt kỹ thuật cũng làm loãng cảm giác “đặc biệt” của bất kỳ một căn nào khi ở. Việc tăng trưởng và sự loãng xuất hiện trong cùng một lần cải tạo.
BABY không có nguồn cung tối đa cố định; các trình theo dõi tokenomics mô tả lịch mở khóa của nó là kéo dài vô thời hạn, thay vì bị giới hạn trần như Bitcoin (21 triệu). Đợt phân bổ ban đầu theo kế hoạch bao gồm 10 tỷ token cho các nhóm nhà đầu tư, đội ngũ, hệ sinh thái, R&D và cộng đồng, nhưng việc phát hành tiếp diễn sau mốc nền này không bị “trói” cứng theo thiết kế giao thức theo cách tương tự. Người ủng hộ cho rằng điều đó là cần thiết: một tập hợp validator đang tăng trưởng và nhà cung cấp khả năng finality (tính xác thực cuối cùng) cùng với các ưu đãi cộng đồng dài hạn cần dòng token được duy trì, thay vì chỉ dựa vào một phân bổ một lần rồi cạn kiệt. Các nhà phê bình lại chỉ ra cùng một cơ chế như một áp lực bán mang tính cấu trúc: hiện đã có khoảng 3,99 tỷ BABY đang lưu hành và mỗi tháng lại có thêm token được đưa vào thông qua lịch vesting và các đợt phát hành trong tương lai, làm loãng tỷ lệ nắm giữ của những người sở hữu hiện tại trong mạng lưới bất kể tăng trưởng nhu cầu sử dụng. Cả hai cách đọc đều dựa trên cùng một thực tế: nguồn cung không bị giới hạn, tiếp tục mở rộng liên tục—nuôi dưỡng một token quản trị và token gas, giá trị của token này phụ thuộc một phần vào độ khan hiếm và một phần vào nhu cầu sử dụng giữ nhịp với lượng phát hành mới. Lịch sử giá của BABY tạo thêm ngữ cảnh: mức cao vào tháng 4/2025 gần $0,1661, sau đó giảm khoảng 93% xuống $0,0107 vào tháng 3/2026 cho thấy thị trường đã định giá sẵn một phiên bản của cuộc tranh luận về sự loãng này.
Không có “kịch bản tăng trưởng” hay “kịch bản loãng” nào thắng trọn vẹn ở đây. Nguồn cung vô hạn có thể tài trợ cho một hệ sinh thái đang trưởng thành, hoặc âm thầm bào mòn giá trị của người nắm giữ; kết quả xảy ra theo hướng nào lại phụ thuộc vào tăng trưởng nhu cầu mà Babylon không thể tự mình bảo đảm hoàn toàn.
@BabylonLabs_io $BABY #baby
$DEXE
BABY không có nguồn cung tối đa cố định; các trình theo dõi tokenomics mô tả lịch mở khóa của nó là kéo dài vô thời hạn, thay vì bị giới hạn trần như Bitcoin (21 triệu). Đợt phân bổ ban đầu theo kế hoạch bao gồm 10 tỷ token cho các nhóm nhà đầu tư, đội ngũ, hệ sinh thái, R&D và cộng đồng, nhưng việc phát hành tiếp diễn sau mốc nền này không bị “trói” cứng theo thiết kế giao thức theo cách tương tự. Người ủng hộ cho rằng điều đó là cần thiết: một tập hợp validator đang tăng trưởng và nhà cung cấp khả năng finality (tính xác thực cuối cùng) cùng với các ưu đãi cộng đồng dài hạn cần dòng token được duy trì, thay vì chỉ dựa vào một phân bổ một lần rồi cạn kiệt. Các nhà phê bình lại chỉ ra cùng một cơ chế như một áp lực bán mang tính cấu trúc: hiện đã có khoảng 3,99 tỷ BABY đang lưu hành và mỗi tháng lại có thêm token được đưa vào thông qua lịch vesting và các đợt phát hành trong tương lai, làm loãng tỷ lệ nắm giữ của những người sở hữu hiện tại trong mạng lưới bất kể tăng trưởng nhu cầu sử dụng. Cả hai cách đọc đều dựa trên cùng một thực tế: nguồn cung không bị giới hạn, tiếp tục mở rộng liên tục—nuôi dưỡng một token quản trị và token gas, giá trị của token này phụ thuộc một phần vào độ khan hiếm và một phần vào nhu cầu sử dụng giữ nhịp với lượng phát hành mới. Lịch sử giá của BABY tạo thêm ngữ cảnh: mức cao vào tháng 4/2025 gần $0,1661, sau đó giảm khoảng 93% xuống $0,0107 vào tháng 3/2026 cho thấy thị trường đã định giá sẵn một phiên bản của cuộc tranh luận về sự loãng này.
Không có “kịch bản tăng trưởng” hay “kịch bản loãng” nào thắng trọn vẹn ở đây. Nguồn cung vô hạn có thể tài trợ cho một hệ sinh thái đang trưởng thành, hoặc âm thầm bào mòn giá trị của người nắm giữ; kết quả xảy ra theo hướng nào lại phụ thuộc vào tăng trưởng nhu cầu mà Babylon không thể tự mình bảo đảm hoàn toàn.
@BabylonLabs_io $BABY #baby
$DEXE
Một người bạn của tôi ở quê nhà là bác sĩ được cấp phép, nhưng bệnh viện nơi cô ấy hiện làm lại đăng một tuyên bố miễn trừ rằng giấy phép hành nghề tại quê nhà của cô ấy không có hiệu lực pháp lý tại địa phương. Cùng một người, cùng bằng cấp, và thế nhưng việc cô ấy có “là bác sĩ được cấp phép” ở đây hay không lại phụ thuộc hoàn toàn vào việc bạn hỏi theo bộ quy tắc của quốc gia nào.
GRVT cũng rơi vào tình huống tương tự. Tháng 12/2024, công ty này nhận được Giấy phép Kinh doanh Tài sản Kỹ thuật số đã Sửa đổi theo hạng M từ Cơ quan Tiền tệ Bermuda (Bermuda Monetary Authority). Phần lớn thông tin của công ty và hầu hết các bài viết/đánh giá mô tả điều đó như thể GRVT là sàn giao dịch phái sinh onchain được quản lý đầu tiên trên thế giới. Danh hiệu đó được nhắc đi nhắc lại liên tục trong marketing và các bài review. Trong khi đó, pháp nhân vận hành đằng sau ứng dụng, GRVT Technologies Pte Ltd, lại đặt trụ sở tại Singapore. Và ngay trên mô tả danh sách ứng dụng trong App Store của nền tảng này cũng có một tuyên bố miễn trừ trực tiếp dành cho thị trường đó: GRVT không được cấp phép, phê duyệt, uỷ quyền, chỉ định, công nhận, đăng ký hoặc được quản lý dưới bất kỳ khuôn khổ luật pháp nào do Cơ quan Tiền tệ Singapore (Monetary Authority of Singapore – MAS) quản lý; đồng thời người dùng tại đây không nhận được bất kỳ biện pháp bảo vệ/khung an toàn điều tiết nào mà sự giám sát của MAS thông thường sẽ cung cấp. Vì vậy, câu trả lời “GRVT có được quản lý không” lại được phân tách theo từng khu vực pháp lý chứ không thể gói gọn trong một câu trả lời một từ. Bermuda: có, theo một hạng mục giấy phép đã sửa đổi. Singapore: rõ ràng là không, theo chính lời của công ty. Nền tảng này cũng đang theo đuổi một giấy phép Bermuda đầy đủ hơn, đồng thời làm việc với các cơ quan quản lý ở EU và Trung Đông—nhưng tất cả vẫn chưa hoàn tất. Một người đọc riêng tiêu đề “sàn DEX được quản lý đầu tiên trên thế giới” một cách độc lập sẽ hợp lý khi kỳ vọng phạm vi điều tiết rộng hơn so với những gì thực sự được cung cấp bởi một giấy phép đã sửa đổi trong một khu vực tài phán nhỏ. Trong khi đó, một người dùng ở Singapore đọc phần chữ nhỏ trong App Store lại nhận được ấn tượng hoàn toàn ngược lại.
Việc GRVT có được quản lý hay không phụ thuộc vào khu vực pháp lý được hỏi: ở Bermuda thì có, theo giấy phép đã sửa đổi; ở Singapore thì rõ ràng là không, theo chính bản tuyên bố miễn trừ của công ty; và cả hai phía—riêng lẻ—đều không nói được toàn bộ câu chuyện.
@grvt_io #grvt
$LAB $VELVET
GRVT cũng rơi vào tình huống tương tự. Tháng 12/2024, công ty này nhận được Giấy phép Kinh doanh Tài sản Kỹ thuật số đã Sửa đổi theo hạng M từ Cơ quan Tiền tệ Bermuda (Bermuda Monetary Authority). Phần lớn thông tin của công ty và hầu hết các bài viết/đánh giá mô tả điều đó như thể GRVT là sàn giao dịch phái sinh onchain được quản lý đầu tiên trên thế giới. Danh hiệu đó được nhắc đi nhắc lại liên tục trong marketing và các bài review. Trong khi đó, pháp nhân vận hành đằng sau ứng dụng, GRVT Technologies Pte Ltd, lại đặt trụ sở tại Singapore. Và ngay trên mô tả danh sách ứng dụng trong App Store của nền tảng này cũng có một tuyên bố miễn trừ trực tiếp dành cho thị trường đó: GRVT không được cấp phép, phê duyệt, uỷ quyền, chỉ định, công nhận, đăng ký hoặc được quản lý dưới bất kỳ khuôn khổ luật pháp nào do Cơ quan Tiền tệ Singapore (Monetary Authority of Singapore – MAS) quản lý; đồng thời người dùng tại đây không nhận được bất kỳ biện pháp bảo vệ/khung an toàn điều tiết nào mà sự giám sát của MAS thông thường sẽ cung cấp. Vì vậy, câu trả lời “GRVT có được quản lý không” lại được phân tách theo từng khu vực pháp lý chứ không thể gói gọn trong một câu trả lời một từ. Bermuda: có, theo một hạng mục giấy phép đã sửa đổi. Singapore: rõ ràng là không, theo chính lời của công ty. Nền tảng này cũng đang theo đuổi một giấy phép Bermuda đầy đủ hơn, đồng thời làm việc với các cơ quan quản lý ở EU và Trung Đông—nhưng tất cả vẫn chưa hoàn tất. Một người đọc riêng tiêu đề “sàn DEX được quản lý đầu tiên trên thế giới” một cách độc lập sẽ hợp lý khi kỳ vọng phạm vi điều tiết rộng hơn so với những gì thực sự được cung cấp bởi một giấy phép đã sửa đổi trong một khu vực tài phán nhỏ. Trong khi đó, một người dùng ở Singapore đọc phần chữ nhỏ trong App Store lại nhận được ấn tượng hoàn toàn ngược lại.
Việc GRVT có được quản lý hay không phụ thuộc vào khu vực pháp lý được hỏi: ở Bermuda thì có, theo giấy phép đã sửa đổi; ở Singapore thì rõ ràng là không, theo chính bản tuyên bố miễn trừ của công ty; và cả hai phía—riêng lẻ—đều không nói được toàn bộ câu chuyện.
@grvt_io #grvt
$LAB $VELVET
Một người bạn xây dựng xe tải thực phẩm khăng khăng chạy nó trong một bãi đỗ xe kín trong hai cuối tuần trước khi đậu ở một góc phố ngoài đời. Đối tác của anh ấy muốn khởi động ngay ở trung tâm thành phố. Anh nói rằng thiết bị cần phải hỏng ở đâu đó nhỏ trước, chứ không phải trong bữa trưa của khách hàng đang trả tiền.
GRVT đã đưa thị trường spot của mình lên testnet vào ngày 29 tháng 4 năm 2026, nhiều tháng trước bất kỳ thông báo công khai nào về ngày ra mắt spot trên mainnet. Điều này diễn ra sau khi sàn giao dịch ấy đã xây dựng uy tín của mình gần như hoàn toàn dựa trên hợp đồng tương lai vĩnh viễn, trải trên khoảng 168 thị trường; vì vậy spot thực sự đại diện cho logic ghép lệnh và thanh toán hoàn toàn mới, thay vì chỉ là một tính năng được gắn thêm quy mô nhỏ. Việc chạy trên testnet trước có nghĩa là người dùng thật và các bên tích hợp có thể định tuyến đơn hàng, thử các trường hợp biên và phát hiện lỗi trên một kiểu thị trường mà nền tảng chưa từng vận hành trực tiếp trước đó, mà không phải chịu rủi ro bất kỳ đô la khối lượng spot thực nào nếu có sự cố. Các sàn giao dịch cạnh tranh thường phát hành sản phẩm mới thẳng lên mainnet dưới áp lực thời gian từ các đợt ra mắt token hoặc lịch marketing, chấp nhận rủi ro rằng lỗi ban đầu sẽ bị phát hiện bởi người dùng trả tiền thay vì người thử nghiệm. Việc triển khai spot của GRVT nằm trong một lộ trình rộng hơn của năm 2026, cũng chịu áp lực deadline thực tế của riêng mình, sau một loạt thông báo gắn với các tháng cụ thể; tuy nhiên đội ngũ vẫn chèn một giai đoạn testnet trước khi cho các lệnh spot chạm đến tiền thật. Cách sắp xếp này đổi tốc độ ra thị trường lấy xác suất thấp hơn về một sự cố đáng xấu hổ hoặc tốn kém khi dòng vốn thực sự bắt đầu chảy qua một kiểu lệnh mà nền tảng chưa từng chạy trực tiếp trước đó.
GRVT không vội vàng đưa mọi sản phẩm mới thẳng vào dòng vốn thực như áp lực từ lộ trình có thể gợi ý; việc ra mắt spot cho thấy sự sẵn sàng chậm lại và kiểm thử căng hơn trước, ngay cả khi lộ trình xung quanh vẫn vận hành theo một deadline công khai.
@grvt_io #grvt
$LAB
GRVT đã đưa thị trường spot của mình lên testnet vào ngày 29 tháng 4 năm 2026, nhiều tháng trước bất kỳ thông báo công khai nào về ngày ra mắt spot trên mainnet. Điều này diễn ra sau khi sàn giao dịch ấy đã xây dựng uy tín của mình gần như hoàn toàn dựa trên hợp đồng tương lai vĩnh viễn, trải trên khoảng 168 thị trường; vì vậy spot thực sự đại diện cho logic ghép lệnh và thanh toán hoàn toàn mới, thay vì chỉ là một tính năng được gắn thêm quy mô nhỏ. Việc chạy trên testnet trước có nghĩa là người dùng thật và các bên tích hợp có thể định tuyến đơn hàng, thử các trường hợp biên và phát hiện lỗi trên một kiểu thị trường mà nền tảng chưa từng vận hành trực tiếp trước đó, mà không phải chịu rủi ro bất kỳ đô la khối lượng spot thực nào nếu có sự cố. Các sàn giao dịch cạnh tranh thường phát hành sản phẩm mới thẳng lên mainnet dưới áp lực thời gian từ các đợt ra mắt token hoặc lịch marketing, chấp nhận rủi ro rằng lỗi ban đầu sẽ bị phát hiện bởi người dùng trả tiền thay vì người thử nghiệm. Việc triển khai spot của GRVT nằm trong một lộ trình rộng hơn của năm 2026, cũng chịu áp lực deadline thực tế của riêng mình, sau một loạt thông báo gắn với các tháng cụ thể; tuy nhiên đội ngũ vẫn chèn một giai đoạn testnet trước khi cho các lệnh spot chạm đến tiền thật. Cách sắp xếp này đổi tốc độ ra thị trường lấy xác suất thấp hơn về một sự cố đáng xấu hổ hoặc tốn kém khi dòng vốn thực sự bắt đầu chảy qua một kiểu lệnh mà nền tảng chưa từng chạy trực tiếp trước đó.
GRVT không vội vàng đưa mọi sản phẩm mới thẳng vào dòng vốn thực như áp lực từ lộ trình có thể gợi ý; việc ra mắt spot cho thấy sự sẵn sàng chậm lại và kiểm thử căng hơn trước, ngay cả khi lộ trình xung quanh vẫn vận hành theo một deadline công khai.
@grvt_io #grvt
$LAB
Một thành phố gần tôi vài năm trước đã lắp các camera giao thông trực tiếp trên cây cầu chính và quảng cáo chúng là thời gian thực. Tôi từng kiểm tra một lần trong lúc đi làm, thấy đúng ba chiếc xe đó đứng yên ở cùng một vị trí trong khoảng thời gian mà cảm giác như kéo dài mãi, và nhận ra luồng dữ liệu thực ra chỉ được làm mới khoảng mỗi 40 phút. Không có gì bị hỏng cả; chỉ là nhãn mác đang làm nhiều việc hơn so với công nghệ bên dưới có thể đáp ứng.
Chuỗi thanh toán của GRVT được “settle” thông qua hệ thống proof của ZKsync, và các câu chữ xoay quanh zero-knowledge proofs thường được mô tả lỏng lẻo như việc xác minh thời gian thực cho mọi giao dịch khi chúng xảy ra. Trên thực tế, giám sát độc lập từ L2BEAT cho thấy các lần gửi proof của ZKsync Era được ghi nhận lên Ethereum trung bình khoảng mỗi 38 phút, và các cập nhật trạng thái cũng theo nhịp tương tự 29 phút, chứ không phải theo từng giao dịch riêng lẻ. Dù vậy, điều đó vẫn nhanh theo tiêu chuẩn blockchain và không phải là một “lỗi”: các proof được gom gói có chủ đích để mỗi proof có chi phí kinh tế cho việc xác minh trên lớp nền Ethereum, thay vì phải xác minh cho từng giao dịch riêng lẻ. Nhưng điều đó cũng có nghĩa là giao dịch của bạn được chứng minh trên Ethereum sẽ gần với việc “giao dịch của bạn được đưa vào một lô và lô đó được chứng minh” hơn là kiểu “được đảm bảo ngay lập tức cho từng giao dịch”. Lần theo dõi giống nhau ghi nhận một khoảng trễ khả dụng thực tế vào tháng 6 năm 2026, khi không có proof nào được gửi lên trong hơn 10 giờ so với nhịp điển hình 38 phút—đó là một ngoại lệ chứ không phải chuẩn mực—nhưng vẫn là một điều đã được ghi nhận và đáng biết, bất kể mức độ hiếm của nó.
Việc thanh toán nền tảng của GRVT không phải là xác minh các giao dịch với Ethereum ngay khoảnh khắc chúng xảy ra; nó gộp khoảng nửa giờ hoạt động vào mỗi proof trước khi proof đó được đưa lên Ethereum. Thỉnh thoảng có các khoảng trống được ghi nhận kéo dài vượt xa mức trung bình. Bảo đảm bảo mật là có thật một khi proof đã được đưa lên, còn thời điểm xảy ra việc đó thì đơn giản là chậm hơn và “dồn cục” hơn so với cảm giác mà cụm từ thời gian thực gợi ra.
@grvt_io #grvt
$LAB
Chuỗi thanh toán của GRVT được “settle” thông qua hệ thống proof của ZKsync, và các câu chữ xoay quanh zero-knowledge proofs thường được mô tả lỏng lẻo như việc xác minh thời gian thực cho mọi giao dịch khi chúng xảy ra. Trên thực tế, giám sát độc lập từ L2BEAT cho thấy các lần gửi proof của ZKsync Era được ghi nhận lên Ethereum trung bình khoảng mỗi 38 phút, và các cập nhật trạng thái cũng theo nhịp tương tự 29 phút, chứ không phải theo từng giao dịch riêng lẻ. Dù vậy, điều đó vẫn nhanh theo tiêu chuẩn blockchain và không phải là một “lỗi”: các proof được gom gói có chủ đích để mỗi proof có chi phí kinh tế cho việc xác minh trên lớp nền Ethereum, thay vì phải xác minh cho từng giao dịch riêng lẻ. Nhưng điều đó cũng có nghĩa là giao dịch của bạn được chứng minh trên Ethereum sẽ gần với việc “giao dịch của bạn được đưa vào một lô và lô đó được chứng minh” hơn là kiểu “được đảm bảo ngay lập tức cho từng giao dịch”. Lần theo dõi giống nhau ghi nhận một khoảng trễ khả dụng thực tế vào tháng 6 năm 2026, khi không có proof nào được gửi lên trong hơn 10 giờ so với nhịp điển hình 38 phút—đó là một ngoại lệ chứ không phải chuẩn mực—nhưng vẫn là một điều đã được ghi nhận và đáng biết, bất kể mức độ hiếm của nó.
Việc thanh toán nền tảng của GRVT không phải là xác minh các giao dịch với Ethereum ngay khoảnh khắc chúng xảy ra; nó gộp khoảng nửa giờ hoạt động vào mỗi proof trước khi proof đó được đưa lên Ethereum. Thỉnh thoảng có các khoảng trống được ghi nhận kéo dài vượt xa mức trung bình. Bảo đảm bảo mật là có thật một khi proof đã được đưa lên, còn thời điểm xảy ra việc đó thì đơn giản là chậm hơn và “dồn cục” hơn so với cảm giác mà cụm từ thời gian thực gợi ra.
@grvt_io #grvt
$LAB
Rất nhiều nhà giao dịch mới giả định rằng các khoản thanh toán funding trên một sàn perpetual hoạt động giống như một khoản phí giao dịch—tiền mà nền tảng thu để cho bạn nắm giữ vị thế đòn bẩy qua đêm. Trên GRVT, giả định đó hoàn toàn sai. Funding được quy định rõ ràng là thanh toán diễn ra trực tiếp giữa người mua (long) và người bán (short), GRVT trong tài liệu của mình nêu rất thẳng rằng funding không phải là phí sàn, nó không hề chạm đến doanh thu của nền tảng.
Cơ chế này tồn tại chỉ nhằm giữ cho giá của hợp đồng perpetual bám theo chỉ số spot. Khi perpetual giao dịch cao hơn so với spot, long sẽ trả cho short để thu hẹp phần chênh lệch (premium) đó về gần bằng 0. Khi perpetual giao dịch rẻ hơn, short sẽ trả cho long. GRVT không phải là một bên đối tác lấy giá trị từ một phía nào cả; GRVT là nơi tái phân phối các khoản thanh toán giữa hai nhóm nhà giao dịch đang, về mặt cấu trúc, đặt cược ngược nhau về hướng giá. Doanh thu của GRVT đến từ phí giao dịch ở phía taker và maker—một hạng mục hoàn toàn tách biệt với cơ chế funding.
Khoảng cách giữa giả định và thực tế ở đây quan trọng vì nó thay đổi cách một trader nên nghĩ về chi phí funding. Funding cao kéo dài không phải là việc GRVT tính bạn nhiều hơn; đó là thị trường tự phát tín hiệu rằng bên long đang bị “đông” và phải trả một mức premium để giữ vị thế long có đòn bẩy. Hiểu funding là một tín hiệu của thị trường, chứ không phải phí nền tảng, sẽ thay đổi cách bạn “đọc” nó trước khi mở vị thế—không phải sau khi đã bị tính phí. Lần đầu tiên tôi thấy funding có xu hướng dương kéo dài trên một thị trường của GRVT, phản xạ của tôi là kiểm tra xem nền tảng có lặng lẽ tăng phí ở đâu đó hay không; và chỉ khi đọc kỹ tài liệu, tôi mới nhận ra phản xạ đó hoàn toàn sai—con số đó đang nói với tôi về mức long bị đông trong chính thị trường đó, chứ không hề liên quan đến doanh thu của GRVT. Từ đó trở đi, cách tôi đọc mọi biểu đồ funding đều thay đổi.
@grvt_io #grvt
$LAB
Cơ chế này tồn tại chỉ nhằm giữ cho giá của hợp đồng perpetual bám theo chỉ số spot. Khi perpetual giao dịch cao hơn so với spot, long sẽ trả cho short để thu hẹp phần chênh lệch (premium) đó về gần bằng 0. Khi perpetual giao dịch rẻ hơn, short sẽ trả cho long. GRVT không phải là một bên đối tác lấy giá trị từ một phía nào cả; GRVT là nơi tái phân phối các khoản thanh toán giữa hai nhóm nhà giao dịch đang, về mặt cấu trúc, đặt cược ngược nhau về hướng giá. Doanh thu của GRVT đến từ phí giao dịch ở phía taker và maker—một hạng mục hoàn toàn tách biệt với cơ chế funding.
Khoảng cách giữa giả định và thực tế ở đây quan trọng vì nó thay đổi cách một trader nên nghĩ về chi phí funding. Funding cao kéo dài không phải là việc GRVT tính bạn nhiều hơn; đó là thị trường tự phát tín hiệu rằng bên long đang bị “đông” và phải trả một mức premium để giữ vị thế long có đòn bẩy. Hiểu funding là một tín hiệu của thị trường, chứ không phải phí nền tảng, sẽ thay đổi cách bạn “đọc” nó trước khi mở vị thế—không phải sau khi đã bị tính phí. Lần đầu tiên tôi thấy funding có xu hướng dương kéo dài trên một thị trường của GRVT, phản xạ của tôi là kiểm tra xem nền tảng có lặng lẽ tăng phí ở đâu đó hay không; và chỉ khi đọc kỹ tài liệu, tôi mới nhận ra phản xạ đó hoàn toàn sai—con số đó đang nói với tôi về mức long bị đông trong chính thị trường đó, chứ không hề liên quan đến doanh thu của GRVT. Từ đó trở đi, cách tôi đọc mọi biểu đồ funding đều thay đổi.
@grvt_io #grvt
$LAB
Đăng nhập để khám phá thêm nội dung