Lukukaku

Giao dịch P2P đầu tiên của tôi trên Binance và giao dịch gần đây nhất có thể không cảm nhận thấy khác biệt hơn, dù các bước thực hiện về cơ bản gần như giống nhau trên giấy. Sự khác biệt hoàn toàn nằm ở việc tôi đã chuẩn bị như thế nào trước khi bắt đầu.

Lần đầu tiên, tôi đã không kiểm tra trạng thái KYC của người bán, không so sánh tỷ lệ hoàn thành, và gần như không đọc kỹ các điều khoản giao dịch trước khi xác nhận. Giao dịch thực sự vẫn diễn ra suôn sẻ, nhưng tôi đã trải qua suốt thời gian trong trạng thái lo lắng, không biết liệu mình có đang làm sai điều gì không, và không chắc ngay cả những biện pháp bảo vệ nào tồn tại nếu mọi thứ đi theo hướng xấu. Binance P2P đã có sẵn tất cả trong suốt thời gian đó: xác minh KYC, cơ chế ký quỹ khóa chặt tài sản crypto một cách an toàn, cuộc trò chuyện trong ứng dụng ghi lại toàn bộ, và tùy chọn khiếu nại/kháng nghị tranh chấp nếu cần. Tôi chỉ đơn giản là chưa tìm đến bất kỳ mục nào trong số đó hoặc chưa hiểu cách các phần ghép lại với nhau.

Giao dịch gần đây lại trông hoàn toàn khác vì bây giờ tôi làm theo một quy trình nhất quán. Trước khi mở một lệnh, tôi kiểm tra cả trạng thái KYC và tỷ lệ hoàn thành. Tôi cũng so sánh ít nhất hai hồ sơ của người bán trước khi chọn, thay vì chấp nhận ngay đề nghị đầu tiên xuất hiện, vì một so sánh nhanh hiếm khi tốn hơn một phút. Tôi đọc đầy đủ các điều khoản giao dịch, không chỉ xem giá. Tôi giữ mọi phần trao đổi trong ứng dụng, vì bản ghi đó quan trọng nếu sau này có tranh chấp. Tôi chỉ xác nhận việc thanh toán đã thực sự được ghi nhận trong tài khoản của mình trước khi nhả bất kỳ tài sản crypto nào, bất kể một ảnh chụp màn hình nói gì. Tôi để ý các dấu hiệu cảnh báo như sự thúc giục hoặc yêu cầu chuyển ra ngoài nền tảng, và tôi không còn phớt lờ cảm giác không ổn nữa chỉ vì đến hiện tại chưa có bằng chứng cụ thể. Bây giờ tôi lưu một kho lưu trữ đơn giản gồm ảnh chụp màn hình và số thứ tự đơn hàng cho mọi giao dịch, và tôi biết chính xác cách liên hệ bộ phận hỗ trợ của Binance nếu bất cứ lúc nào cần ý kiến thứ hai.

Cơ chế của Binance P2P không hề thay đổi giữa hai lần giao dịch đó. Nhận thức của tôi về chúng đã thay đổi, và điều đó đã thay đổi hoàn toàn cách tôi cảm nhận về toàn bộ quá trình.

@Binance Vietnam #BinanceP2PAnToan $TUT $BLUAI

Không phải mọi phương thức thanh toán được liệt kê trên Binance P2P đều mang cùng mức độ rủi ro, và phải trải qua vài lần giao dịch không mấy thoải mái trước khi tôi bắt đầu thực sự chú ý bên đối tác ưa thích phương thức nào.

Binance P2P cho phép người bán chọn những phương thức thanh toán họ chấp nhận khi đăng một ưu đãi, và lựa chọn đó đáng để nghiêm túc cân nhắc thay vì chấp nhận mọi thứ chỉ để thu hút thêm nhiều người mua. Chuyển khoản ngân hàng để lại một hồ sơ rõ ràng, có thể truy vết, kèm theo tên và mã tham chiếu, điều này phù hợp tự nhiên với yêu cầu xác minh danh tính mà Binance P2P đã áp dụng cho mọi người giao dịch. Các phương thức khó truy vết hơn hoặc dễ bị hoàn trả hơn sẽ tạo thêm không gian để kẻ lừa đảo khai thác khoảng trống giữa việc thanh toán trông có vẻ đã được gửi và thanh toán thực sự được hoàn tất.

Tôi chỉ thu hẹp các phương thức được chấp nhận còn duy nhất chuyển khoản ngân hàng sau một giao dịch mà người mua sử dụng một phương thức mà tôi hầu như không nhận ra, gửi bằng chứng trông có vẻ hợp lệ, rồi hai ngày sau đó hoàn lại giao dịch thông qua bên cung cấp dịch vụ của anh ta, trong khi tiền mã hoá của tôi lúc đó đã được chuyển đi. Tôi đã nộp kháng nghị với những gì mình có, nhưng đến lúc đó, số tiền đã bị rút lại qua một kênh khiến việc khôi phục trở nên khó hơn nhiều so với lẽ ra.

Giờ đây, trước khi chấp nhận bất kỳ đơn hàng nào, tôi xác nhận chính xác phương thức thanh toán khớp với những gì danh sách của tôi nêu, kiểm tra tên người gửi có khớp với hồ sơ Binance P2P đã được xác minh của họ hay không, và xác minh rằng tiền đã thực sự được ghi nhận trong tài khoản của chính tôi thay vì chỉ hiện trạng thái “đang chờ”. Không gì trong số này loại bỏ rủi ro hoàn toàn, nhưng việc thu hẹp các phương thức tôi chấp nhận cũng đồng nghĩa với việc giảm số cách mà ai đó có thể khai thác khoảng trống giữa “đã gửi” và “đã được hoàn tất”.

Tôi cũng mở một kháng nghị đúng vào ngày hôm đó và lưu lại mọi ảnh chụp màn hình từ sàn, bao gồm phương thức thanh toán được sử dụng và bằng chứng đã được gửi, vì bộ phận hỗ trợ của Binance P2P cần những chi tiết cụ thể đó để hiểu kiểu hoàn trả mà tôi đang mô tả.

Việc lựa chọn cẩn thận các phương thức thanh toán là một biện pháp phòng vệ do bạn tự kiểm soát trước cả khi giao dịch bắt đầu—tức là còn lâu trước khi các huy hiệu xác minh hay hành vi trong khung chat xuất hiện.

