三个场景 · 为什么需要自己的 service token

识别调用,流转额度

三个场景在现在的架构下都做不到。它们说的是同一个问题。

现在无法完成的三个场景

给出服务的人已经拥有上游。系统里不需要有钱流动。需要的只有两件事。

识别调用。每一次调用都要被计数。有时按人计数,有时只按次数计数。

流转额度。额度要能方便地交到别人手里:从我到朋友,从厂商到 Bob,从 Bob 到学员,再到别人。

0.0.120 版的架构里,能计数的只有钱。所以每一次“限量赠送”都必须先变成钱。service token 是不花钱的计数单位,并且能转账。

现在的架构

两条通路同时存在。三个场景里说的“旧架构”是通路 A。

通路 A · 美元额度 + ops 钱包 · 现在的 main 分支(0.0.124) 用户美元额度账户 Woodpecker 平台额度账本 + ops 钱包 x402 商户按 USDC 收费 Stripe 充值 x402_call 付 USDC Base 主网 平台用 ops 钱包代付。用户的额度扣价格加 15% 手续费。用户没有链上钱包。 通路 B · service token · 五个 Worker 已上线;扩展侧在 PR #127–#140,未合并 用户嵌入式钱包持有 token 我们的 Worker ×5image · voice · jev · … 服务拥有者铸造 token,不花钱 付 1 个 token Base Sepolia token 到账 = 用量记录 铸造 service token,发到用户的钱包
通路 A 的工具是 x402_quote 和 x402_call。通路 B 的工具是 token_pay_call。 通路 B 的统计页面还没有,用量只在链上。三个 Worker 上还有 access key 临时通道。