Coinbase đẩy x402 về mức trung lập, trong khi Stripe tiếp tục đặt cược vào cả hai phía bên ngoài MPP.

Tác giả: Charlie, Giám đốc OSL khu vực châu Mỹ, Đối tác đầu tư mạo hiểm tại Generative Ventures. Từng là Phó Chủ tịch tại công ty tiền điện tử kỳ lân Strike (tham gia vào luật Bitcoin của El Salvador và chịu trách nhiệm về Mạng lưới Bitcoin Lightning của Mỹ Latinh và hoạt động kinh doanh thanh toán bằng stablecoin), nhà phân tích kinh tế vĩ mô và tiền tệ tại quỹ đầu tư nghìn tỷ đô la Franklin Templeton, và là một trong những thành viên đầu tiên của tập đoàn thanh toán toàn cầu Adyen.

Bài viết phản ánh quan điểm cá nhân của tác giả và không đại diện cho lập trường của các công ty liên quan.

Gần đây, ngày càng nhiều người quan tâm đến thương mại đại lý, nhưng các giao thức và các bên tham gia khác nhau ngày càng trở nên khó hiểu.

Đặc biệt là tuần trước, trong khi mọi người đang bận rộn tìm hiểu về MPP của Stripe/Tempo, Stripe bất ngờ gia nhập quỹ x402 của đối thủ Coinbase.

Hơn nữa, Cloudflare hiện hỗ trợ cả hai hệ thống. Google cũng tham gia, nhưng họ có AP2 và UCP riêng.

Visa và Mastercard cũng đã tham gia, nhưng rõ ràng họ không có mặt ở đó để hỗ trợ stablecoin.

Tổ chức Linux Foundation công khai định nghĩa x402 là một "nền tảng cơ bản" trung lập, được quản lý chung bởi ngành công nghiệp, trong khi Cloudflare đã tích hợp cả x402 và MPP vào SDK Agent của riêng mình, và Stripe cũng đã công khai tuyên bố rằng họ hỗ trợ cả MPP và x402.

Ai đang cạnh tranh với ai, và ai đang chồng chéo hoạt động với ai?

Tuy nhiên, càng nhìn vào thị trường dạo gần đây, tôi càng cảm thấy rằng "sự hỗn loạn" này không phải vì thị trường thiếu định hướng, mà vì thị trường đã rất rõ ràng rồi. Như tôi đã đề cập trước đó trong x402, có thể chúng ta đã hiểu sai ý định ban đầu của nó: ngay từ đầu, vấn đề này sẽ không được thống nhất bằng một giao thức duy nhất ngay lập tức.

Điều này tương tự như một tình huống phổ biến trong cơ sở hạ tầng internet—các lớp khác nhau đang phát triển đồng thời, các công ty khác nhau đang đặt cược vào các lớp khác nhau, và cuối cùng, khả năng tương tác sẽ giúp toàn bộ hệ thống hoạt động.

Câu chuyện chiến lược thực sự nằm ở việc ai sẽ định nghĩa lớp kiểm soát mặc định cho việc truy cập máy có trả phí trên web tác nhân; và các bên chủ chốt rõ ràng đang tham gia vào nhiều kết nối, vì mọi người vẫn đang đặt cược vào việc điểm nghẽn thực sự sẽ nằm ở đâu—ủy quyền, phân phối hay thanh toán.

1. Tại sao Coinbase lại chuyển giao Quỹ x402 cho Linux?

Nếu x402 chỉ là giao thức của Coinbase, nó sẽ khó có thể trở thành lựa chọn mặc định trong ngành.

Đây không phải là một phát ngôn mang tính chính trị đúng đắn, mà là một logic tiêu chuẩn hóa thực tế.

Lần này, tuyên bố của Linux Foundation rất rõ ràng; nó nhấn mạnh tính trung lập của nhà cung cấp dịch vụ, quản trị cộng đồng và cơ sở hạ tầng dùng chung, thay vì chỉ đơn thuần là "một công ty nào đó đã phát hành một tính năng sản phẩm mới".