@Binance Vietnam #BinanceP2PAnToan $TST $HFT

Tôi thực hiện giao dịch Binance P2P đầu tiên của mình với một đối tác hoàn toàn mới, nhưng cố tình đặt một đơn hàng có giá trị nhỏ. Một đơn nhỏ không loại bỏ rủi ro, nhưng giúp tôi học luồng thanh toán, thời điểm và phong cách liên lạc mà không nhầm lẫn sự tự tin với kinh nghiệm. Tôi vẫn áp dụng đầy đủ danh sách kiểm tra vì gian lận không vì số tiền thấp mà trở nên an toàn.

Trước khi đặt lệnh, tôi nghiên cứu các thông tin hồ sơ có sẵn: hoạt động đã hoàn tất, các dấu hiệu hoàn thành, phản hồi, lịch sử tài khoản hoặc trạng thái người bán/merchant khi được hiển thị, giới hạn quảng cáo và điều khoản. Tôi không chỉ chọn theo giá. Một mức giá hợp lý và hướng dẫn rõ ràng quan trọng hơn với tôi so với một ưu đãi chỉ trở nên hấp dẫn nếu tôi bỏ qua lịch sử mỏng hoặc các điều kiện bất thường.

Khi lệnh được mở, tôi giữ giao dịch hoàn toàn trên Binance P2P. KYC giúp xác định cả hai người dùng, tài khoản ký quỹ (escrow) giữ crypto của người bán, chat lệnh lưu cuộc trò chuyện giao dịch, và Appeal tạo đường đi để Binance Support xử lý tranh chấp. Tôi từ chối các yêu cầu thay đổi bên nhận, thỏa thuận “làm thêm” ngoài lề, tiếp tục sau khi hủy, hoặc chuyển cuộc trò chuyện sang nơi khác.

Danh tính và hình thức thanh toán là “cửa ải” tiếp theo. Với tư cách người mua, tôi gửi đúng số tiền từ một tài khoản đứng tên đã được xác minh của mình đến các chi tiết thanh toán được hiển thị trong lệnh còn hiệu lực. Với tư cách người bán, tôi đối chiếu tên người gửi với danh tính đã được xác minh của người mua, tự mở ngân hàng hoặc ví của mình, và xác nhận toàn bộ số tiền đã được thanh toán và sẵn sàng. Ảnh chụp màn hình và thông báo không có giá trị ủy quyền để giải phóng.

Tôi ghi lại số thứ tự lệnh, mã giao dịch (transaction ID), số tiền, thời điểm (timestamp) và cuộc chat liên quan cho đến khi giao dịch được giải quyết. Nếu tên không khớp, khoản thanh toán bị thiếu hoặc áp lực thay thế cho câu trả lời rõ ràng, tôi để crypto trong ký quỹ và sử dụng Appeal hoặc bộ phận Binance Support chính thức. Tôi không tăng quy mô giao dịch để bù thời gian hay chứng minh sự tin cậy.

Sau khi hoàn tất suôn sẻ, tôi xem lại những gì thực sự diễn ra tốt: các chi tiết khớp nhau, khoản thanh toán đã được ghi nhận, và dấu vết trên nền tảng vẫn được giữ nguyên. Chỉ có bằng chứng lặp lại mới có thể biện minh cho việc tăng giới hạn lớn hơn sau này. Đơn hàng đầu tiên của tôi không phải nghi thức “lấy lòng tin”. Đó là một bài kiểm tra có kiểm soát về quy trình.

@Binance Vietnam #BinanceP2PAnToan $HFT

"Trustless" là một trong những từ bị lạm dụng nhiều nhất trong crypto, và tôi nghĩ các Babylon Trustless Bitcoin Vaults (kho Bitcoin tin cậy-không-cần) của chính họ là một ví dụ nghiên cứu khá tốt về ý nghĩa mà từ đó nên mang so với cách nó thường được dùng. Đọc trực tiếp tài liệu giao thức thay vì chỉ nhìn vào cái tên sẽ làm bức tranh trở nên khác đi một chút.

TBV không loại bỏ mọi tác nhân khỏi hệ thống; nó loại bỏ đúng kiểu tác nhân có thể đơn phương chuyển Bitcoin của bạn mà không cần có sự đồng ý của bạn. Hệ thống vẫn có 3 nhóm tham gia: Vault Providers (nhà cung cấp vault) xử lý việc tạo vault và các yêu cầu nhận tài sản; Arbitrageurs (nhà kinh doanh chênh lệch) với quyền chuộc lại được cấp phép, họ mua phần tài sản thế chấp bị tịch thu trong các đợt thanh lý; và Universal Challengers (những bên thách thức phổ quát) theo dõi mọi yêu cầu chuộc lại như một “lớp chốt chặn” ở cấp giao thức. Không ai trong số họ (kể cả người gửi tiền) có thể chuyển BTC ra ngoài các quy tắc được mã hóa trong Taproot script, và bất kỳ ai trong số họ, kể cả người gửi tiền, đều có thể chặn một yêu cầu không hợp lệ trong khung thời gian diễn ra “fraud-proof window” (cửa sổ chống gian lận).

Điều này thực sự khác với “custodial trust” (niềm tin do bên lưu ký nắm giữ), nơi chỉ có một bên duy nhất sở hữu quyền kiểm soát tùy ý một cách đơn phương. Tuy vậy, không phải là sự vắng mặt hoàn toàn của sự phụ thuộc vào việc người khác xuất hiện và hành động trung thực—đó chính là điều mà “trustless” ngụ ý theo nghĩa đen. Từ chính xác hơn là “trust-minimized” (tối thiểu hóa niềm tin): chuyển niềm tin từ một người giữ tài sản tùy ý sang một tập hợp các vai trò được ràng buộc chặt chẽ bằng ràng buộc mật mã; trong đó có nhiều vai trò được khuyến khích tài chính để bắt lỗi của nhau.

