Request

Request là gì?

Request là một giao thức mã nguồn mở dành cho yêu cầu thanh toán và đối soát thanh toán bằng tiền mã hóa, cho phép doanh nghiệp hoặc người dùng tạo một yêu cầu thanh toán dạng hóa đơn đã ký, lưu trữ dữ liệu yêu cầu trên hạ tầng phi tập trung, và khớp các khoản thanh toán on-chain phát sinh với yêu cầu đó mà không cần giao quyền lưu ký tài sản cho một đơn vị xử lý thanh toán. Vấn đề cốt lõi mà giao thức giải quyết không phải là “di chuyển token” theo nghĩa trừu tượng, vốn đã được nhiều ví và cổng thanh toán thực hiện, mà là tạo ra một đối tượng kế toán có thể kiểm chứng xoay quanh khoản thanh toán: ai là người yêu cầu, số tiền đến hạn là bao nhiêu, sử dụng loại tiền tệ hay đơn vị ghi sổ nào, nơi diễn ra quyết toán, và liệu khoản thanh toán có thể được phát hiện và đối soát tự động hay không.

Lợi thế thực tiễn của giao thức vì vậy nằm ở khả năng tích hợp quy trình làm việc hơn là ở cơ chế đồng thuận lớp nền tảng: Request kết hợp các yêu cầu thanh toán đã ký, lưu trữ trên IPFS, neo CID lên chuỗi, sự kiện tham chiếu thanh toán, webhook, bộ công cụ API và định tuyến thanh toán đa chuỗi thành một “primitive” cho bộ phận back-office tài chính, như được mô tả trong tài liệu Request Network và phần tổng quan giao thức của nó. docs.request.network

Request không phải là một Layer 1 thống trị, một rollup hay một giao thức thị trường tiền tệ DeFi quy mô lớn; đây là một lớp ứng dụng chuyên biệt về thanh toán và công cụ dành cho lập trình viên, được xây dựng xoay quanh hóa đơn tiền mã hóa, phát hiện thanh toán và đối soát.

Tính đến cuối tháng 5 năm 2026, các nhà cung cấp dữ liệu thị trường xếp REQ vào nhóm token có vốn hóa nhỏ đến trung bình, thay vì nhóm tài sản tiền mã hóa có tầm quan trọng hệ thống: CoinMarketCap xếp Request ở khoảng hạng #384, trong khi CoinGecko và DeFiLlama đưa ra các con số vốn hóa thị trường khác nhau đáng kể do khác biệt về phương pháp tính nguồn cung lưu hành và thời điểm ghi nhận. Với kiểu giao thức này, TVL là một chỉ số hạn chế: Request Network page trên DeFiLlama ghi nhận dữ liệu kho bạc và thị trường token thay vì TVL cho vay/AMM theo nghĩa truyền thống, điều này phù hợp với vai trò của Request như một hạ tầng thanh toán hơn là một bể tiền gửi của người dùng. Các chỉ báo quy mô phù hợp hơn là khối lượng thanh toán và hoạt động kinh doanh được xử lý; website của foundation cho biết đã xử lý hơn 2 tỷ USD khối lượng thanh toán với độ phủ rộng các stablecoin, trong khi Request Activity Dashboard do cộng đồng vận hành theo dõi số lượng thanh toán hàng ngày và khối lượng thanh toán nhưng không cung cấp các nhóm người dùng DAU/MAU rõ ràng để so sánh với ví hay sàn giao dịch dành cho người dùng cuối. (coinmarketcap.com)

Ai sáng lập Request và vào thời điểm nào?

Request được sáng lập năm 2017 bởi Christophe Lassuyt và Etienne Tatur, cả hai đều gắn với dự án fintech trước đó là MONEYTIS; Y Combinator liệt kê Request Network là một công ty thuộc đợt Winter 2017 đặt trụ sở tại Paris, với Lassuyt là Founder/CFO và Tatur là Founder/CTO. Bối cảnh ra mắt là một yếu tố quan trọng: REQ xuất hiện trong chu kỳ ICO 2017, khi nhiều dự án tìm cách mở rộng phạm vi ứng dụng của Ethereum vượt ra ngoài chuyển token sang các lĩnh vực kế toán, thương mại và tự động hóa nghiệp vụ kinh doanh. Các cơ sở dữ liệu ICO lịch sử cho rằng đợt bán token diễn ra vào tháng 10/2017, với nguồn cung ban đầu khoảng một tỷ REQ, mặc dù nguồn cung hiện tại đã giảm sau các đợt đốt và điều chỉnh ghi nhận token. “Đời” token này mang lại cả lợi thế lẫn gánh nặng: Request đã vượt qua được nhiều chu kỳ thị trường và vẫn duy trì phần mềm đang hoạt động, nhưng cũng phải chịu ảnh hưởng từ định kiến chung đối với các dự án token tiện ích giai đoạn 2017, khi câu chuyện ban đầu thường vượt xa mức độ chấp nhận thực tế trong ngắn hạn. (ycombinator.com)