Quan trọng hơn, trang web của Quỹ x402 hiện cho biết dự án đang trong giai đoạn thành lập, và cơ chế quản trị cũng như hội đồng quản trị vẫn đang được xây dựng.

Nói cách khác, hành động này không chủ yếu là để thông báo "sản phẩm đã hoàn thiện", mà là để thông báo "chúng tôi muốn tạo một môi trường trung lập cho giao thức này".

Ý nghĩa ẩn chứa bên trong khá đơn giản.

Nếu x402 tiếp tục mang hình thức một tính năng sản phẩm của Coinbase (giống như Base hiện tại), thì các nhà cung cấp dịch vụ đám mây, công ty thanh toán, tổ chức thẻ và các nhà cung cấp nền tảng, ngay cả khi về mặt kỹ thuật sẵn sàng áp dụng nó, cũng sẽ do dự về mặt chính trị.

Không ai muốn giao phó lớp truy cập trả phí trong tương lai cho một nền tảng duy nhất. Việc đặt nó dưới sự quản lý của Linux Foundation không phải vì Coinbase không muốn kiểm soát nó; mà chính là vì họ muốn x402 được sử dụng rộng rãi nên trước tiên họ phải loại bỏ gánh nặng của việc "đây là giao thức của Coinbase".

Điểm này thực sự rất quan trọng bởi vì nhiều người coi những hành động như của quỹ chỉ là những chiêu trò PR hoặc những hành động thể hiện sự cởi mở.

Nhưng trong cuộc chiến giao thức, quản trị là một phần của sản phẩm.

Đặc biệt khi một tiêu chuẩn vẫn còn ở giai đoạn sơ khai và chưa có hiệu ứng mạng lưới tuyệt đối, thì cái gọi là "trung lập và đáng tin cậy" không kém phần quan trọng so với sự tinh tế về mặt kỹ thuật.

Ngược lại, nếu x402 thực sự có thể trở thành một dạng tiêu chuẩn truy cập trả phí gốc HTTP trong tương lai, thì có lẽ không phải vì mã nguồn của nó đẹp nhất, mà vì nó đã giảm thiểu chi phí chính trị sớm hơn so với các giải pháp khác.

Nói cách khác, quản trị ở đây không phải là vai trò hỗ trợ; bản thân quản trị là động lực thúc đẩy tăng trưởng.

2. Chiến lược kép của Stripe thực sự đang hướng đến điều gì?

Lần này, đối thủ đáng chú ý nhất chắc chắn là Stripe, vì các động thái của họ khó hiểu nhất.

Một mặt, họ đã ra mắt MPP với nhiều sự phô trương vào ngày 18 tháng 3, quảng bá nó như một tiêu chuẩn mở cho thanh toán bằng máy.

Mặt khác, nó là một trong những nhà sáng lập đóng góp cho Tổ chức x402 và tài liệu của chính nó cũng hỗ trợ thanh toán bằng máy x402.

Tài liệu của Cloudflare thậm chí còn trực tiếp hơn, nêu rõ rằng MPP tương thích ngược với quy trình thanh toán cốt lõi của x402 và các khách hàng MPP có thể trực tiếp sử dụng các dịch vụ x402 hiện có.

Nếu chỉ xét riêng khía cạnh "cạnh tranh giao thức", Stripe dường như đang theo đuổi chiến lược kép.

Nhưng nếu bạn mở rộng tầm nhìn một chút, cách tiếp cận này thực sự mang lại hiệu quả kinh tế cao nhất.

Bởi vì điều mà Stripe thực sự muốn bảo vệ không chỉ là quá trình bắt tay 402.

Điều mà nó thực sự muốn bảo vệ là các lớp nằm trên cả quá trình bắt tay: thông tin xác thực, tuân thủ quy định, rủi ro, báo cáo, thuế, hoàn tiền, tích hợp với nhà cung cấp.

Có vẻ như Stripe không hoàn toàn tin tưởng vào bất kỳ giao thức nào; thay vào đó, họ dường như đang đảm bảo rằng bất kể tiêu chuẩn bắt tay nào cuối cùng được chấp nhận, Stripe vẫn là lớp trừu tượng mặc định cho các khoản thanh toán của đại lý.

