Request

Request 是什么？

Request 是一个开源的加密支付请求与对账协议，它允许企业或个人创建类似发票的签名支付请求，将请求数据存储在去中心化基础设施中，并在不将资金托管给支付处理方的前提下，将后续链上支付与该请求进行匹配。它试图解决的核心问题并不是抽象意义上的“代币转移”（很多钱包和支付网关已经能做到这一点），而是围绕支付创建一个可验证的会计对象：是谁发起了请求、应付金额是多少、使用了哪种货币或计价单位、结算发生在何处，以及该笔支付是否可以被自动检测和对账。

因此，该协议的实际护城河更多体现在工作流集成上，而不是底层共识本身：Request 将签名支付请求、IPFS 存储、链上 CID 锚定、支付引用事件、webhook、API 工具以及多链支付路由组合在一起，形成一个金融后台基础组件，如 Request Network 文档及其协议总览中所述。docs.request.network

Request 不是一个占主导地位的第一层网络、Rollup，或者大型 DeFi 借贷市场；它是围绕加密发票、支付检测和对账构建的，面向支付和开发者工具的细分应用层。

截至 2026 年 5 月下旬，市场数据提供方将 REQ 归类为中小市值代币，而非系统性重要的加密资产：CoinMarketCap 显示 Request 的排名接近第 384 名，而 CoinGecko 和 DeFiLlama 报告的市值因流通量统计方法和时间点不同而有明显差异。对于这类协议来说，TVL 的参考价值有限：DeFiLlama 的 Request Network page 报告的是金库与代币市场数据，而不是传统的借贷/AMM TVL，这与 Request 作为支付基础设施而非用户存款池的角色是一致的。对它来说，更相关的规模指标是支付量和经其处理的业务活动；基金会官网声称累计处理支付量超过 20 亿美元，并支持广泛的稳定币覆盖，而社区运营的 Request Activity Dashboard 跟踪每日支付笔数和支付量，但尚未提供可与消费级钱包或交易所 DAU/MAU 相类比的清晰用户分群数据。（coinmarketcap.com）

Request 的创始人是谁？何时创立？

Request 成立于 2017 年，由 Christophe Lassuyt 和 Etienne Tatur 创建，两人都曾参与早期金融科技项目 MONEYTIS；Y Combinator 将 Request Network 列为 2017 年冬季项目，总部位于巴黎，Lassuyt 担任创始人/CFO，Tatur 担任创始人/CTO。其发行背景很重要：REQ 诞生于 2017 年的 ICO 周期，那一阶段许多项目试图将以太坊的应用从代币转账拓展到会计、商业与业务自动化。历史 ICO 数据库显示其代币销售发生在 2017 年 10 月，初始代币总量约为 10 亿枚 REQ，尽管当前供应量在销毁和代币会计调整后有所降低。这个“年份”既是优势，也是包袱：Request 经历了多轮市场周期仍保留着可用软件，但它也背负着 2017 年实用型代币项目普遍存在的名誉阴影——早期叙事往往远超短期真实采用。（ycombinator.com）

该项目的叙事随时间逐渐收窄。

最初的定位是一个面向发票、审计轨迹、贸易法规合规和全球支付请求的广义去中心化支付网络；而当前的产品重心则更偏向运营、少一点意识形态色彩，围绕基于 API 的加密支付、链上开票、支付检测、跨链路由、批量支付、周期性支付与对账展开。

这一演进在基金会 2025 年的更新中可见：Request 发布了 API V2、部分支付、增强的 webhook、加密到法币工作流、批量支付以及跨链支付功能，而不是试图成为新的通用区块链。从机构定位上看，这种转变是从“区块链上的 PayPal”转向面向财务团队、支付服务提供商以及需要在多条链上维护结构化支付记录的加密原生企业的中间件。request.network

Request Network 如何运作？

Request 没有自己的工作量证明、权益证明、DAG、验证人集合、排序器，或 Rollup 共识机制。它是一个链下/链上混合协议，将大部分请求内容持久化到 IPFS，在链上锚定 IPFS 内容标识符（CID），并通过支持的结算链上的智能合约处理支付。

文档指出，请求是通过在 Gnosis Chain 上存储 CID 来创建的，而支付则可以发生在 20 多条支持的 EVM 兼容链或 NEAR 上；然后通过索引与派生支付引用相关的链上支付事件来计算请求余额。从技术角度看，Request 是一个应用层协议和开发者 API，它从 Gnosis、以太坊、Base、Arbitrum、Optimism、Polygon 等外部网络继承活性和终局性，而不是提供自身的底层安全预算。docs.request.network