Câu chuyện về dự án đã được thu hẹp dần theo thời gian.

Khung ý tưởng ban đầu là một mạng lưới thanh toán phi tập trung rộng lớn dành cho hóa đơn, dấu vết kiểm toán, tuân thủ luật thương mại và yêu cầu thanh toán toàn cầu; trọng tâm sản phẩm hiện tại mang tính vận hành nhiều hơn và ít mang tính ý thức hệ hơn, xoay quanh thanh toán tiền mã hóa thông qua API, lập hóa đơn on-chain, phát hiện thanh toán, định tuyến xuyên chuỗi, thanh toán theo lô, thanh toán định kỳ và đối soát.

Sự chuyển dịch này thể hiện rõ trong các cập nhật năm 2025 của foundation: Request phát hành API V2, thanh toán một phần, webhook được nâng cấp, quy trình từ crypto sang fiat, thanh toán theo lô và chức năng thanh toán xuyên chuỗi, thay vì cố gắng trở thành một blockchain mục đích chung mới. Về mặt tổ chức, đây là bước chuyển từ “PayPal trên blockchain” sang tầng middleware cho các đội tài chính, nhà cung cấp dịch vụ thanh toán và doanh nghiệp crypto-native cần bản ghi thanh toán có cấu trúc trên nhiều chuỗi. request.network

Request Network hoạt động như thế nào?

Request không có cơ chế đồng thuận proof-of-work, proof-of-stake, DAG, bộ xác thực, sequencer hay rollup riêng. Đây là một giao thức kết hợp off-chain/on-chain, trong đó phần lớn nội dung yêu cầu được lưu trên IPFS, CID của IPFS được neo lên chuỗi, và các khoản thanh toán được xử lý thông qua smart contract trên các chuỗi quyết toán được hỗ trợ.

Tài liệu ghi rõ rằng yêu cầu được tạo ra bằng cách lưu trữ CID trên Gnosis Chain, trong khi thanh toán có thể diễn ra trên hơn 20 chuỗi tương thích EVM hoặc NEAR; số dư của yêu cầu sau đó được tính bằng cách lập chỉ mục các sự kiện thanh toán on-chain gắn với một tham chiếu thanh toán được dẫn xuất. Về mặt kỹ thuật, Request là một giao thức lớp ứng dụng và là API dành cho lập trình viên, thừa hưởng tính sẵn sàng và tính cuối cùng từ các mạng bên ngoài như Gnosis, Ethereum, Base, Arbitrum, Optimism, Polygon và những mạng khác, thay vì tự cung cấp ngân sách an ninh lớp nền tảng. docs.request.network

Cơ chế khác biệt của giao thức là tham chiếu thanh toán (payment reference). Trong mô hình khuyến nghị dựa trên tham chiếu, một định danh duy nhất được dẫn xuất từ dữ liệu yêu cầu sẽ liên kết khoản thanh toán trên blockchain với hóa đơn hoặc yêu cầu thanh toán tương ứng; các proxy contract chuyển tiếp tiền cho người nhận và phát ra sự kiện chứa số tiền thanh toán và tham chiếu, trong khi các subgraph lập chỉ mục những sự kiện này cho mục đích đối soát về sau.

Hệ thống không sử dụng sharding hay ZK-rollup như các primitive mở rộng quy mô gốc, và mô hình xác minh của nó gần với hình thức quyết toán dựa trên sự kiện được lập chỉ mục cộng với siêu dữ liệu yêu cầu đã ký, hơn là xác minh bằng bằng chứng rollup mật mã. Request Node cung cấp cổng kết nối giữa IPFS, smart contract và The Graph; foundation vận hành các node nhằm tạo thuận tiện cho lập trình viên, nhưng khuyến nghị các nhà xây dựng sản phẩm ở môi trường production tự vận hành node của mình, vì việc phụ thuộc vào cổng và API do foundation vận hành là một vector tập trung, ngay cả khi dữ liệu yêu cầu và contract nền tảng đều là mã nguồn mở.