Việc hỗ trợ x402 nhằm đảm bảo sự tham gia vào hệ sinh thái mở; thúc đẩy MPP nhằm giúp định hình ngữ nghĩa cơ bản; và tiếp tục quảng bá ACP và Mã thông báo thanh toán dùng chung nhằm bảo vệ lớp giá trị dày hơn của quy trình làm việc và thông tin xác thực thanh toán.

Như vậy, khía cạnh "kỳ lạ" nhất của Stripe lần này lại chính là khía cạnh chân thật nhất của nó.

Nó không hề giả vờ rằng tương lai sẽ nhanh chóng thu gọn lại thành một giao thức duy nhất. Hành động này nhằm mục đích nói với bạn rằng: ít nhất ở giai đoạn này, không ai nên đặt cược chỉ vào một phía.

3. Đây thực chất là một câu chuyện về cơ sở hạ tầng B2B.

Tôi ngày càng cảm thấy nhiều phương tiện truyền thông đã tập trung sai hướng vào vấn đề này.

Khi nói đến phí đại lý, điều dễ nghĩ đến nhất chính là mảng bán lẻ: Trí tuệ nhân tạo (AI) giúp bạn đặt vé máy bay, đặt phòng khách sạn, đặt hàng và hoàn tất thanh toán.

Nhưng nếu bạn nhìn vào những kịch bản đã thực sự được triển khai công khai và mang đậm tính chất cơ sở hạ tầng, thì kịch bản đầu tiên thành công không phải là quầy thanh toán bán lẻ, mà là các hình thức truy cập trả phí B2B thực tế và quen thuộc hơn: API trả phí, dữ liệu trả phí, công cụ trả phí, phiên duyệt web trả phí, quy trình làm việc của đại lý trả phí.

Cloudflare hiện đã công khai hỗ trợ tính phí cho nội dung HTTP, API và các công cụ MCP sử dụng x402 và MPP.

Con đường áp dụng hiệu quả nhất cho x402 nằm ở các API và công cụ trả phí giữa các nhà phát triển với nhau, bởi vì mô hình "không cần tài khoản + trả phí theo yêu cầu" ở đây không chỉ là một chiêu trò mà là một thực tế hoạt động hiệu quả.

Những thay đổi đằng sau điều này khá đáng kể.

Trước đây, việc tính phí cho API thường yêu cầu phải trải qua một loạt các quy trình "thân thiện với người dùng": mở tài khoản, liên kết thanh toán, cấp khóa API, thiết lập giới hạn, đối chiếu và sau đó xử lý quyền thanh toán.

Đối với con người, điều này đã khá khó chịu rồi; đối với các nhân viên hỗ trợ, nó còn bất tiện hơn nữa.

Điểm hấp dẫn nhất của x402 không phải là việc nó tiên tiến hơn về mã hóa hay trí tuệ nhân tạo, mà là nỗ lực đưa "quyền truy cập trả phí" trở lại chính giao thức HTTP, cho phép kiểm soát truy cập và đàm phán thanh toán diễn ra như một phản hồi yêu cầu thông thường.

Máy chủ trả về mã lỗi 402, cho biết chi phí của yêu cầu này; khách hàng thanh toán, sau đó thử lại yêu cầu tương tự với thông tin thanh toán đã cung cấp.

Nếu nhìn mô hình này từ góc độ phần mềm B2B và truy cập giữa các máy móc, nó vận hành trơn tru hơn nhiều so với góc độ bán lẻ.

Hơn nữa, càng xem xét kỹ hơn về mảng B2B, những ưu điểm của x402 càng trở nên rõ ràng hơn, và những nhược điểm của nó cũng ít gây ảnh hưởng nghiêm trọng hơn.

Bởi vì trong thương mại tiêu dùng, việc hoàn tiền, khiếu nại, xác định người bán hàng chính thức, bảo vệ người tiêu dùng và phân định trách nhiệm đều là những vấn đề phức tạp; nhưng trong các cuộc gọi API và công cụ B2B, tầm quan trọng của những vấn đề này giảm đi đáng kể.