Tôi không nói điều này để hạ thấp những gì Babylon đã xây dựng. Việc phân phối và ràng buộc niềm tin chính xác đến vậy là một thành tựu kỹ thuật thực sự mà đa số dự án BTCFi khác chưa đạt được. Tôi nói vì việc hiểu đúng mô hình thực tế—thay vì hiểu theo câu chữ marketing viết tắt—mới là thứ quyết định liệu việc vay mượn dựa trên Bitcoin “native” (bản địa, gốc) có xứng đáng với mức độ tin cậy mà cái tên của nó ngụ ý hay không.

@BabylonLabs_io $GRVT $BABY #baby

Cách David Tse định khung cho các Vault Bitcoin không cần tin cậy (Trustless) rất thẳng thừng: Bitcoin vẫn ở trên Bitcoin, được điều hành bởi các điều kiện được xác minh chứ không phải được tin tưởng, không có bên trung gian nào đứng giữa một người nắm giữ và các đồng coin của họ. Tóm lại, đó là toàn bộ “chiêu” trong một câu, và ở phía lưu ký, thiết kế cũng chứng minh điều đó: BTC được khóa trong một Taproot UTXO trong suốt quá trình.

Nhưng cách an toàn nhất để thực sự sử dụng TBV trong thực tế lại đi qua một phần cứng cụ thể. Tháng 3 năm 2026, Babylon hợp tác với Ledger—hãng đã bán hơn 8 triệu thiết bị ví phần cứng—nhờ đó các giao dịch vault có thể được ký và xác nhận trực tiếp trên thiết bị bằng Clear Signing, cho phép người dùng đọc chi tiết giao dịch theo cách con người dễ hiểu trước khi chấp thuận bất cứ điều gì. Điều này thực sự an toàn hơn việc duyệt và chấp thuận “mù” thông qua một cửa sổ bật lên trên trình duyệt, đồng thời cũng có nghĩa là lộ trình bảo mật được khuyến nghị cho TBV phụ thuộc vào việc tin tưởng firmware, màn hình và cách triển khai ký của một nhà cung cấp phần cứng cụ thể.

Đây không phải là một bên lưu ký ẩn giấu; không ai ở Ledger có thể di chuyển BTC của người dùng nếu không có thiết bị vật lý và sự chấp thuận của người dùng. Vẫn có sự phụ thuộc, vì một thiết bị bị xâm phạm hoặc trục trặc có thể hiển thị sai chi tiết giao dịch để ký, và thiết kế trustless của Babylon không đi sâu vào việc đảm bảo bất kỳ phần cứng cụ thể nào hoạt động đúng.

Babylon đã loại bỏ trung gian có thể chuyển Bitcoin mà không hỏi ý kiến—cả các tổ chức lưu ký lẫn các cầu nối—và lời hứa đó được giữ nguyên. Tuy nhiên, họ không loại bỏ mọi sự phụ thuộc giữa người dùng và kết quả đúng, vì con đường an toàn nhất để tới TBV vẫn phải dựa vào việc tin một nhà sản xuất phần cứng để hiển thị “sự thật” trên một màn hình nhỏ.

@BabylonLabs_io $HYPER $BABY #baby

Không bọc, không bắc cầu—đường đi của Babylon lặp lại trên gần như mọi mẩu marketing của Trustless Bitcoin Vaults, và đó không phải là một tuyên bố sai. Bitcoin được gửi vào một vault sẽ không bao giờ được đúc thành một token có thể giao dịch tự do như WBTC, và nó cũng không bao giờ được định tuyến thông qua một cầu nối bên thứ ba.

Nhưng một hợp đồng cho vay hoặc hợp đồng perpetual chạy trên Ethereum thì không thể chỉ “nhìn” được chuỗi Bitcoin và biết rằng một vault tồn tại. Nó cần một thứ để đối chiếu. Trong phiên chạy thử Morpho của Babylon từ tháng 10/2025, phía smart contract trên Ethereum sẽ xác minh vault BTC thông qua một Bitcoin light client trước khi nó tính BTC đó làm tài sản thế chấp, và phần assertion BitVM3 nền tảng giúp điều này khả thi vẫn đăng tải khoảng 56 kilobytes dữ liệu on-chain. Một phân tích bên ngoài về thiết kế này thậm chí còn so sánh bộ theo dõi tài sản thế chấp kết quả với một token tổng hợp được dùng thuần để kế toán—khác với một IOU có thể chuyển nhượng—nhưng vẫn là một biểu diễn cần phải tồn tại ở đâu đó bên ngoài chuỗi Bitcoin để mọi thứ hoạt động.

Biểu diễn đó không phải là một token được bọc mà bạn có thể gửi cho bạn bè hoặc tuồn lên sàn giao dịch, và sự khác biệt này là có thật. Nhưng việc “không bọc” hoàn toàn là quá đơn giản hóa một hệ thống vẫn cần một lớp kế toán để nối những gì chuỗi Bitcoin chứng minh với những gì các hợp đồng Ethereum có thể đọc.

Babylon không bọc bitcoin theo nghĩa của WBTC, dù TBV vẫn dựa vào một biểu diễn nhẹ hơn, không thể chuyển nhượng, để làm cho hai chuỗi “nói chuyện” với nhau.

@BabylonLabs_io $EPIC $BABY #baby

Giá vay trên Aave tăng giảm thông qua mức sử dụng (utilization) chứ không phải bằng một cuộc gọi điện thoại tới bộ phận quản lý rủi ro để họ quyết định bạn xứng đáng nhận được mức nào trong ngày đó. Tôi nghĩ sự phân biệt này nằm ở trung tâm lý do vì sao Babylon liên tục mô tả việc vay mượn native Bitcoin được bảo đảm bằng tài sản thế chấp là hiệu quả sử dụng vốn, và đáng để thực sự mổ xẻ cơ chế này thay vì chỉ nghe theo câu chữ một cách bề ngoài.

Trong mô hình của Aave, lãi suất trên các tài sản được vay sẽ tăng giảm theo cách mang tính thuật toán dựa trên việc phần thanh khoản sẵn có hiện đang được vay đến mức nào. Mức sử dụng cao sẽ đẩy lãi suất lên để thu hút thêm người gửi tiền và hạ nhiệt nhu cầu vay. Mức sử dụng thấp sẽ kéo lãi suất xuống. Mọi phần của đường cong đó đều có thể nhìn thấy trên chuỗi (on-chain), và không ai ở Babylon hay Aave có thể âm thầm thay đổi mức lãi suất cụ thể của bạn ở hậu trường theo kiểu các bên cho vay Bitcoin tập trung trong lịch sử từng có thể—và đôi khi đã làm—ngay trước khi một số trong họ sụp đổ hoàn toàn.