Các yêu cầu riêng tư bổ sung cơ chế mã hóa bất đối xứng và AES: nội dung yêu cầu được mã hóa bằng khóa AES, và khóa này lại được mã hóa bằng khóa công khai của từng bên liên quan trước khi được lưu trữ trên IPFS. docs.request.network

Tokenomics của REQ là gì?

REQ là một token ERC-20 được phát hành ban đầu với khoảng một tỷ đơn vị, và hồ sơ nguồn cung của nó nên được hiểu là gần như cố định kèm một cơ chế đốt ở mức vừa phải, hơn là một tài sản lạm phát có phát thải định kỳ. Tính đến cuối tháng 5 năm 2026, Etherscan liệt kê contract token ERC-20 tại địa chỉ 0x8f8221afbb33998d8584a2b05749ba73c37a938a với tổng cung tối đa khoảng 999,416 triệu REQ, trong khi CoinMarketCap báo cáo nguồn cung lưu hành khoảng 796,7 triệu REQ và CoinGecko đưa ra con số nguồn cung lưu hành khác, cho thấy “nguồn cung lưu hành” còn phụ thuộc vào cách phân loại dự trữ, cầu nối và các số dư không hoạt động.

Bảng điều khiển cộng đồng ghi nhận khoảng 583.000 REQ đã bị đốt, chỉ là một phần rất nhỏ so với nguồn cung ban đầu, nên hiệu ứng giảm phát có tồn tại nhưng không đủ lớn để tự nó trở thành luận điểm đầu tư trung tâm. (etherscan.io)

Giá trị tích lũy của REQ là gián tiếp và cần được nhìn nhận một cách thận trọng.

Tài liệu kỹ thuật xác định các contract token REQ và contract cơ chế đốt có thể khóa, cầu nối và đốt REQ khi yêu cầu được lưu trữ, trong khi tài liệu API mô tả mức phí giao thức 5 điểm cơ bản trên các khoản thanh toán xử lý qua API, được giới hạn khoảng 25 USD hoặc 25 EUR đối với các stablecoin lớn neo theo USD và EUR.

Những yếu tố này không giống với lợi suất staking PoS thông thường, và Request không được bảo mật bằng staking REQ theo cách Ethereum được bảo mật nhờ các validator staking ETH. Một số mô tả từ bên thứ ba trình bày công dụng của REQ theo các khía cạnh chống spam, quản trị, staking, chiết khấu và tính độc lập, nhưng tài liệu kỹ thuật chính thức hiện tại không đưa ra một thị trường staking thanh khoản lớn, lịch trình phần thưởng cho validator, hay chương trình phát thải định kỳ cho người nắm giữ REQ.

Cách hiểu tokenomics chắc chắn nhất vì vậy là: REQ là một token kiểu tiện ích/quản trị thuộc thế hệ cũ với nguồn cung được giới hạn và một số yếu tố đốt gắn với mức độ sử dụng, trong khi phần lớn giá trị sử dụng giao thức trong ngắn hạn nhiều khả năng sẽ tích lũy trực tiếp hơn cho lớp sản phẩm và các dịch vụ API do foundation vận hành, thay vì tự động chảy về các holder thụ động. docs.request.network

Ai đang sử dụng Request?

Sự khác biệt giữa giao dịch REQ mang tính đầu cơ và mức độ sử dụng thực tế của Request Network là rất đáng kể. Khối lượng token trên sàn thể hiện thanh khoản thị trường và sự luân chuyển của nhà đầu tư, trong khi mức độ sử dụng giao thức được đo tốt hơn bằng số yêu cầu được tạo, số thanh toán được phát hiện, khối lượng thanh toán, mức độ chấp nhận API và mức độ tích hợp vào quy trình làm việc tài chính.

Bản cập nhật hệ sinh thái tháng 5/2025 của chính Request đã chuyển trọng tâm báo cáo từ số lượng giao dịch chung sang “số lượng khoản thanh toán”, bởi việc tạo, phê duyệt, từ chối hóa đơn và các thao tác khác có thể làm phình số liệu giao dịch mà không phản ánh hoạt động quyết toán thực sự.