Ngược lại, "không cần tài khoản, trả tiền theo cuộc gọi, nhận kết quả và đi" là một nhu cầu thực tế.

Ngành bán lẻ chắc chắn lớn hơn, sôi động hơn và dễ thu hút sự chú ý hơn; nhưng những tình huống thực sự định hình nên giao thức này thường không phải là những tình huống sôi động nhất, mà là những tình huống đầu tiên bộc lộ nhu cầu thực sự.

Đối với làn sóng thanh toán cho đại lý hiện nay, kịch bản đó có lẽ không phải là giỏ hàng, mà là số lượng ngày càng tăng các quyền truy cập trả phí giữa phần mềm, đại lý và quy trình làm việc.

4. Sự phát triển của ngành công nghiệp đã chứng thực nhận định trước đây của tôi về khả năng tương tác.

Nhận định cốt lõi trong bài viết trước của tôi là về khả năng tương tác.

Vào thời điểm đó, phán quyết này nghe có vẻ giống như "nó nên được cấu trúc theo cách này".

Giờ đây, nó ngày càng giống một ràng buộc thực tế, khi thị trường mở đã bắt đầu thể hiện quan điểm của mình bằng hành động.

Cloudflare không chọn phe nào mà trực tiếp hỗ trợ cả x402 và MPP, đồng thời đưa ra các bản đồ tương thích rõ ràng.

Google đang tham gia vào dự án x402 đồng thời tiếp tục phát triển AP2 và UCP.

Visa và Mastercard cũng không trình bày chiến lược của mình theo kiểu "giải pháp toàn diện"; thay vào đó, cả hai đều tham gia x402 đồng thời tiếp tục tập trung vào mã thông báo đại lý, xác minh danh tính, xác thực hướng dẫn và tín hiệu tranh chấp.

Các khoản đầu tư đa phương của các tập đoàn khổng lồ là những quyết định hợp lý, chứ không phải là sự đạo đức giả về mặt thương mại.

Tại sao lại như vậy? Vì các giao thức này thậm chí không nằm trên cùng một lớp.

Ít nhất cho đến nay, x402 và MPP đang tiến gần hơn đến lớp bắt tay HTTP trả phí, giải quyết câu hỏi "làm thế nào để đảm bảo các yêu cầu trả về có khả năng thanh toán".

AP2 gần hơn với việc ủy ​​quyền và ý định đáng tin cậy, giải quyết câu hỏi "người đại diện này có quyền chi tiêu số tiền này hay không?"

UCP và ACP giống với lớp quy trình làm việc hơn, xử lý việc tìm kiếm, thanh toán, quan hệ với người bán và truyền tải thông tin xác thực — những vấn đề gần gũi hơn với "ai kiểm soát lưu lượng truy cập và điều phối giao dịch".

Nhiều công ty hỗ trợ đồng thời x402, MPP, AP2 và UCP không phải vì bản thân chúng không rõ ràng, mà vì kiến ​​trúc chiến thắng cuối cùng có khả năng trải rộng trên nhiều lớp và thậm chí có thể yêu cầu nhiều giao thức kết hợp với nhau.

Vì vậy, nếu phải tóm tắt nhận định trước đây của tôi trong một câu, thì giờ đây tôi càng tin chắc hơn rằng nếu không có khả năng tương tác giữa các hệ thống, làn sóng phát triển sinh thái học này sẽ không thể xuất hiện.

Nhìn vào tình hình hiện tại, thị trường đang tích cực chứng thực nhận định này.

Hơn nữa, phán quyết này cũng rất quan trọng đối với sự khác biệt giữa mô hình B2B và bán lẻ.

Bởi vì trong thế giới bán lẻ, nó có thể cuối cùng sẽ bị thâu tóm bởi một vài nền tảng lớn và một vài quy trình làm việc chính; nhưng thế giới B2B thì không như vậy.

