多彩编程 多彩编程MZPH · CODE BLOG
ARTICLE DETAIL

文章详情

深耕前端与后端开发技术的一线实战笔记与踩坑复盘。

OKX Agent Payments Protocol 金额显示规范:human/atomic 双形态转换、精度表与未知 decimals 回退

OKX Agent Payments Protocol 金额显示规范:human/atomic 双形态转换、精度表与未知 decimals 回退 【免费下载链接】internet-court-skillThe trust layer for agent-to-agent commerce — natural-language mandates, ERC-7710 delegated permissions, x402 payments, escrow, and dispute resolution as one open, catch-all Agent Skill / Claude Code plugin.项目地址https://gitcode.com/gh_mirrors/in/internet-court-skill点击查看免费下载本文详解 OKX Agent Payments ProtocolOKX 智能体支付协议收录于本仓库vendored/okx中所有用户可见金额的统一显示规范为何必须同时呈现人类可读值与原子最小单位值human (atomic)、如何依据代币 decimals 完成换算、内置精度表覆盖哪些资产以及遇到未知符号时如何在不阻塞支付流程的前提下安全降级。读完本文你将掌握在 x402、MPP charge/session 与 a2a-pay 三类支付路径中正确渲染金额、费率、押金与退款的可执行方法并能据此避免精度错位、误报金额等支付展示事故。为什么金额必须双形态显示在 Agent 与 Agent 之间的支付场景里amount字段在协议层HTTP 402 challenge、PAYMENT-REQUIRED头、WWW-Authenticate: Payment挑战几乎总是以**原子最小单位minimal units**的字符串形式出现——例如1000000、1500000000000000000。直接把这些原始数字丢给用户既无法判断实际价值也无法核对与商定金额是否一致而只显示人类可读值如1.00 USDC又会丢失链上签名/校验所需的精确原子值。因此该协议强制规定一条对所有用户可见金额一律适用的规则见 vendored/okx/okx-agent-payments-protocol/_shared/amount-display.md所有用户可见金额必须同时以人类可读形式和原子形式呈现human (atomic)。典型示例0.0004 USDC (400)1.5 ETH (1500000000000000000)这条规则不只作用于确认卡片而是贯穿协议全流程challenge 解码、确认展示、会话状态回显、close 退款计算、a2a 手续费渲染全部遵循同一格式。在 SKILL.md 的 Cross-cutting「Amount display」一节中该规则被再次明确并指向本共享文档任何路径accepts-based、charge、session、a2a-pay都不能例外。转换公式human atomic / 10^decimals换算关系非常简单且唯一decimals 必须取自 challenge 中的currency代币human atomic / 10^decimals已知原子值400、decimals 为 6USDC/USDT/USDG→400 / 10^6 0.0004已知原子值1500000000000000000、decimals 为 18ETH→1.5在解码链路中这一转换有明确的落点WWW-Authenticate: Payment路径Step A3 解码出amountbase units 字符串如1000000与currencyERC-20 合约地址后必须「Convertamountfrom base units to human-readable」——见 SKILL.md。其中currency就是决定 decimals 的关键字段decimals 是代币属性而非金额属性所以从 challenge 的currency代币解析。accepts-based 402 路径v2 取option.amount、v1 取option.maxAmountRequired同样用代币 decimals 从最小单位换算成人类可读值后展示SKILL.md Step A4。内置 decimals 精度表协议内置了一张硬编码精度表覆盖三种 6 位小数稳定币与 ETH是无需查询即可直接换算的白名单TokenDecimals1 unit1 个原子单位换算示例USDC610000001000000→ 1.00 USDCUSDT610000002500000→ 2.50 USDTUSDG61000000500000→ 0.50 USDGETH18100000000000000000010000000000000000→ 0.01 ETH这张表在实际换算中的含义6 位小数资产USDC/USDT/USDG1 unit 10^6 1000000即 1 个原子单位代表0.000001个代币。表中 USDC 的示例把1000000 1 USDC显示为1.00 USDC说明人类可读侧应保留两位小数格式。18 位小数资产ETH1 unit 10^1810000000000000000 0.01 ETH显示为0.01 ETH。协议规定换算时的展示精度以稳定币两位小数为基准避免把1.000000 USDC这种浮夸位数呈现给用户但原子侧必须原样保留字符串不做任何四舍五入或截断因为它是签名与对账的原始依据。未知符号不在表中的回退流程当 challenge 中的currency代币不在上述精度表内时协议的规则是绝不臆测 decimalsnever assume。回退流程分两步见 amount-display.md优先查询okx-dex获取该代币的 decimals本仓库的 okx-dex 技能可返回链上代币元数据。若仍无法解析则以atomic symbol形式渲染并附加提示语unknown decimals — please double-check the seller-provided amount未知精度——请复核卖家提供的金额关键约束是不要阻塞支付流程Do not block the flow精度未知只影响展示形态不影响 Agent 是否继续完成支付。这保证了即使遇到长尾代币用户体验依然是「提示存疑、流程照走」而不是卡死在查询环节。值得注意的是协议在 references/accepts-schemes.md 中同样遵循「不臆测」精神Permit2 一次性授权金额询问中数字型授权至少需达到required原子单位且必须由用户明示绝不默认给 MAX。双形态规范在各支付路径中的落地该规范不是孤立的展示规则而是被三条支付路径反复引用的硬性要求引用点见 SKILL.md、SKILL.md。accepts-based 402exact / aggr_deferred / upto确认卡片中的金额行来自 v2option.amount或 v1option.maxAmountRequired换算后展示human-readable amountSKILL.md Step A4。多方案推荐流程中每个候选都携带amount (atomic)与amountHuman两个字段推荐卡片同样呈现Amount: human (atomic)见 references/multi-scheme.md 与 L52。WWW-Authenticate charge一次性支付确认卡片要求Amount per request: human-readable (atomic: amount)——人类可读在前、原子值以atomic:标注在后SKILL.md。此外 charge 支持methodDetails.splits[]最多 10 笔拆分收款拆分会改变单方实收但金额展示仍以 challenge 声明的总量为基准换算。session通道/会话支付session 路径是双形态规范最密集的使用场景references/session.md每次状态回显强制采用 Channel channel_id · chain chain_id · escrow escrow · deposit human(deposit) (deposit) · cum human(current_cum) (current_cum) · spent~human(estimated_spent) (estimated_spent) · sig current_sig prefix...格式——押金、累计授权额、预估消费额全部双形态。开通道时的建议押金Suggested: human(suggestedDeposit) (suggestedDeposit)无建议时按unit_amount × 100推算约 100 次请求的预算。充值询问Current balance: human(deposit) (deposit) · Used so far: human(current_cum) (current_cum)。关闭通道后的结算确认涉及三处换算已扣费Charged human(final_cum) (final_cum)、总押金human(deposit) (deposit)、退款Refund of human(deposit - final_cum) (deposit - final_cum)session.md S3.4。这里尤其要注意退款、累计消费、押金差这些「派生金额」同样必须双形态不能因为只是差额就偷懒只给一边。a2a-paypaymentId 支付链接a2a 路径的金额显示有两点特殊见 references/a2a_charge.md手续费渲染status返回的fee_amount是顶层字符串最小单位另有fee_bps表示基点。换算fee_decimal需要查代币 decimals而fee_symbol无法从 status 响应中取回必须复用卖家在create时传入的--symbol上游调用方为唯一事实来源两者皆缺时直接原样展示fee_amount最小单位。a2a 例外a2a 把信任委托给上游因此遇到未列入精度表的符号时不查询okx-dex、不阻塞直接套用未知 decimals 回退atomic symbol double-check。这一例外与通用规则形成对照唯一查询okx-dex的来源是 HTTP 402 类路径a2a 由于签署的是服务器下发的 challenge、无需本地精度换算故直接降级。常见陷阱与最佳实践陷阱正确做法依据只显示人类可读值丢了原子值一律human (atomic)原子侧保留原始字符串amount-display.md用错 decimals如把 ETH 当 6 位decimals 必须来自 challengecurrency代币且查表/查 okx-dex绝不臆测amount-display.md未知符号卡住流程等查询结果查不到就atomic symbol 提示复核不阻塞a2a 路径直接降级amount-display.md、a2a_charge.md手续费符号从 status 响应里找复用create时的--symbol无则显示fee_amount原样a2a_charge.md派生金额退款/消费/差额只给单形态所有用户可见金额一律双形态session.md总结金额显示是支付协议与用户交互的「最后一公里」human (atomic)双形态格式保证了可读性与精确性兼得human atomic / 10^decimals配合内置精度表覆盖了 USDC/USDT/USDG/ETH 四种高频资产而未知符号的「查 okx-dex → 降级渲染 → 不阻塞」三级策略兜底了长尾代币场景。这套规范在accepts-based、charge、session、a2a-pay 四条路径中由 SKILL.md 统一引用是任何基于 OKX Agent Payments Protocol 构建的支付 Agent 都必须遵守的展示基线。赞分享【免费下载链接】internet-court-skillThe trust layer for agent-to-agent commerce — natural-language mandates, ERC-7710 delegated permissions, x402 payments, escrow, and dispute resolution as one open, catch-all Agent Skill / Claude Code plugin.项目地址https://gitcode.com/gh_mirrors/in/internet-court-skill点击查看免费下载相关推荐OKX Agent Payments Protocol accepts 方案深度指南exact / aggr_deferred / upto 的签名、结算与 Permit2 一次性授权OKX Agent Payments Protocol accepts 方案深度指南exact / aggr_deferred / upto 的签名、结算与从零开始理解HTTP/1.x协议基于httparse的协议解析原理教程从零开始理解HTTP/1.x协议基于httparse的协议解析原理教程 HTTP协议是现代互联网通信的基石而高效的协议解析则是构建高性能网络应用的关键。htAurora Store更新管理完全手册如何智能控制应用自动更新Aurora Store更新管理完全手册如何智能控制应用自动更新 Aurora Store是一款功能强大的Android应用商店替代方案它不仅提供了丰富的应移动开发上一篇2025年网盘直链下载助手终极指南一键解锁九大网盘高速下载下一篇用 FRONTEND.md 给 Agent 定义稳定的前端预期learn-harness-engineering 仓库中的 UI 护栏与验证规范创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表