Bảng điều khiển cộng đồng cũng báo cáo khối lượng thanh toán và số lượng thanh toán trên các chuỗi được hỗ trợ, nhưng đây là các chỉ báo theo ngày mang tính biến động cao và không nên được xem như chỉ số người dùng hoạt động ổn định. Xét theo lĩnh vực, Request nằm ở giao điểm giữa thanh toán crypto, quyết toán bằng stablecoin, lập hóa đơn, payroll, kế toán và vận hành ngân quỹ, chứ không phải các mảng thanh khoản DeFi, game hay đầu cơ NFT. request.network

Bằng chứng mạnh mẽ nhất về mức độ chấp nhận là các tích hợp với những sản phẩm tài chính hoặc vận hành crypto có thể nhận diện được, chứ không phải là số lượng ví ẩn danh. Request’s Các bản cập nhật hệ sinh thái năm 2025 đã nêu tên những nhà xây dựng đang hoạt động, bao gồm Animal Social Club, intrXn, 0 Finance, Allora và Request Finance, trong khi các bản cập nhật trước đó cũng đề cập đến Huma Finance, BSOS, Joba Network và các bên tham gia hệ sinh thái khác.

Vào tháng 10 năm 2025, Kryptos thông báo rằng họ đã tích hợp Request Network API để cung cấp tính năng lập hóa đơn trong Kryptos Enterprise, với Request cung cấp tạo hóa đơn, thanh toán on-chain, webhooks sự kiện và đối soát; thông báo đó cũng trích dẫn ảnh chụp nhanh về mức độ tiếp nhận của chính Kryptos với hơn 200.000 người dùng đã đăng ký, hơn 50 doanh nghiệp Web3 được onboard trong các giai đoạn đầu, và hàng nghìn tích hợp với ví, CEX, DeFi và các blockchain. Những con số này nên được hiểu là quy mô nền tảng-đối tác hơn là mức độ tiếp nhận trực tiếp từ người nắm giữ REQ, nhưng chúng vẫn mang tính thực chất hơn so với các tin đồn hợp tác không có nguồn. request.network

Những Rủi Ro và Thách Thức Đối Với Request Là Gì?

Rủi ro pháp lý với Request tinh vi hơn so với sàn giao dịch, giao thức cho vay hoặc mixer bảo mật, nhưng không phải là bằng không. Các tra cứu công khai và nội dung đơn khiếu nại của SEC có sẵn qua kết quả tìm kiếm không cho thấy REQ được nêu tên là token trong các đơn kiện lớn năm 2023 của SEC đối với Coinbase hoặc Binance, và không có vụ kiện SEC nào đang diễn ra, được đưa tin rộng rãi, nhắm trực tiếp vào Request Network tính đến cuối tháng 5 năm 2026.

Điều đó không đồng nghĩa với vùng an toàn pháp lý. REQ đã được bán trong thời kỳ ICO năm 2017, nó được giao dịch trên các thị trường thứ cấp, và các cơ quan quản lý Hoa Kỳ trong lịch sử đã xem xét kỹ các token được phân phối để tài trợ cho việc phát triển giao thức.

Mảng kinh doanh thanh toán của giao thức cũng chạm tới các câu hỏi về AML, sàng lọc trừng phạt, KYC, quản lý stablecoin, hoạt động chuyển tiền và báo cáo thuế, đặc biệt ở những nơi Request hỗ trợ thanh toán từ crypto sang fiat, sàng lọc ví và lập hóa đơn cho doanh nghiệp. Rủi ro tập trung hóa cũng mang tính thực tiễn hơn là lý thuyết: API, bảng điều khiển (dashboard), trang thanh toán bảo mật do foundation vận hành, các Request Node và hạ tầng phát hiện thanh toán có thể tạo ra sự phụ thuộc vận hành ngay cả khi các smart contract, SDK và mô hình dữ liệu vẫn là mã nguồn mở. sec.gov

Cạnh tranh rất gay gắt vì bài toán hướng tới người dùng của Request có thể bị tấn công từ nhiều hướng. Các bộ xử lý thanh toán truyền thống đang bổ sung tính năng thanh toán bằng stablecoin; các bộ xử lý thanh toán crypto tập trung có thể cung cấp tuân thủ, chính sách bồi hoàn (chargeback), đường thoát sang fiat và bảng điều khiển cho merchant; ví và sàn giao dịch có thể thêm liên kết thanh toán trực tiếp; và các nhà cung cấp giải pháp kế toán crypto cho doanh nghiệp có thể xây dựng tính năng đối soát hóa đơn ngay trong stack của họ. Trong Web3, các sản phẩm giống Safe, Coinbase Commerce, công cụ treasury multisig, nền tảng payroll, nhà cung cấp checkout bằng stablecoin, bảng điều khiển kế toán on-chain và các API định tuyến cross-chain đều có thể hấp thụ từng phần trong quy trình làm việc của Request.