Về bản chất, các doanh nghiệp tồn tại trong một thực tế nơi đa đám mây, nhiều phương thức thanh toán, nhiều hệ thống quy trình làm việc và nhiều hệ thống phân quyền danh tính cùng tồn tại.

Bất kỳ ai cố gắng sử dụng một giao thức mới để cải tổ hoàn toàn toàn bộ hệ thống doanh nghiệp đều có khả năng thất bại trước tiên.

Điều mà khách hàng B2B thực sự sẵn lòng trả tiền thường không phải là "một giao thức duy nhất đúng", mà là khả năng làm cho các hệ thống hiện có hoạt động trong môi trường đa giao thức.

Chính vì lý do này mà khả năng tương tác lại quan trọng hơn trong môi trường doanh nghiệp so với môi trường người tiêu dùng.

5. Đây không chỉ đơn thuần là cuộc cạnh tranh về giao thức, mà là cuộc cạnh tranh về kiến ​​trúc nhiều lớp.

Khi bạn hiểu vấn đề này như một chồng lớp chồng lên nhau, nhiều hiện tượng ban đầu có vẻ hỗn loạn sẽ lập tức trở nên dễ hiểu.

Ở lớp dưới cùng là bước xác nhận quyền truy cập trả phí.

Lớp này liên quan đến cách các yêu cầu HTTP thể hiện thông báo "cần thanh toán tại đây" và cách máy khách nhận lại thông tin thanh toán sau khi hoàn tất giao dịch.

x402 và MPP đang cạnh tranh chủ yếu ở đây. MPP đang cố gắng chính thức hóa lỗi 402 thành ngữ nghĩa xác thực HTTP chính thức hơn; trong khi x402 tập trung hơn vào việc xây dựng nền tảng cho lỗi 402, sử dụng các tiêu đề tùy chỉnh, các bên trung gian, các trừu tượng thanh toán trên chuỗi và tích hợp hệ sinh thái để đưa nó vào hoạt động trước tiên.

Một cái giống với lộ trình ngữ nghĩa tiêu chuẩn hóa hơn, trong khi cái kia lại giống với lộ trình phân phối nền tảng.

Cấp độ tiếp theo là thẩm quyền chi tiêu, tức là "ai đã cho phép sử dụng số tiền này".

Lớp này chính là chìa khóa mà nhiều người vẫn chưa nhận ra đầy đủ.

Việc máy móc chi trả tiền không quá khó; thách thức thực sự là đảm bảo rằng máy móc có thể được tin tưởng và được ủy quyền để chi tiêu tiền.

AP2 rất quan trọng chính vì nó không chỉ đề cập đến "cách thức thanh toán", mà còn cả các quy định, chứng chỉ có thể kiểm chứng, tính xác thực và trách nhiệm giải trình.

Các mã thông báo của đại lý, xác thực hướng dẫn, mật khẩu và tín hiệu tranh chấp mà Visa và Mastercard gần đây đã tập trung mạnh vào về cơ bản đều thuộc lớp này.

Lớp tiếp theo là quy trình làm việc và phân phối.

Điều này bao gồm việc tìm kiếm, thanh toán, quan hệ với nhà bán lẻ, chia sẻ thông tin đăng nhập và tích hợp giao diện AI — những vấn đề gần gũi hơn với câu hỏi "ai kiểm soát lưu lượng truy cập và điều phối giao dịch?"

UCP và ACP dường như đang cạnh tranh nhau để giành lấy lớp này.

Đối với B2B, lớp này có thể không sôi động trong ngắn hạn, nhưng giá trị lâu dài của nó có thể rất cao.

Bởi vì nếu trong tương lai ngày càng nhiều phần mềm doanh nghiệp được điều phối, gọi điện, mua sắm và thanh toán bởi các đại lý, thì người nào nắm vững ngôn ngữ quy trình làm việc sẽ không chỉ quản lý một khoản thanh toán đơn lẻ mà là toàn bộ quy trình làm việc.

Khi bạn tách biệt ba lớp này, bạn sẽ khám phá ra một sự thật rất đơn giản: không cần thiết phải kỳ vọng một giao thức duy nhất có thể giải quyết tất cả các vấn đề.