Các Babylon Trustless Bitcoin Vaults cung cấp tài sản thế chấp native BTC vào đúng hệ thống định giá này thông qua Babylon Core Lending Spoke trên Aave v4, hiện đang chạy trực tiếp trên public testnet. Người gửi tài sản thế chấp bằng Bitcoin, vay các tài sản được hỗ trợ như USDC hoặc USDT, và mức lãi suất áp dụng được xác định bởi nhu cầu thị trường thực sự và có thể quan sát được đối với thanh khoản đó, thay vì một quyết định được đưa ra về từng cá nhân.

Điều mà testnet hiện tại chưa thể cho chúng ta biết một cách đáng tin là cách thị trường cụ thể này vận hành ra sao khi tài sản thế chấp Bitcoin native đạt đến quy mô đủ lớn. Những đường cong mức sử dụng trông có vẻ hợp lý khi hoạt động testnet còn nhẹ có thể diễn biến hoàn toàn khác khi hàng tỷ USD Bitcoin native và nhu cầu vay thực sự cùng xuất hiện. “Hiệu quả sử dụng vốn” trên giấy và “hiệu quả sử dụng vốn” khi chịu áp lực thực tế là hai tuyên bố khác nhau, và chỉ có một trong số đó đã được kiểm chứng cho đến nay.

@BabylonLabs_io $GRVT $BABY #baby

Vào tháng 12 năm 2025, khi Babylon và Aave lần đầu tiên công bố họ sẽ bắt tay hợp tác, các thông tin được đưa ra lúc bấy giờ cho biết việc thử nghiệm sẽ bắt đầu vào đầu năm 2026, với mục tiêu ra mắt sản phẩm vào khoảng tháng 4. Đó là một mốc công khai cụ thể, chứ không phải kiểu “một ngày nào đó”.

Tháng 4 đến rồi đi mà không có một testnet công khai. “Temp Check” chính thức được gửi tới diễn đàn quản trị của Aave vào ngày 25 tháng 5, và mảng vay mượn được bảo đảm bằng native Bitcoin thực sự chỉ đi vào hoạt động trên testnet công khai vào ngày 2 tháng 6, tức là trễ khoảng hai tháng so với mốc thời gian mục tiêu không chính thức ban đầu.

Nhóm của Babylon sau đó mô tả toàn bộ tiến trình theo cách khác: họ nói đó là bốn tháng kể từ một bước đột phá nghiên cứu quan trọng đến khi có testnet công khai. Cách nói này đúng theo ý của họ, nhưng lại tính từ một điểm xuất phát khác với mốc tháng 4 đã được đề cập trong báo cáo hồi tháng 12.

Hai tháng không phải là điều gì quá “tai tiếng” trong một dự án liên quan đến mật mã mới, một diễn đàn quản trị và quy trình rà soát bảo mật với sự tham gia của năm công ty audit. Tuy nhiên, đó là một khoảng trống thực sự, có thể kiểm chứng, giữa lịch trình công khai ban đầu và những gì rốt cuộc đã được phát hành. Và đáng để gọi thẳng tên vấn đề, thay vì chỉ lặp lại phiên bản câu chuyện nghe có vẻ nhanh nhất.

Babylon không phải dự án “ra đúng lịch” theo mốc thời gian không chính thức sớm nhất, và sự tích hợp này là ví dụ rõ ràng: nó không chạm mốc tháng 4, mà rơi vào trễ hơn vài tháng. Điều đó không làm giảm thành tựu trong việc phát hành được cơ sở hạ tầng testnet hoạt động, nhưng đó là một cách đọc chân thực hơn so với việc coi mọi mốc đều đến đúng hẹn.

@BabylonLabs_io $COTI $RIF $BABY #baby

"Giải pháp vay Bitcoin nguyên bản và không cần tin cậy (trustless) đầu tiên trên thị trường" là một câu nói hoặc hoàn toàn đúng, hoặc quá phóng đại—tùy thuộc hoàn toàn vào mức độ bạn giới hạn phạm vi của từ “thị trường”. Tôi không nghĩ công bằng khi gọi nó là một trong hai theo nghĩa tuyệt đối.

Nếu giới hạn riêng cho Aave, thì nó đúng và xứng đáng được ghi nhận như vậy. Nhóm phát triển của Aave mô tả đây là BTC nguyên bản (native BTC) được cung cấp làm tài sản thế chấp trên giao thức của họ lần đầu tiên, và đây là một “lần đầu tiên” có cơ sở đối với giao thức cho vay lớn nhất trong DeFi xét theo thanh khoản. Nếu mở rộng cho toàn bộ hạng mục BTCFi, tuyên bố này trở nên mờ nhạt nhanh chóng. Một nghiên cứu gần đây của ngành cho biết Babylon, Solv Protocol và Lombard Finance đang kiểm soát khoảng 85% tổng lượng BTC được stake trong toàn ngành; riêng Solv đã đạt gần 2 tỷ USD TVL và Lombard gần 1,8 tỷ USD—cả hai đều đã vận hành các sản phẩm Bitcoin không cần tin cậy (trust minimized) của riêng họ trước đợt ra mắt cho vay cụ thể này. “Đầu tiên” trong lĩnh vực cho vay nói chung, “đầu tiên” xét riêng trên Aave—sẽ cùng tồn tại với “một trong số nhiều” khi bạn mở rộng góc nhìn sang hạ tầng Bitcoin không cần tin cậy nói chung.

Không có cách diễn đạt nào là không trung thực. Chúng chỉ đang trả lời những câu hỏi khác nhau, và người đọc xứng đáng biết câu hỏi nào đang được trả lời trước khi coi “đầu tiên trên thị trường” là một sự thật không kèm điều kiện.

Babylon là đơn vị đầu tiên ở cấp độ Aave: BTC nguyên bản chưa từng đứng ra làm tài sản thế chấp cho một khoản vay ở đó trước đây. Babylon không phải là “đầu tiên” ở cấp độ toàn hạng mục; Solv và Lombard đã và đang vận hành các sản phẩm Bitcoin cỡ lớn không cần tin cậy. Hãy xem xét phạm vi của từ “đầu tiên” trước khi lặp lại nó như một sự thật không được định tính.