Nguy cơ về kinh tế là mối liên kết giữa phí 5 điểm cơ bản và đốt REQ của Request có thể bị cạnh tranh làm suy giảm nếu định tuyến thanh toán và đối soát trở thành những tính năng API mang tính hàng hóa. Khả năng phòng thủ của nó phụ thuộc vào việc các nhà phát triển có coi đối tượng hóa đơn (invoice object), tiêu chuẩn tham chiếu thanh toán (payment-reference standard) và công cụ đối soát của Request là một lớp tích hợp bền vững hay chỉ là một lớp bao tiện lợi có thể thay thế được. docs.request.network

Triển Vọng Tương Lai Của Request Là Gì?

Lộ trình ngắn hạn của Request có vẻ tập trung vào chiều sâu sản phẩm hơn là tái tạo lớp đồng thuận. Tài liệu đã được xác thực trong năm 2025 và đầu 2026 cho thấy trọng tâm là chuyển sang API V2, thanh toán stablecoin cross-chain, thanh toán theo lô, thanh toán một phần, quy trình từ crypto sang fiat, thanh toán định kỳ, tùy chỉnh phí, cải thiện chuyển đổi ví và mạng lưới, theo dõi thanh toán rộng hơn và hỗ trợ hơn 25 blockchain thông qua bề mặt API. Thanh toán cross-chain đặc biệt quan trọng vì chúng giải quyết một điểm đau vận hành thực tế: bên trả có thể nắm giữ USDT trên Optimism trong khi hóa đơn yêu cầu USDC trên Base, và các đội tài chính không muốn tự mình quản lý bridge, swap, token gas và đối soát.

Tài liệu của Request cho biết thanh toán cross-chain hỗ trợ USDC (USDC), USDT (USDT) và DAI (DAI) trên Ethereum (ETH), Arbitrum One (ARB), Base và OP Mainnet (OP), với các tuyến được xếp hạng theo phí giao dịch và tốc độ xử lý; trang sản phẩm cross-chain công khai nêu rằng Request sử dụng định tuyến LI.FI đồng thời vẫn giữ logic phát hiện thanh toán và webhook thống nhất. request.network

Trở ngại mang tính cấu trúc là mật độ mức độ chấp nhận. Request không cần phải đánh bại Ethereum, Visa, Stripe hay mọi bộ xử lý stablecoin theo nghĩa rộng; nó cần đủ nhiều ứng dụng doanh nghiệp, sản phẩm kế toán, PSP và đội ngũ tài chính crypto-native tiêu chuẩn hóa quanh lớp request-and-reconciliation của mình. Kịch bản bi quan là việc thanh toán bằng stablecoin được nhúng trực tiếp vào ví, ngân hàng và API sàn giao dịch, khiến Request chỉ còn là một công cụ cho nhà phát triển nhỏ với khả năng thu giá trị cho token hạn chế.

Kịch bản lạc quan có phần kiềm chế hơn so với các câu chuyện giá cả: nếu thanh toán bằng stablecoin tiếp tục mở rộng và các đội tài chính cần hồ sơ thanh toán phi lưu ký, đa chuỗi, có thể kiểm toán được, thì sự kết hợp giữa yêu cầu đã ký (signed requests), tham chiếu thanh toán, webhook, luồng theo lô, thanh toán định kỳ và định tuyến cross-chain của Request có thể tiếp tục là hạ tầng khả thi.

Do đó, tương lai của dự án phụ thuộc ít hơn vào nhu cầu mang tính đầu cơ đối với REQ và nhiều hơn vào việc Request có thể chuyển lịch sử vận hành lâu dài của mình thành các tích hợp bền vững, số liệu sử dụng minh bạch và một mô hình token mà mối liên kết kinh tế với các khoản thanh toán thực tế đủ rõ ràng để người dùng tổ chức và người nắm giữ token có thể đánh giá và chấp nhận rủi ro hay không.