尧图网站建设 
x402 Hederaexact支付方案详解TransferTransaction 部分签名、feePayer 代付与 Facilitator 验证规则【免费下载链接】x402A payments protocol for the internet. Built on HTTP.项目地址: https://gitcode.com/GitHub_Trending/x4/x402本文基于 x402 协议仓库中的 Hedera 网络规范 scheme_exact_hedera.md详解exact支付方案在 Hedera 网络上的完整落地细节客户端如何构造并部分签名TransferTransaction、feePayer代付网络费用的机制、PaymentRequirements/PaymentPayload/SettlementResponse三类对象的结构与字段约束以及 Facilitator 在验证与结算阶段必须强制执行的六类安全校验规则。读完本文你可以按规范自行实现 Hedera 上的 x402 收款服务端与 Facilitator 校验逻辑并准确理解自动账户创建这一 Hedera 特有的费用风险。一、方案定位exact在 Hedera 上支持哪些资产x402 是一种构建在 HTTP 之上的互联网支付协议其核心理念是把支付流程嵌入标准的 HTTP 请求/响应之中详见 README.md 中的 Typical x402 flow 一节。协议通过scheme字段扩展不同的资金划转方式其中exact是最早随协议发布的方案资源服务器事先知道需要收取的精确金额例如付费阅读一篇文章、购买数字积分、LLM 调用工具付费等参见 scheme_exact.md。Hedera 网络上的exact方案network形如hedera:mainnet支持两类资产的固定金额划转HBAR 原生代币此时asset字段固定为0.0.0HTSHedera Token Service可兑换通证fungible token此时asset为通证的实体 IDentity ID。该方案是**客户端驱动client-driven**的客户端负责构造并签署真正的转账交易Facilitator 只负责验证、补充feePayer签名并上链广播——Facilitator 无法篡改金额与收款方这与其他网络上exact方案由用户签名锁定资金流向的设计目标一致。二、协议流程14 步完成从 402 到资源交付按规范定义Hedera 上exact的完整交互流程如下原文见 scheme_exact_hedera.md 的 Protocol Flow 一节Client向Resource Server发起资源请求Resource Server返回支付要求信号其中包含PaymentRequirements。关键点是requirements的extra字段中携带feePayer——即一个 Hedera 账户 ID0.0.xxxx由它承担该交易的链上网络费用通常是 Facilitator 的账户Client构造一笔TransferTransaction把指定asset以指定amount从客户端账户转入资源服务器的payTo账户并把transactionId.accountId设置为PaymentRequirements.extra.feePayerClient用自己的钱包签名。此时得到的是一个**部分签名partially signed**的交易——还缺少费用支付方feePayer的签名Client将部分签名交易序列化并编码为 Base64 字符串Client携带包含该 Base64 编码交易的PaymentPayload向资源服务器重新发起请求Resource Server收到请求后把PaymentPayload与PaymentRequirements一起转发给Facilitator Server的/verify端点Facilitator解码并反序列化这笔拟提交的交易Facilitator检查交易合法且仅包含预期的支付转账Facilitator向Resource Server返回VerifyResponse验证成功后Resource Server把载荷转发到 Facilitator 的/settle端点Facilitator Server以feePayer身份补上自己的签名将这份已完整签名的交易提交到 Hedera 网络链上结算成功后Facilitator Server向Resource Server返回SettlementResponseResource Server在响应中将资源授予Client。整个流程与仓库根目录 README.md 中描述的通用 x402 流程402 Payment Required→ 构造PaymentPayload→/verify→ 服务端执行工作 →/settle→200 OK PAYMENT-RESPONSE一脉相承Hedera 的差异在于谁来付 gas的机制交易通过transactionId.accountId把网络费用锁定到feePayer账户且该签名在验证之后、结算之前才由 Facilitator 补全。三、PaymentRequirements字段、单位与完整示例除标准 x402PaymentRequirements字段外Hedera 上的exact方案要求在extra中提供feePayer。规范给出的完整示例如下{ scheme: exact, network: hedera:mainnet, amount: 1000, asset: 0.0.0, payTo: 0.0.1234, maxTimeoutSeconds: 180, extra: { feePayer: 0.0.1235 } }各字段语义与约束规范原文 scheme_exact_hedera.md字段说明assetHTS 可兑换通证的 Hedera 实体 ID若支付 HBAR必须使用0.0.0amount要划转的金额。HBARasset为0.0.0时必须以 tinybar 为单位表达1 HBAR 10⁸ tinybarHTS 通证则使用该通证最小单位按通证 decimals 定义payTo收取资金的资源服务器 Hedera 账户 IDextra.feePayer承担交易网络费用的 Hedera 账户 ID通常是 Facilitator 账户该账户还必须作为费用支付方对交易进行签名这里的单位规范与 scheme_exact.md 中金额精确性Amount exactness这一跨网络关键校验要求相呼应无论哪种网络payTo实际收到的净额必须与amount完全一致。四、PaymentPayload载荷中只有 Base64 的部分签名交易PaymentPayload的payload字段包含一个transaction键{ transaction: AAAAAAAAAAAAA...AAAAAAAAAAAAA }transaction承载的是 Base64 编码的、已序列化的部分签名版式化versionedHedera 交易例如TransferTransaction由客户端签署但尚未由feePayer签署。完整的PaymentPayload对象示例规范原文 scheme_exact_hedera.md{ x402Version: 2, resource: { url: https://example.com/weather, description: Access to protected content, mimeType: application/json }, accepted: { scheme: exact, network: hedera:mainnet, amount: 1000, asset: 0.0.0, payTo: 0.0.1234, maxTimeoutSeconds: 180, extra: { feePayer: 0.0.1235 } }, payload: { transaction: AAAAAAAAAAAAA...AAAAAAAAAAAAA } }注意两点实现细节x402Version为2表明该载荷遵循 x402 v2 传输层格式accepted字段原样回显客户端接受的PaymentRequirements便于 Facilitator 做network/asset/amount的一致性比对。五、SettlementResponse结算回执结算成功后的SettlementResponse结构如下{ success: true, transactionId: 0.0.12351700000000.000000000, network: hedera:mainnet, payer: 0.0.1235 }transactionId已提交交易的 Hedera 交易 ID规范示例采用账户时间戳形式payer代付网络费用的 Hedera 账户 ID即feePayer。六、Facilitator 验证规则六类 MUST 检查这是整份规范中最具安全价值的部分。Facilitator 在代付并签名交易之前必须MUST强制执行以下全部检查规范原文 scheme_exact_hedera.md。1. 交易结构Transaction layout反编译出的交易必须直接是一笔TransferTransaction不得被ScheduleCreateTransaction或其他任何交易类型包裹交易必须满足transactionId.accountId PaymentRequirements中的extra.feePayer确保网络层面的费用支付方就是 Facilitator 账户只包含实现本次支付所必需的转账操作HBAR 或 HTS FT 转账不允许出现任何额外转账或非转账操作所有 HBAR 转账的净和必须为零指定asset的所有转账净和必须为零。2. 费用支付方安全Fee payer safety配置的feePayer不得以任何 HBAR 转账列表中的负值条目出现feePayer不得在指定asset的通证转账列表中作为负值条目出现feePayer可以作为正值条目即收款方出现例如收取费用或自定义费用分配场景但feePayer绝不能是支付交易中的净资金发送方——它仅通过transactionId.accountId代付网络费用。3. 网络与资产正确性Network and asset correctnessPaymentRequirements.network必须是有效的 Hedera CAIP-2 网络标识符对应交易将被提交到的 Hedera 网络如hedera:mainnet、hedera:testnetasset必须是0.0.0表示 HBAR或一个有效的 HTS 可兑换通证 ID交易中的全部通证转账必须且只能是PaymentRequirements.asset指定的单一asset不得出现其他通证 ID。4. 转账意图与目的地Transfer intent and destination交易必须把资金从客户端账户转入PaymentRequirements.payTo指定的账户HBAR 支付计入payTo的 HBAR 净额单位归一化后必须等于PaymentRequirements.amountHTS FT 支付asset计入payTo的净额必须等于PaymentRequirements.amount。5. 金额精确性Amount exactness转入payTo的金额对指定asset必须与PaymentRequirements.amount精确相等除payTo外不得存在针对指定asset的其他正向净转账Facilitator 必须拒绝以下交易计入payTo的净额与PaymentRequirements.amount不精确相等客户端针对指定asset的总发送量超过PaymentRequirements.amount。6. 通用有效性与重放防护General validity and replay protection交易不得已被提交/观察到过实现 SHOULD 在可行范围内做幂等/重放检查Facilitator SHOULD 在有可用的 Hedera API 时对交易做模拟simulate或预检确保客户端的asset余额足以覆盖转账交易预期能在链上成功不出现明显的INSUFFICIENT_BALANCE、通证未关联invalid token association等失败。规范特别强调这些检查是安全关键security-critical的——它们确保费用支付方不会被诱骗转出自己的资金或代付非预期行为。实现方可以引入更严格的限制例如最大费用、最大金额或允许通证列表等额外策略但绝不能放宽上述约束。这与 scheme_exact.md Critical Validation Requirements 一节对 SVM、Stellar 等网络的通用要求属于同一安全模型。七、账户别名与自动账户创建Hedera 特有风险这是 Hedera 网络独有的、值得服务端与 Facilitator 特别关注的机制当资源服务器的payTo使用账户别名account alias例如 EVM 地址或公钥别名而非已存在的账户 ID 时向该别名转 HBAR 可能触发 Hedera 的自动账户创建——第一次向该别名转账会创建新账户并将余额记入其中此时 Facilitator 实际上为该新账户的创建埋单恶意或配置不当的资源服务器可能借此让 Facilitator 代为支付账户创建成本规范不要求Facilitator 禁止此类转账Facilitator 可以自行处理例如要求payTo必须解析为已存在账户、拒绝会触发自动账户创建的交易或者允许并承担该成本。规范建议实现方应记录document自己的策略若允许向别名转账需评估相应成本与滥用风险。八、横向对照Hederaexact与其他网络实现的异同仓库中同一exact方案还有其他网络的分册规范对照阅读有助于理解 Hedera 版本的定位scheme_exact_evm.mdEVM 上由 Facilitator 付 gas、用户通过 EIP-3009transferWithAuthorization或 Permit2 签名控制资金流向同样是一次性的签名授权 Facilitator 广播模型但载体是授权签名而非完整交易scheme_exact_sui.mdSui 上由付款方构造完整已签名交易payload同时包含signature与transaction两个字段scheme_exact_algo.mdAlgorand 上使用原子交易组paymentGroup并额外携带paymentIndex。相比之下Hedera 版exact的特征是客户端提交的是单交易的部分签名TransferTransactiongas 费用通过transactionId.accountId指向feePayer实现Facilitator 的签名在/settle阶段才补入。对实现者而言/verify阶段的核心工作就是对第六节的六类规则逐项反编译校验任何一项不满足都应拒绝代付。九、实现清单Checklist结合规范一份可落地的 Hederaexact实现应覆盖资源服务器侧在 402 响应中正确设置assetHBAR 用0.0.0、amountHBAR 用 tinybar、payTo与extra.feePayer收到PaymentPayload后转发至 Facilitator/verify验证通过则执行工作并调用/settle将SettlementResponse放入成功响应的PAYMENT-RESPONSE头返回给客户端。Facilitator 侧反序列化 Base64 交易确认其为未被包裹的TransferTransaction校验transactionId.accountId等于配置的feePayer校验 HBAR 与asset转账净和均为零、feePayer不出现在任何负值条目中校验networkCAIP-2、asset单一性与目的地/金额精确性执行幂等/重放检查并按可行条件做链上模拟预检全部通过后才以feePayer签名并提交交易最后返回含transactionId与payer的SettlementResponse明确并公开记录对别名自动账户创建场景的策略。【免费下载链接】x402A payments protocol for the internet. Built on HTTP.项目地址: https://gitcode.com/GitHub_Trending/x4/x402创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 x402 Hedera `exact` 支付方案详解：TransferTransaction 部分签名、feePayer 代付与 Facilitator 验证规则
x402 Hederaexact支付方案详解TransferTransaction 部分签名、feePayer 代付与 Facilitator 验证规则【免费下载链接】x402A payments protocol for the internet. Built on HTTP.项目地址: https://gitcode.com/GitHub_Trending/x4/x402本文基于 x402 协议仓库中的 Hedera 网络规范 scheme_exact_hedera.md详解exact支付方案在 Hedera 网络上的完整落地细节客户端如何构造并部分签名TransferTransaction、feePayer代付网络费用的机制、PaymentRequirements/PaymentPayload/SettlementResponse三类对象的结构与字段约束以及 Facilitator 在验证与结算阶段必须强制执行的六类安全校验规则。读完本文你可以按规范自行实现 Hedera 上的 x402 收款服务端与 Facilitator 校验逻辑并准确理解自动账户创建这一 Hedera 特有的费用风险。一、方案定位exact在 Hedera 上支持哪些资产x402 是一种构建在 HTTP 之上的互联网支付协议其核心理念是把支付流程嵌入标准的 HTTP 请求/响应之中详见 README.md 中的 Typical x402 flow 一节。协议通过scheme字段扩展不同的资金划转方式其中exact是最早随协议发布的方案资源服务器事先知道需要收取的精确金额例如付费阅读一篇文章、购买数字积分、LLM 调用工具付费等参见 scheme_exact.md。Hedera 网络上的exact方案network形如hedera:mainnet支持两类资产的固定金额划转HBAR 原生代币此时asset字段固定为0.0.0HTSHedera Token Service可兑换通证fungible token此时asset为通证的实体 IDentity ID。该方案是**客户端驱动client-driven**的客户端负责构造并签署真正的转账交易Facilitator 只负责验证、补充feePayer签名并上链广播——Facilitator 无法篡改金额与收款方这与其他网络上exact方案由用户签名锁定资金流向的设计目标一致。二、协议流程14 步完成从 402 到资源交付按规范定义Hedera 上exact的完整交互流程如下原文见 scheme_exact_hedera.md 的 Protocol Flow 一节Client向Resource Server发起资源请求Resource Server返回支付要求信号其中包含PaymentRequirements。关键点是requirements的extra字段中携带feePayer——即一个 Hedera 账户 ID0.0.xxxx由它承担该交易的链上网络费用通常是 Facilitator 的账户Client构造一笔TransferTransaction把指定asset以指定amount从客户端账户转入资源服务器的payTo账户并把transactionId.accountId设置为PaymentRequirements.extra.feePayerClient用自己的钱包签名。此时得到的是一个**部分签名partially signed**的交易——还缺少费用支付方feePayer的签名Client将部分签名交易序列化并编码为 Base64 字符串Client携带包含该 Base64 编码交易的PaymentPayload向资源服务器重新发起请求Resource Server收到请求后把PaymentPayload与PaymentRequirements一起转发给Facilitator Server的/verify端点Facilitator解码并反序列化这笔拟提交的交易Facilitator检查交易合法且仅包含预期的支付转账Facilitator向Resource Server返回VerifyResponse验证成功后Resource Server把载荷转发到 Facilitator 的/settle端点Facilitator Server以feePayer身份补上自己的签名将这份已完整签名的交易提交到 Hedera 网络链上结算成功后Facilitator Server向Resource Server返回SettlementResponseResource Server在响应中将资源授予Client。整个流程与仓库根目录 README.md 中描述的通用 x402 流程402 Payment Required→ 构造PaymentPayload→/verify→ 服务端执行工作 →/settle→200 OK PAYMENT-RESPONSE一脉相承Hedera 的差异在于谁来付 gas的机制交易通过transactionId.accountId把网络费用锁定到feePayer账户且该签名在验证之后、结算之前才由 Facilitator 补全。三、PaymentRequirements字段、单位与完整示例除标准 x402PaymentRequirements字段外Hedera 上的exact方案要求在extra中提供feePayer。规范给出的完整示例如下{ scheme: exact, network: hedera:mainnet, amount: 1000, asset: 0.0.0, payTo: 0.0.1234, maxTimeoutSeconds: 180, extra: { feePayer: 0.0.1235 } }各字段语义与约束规范原文 scheme_exact_hedera.md字段说明assetHTS 可兑换通证的 Hedera 实体 ID若支付 HBAR必须使用0.0.0amount要划转的金额。HBARasset为0.0.0时必须以 tinybar 为单位表达1 HBAR 10⁸ tinybarHTS 通证则使用该通证最小单位按通证 decimals 定义payTo收取资金的资源服务器 Hedera 账户 IDextra.feePayer承担交易网络费用的 Hedera 账户 ID通常是 Facilitator 账户该账户还必须作为费用支付方对交易进行签名这里的单位规范与 scheme_exact.md 中金额精确性Amount exactness这一跨网络关键校验要求相呼应无论哪种网络payTo实际收到的净额必须与amount完全一致。四、PaymentPayload载荷中只有 Base64 的部分签名交易PaymentPayload的payload字段包含一个transaction键{ transaction: AAAAAAAAAAAAA...AAAAAAAAAAAAA }transaction承载的是 Base64 编码的、已序列化的部分签名版式化versionedHedera 交易例如TransferTransaction由客户端签署但尚未由feePayer签署。完整的PaymentPayload对象示例规范原文 scheme_exact_hedera.md{ x402Version: 2, resource: { url: https://example.com/weather, description: Access to protected content, mimeType: application/json }, accepted: { scheme: exact, network: hedera:mainnet, amount: 1000, asset: 0.0.0, payTo: 0.0.1234, maxTimeoutSeconds: 180, extra: { feePayer: 0.0.1235 } }, payload: { transaction: AAAAAAAAAAAAA...AAAAAAAAAAAAA } }注意两点实现细节x402Version为2表明该载荷遵循 x402 v2 传输层格式accepted字段原样回显客户端接受的PaymentRequirements便于 Facilitator 做network/asset/amount的一致性比对。五、SettlementResponse结算回执结算成功后的SettlementResponse结构如下{ success: true, transactionId: 0.0.12351700000000.000000000, network: hedera:mainnet, payer: 0.0.1235 }transactionId已提交交易的 Hedera 交易 ID规范示例采用账户时间戳形式payer代付网络费用的 Hedera 账户 ID即feePayer。六、Facilitator 验证规则六类 MUST 检查这是整份规范中最具安全价值的部分。Facilitator 在代付并签名交易之前必须MUST强制执行以下全部检查规范原文 scheme_exact_hedera.md。1. 交易结构Transaction layout反编译出的交易必须直接是一笔TransferTransaction不得被ScheduleCreateTransaction或其他任何交易类型包裹交易必须满足transactionId.accountId PaymentRequirements中的extra.feePayer确保网络层面的费用支付方就是 Facilitator 账户只包含实现本次支付所必需的转账操作HBAR 或 HTS FT 转账不允许出现任何额外转账或非转账操作所有 HBAR 转账的净和必须为零指定asset的所有转账净和必须为零。2. 费用支付方安全Fee payer safety配置的feePayer不得以任何 HBAR 转账列表中的负值条目出现feePayer不得在指定asset的通证转账列表中作为负值条目出现feePayer可以作为正值条目即收款方出现例如收取费用或自定义费用分配场景但feePayer绝不能是支付交易中的净资金发送方——它仅通过transactionId.accountId代付网络费用。3. 网络与资产正确性Network and asset correctnessPaymentRequirements.network必须是有效的 Hedera CAIP-2 网络标识符对应交易将被提交到的 Hedera 网络如hedera:mainnet、hedera:testnetasset必须是0.0.0表示 HBAR或一个有效的 HTS 可兑换通证 ID交易中的全部通证转账必须且只能是PaymentRequirements.asset指定的单一asset不得出现其他通证 ID。4. 转账意图与目的地Transfer intent and destination交易必须把资金从客户端账户转入PaymentRequirements.payTo指定的账户HBAR 支付计入payTo的 HBAR 净额单位归一化后必须等于PaymentRequirements.amountHTS FT 支付asset计入payTo的净额必须等于PaymentRequirements.amount。5. 金额精确性Amount exactness转入payTo的金额对指定asset必须与PaymentRequirements.amount精确相等除payTo外不得存在针对指定asset的其他正向净转账Facilitator 必须拒绝以下交易计入payTo的净额与PaymentRequirements.amount不精确相等客户端针对指定asset的总发送量超过PaymentRequirements.amount。6. 通用有效性与重放防护General validity and replay protection交易不得已被提交/观察到过实现 SHOULD 在可行范围内做幂等/重放检查Facilitator SHOULD 在有可用的 Hedera API 时对交易做模拟simulate或预检确保客户端的asset余额足以覆盖转账交易预期能在链上成功不出现明显的INSUFFICIENT_BALANCE、通证未关联invalid token association等失败。规范特别强调这些检查是安全关键security-critical的——它们确保费用支付方不会被诱骗转出自己的资金或代付非预期行为。实现方可以引入更严格的限制例如最大费用、最大金额或允许通证列表等额外策略但绝不能放宽上述约束。这与 scheme_exact.md Critical Validation Requirements 一节对 SVM、Stellar 等网络的通用要求属于同一安全模型。七、账户别名与自动账户创建Hedera 特有风险这是 Hedera 网络独有的、值得服务端与 Facilitator 特别关注的机制当资源服务器的payTo使用账户别名account alias例如 EVM 地址或公钥别名而非已存在的账户 ID 时向该别名转 HBAR 可能触发 Hedera 的自动账户创建——第一次向该别名转账会创建新账户并将余额记入其中此时 Facilitator 实际上为该新账户的创建埋单恶意或配置不当的资源服务器可能借此让 Facilitator 代为支付账户创建成本规范不要求Facilitator 禁止此类转账Facilitator 可以自行处理例如要求payTo必须解析为已存在账户、拒绝会触发自动账户创建的交易或者允许并承担该成本。规范建议实现方应记录document自己的策略若允许向别名转账需评估相应成本与滥用风险。八、横向对照Hederaexact与其他网络实现的异同仓库中同一exact方案还有其他网络的分册规范对照阅读有助于理解 Hedera 版本的定位scheme_exact_evm.mdEVM 上由 Facilitator 付 gas、用户通过 EIP-3009transferWithAuthorization或 Permit2 签名控制资金流向同样是一次性的签名授权 Facilitator 广播模型但载体是授权签名而非完整交易scheme_exact_sui.mdSui 上由付款方构造完整已签名交易payload同时包含signature与transaction两个字段scheme_exact_algo.mdAlgorand 上使用原子交易组paymentGroup并额外携带paymentIndex。相比之下Hedera 版exact的特征是客户端提交的是单交易的部分签名TransferTransactiongas 费用通过transactionId.accountId指向feePayer实现Facilitator 的签名在/settle阶段才补入。对实现者而言/verify阶段的核心工作就是对第六节的六类规则逐项反编译校验任何一项不满足都应拒绝代付。九、实现清单Checklist结合规范一份可落地的 Hederaexact实现应覆盖资源服务器侧在 402 响应中正确设置assetHBAR 用0.0.0、amountHBAR 用 tinybar、payTo与extra.feePayer收到PaymentPayload后转发至 Facilitator/verify验证通过则执行工作并调用/settle将SettlementResponse放入成功响应的PAYMENT-RESPONSE头返回给客户端。Facilitator 侧反序列化 Base64 交易确认其为未被包裹的TransferTransaction校验transactionId.accountId等于配置的feePayer校验 HBAR 与asset转账净和均为零、feePayer不出现在任何负值条目中校验networkCAIP-2、asset单一性与目的地/金额精确性执行幂等/重放检查并按可行条件做链上模拟预检全部通过后才以feePayer签名并提交交易最后返回含transactionId与payer的SettlementResponse明确并公开记录对别名自动账户创建场景的策略。【免费下载链接】x402A payments protocol for the internet. Built on HTTP.项目地址: https://gitcode.com/GitHub_Trending/x4/x402创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考