@BabylonLabs_io $COTI $RIF $BABY #baby

Trên toàn bộ danh mục BTCfi, một báo cáo ngành gần đây ước tính tổng giá trị bị khóa ở mức khoảng 7,39 tỷ USD, trải rộng trên hơn 68.500 BTC, với ba giao thức là Babylon, Solv và Lombard nắm giữ khoảng 85% trong số đó. Riêng Babylon chiếm phần lớn nhất, hơn 4,79 tỷ USD, chiếm hơn 47% của toàn bộ danh mục, vượt xa Solv với 1,96 tỷ USD và Lombard với 1,78 tỷ USD. Một nghiên cứu khác cho thấy tỷ trọng của Babylon trong TVL đặt cược riêng cho Bitcoin còn cao hơn, vào khoảng 78%.

Nhìn theo một cách, đây là một “hào lũy” thực sự: thanh khoản, các tích hợp và hạ tầng nhà cung cấp tính cuối cùng (finality) được xây dựng trong khoảng hai năm và gần 95 triệu USD vốn đầu tư, khiến đối thủ khó có thể sao chép nhanh chóng. Nhìn theo cách khác, nó lại có nghĩa là toàn bộ câu chuyện BTCfi mà truyền thông crypto đưa ra như bằng chứng rằng Bitcoin có thể là vốn tạo ra lợi nhuận đang bị “đề cao quá mức” như một cuộc trưng cầu ý kiến đối với độ ổn định (uptime), tokenomics và các lựa chọn bảo mật của riêng một giao thức. Một sự cố nghiêm trọng ở Babylon cụ thể sẽ không chỉ làm hại Babylon; nó còn có thể kéo giảm uy tín của cả danh mục mà hiện tại giao thức này đang định hình.

Sự thống trị của Babylon không chỉ đơn thuần là một lợi thế phòng thủ (moat), và cũng không chỉ là sự mong manh (fragility). Dữ liệu ủng hộ cả hai cách đọc, tùy vào lăng kính bạn chọn. Tăng trưởng của danh mục và rủi ro của chính Babylon giờ đây không còn tách rời ở mức tập trung này. Liệu điều đó có thay đổi khi Solv và Lombard thu hẹp khoảng cách hay không vẫn là một câu hỏi còn bỏ ngỏ.

@BabylonLabs_io $BABY #baby $BTW

Các đợt ra mắt theo cơ chế cap ở giai đoạn đầu thường được hiểu theo một trong hai cách: hoặc một nhóm nhỏ người trong cuộc gom nhanh phần phân bổ, còn lại là hoạt động marketing; hoặc nhu cầu thực sự rộng rãi xuất hiện và tiếp tục duy trì khi cap được nâng lên. Câu chuyện nào phù hợp với kế hoạch triển khai Phase-1 của Babylon thì không thể kết luận chỉ từ tiêu đề “Cap-1 được lấp đầy trong 74 phút”.

Nhìn vào những gì đã xảy ra sau cap đầu tiên sẽ trả lời câu hỏi đó. Cap-2 đã nâng trần và thu hút khoảng 23.000 BTC vào tháng 10 năm 2024, tức là hơn 20 lần quy mô toàn bộ phần phân bổ của Cap-1. Cap-3 tiếp tục đẩy xa hơn, đạt khoảng 57.290 BTC vào thời điểm Phase-1 đóng lại vào tháng 12 năm 2024, và báo cáo nội bộ của Babylon về cap cuối cùng cho thấy số lượng người tham gia vào khoảng 135.000, không phải vài trăm ví lớn cùng chia nhau một con số lớn hơn. Tổng lượng BTC tăng hơn 50 lần từ Cap-1 đến thời điểm Cap-3 đóng, và số lượng người tham gia riêng biệt cũng tăng tương ứng ngay bên cạnh đó, thay vì đứng yên.

Khoảng chênh đáng chú ý cần nêu là giữa “một cap được lấp đầy nhanh” theo dạng tiêu đề và “nhu cầu rộng rãi, được duy trì” theo đúng mô thức, hai thứ nghe có vẻ giống nhau nhưng không có gì đảm bảo sẽ đi cùng nhau. Số lượng người tham gia tăng lên đến hàng trăm nghìn ở Cap-3 khó có thể giải thích chỉ bằng việc một nhóm nhỏ người trong cuộc di chuyển nhanh, và điều đó gợi ý rằng tốc độ ban đầu là dấu hiệu của nhu cầu thực sự vượt quá năng lực đáp ứng, hơn là bản thân nhu cầu chỉ hẹp.

Đường cầu của Babylon không chỉ nhanh ngay từ đầu—nó mở rộng. Số lượng người tham gia tăng lên đến hàng trăm nghìn vào thời điểm Phase-1 đóng thay vì tiếp tục tập trung chỉ ở nhóm người tham gia sớm. Đây là một tín hiệu khác so với việc chỉ nhìn vào việc cap được lấp đầy nhanh. Tuy nhiên, nó không nói chắc chắn liệu độ rộng đó có tiếp tục được thể hiện trong các vault hay không.

@BabylonLabs_io $EUL $BABY #baby

Tư cách thành viên phòng gym của một người bạn cho phép anh ấy hủy bất cứ lúc nào, nhưng trước tiên lại yêu cầu thông báo trước 30 ngày. Anh ấy phàn nàn về sự “cản trở” đó cho đến khi một tháng chậm rãi khiến anh ấy cảm thấy biết ơn vì phòng gym không thể mất một nửa số thành viên qua đêm chỉ vì một tuần tệ hại.