协议的独特机制是“支付引用”。在推荐的基于引用模型中，从请求数据中派生出的唯一标识符将区块链上的支付与底层发票或支付请求关联起来；代理合约将资金转发给收款人，并在事件中记录支付金额及该引用，而子图则对这些事件进行索引，以便后续对账。

系统没有将分片或 ZK-Rollup 作为原生扩容原语，其验证模型更接近“基于事件索引的结算 + 签名请求元数据”，而不是验证加密 Rollup 证明。Request 节点在 IPFS、智能合约和 The Graph 之间提供网关；基金会为开发者便利而运行节点，但建议生产环境的建设者运行自己的节点，这一点很重要，因为即便底层请求数据和合约是开源的，如果过度依赖基金会托管的网关和 API，依然会形成中心化风险。

私密请求在此基础上增加了非对称加密与 AES 加密：请求内容使用 AES 密钥加密，而该密钥会分别用每个参与方的公钥加密后再持久化到 IPFS。docs.request.network

REQ 代币的代币经济模型是什么？

REQ 是一个最初发行量约为 10 亿枚的 ERC-20 代币，其供应特征更适合被理解为“基本固定、带有温和销毁机制”，而不是存在通胀排放的资产。截至 2026 年 5 月下旬，Etherscan 显示其 ERC-20 代币合约地址为 0x8f8221afbb33998d8584a2b05749ba73c37a938a，最大发电总量约为 9.99416 亿枚 REQ，而 CoinMarketCap 报告的流通量约为 7.967 亿枚 REQ，CoinGecko 提供的流通量数据则不同，凸显了“流通量”在如何划分储备、跨链桥和不活跃余额方面的口径差异。

社区仪表盘报告显示约有 58.3 万枚 REQ 被销毁，占初始供应量的比例很小，因此虽然存在通缩效应，但单靠这一点并不足以构成核心投资论点。（etherscan.io）

REQ 的价值捕获是间接的，需要谨慎看待。

文档标明了 REQ 代币及销毁机制合约，可在存储请求时锁定、跨链桥接和销毁 REQ，而 API 文档则描述了通过 API 处理的支付会收取 5 个基点的协议费，对主要美元和欧元计价稳定币，单笔费用上限约为 25 美元或 25 欧元。

这些机制与传统 PoS 质押收益并不相同，Request 也不是通过 REQ 质押来获得安全性的——与以太坊通过 ETH 验证人获得安全性不同。一些第三方描述将 REQ 的用途概括为防垃圾、治理、质押、折扣和独立性等，但当前官方技术文档中并未呈现一个大型流动质押市场、验证人奖励排程，或面向 REQ 持有人的持续排放计划。

因此，最稳健的代币经济解读是：REQ 是一种沿袭自早期的实用/治理型代币，供应上限固定，并带有与使用挂钩的销毁元素，而在可预见的未来，协议的使用价值更有可能直接体现在产品层和由基金会运营的 API 服务上，而不是自动回流给被动持币者。docs.request.network

谁在使用 Request？

REQ 的投机性交易与 Request Network 的实际效用之间存在显著差异。交易所上的代币成交量更多反映市场流动性和投资人轮动，而协议使用情况则更适合通过创建的请求、被检测到的支付、支付量、API 采用度以及在财务工作流中的集成程度来衡量。

Request 自身在 2025 年 5 月的生态系统更新中明确将报告重点从泛泛的交易次数转移到“支付笔数”，因为发票创建、审批、拒绝等动作会放大交易指标，但未必代表真实结算活动。

社区仪表盘同样报告各条支持链上的支付量和支付笔数，但这些是波动性较大的日度指标，不应被简单视为稳定的活跃用户数。从行业定位来看，Request 位于加密支付、稳定币结算、开票、薪酬发放、会计和金库运营的交叉点，而不是 DeFi 流动性、游戏或 NFT 投机领域。request.network

最有说服力的采用证据来自与可识别的财务或加密运营产品的集成，而不是匿名钱包地址数量。Request 的 2025 年的生态更新中，将 Animal Social Club、intrXn、0 Finance、Allora 和 Request Finance 等项目列为活跃建设者，而更早的更新中也提到过 Huma Finance、BSOS、Joba Network 以及其他生态参与者。

2025 年 10 月，Kryptos 宣布已集成 Request Network 的 API，为 Kryptos Enterprise 内部的发票功能提供支持，由 Request 提供发票创建、链上结算、事件 Webhook 和对账功能；该公告同时引用了 Kryptos 自身的采用数据快照：注册用户超过 20 万，在早期阶段已上线超过 50 家 Web3 企业，以及数千个钱包、中心化交易所、DeFi 协议和公链集成。这些数字应被视为“合作平台层面规模”，而非直接代表 REQ 持有者的采用情况，但依然比那些没有来源的“合作传闻”更具实质性。request.network