Một hướng đi thực tế hơn là để ba lớp này phát triển riêng biệt và sau đó dần dần tương tác với nhau.

Vì lý do này, việc đặt cược nhiều lựa chọn không phải là sự thiếu quyết đoán mà là sự hợp lý.

6. Rủi ro thực sự của x402 có thể không phải là vấn đề quy định, mà là vấn đề kinh tế của việc xử lý đồng thời.

Nếu chúng ta chỉ thừa nhận "sự cùng tồn tại của nhiều giao thức", thì vẫn chưa đủ sâu sắc.

Rủi ro lớn nhất đối với x402 có thể không phải chủ yếu là vấn đề quy định, mà là vấn đề kinh tế thời điểm kiểm tra/thời điểm sử dụng do quy trình xác minh-thanh toán hai bước gây ra.

Nói một cách đơn giản, nếu việc xác nhận thanh toán và việc thanh toán cuối cùng không phải là một, thì trong môi trường internet thực tế với đặc điểm là độ truy cập đồng thời cao, nhiều lần thử lại, các lớp proxy và lớp bộ nhớ đệm, sẽ có một khoảng thời gian cho phép "thanh toán một lần, truy cập nhiều lần".

Hệ sinh thái x402 hiện cũng đang vá các lỗ hổng, chẳng hạn như bộ nhớ đệm thanh toán, mở rộng tính bất biến và định danh thanh toán, nhưng điều này cho thấy rõ ràng rằng vấn đề không chỉ đơn thuần là lý thuyết.

Tại sao điều này lại đặc biệt đáng chú ý đối với độc giả B2B?

Bởi vì điều mà thế giới B2B lo sợ nhất không phải là việc không thể tạo ra một bản demo đẹp mắt, mà là có quá nhiều trường hợp ngoại lệ, và một khi đưa vào sản xuất, nó bắt đầu bị lỗi.

Việc kiếm tiền từ API thoạt nhìn có vẻ chỉ là trả vài xu cho mỗi yêu cầu, khá ít; nhưng một khi sản phẩm của bạn tính phí theo mỗi lần gọi, mỗi kết quả hoặc mỗi quy trình, thì việc "trả tiền một lần được nhiều lần" hay "trả tiền một lần được nhiều lần" không chỉ là chi tiết sản phẩm mà còn là vấn đề sống còn.

Vì vậy, nếu x402 thực sự có thể phát triển mạnh trong lĩnh vực B2B, điều kiện tiên quyết quan trọng không phải là câu chuyện mà là các cơ chế an toàn mặc định này phải đủ đơn giản; nếu không, các doanh nghiệp sẽ không cảm thấy an toàn khi thu hút lưu lượng truy cập thực sự.

7. Các quy trình có thể miễn phí, nhưng các trạm thu phí sẽ không biến mất.

Có một điểm nữa mà tôi nghĩ đáng để làm rõ hơn trong bài viết này.

Nhiều giao thức mở cuối cùng đều đi đến một kết cục rất quen thuộc: bản thân giao thức trở nên ngày càng rẻ, thậm chí miễn phí, nhưng các trạm thu phí thực sự sẽ mọc lên song song với nó.

x402 cũng không khác biệt.

Bản thân tiêu chuẩn này chắc chắn nhấn mạnh tính cởi mở, trung lập và không thu phí, nhưng điều đó không có nghĩa là việc thu lợi nhuận bất chính sẽ biến mất.

Nếu x402 thành công, giá trị sẽ không chỉ nằm chủ yếu trong giao thức mà còn lan tỏa sang các bên hỗ trợ, ví điện tử, quản lý khóa, khám phá, công cụ hoạch định chính sách và các lớp bảo mật – những lớp liền kề này.

Điều này đặc biệt quan trọng đối với lĩnh vực B2B.

Vì khách hàng doanh nghiệp sẽ không đại tu toàn bộ hệ thống của họ để chuyển sang một giao thức mới; điều họ thực sự sẵn sàng trả tiền là chi phí cho việc ai có thể giúp họ sắp xếp lại việc điều phối, chính sách, rủi ro, tuân thủ, kiểm toán, thanh toán và ranh giới quyền hạn trong môi trường đa giao thức.