Một người tham gia Babylon muốn rút ra trước khi thời hạn khóa ban đầu của họ hết hạn thì không thể chỉ đơn giản rút. Họ phải khởi tạo yêu cầu “thoàn unbond” sớm, yêu cầu một thời hạn khóa tối thiểu mới ít nhất là 1008 khối Bitcoin (khoảng bảy ngày), và cần có sự chấp thuận từ Ủy ban Covenant trước khi giao dịch unbond được thực thi. Đây là sự cản trở mà Babylon cố tình thiết kế để không cho phép thoát ngay lập tức. Lý do thiết kế liên quan trực tiếp đến cách Babylon Genesis đo lường mức độ an ninh của mình: cam kết cuối cùng (finality) của giao thức phụ thuộc vào việc biết vào bất kỳ thời điểm nào có bao nhiêu BTC đang thực sự hỗ trợ mạng lưới, và nếu người tham gia có thể rút ra tức thì một cách không thể dự đoán, thì phần bảo đảm an ninh hiệu quả mà một khối cụ thể nhận được có thể dao động bất ngờ, làm suy yếu ngưỡng chữ ký 66,66% mà finality dựa vào. Cửa sổ unbond bắt buộc và việc ký duyệt covenant mang lại cho mạng lưới một lộ trình “trượt” có thể dự đoán cho dòng vốn rời khỏi hệ thống—tương tự về tinh thần với các giai đoạn unbond trên các chuỗi PoS truyền thống—nhưng được đặt trên thời gian thanh toán của chính Bitcoin thay vì một đồng hồ nội bộ trong hợp đồng thông minh. Chi phí hoàn toàn rơi vào người tham gia, người đó mất khoảng một tuần thanh khoản và cần sự phối hợp của ủy ban cho một hành động mà trên giấy tờ chỉ liên quan đến chính quỹ của họ và chữ ký của họ.

Sự cản trở khi rút khỏi Babylon không phải là thiếu sót; đó là một sự đánh đổi có chủ đích. Nó hy sinh thanh khoản của từng người tham gia để đổi lấy tính dự đoán trên toàn mạng về việc chính xác bao nhiêu BTC đang thực sự bảo trợ an ninh.

@BabylonLabs_io $RIF $BABY #baby

Gần đây, ban quản trị căn hộ của một người bạn đã yêu cầu kiểm tra lý lịch trước khi bất kỳ ai có thể cho thuê căn hộ theo hình thức ngắn hạn, một quy định khiến những chủ sở hữu “tay ngang” cảm thấy bực bội nhưng lại trấn an những cư dân đã từng gặp phải một người thuê tệ trước đó. Việc thẩm định làm chậm quá trình tiếp nhận người thuê và đồng thời cũng ngăn chặn chính vấn đề mà mọi người sợ nhất.

Vai trò cung cấp tính năng “finality” của Babylon Genesis giờ đây bao gồm cả các tổ chức lưu ký/custodian mang tính thể chế như Hex Trust. Khách hàng sẽ ủy quyền BTC cho Hex Trust để nhận phần thưởng staking, trong khi Hex Trust thực hiện các trách nhiệm kỹ thuật về bầu chọn finality thay mặt họ. Đây là một quyết định chủ đích về “cấp độ truy cập”: thay vì yêu cầu từng khách hàng thể chế tự trực tiếp tự quản lý khóa EOTS và tự vận hành hạ tầng finality daemon, thiết kế của Babylon cho phép các custodian được quản lý tiếp nhận gánh nặng vận hành và bảo mật đó như những bên trung gian. Sự đánh đổi là có thật. Việc ủy quyền thông qua một nhà cung cấp finality mang tính thể chế sẽ tập trung nhiều BTC đã stake và quyền biểu quyết vào sau ít hơn, các nhà vận hành lớn hơn—đi ngược lại hướng của phi tập trung tối đa—đổi lại lấy bảo mật khóa chuyên nghiệp và việc xử lý tuân thủ mà nhiều nhà phân bổ theo thể chế cần trước khi họ sẵn sàng tham gia. Vì toàn bộ cơ chế slashing phụ thuộc vào việc nhà cung cấp finality không bao giờ double-sign, việc chọn một nhà cung cấp có kỷ luật vận hành ở chuẩn thể chế thực sự là một quyết định giảm rủi ro đối với bên ủy quyền, không chỉ là một mục tuân thủ trên giấy. Nó cũng giúp Babylon có một “bài pitch” thuyết phục đối với các nhà phân bổ sẽ không bao giờ tự lưu ký khóa trực tiếp, nhưng sẽ ủy quyền cho một cái tên mà họ đã tin từ tài chính truyền thống.

Việc đưa các nhà cung cấp finality mang tính thể chế vào là một sự đánh đổi thiết kế thực sự. Babylon nhận được bảo mật khóa chuyên nghiệp và nguồn vốn mang tính tổ chức, đồng thời đánh đổi để mất đi một phần mức độ phi tập trung tối đa mà một tập hợp nhà cung cấp thuần permissionless có thể mang lại.

@BabylonLabs_io $BABY #baby $RIF $BANK

Tôi đã gọi cho công ty bảo hiểm của mình sau một vụ va chạm nhẹ và bị chuyển vào hàng đợi xử lý theo dạng tạo ticket kèm lời hứa gọi lại nhưng không bao giờ đến. Cửa hàng phần cứng trong khu phố của tôi vẫn có người bắt máy mỗi lần tôi gọi hỏi về một van tưới bị hỏng. Cùng một thời đại, nhưng hoàn toàn khác nhau về cách đặt cược cho hỗ trợ.

GRVT cũng tự đặt cược của riêng mình, và họ nghiêng về mô hình của công ty bảo hiểm thay vì cửa hàng phần cứng. Hỗ trợ chủ yếu vận hành qua kênh tự phục vụ và ticket, thay vì một đường dây điện thoại trực tiếp. Điểm dừng đầu tiên cho hầu hết người dùng là Trung tâm Trợ giúp (Help Center), bao phủ việc thiết lập tài khoản, giao dịch, nạp tiền, rút tiền và các chủ đề bảo mật dưới dạng bài viết tĩnh thay vì một người để gọi. Với mọi vấn đề liên quan đến tài khoản hoặc mang tính kỹ thuật, việc xử lý sẽ diễn ra qua email và gửi ticket, chứ không phải một hàng đợi mà bạn có thể ngồi chờ theo thời gian thực. Kênh mang cảm giác “đang có người” nhất là chat chăm sóc khách hàng trong ứng dụng, chỉ khả dụng trong ứng dụng di động chứ không phải trên toàn bộ nền tảng. Đó là một cấu trúc chủ đích, không phải một sơ suất, bởi một sàn giao dịch lai vừa đối soát giao dịch onchain vừa xử lý khối lượng giao dịch đáng kể hằng ngày thì không thể nhân sự để có quầy điện thoại trực 24/7 như một công ty môi giới truyền thống được—vì vậy mô hình dịch chuyển trọng lượng sang tài liệu và ticket bất đồng bộ thay vì gọi điện trực tiếp. Đây là một lựa chọn đánh đổi hợp lý cho một đội ngũ tinh gọn, nhưng cũng là một đánh đổi thật sự. Một trader đang trong chuỗi thanh lý hàng loạt lúc 3 giờ sáng mà bị kẹt rút tiền thì đang đối mặt với hàng đợi ticket và một bài viết trợ giúp—không phải một người ở đầu dây bên kia. Khoảng cách giữa “chất” thương hiệu theo chuẩn tổ chức và năng lực hỗ trợ theo quy mô startup là điều đáng biết trước khi nó trở nên cấp bách.