Request 面临哪些风险与挑战？

与交易所、借贷协议或隐私混币器相比，Request 的监管风险更为隐性，但并非不存在。公开检索与 SEC 诉状文本（通过搜索结果可获取）显示，在 2023 年 SEC 对 Coinbase 和 Binance 的几起重大诉讼中，REQ 并未被点名为涉案代币，截至 2026 年 5 月底，也没有广泛报道显示 SEC 正在针对 Request Network 本身发起专门诉讼。

这并不等于获得了监管“安全港”。REQ 诞生于 2017 年 ICO 时代，通过代币销售募集资金用于协议开发，并且在二级市场持续交易；美国监管机构历来会重点审查这类“为资助协议开发而分发”的代币。

该协议的支付业务同样会触及反洗钱（AML）、制裁筛查、KYC、稳定币监管、资金传输牌照以及税务申报等问题，尤其是在 Request 支持加密资产到法币结算、钱包筛查和企业开票等场景时。中心化风险也不仅是理论上的：由基金会运营的 API、仪表盘、安全支付页面、Request 节点以及支付检测基础设施，会在实际运营中形成依赖，即便合约、SDK 和数据模型保持开源。sec.gov

竞争也极为激烈，因为 Request 所解决的用户侧问题可以从多个方向切入。传统支付处理商正在加入稳定币结算；中心化的加密支付处理商可以提供合规支持、拒付政策、法币出口通道以及商户后台；钱包和交易所可以直接集成支付链接；企业级加密会计服务商可以在自家技术栈中内嵌发票对账功能。在 Web3 内部，Safe、类似 Coinbase Commerce 的产品、多签金库工具、薪资发放平台、稳定币收款/结账工具、链上会计仪表盘以及跨链路由 API，都有能力吞并 Request 流程中的某些环节。

在经济层面，风险在于：如果支付路由与对账日益被“商品化”为标准 API 功能，那么 Request 当前 5 个基点（5 bps）的手续费和与 REQ 销毁挂钩的模式，可能被价格竞争一路压低。其护城河取决于开发者是否会把 Request 的发票对象、支付引用标准以及对账工具视为一个长期的集成层，而不是一个随时可被替换的“便利封装层”。docs.request.network

Request 的未来前景如何？

Request 近期路线图更侧重于产品深度扩展，而非在共识层做颠覆式重构。经过验证的 2025 年及 2026 年初文档显示，其重点包括：API V2 迁移、跨链稳定币支付、批量支付、部分支付、加密到法币支付流程、周期性支付、费用自定义、钱包与网络切换优化、更广泛的支付追踪能力，以及通过 API 支持 25 条以上的公链。跨链支付尤其重要，因为它对应的是现实中的运营痛点：付款方可能在 Optimism 上持有 USDT，而发票要求支付 Base 上的 USDC，财务团队并不希望手动处理跨链桥、代币兑换、Gas 代币与对账。

Request 的文档显示，跨链支付支持 USDC (USDC)、USDT (USDT) 和 DAI (DAI)，覆盖 Ethereum (ETH)、Arbitrum One (ARB)、Base 和 OP Mainnet (OP)，并按交易费用和处理速度对路由进行排序；公开的跨链产品页面则称，Request 使用 LI.FI 进行路由，同时保持统一的支付检测与 Webhook 逻辑。request.network

结构性难点在于“采用密度”。Request 并不需要在广义上击败 Ethereum、Visa、Stripe 或所有稳定币支付处理商；它需要的是，足够多的业务应用、会计产品、支付服务商（PSP）以及加密原生财务团队，愿意在其“请求-与-对账”这一中间层上达成标准化共识。悲观情形是：稳定币支付被直接嵌入钱包、银行与交易所 API，当这一切成为基础设施的一部分时，Request 可能沦为一个小众开发者工具，代币价值捕获空间有限。

相对谨慎的乐观情形是：如果稳定币结算继续扩张，而财务团队又必须维持可审计、非托管、多链的支付记录，那么 Request 将已签名的支付请求、支付引用、Webhooks、批量流程、周期性支付与跨链路由结合起来的这套组合，仍可能是一套有生命力的基础设施。

因此，项目的未来更大程度上取决于：Request 能否把其长期运营记录转化为稳固的集成关系、透明的使用数据，以及一种让机构用户和代币持有者都能清晰理解“真实支付与代币价值之间经济联动”的代币模型，而不是依赖对 REQ 的投机性需求。