Nói cách khác, các giao thức sẽ ngày càng giống với các ngôn ngữ cơ bản, nhưng khả năng chuyển đổi các ngôn ngữ này thành các chức năng "sẵn sàng cho doanh nghiệp" sẽ dễ dàng trở thành các nền tảng mới và các trạm thu phí mới.

Đây cũng là lý do tại sao tôi cảm thấy rằng khi nhìn vào x402 ngày nay, chúng ta không nên chỉ tập trung vào việc ai trong số Coinbase, Cloudflare hay Stripe giống "nhân vật chính" hơn.

Điều thực sự đáng quan tâm là ai có cơ hội tốt nhất để đứng vững trên những tầng lớp liền kề này.

Cloudflare nắm giữ vị trí trong lĩnh vực điện toán biên và phân phối lưu lượng truy cập, Stripe nắm giữ vị trí trong cơ sở hạ tầng thanh toán và quan hệ với người bán, Visa và Mastercard nắm giữ vị trí trong lĩnh vực xác thực, mã thông báo mạng và lòng tin người tiêu dùng, còn Google nắm giữ vị trí trong quy trình làm việc và giao diện khám phá.

Việc nắm bắt giá trị thực sự có thể không nằm ở "ai đã định nghĩa 402", mà nằm ở "ai đã tích hợp 402 vào các hệ thống doanh nghiệp lớn hơn".

8. Phần kết luận

Tổ chức x402 không tuyên bố rằng x402 đã chiến thắng trong tất cả các giao thức thương mại dựa trên tác nhân.

Điều này thể hiện sự thừa nhận công khai rằng thế hệ thanh toán đại lý này sẽ không phải là một thế giới chỉ sử dụng một giao thức duy nhất ngay từ ngày đầu tiên.

Việc Coinbase chuyển giao x402 cho Linux Foundation nhằm mục đích biến nó thành một lớp trung lập công cộng hơn là một sản phẩm độc quyền.

Việc Stripe thúc đẩy MPP trong khi tham gia x402 không phải là sự thiếu quyết đoán; đó là vì họ biết rằng hiện tại không nên chỉ đặt cược vào một phía.

Việc Cloudflare hỗ trợ cả hai hệ thống cùng lúc là vì nó gần gũi nhất với lưu lượng truy cập thực tế.

Hành động của các công ty như Google, Visa, Mastercard và Adyen cũng cho thấy điều tương tự: trước tiên, hãy để các hệ thống tương tác với nhau, sau đó mới thảo luận xem ai sẽ nắm giữ lớp nào.

Và nếu chúng ta chuyển góc nhìn ra khỏi lĩnh vực bán lẻ, thì nhận định này càng trở nên rõ ràng hơn.

Vì đối tượng đầu tiên cần đến các giao thức này có thể không phải là giỏ hàng trực tuyến, mà là số lượng ngày càng tăng các phần mềm và dịch vụ B2B tính phí theo từng cuộc gọi, nhiệm vụ hoặc kết quả.

Ngành bán lẻ chắc chắn lớn hơn, nhưng lĩnh vực B2B thường bộc lộ nhu cầu thực sự sớm hơn và định hình cấu trúc hạ tầng cuối cùng sẽ như thế nào sớm hơn.

Trong bài viết trước, tôi đã đặt khả năng tương tác làm trọng tâm, và tôi tin rằng câu trả lời của thị trường giờ đây khá rõ ràng: có, và thậm chí còn sớm hơn tôi nghĩ vào thời điểm đó.

Theo nghĩa này, Quỹ x402 không phải là điểm kết thúc của câu chuyện.

Điều này đơn giản giúp chúng ta nhận ra sớm hơn rằng chủ đề thực sự chưa bao giờ là "ai sẽ thắng", mà là "thế giới này được định sẵn để tương tác trước tiên, và ai có thể chiếm lĩnh tầng lớp có giá trị nhất sau khi khả năng tương tác được thiết lập".