GRVT không cung cấp hỗ trợ điện thoại trực tiếp; họ xây dựng cấu trúc trợ giúp dựa trên các bài viết tự phục vụ, ticket qua email và chat trong ứng dụng—một lựa chọn có thể mở rộng cho đội ngũ tinh gọn, đồng thời cũng đồng nghĩa rằng các vấn đề tài khoản khẩn cấp sẽ được giải quyết theo thời gian xử lý ticket, không phải theo thời gian trả lời qua điện thoại.

@grvt_io $GRVT #grvt $LAB $BEE

Một y tá mà tôi biết đã giải thích vì sao bệnh viện giới hạn tốc độ tối đa mà bạn có thể yêu cầu cấp lại thuốc, kể cả với những bệnh nhân cần thường xuyên. Giới hạn tốc độ cho yêu cầu không phải để làm khó những người lương thiện, mà vì một kẻ xấu hành động nhanh có thể gây hại nhiều hơn cả một nghìn người lương thiện làm chậm.

Newton cũng áp dụng cùng một trực giác đối với việc cập nhật quyền và thực thi ý định. Giao thức giới hạn tốc độ và gom lô (batch) để kiểm soát mức độ nhanh mà các thay đổi quyền và các hành động do tác nhân kích hoạt có thể diễn ra, nhằm ngăn tình trạng quá tải hoặc thao túng; đồng thời cơ chế tham gia của các trình xác thực theo kiểu phi tập trung được thiết kế để giảm xác suất thông đồng. Trên lớp đó còn có một chương trình săn tìm lỗ hổng (bug bounty) theo kế hoạch, trả tiền cho các nhà nghiên cứu nhằm phát hiện và công bố lỗ hổng trước khi chúng bị khai thác lén lút, cộng thêm các đợt rà soát định kỳ về hành vi của trình xác thực và tác nhân để phát hiện các bất thường mà một cuộc kiểm toán tại thời điểm khởi chạy sẽ không thể bắt được.

Không cái nào trong số này nghe có vẻ hấp dẫn. Giới hạn tốc độ không phải là tính năng đáng chú ý; bug bounty là thông lệ phổ biến trong ngành hiện nay, không phải điểm khác biệt. Điều nổi bật nằm ở việc coi bảo mật như một kỷ luật vận hành liên tục, thay vì chỉ là một mục “đánh dấu đã kiểm” trong một lần kiểm toán. Nhiều giao thức công bố báo cáo kiểm toán rồi dừng lại, coi bản PDF đã hoàn thành như bằng chứng an toàn. Cách tiếp cận mà Newton nêu ra giả định rằng các mẫu tấn công mới sẽ xuất hiện sau khi ra mắt, đặc biệt khi các tác nhân tự động bắt đầu hành xử theo những cách mà không ai lường trước được trong quá trình rà soát mã tĩnh.

Newton không khẳng định rằng giới hạn tốc độ và phần thưởng săn lỗ hổng khiến hệ thống không thể bị phá vỡ; họ đang xây dựng “đường ống” để liên tục phát hiện và phản ứng với vấn đề. Đây là một canh bạc thầm lặng hơn, ít được thị trường chú ý hơn so với việc tuyên bố có bảo mật hoàn hảo ngay từ đầu.

@NewtonProtocol $NEWT #Newt $PALU $VELVET

Một dự án khởi nghiệp của người hàng xóm tự giới thiệu mình như một công việc “làm trong gara” đầy tinh thần chắp vá, được bạn bè và gia đình tài trợ. Nhiều năm sau, tôi mới biết một trong những người bạn thuở ban đầu đó đã điều hành một văn phòng gia đình cho một quỹ đầu tư chủ quyền vùng Vịnh. Câu chuyện “làm ăn chắp vá” đó không sai, nó chỉ lược đi ai mới là người đứng sau các khoản tiền chi.

Cái định kiến về một sàn giao dịch tự quản lý tài sản, mặc định không cần KYC, là rằng vốn của nó đến từ các vòng gọi vốn theo cộng đồng “crypto-native”, các khoản đầu tư của thiên thần và những người tin theo phong trào cơ sở hơn là tiền từ tài chính truyền thống. Lịch sử huy động vốn của GRVT làm bức tranh đó trở nên phức tạp. Đến tháng 1/2025, công ty đã huy động được 14,3 triệu USD qua nhiều vòng, trong đó có khoản đầu tư chiến lược 5 triệu USD từ Further Ventures, một công ty được hậu thuẫn bởi ADQ—quỹ đầu tư tài sản chủ quyền của Abu Dhabi. Vòng đó đi cùng một Series A sau đó trị giá 19 triệu USD hoàn tất vào cuối năm 2025, đẩy tổng vốn tư nhân lên hơn 33 triệu USD, với những nhà đầu tư trải dài từ các quỹ hạ tầng crypto cho đến các công ty mà hoạt động cốt lõi là tự giao dịch. Vốn “gần khu vực tài sản chủ quyền” và vốn đầu tư mạo hiểm truyền thống đứng sau một nền tảng tự quảng bá mình theo hướng “bỏ KYC” và cho phép người dùng giao dịch chỉ với email—không hẳn là một mâu thuẫn, nhưng nó khiến câu chuyện đơn giản kiểu “sản phẩm chỉ thấy cảm giác vô permission thì chỉ có vốn vô permission mới đứng sau” trở nên khó tin hơn. Đồng tiền tài trợ cho một sàn giao dịch tùy chọn KYC ít nhất cũng phần nào bắt nguồn từ các thể chế được xây dựng hoàn toàn dựa trên dòng vốn đã được xác thực danh tính và quản lý chặt chẽ—đúng nhóm thể chế mà hiện tại chính quá trình onboarding của nền tảng không còn yêu cầu người dùng phải đáp ứng.

GRVT không phải là dự án grassroots, thuần crypto-native như phần branding không-KYC có thể gợi ý. Vốn gắn với tài sản chủ quyền và vốn đầu tư mạo hiểm truyền thống đứng sau nó nhiều ngang với các quỹ crypto-native.

@grvt_io $GRVT #grvt $DCR $XEC

Một người bạn từng làm công việc vận hành mặt đất tại sân bay nói với tôi rằng phần khó nhất trong công việc của anh ấy không phải là việc không ngừng di chuyển một chiếc máy bay nào cả—mà là quyết định xem trong số sáu máy bay đang chờ trên cùng một đoạn taxiway, chiếc nào được phép đi trước khi tất cả cùng muốn được vào đường băng cùng lúc. Sự công bằng khi có tranh chấp trước hết là một bài toán lập lịch, chứ không phải bất kỳ điều gì khác.

Lộ trình của Newton mượn cấu trúc phí cơ bản cộng với phí ưu tiên—cùng một hình thức mà Ethereum đã áp dụng theo EIP-1559—để sắp xếp các giao dịch tự động hóa cạnh tranh để được thực thi tại cùng một thời điểm. Đây không phải là một lựa chọn trung tính; đó là một dự đoán cụ thể về việc “công bằng” nên được hiểu như thế nào khi nhiều tác nhân muốn giao dịch cùng lúc. Mô hình phí cố định, mà đa số các công cụ theo kiểu tuân thủ mặc định sử dụng, đối xử mọi giao dịch giống nhau bất kể mức độ khẩn cấp; kiểu “đến trước được phục vụ trước” không có cách nào để báo hiệu rằng một hành động nào đó quan trọng hơn hành động khác ngay lúc này.

Các cuộc đấu giá gas ưu tiên trên Ethereum đã tạo ra những vấn đề thực tế và được ghi nhận rõ ràng: bot trả giá quá cao để vượt lên trước nhau, người dùng bình thường bị đẩy ra khỏi thị trường trong lúc tắc nghẽn tăng đột biến, các công cụ ước tính phí đoán sai đúng vào thời điểm tệ nhất. Những kiểu hỏng hóc đó sẽ không biến mất chỉ vì các người tham gia trong hàng đợi của Newton là các tác nhân tự động thay vì con người nhấp nút swap.

Việc mượn hình dạng phí của Ethereum đồng nghĩa với việc các tác nhân có thể trả thêm khoản phí ưu tiên để nhảy hàng khi có tranh chấp, nhưng đổi lại là phải “nhập” nguyên vẹn động lực tắc nghẽn và biến động phí mà chính Ethereum đã mất nhiều năm để cố gắng quản lý. Liệu lịch sử này có chuyển dịch suôn sẻ sang một mạng tự động hóa hoàn toàn mới, nơi các tác nhân cạnh tranh chỗ trong block thay vì người dùng nhấp swap, là điều thực sự chưa được kiểm chứng. Newton không phát minh ra một câu trả lời mới cho việc sắp xếp thứ tự giao dịch; họ đã nhập một cơ chế mà vốn đã có sẵn các chế độ thất bại đã biết, đặt cược rằng một hệ thống được xây dựng cho các nhà giao dịch con người sẽ hoạt động một cách có thể dự đoán khi người tham gia là các tác nhân tự động.
@NewtonProtocol $NEWT #Newt $DODO $AA

Có hai cách để băng qua con sông gần quê tôi. Một là có một cây cầu thu phí do chính quận tự xây dựng và duy trì, việc xin phép để thay đổi sẽ chậm hơn, nhưng hoàn toàn nằm dưới sự kiểm soát của quận. Hai là có một dịch vụ phà tư nhân do một công ty riêng vận hành, nhanh hơn để lắp thêm bến hoặc tuyến mới vì đó không phải là hạ tầng do quận tự quản lý, nhưng mọi lượt qua sông đều phụ thuộc việc công ty đó còn hoạt động.

GRVT vận hành hai luồng song song để nạp và rút, tách ra theo cách khá tương đồng. Cầu GRVT Native Bridge bao phủ đúng ba mạng: Ethereum, Arbitrum One và BNB Smart Chain, chuyển USDT trực tiếp thông qua các hợp đồng do chính GRVT sở hữu. Riêng GRVT's Multichain Bridge, được kích hoạt nhờ một đối tác trung gian, mở rộng phạm vi sang Solana, Tron, KAIA và Base, đồng thời cũng chạy trên cùng các mạng nền tảng đó. Luồng này tạo ra một địa chỉ proxy riêng cho mỗi lần nạp thay vì chuyển qua hợp đồng cầu do GRVT sở hữu. Hai hệ thống không thể thay thế cho nhau về mặt kỹ thuật: luồng được đối tác vận hành chỉ hỗ trợ USDT và USDC theo các định dạng mạng cụ thể như ARB, BEP20 và TRC20. Việc nạp một token hoặc mạng không được hỗ trợ vào luồng này có nguy cơ làm mất toàn bộ số tiền, theo tài liệu trợ giúp do chính GRVT cung cấp. Việc chạy cả hai luồng giúp GRVT hỗ trợ nhiều chuỗi hơn so với khả năng duy trì hợp lý chỉ với Native bridge của chính mình, nhưng đổi lại là một phần trải nghiệm nạp phụ thuộc vào thời gian hoạt động của đối tác thay vì phụ thuộc vào các hợp đồng của GRVT.

GRVT không chuyển tiền qua một cây cầu hợp nhất. Họ vận hành một lộ trình trực tiếp do GRVT tự vận hành cho một tập nhỏ các mạng cốt lõi, song song với một lộ trình rộng hơn do đối tác vận hành cho mọi thứ còn lại. Việc chọn dùng cây cầu nào không chỉ là quyết định về sự tiện lợi; đó là lựa chọn giữa việc tin tưởng các hợp đồng do GRVT sở hữu và tin tưởng vào hạ tầng của một công ty khác.

@grvt_io $GRVT #grvt $T $BEE