Tempo Wallet

让 AI Agent 像调 HTTP 接口一样完成支付

整理自官方文档与主网发布 · 2026-03 上线 · 官网 ↗ · 文档 ↗ · GitHub ↗

AI Agent 无需 API Key，Tempo Wallet 自动处理 HTTP 402 挑战，完成链上结算后返回数据

HTTP 状态码 402 叫做"Payment Required"。它在 1991 年就写进了 RFC，标注为"reserved for future use"，然后被搁置了三十年。没有人实现它，因为没有支付层——把信用卡塞进 HTTP 响应头里，没有任何意义。

Stripe 解决了人类支付。它让任何开发者能在网站上收钱。但 Stripe 的收款对象是人——需要账号、需要信用卡、需要 KYC。当付款方是一个 AI Agent，Stripe 就无从下手了。

Tempo 就是为这个缺口而来的。它是一条专为稳定币支付设计的 Layer 1 链，搭配一套叫做 Machine Payments Protocol（MPP） 的协议，让那个搁置了三十年的 402 状态码终于有了意义： Agent 遇到 402，钱包自动结算，数据继续流。整个过程不需要 API Key，不需要人类介入。

核心洞察

Tempo 不是在区块链上重造 Stripe。它是在 HTTP 层里嵌入了一个支付层——让机器之间的服务交换，和调用一个普通 REST API 一样自然。

Tempo 链设计
- 无 Gas Token 设计
- TIP-20 稳定币标准
Tempo Transactions
Tempo vs Ethereum 签名交易的区别
Machine Payments Protocol
- 402 支付流程
- 会话级流式支付
Tempo Wallet CLI
- 核心命令
应用场景
对比：Tempo vs x402
Quick Reference
测验

Tempo 链设计 ↑ top

Tempo 是一条 EVM 兼容的 Layer 1 链，基于 Reth SDK 构建，由 Stripe 和 Paradigm 联合主导，2026 年 3 月主网上线。它的定位不是通用区块链，而是支付基础设施——设计决策围绕"如何让稳定币转账又快又便宜又对机构友好"展开。

— Tempo 官方定位

"A blockchain designed specifically for stablecoin payments at scale — high throughput, low cost, with features that financial institutions and fintech platforms expect."

无 Gas Token 设计 [↑]

几乎所有区块链都有一个同样的入场摩擦：先买 Gas，才能转账。 这对人类已经够烦了，对 AI Agent 更是一道荒谬的关卡——Agent 要用 USDC 买服务，先要持有 ETH，而 ETH 的价格随时在变。

Tempo 彻底移除了这个摩擦。链上没有原生 Gas 代币。 手续费直接用 TIP-20 稳定币支付，通常是 USDC。 Agent 只需要持有稳定币，不需要维护任何 Gas 余额。

Tip:

对于 AI Agent 来说，"不需要 Gas Token"意味着账户管理的复杂度下降一个数量级。资金模型只有一种资产：稳定币。

TIP-20 稳定币标准 [↑]

标准: TIP-20（Tempo 的同质化代币标准，对标 ERC-20）
用途: 链上手续费 · 服务结算 · MPP 支付

TIP-20 vs ERC-20 关键差异
维度	TIP-20（Tempo）	ERC-20（以太坊）
Gas 支付	直接用 TIP-20 支付手续费	必须持有 ETH
Fee Sponsorship	原生支持第三方代付	需要 ERC-4337 等额外基础设施
批量转账	协议级原生批量	需要 Multicall 合约
接口兼容	EVM 兼容，工具链复用	—

Tempo Transactions ↑ top

Tempo 在协议层内置了一套交易能力，让以往需要额外合约或中间件才能做到的事情，变成了一个标准 API 调用。

Tempo Transactions 六大能力
能力	说明
任意稳定币付 Gas	用 USDC、USDT 等任何 TIP-20 稳定币支付链上手续费，无需原生 Gas Token
批量 & 并发交易	单次签名执行多笔转账，大幅降低 Agent 批量操作的成本与延迟
Fee Sponsorship	第三方（如平台方）可代 Agent 支付手续费，Agent 账户零余额也能发送交易
定时支付	协议层原生支持预设时间点触发的转账，无需外部调度服务
Passkey 认证	支持 Touch ID / Face ID / 硬件密钥签名，替代私钥管理
备注（Memo）	每笔交易可附加结构化备注，供对账、审计、Agent 间协议协商使用

Passkey 认证 [↑]

Tempo Wallet 支持用系统 Passkey（Touch ID、Face ID、YubiKey）直接签名交易，完全绕过私钥文件的管理问题。对于人类用户，这意味着"刷指纹就能付款"。对于 Agent，这为 TEE 环境下的无私钥签名提供了基础。

注意:

Passkey 认证目前主要服务于 wallet.tempo.xyz 的浏览器端。CLI 钱包在服务端环境下仍使用密钥文件或环境变量注入的方式管理凭证。

Tempo vs Ethereum 签名交易的区别 ↑ top

Tempo 是 EVM 兼容链，因此大量底层概念沿用以太坊——同样基于 ECDSA 椭圆曲线、同样的账户模型。但在签名算法、交易字段、Gas 模型三个维度上，Tempo 做出了系统性的差异化设计，尤其是引入了 Passkey（WebAuthn P-256） 作为第二条签名路径，彻底改变了私钥管理方式。

Tempo 签名交易 vs Ethereum 签名交易 — 关键差异
维度	Ethereum	Tempo
签名曲线	secp256k1（唯一选项）	secp256k1（传统路径）或 secp256r1 / P-256（Passkey 路径）
签名组件	`v, r, s`（或 EIP-2718 的 `yParity, r, s`）	传统路径同 Ethereum； Passkey 路径：`authenticatorData + clientDataJSON + (r, s)`
哈希算法	RLP 编码 → keccak256	传统路径：RLP → keccak256； Passkey 路径：SHA-256（WebAuthn 规范）
Gas 字段	`gasLimit` + `gasPrice` / `maxFeePerGas`，以 ETH 计价	`fee_amount` + `fee_token`（稳定币地址），无原生 Gas Token
额外字段	标准字段：nonce, to, value, data, chainId	新增：`memo`（结构化备注）、`sponsor`（代付方地址）、`batch_ops`（批量操作列表）
批量交易	需要 Multicall 合约，多次签名或一次签名调用合约	协议原生支持，`batch_ops` 字段携带多笔转账，单次签名覆盖所有操作
Fee Sponsorship	依赖 ERC-4337 UserOperation，需要 Bundler + Paymaster 基础设施	交易结构原生包含 `sponsor` 字段，链上协议层直接验证，无需额外合约
链上验证复杂度	单一 ecrecover（secp256k1），验证成本固定	传统路径同 Ethereum；Passkey 路径需链上验证 WebAuthn 断言，成本略高

Ethereum 签名流程 [↑]

以太坊的交易签名流程相对固定：对交易体做 RLP 编码后求 keccak256 哈希，再用 secp256k1 私钥生成 ECDSA 签名。

// Ethereum EIP-1559 交易签名（伪代码）
const tx = {
  chainId:              1,
  nonce:                42,
  maxFeePerGas:         20_000_000_000n,   // wei，ETH 计价
  maxPriorityFeePerGas: 1_000_000_000n,
  gasLimit:             21_000n,
  to:                   "0xRecipient...",
  value:                0n,
  data:                 "0x",
};

// 1. RLP 编码 → keccak256 哈希
const txHash = keccak256(rlpEncode(tx));

// 2. secp256k1 ECDSA 签名
const { r, s, yParity } = secp256k1.sign(txHash, privateKey);

// 3. 广播：链上用 ecrecover 还原公钥，验证发送方地址

关键约束:

Ethereum 签名强依赖私钥文件。私钥泄露 = 账户完全失控，且无法撤销。这对 AI Agent 和服务端场景是安全瓶颈。

Tempo 传统路径签名流程 [↑]

Tempo 的传统签名路径与 Ethereum 兼容，但交易字段结构不同—— 移除了 ETH Gas 字段，改为稳定币计价的 fee_amount / fee_token，并新增了 Tempo 专属字段。

// Tempo 交易签名（传统 secp256k1 路径，伪代码）
const tx = {
  chainId:    tempo_chain_id,
  nonce:      42,
  // ↓ 替代 gasPrice / gasLimit：稳定币计价手续费
  fee_amount: "0.001",
  fee_token:  "0xUSDC_on_Tempo...",
  to:         "0xRecipient...",
  value:      "1.00",           // USDC 金额
  memo:       "服务费-2026-04",   // Tempo 新增：结构化备注
  sponsor:    "0xPlatform...",   // Tempo 新增：代付方（可选）
  batch_ops:  [],                   // Tempo 新增：批量操作列表
};

// 签名机制与 Ethereum 相同：RLP → keccak256 → secp256k1
const txHash = keccak256(rlpEncode(tx));
const { r, s, yParity } = secp256k1.sign(txHash, privateKey);

// 批量示例：单次签名，多笔转账
tx.batch_ops = [
  { to: "0xA...", value: "0.50", memo: "pay-A" },
  { to: "0xB...", value: "0.30", memo: "pay-B" },
];
// 链上一次性执行全部操作，无需 Multicall 合约

Passkey（P-256）签名路径 [↑]

这是 Tempo 与 Ethereum 最本质的签名差异：Tempo 支持 WebAuthn Passkey 作为签名者，使用的是 P-256（secp256r1） 曲线，而非 Ethereum 的 secp256k1。签名由设备安全芯片（Secure Enclave / YubiKey）完成，私钥永远不离开设备。

左：Ethereum secp256k1 路径，私钥文件参与签名；右：Tempo Passkey 路径，私钥由设备安全芯片持有，永不导出

// Tempo Passkey 签名流程（伪代码）

// 1. 构造 Tempo 交易体（同传统路径）
const tx = { fee_token: USDC, to: "0x...", value: "1.00", memo: "..." };

// 2. 序列化为 clientDataJSON（WebAuthn 挑战）
const challenge = base64url(sha256(cbor_encode(tx)));

// 3. 调用 WebAuthn API，设备安全芯片完成签名（P-256 曲线）
const assertion = await navigator.credentials.get({
  publicKey: { challenge, allowCredentials: [{ id: credentialId }] }
});
// assertion 包含：authenticatorData, clientDataJSON, signature(r, s)

// 4. 将 WebAuthn 断言附加到 Tempo 交易并广播
const signedTx = { ...tx, auth: {
  type:              "passkey",
  authenticatorData: assertion.authenticatorData,
  clientDataJSON:    assertion.clientDataJSON,
  signature:         assertion.signature,   // (r, s) over P-256
}};

// 5. 链上：Tempo 节点调用 P-256 验证合约还原公钥并匹配账户

为什么 Passkey 更安全？

secp256k1 私钥一旦写入文件，就存在泄露风险（备份、日志、内存 dump）。P-256 Passkey 的私钥由设备安全芯片生成，永远不会以任何形式导出——攻击者即使拿到服务器也无法盗走密钥，因为密钥根本不在服务器上。

签名路径选择指南
场景	推荐路径	原因
服务端 Agent 自动签名	secp256k1（传统）	无需用户交互，私钥通过 TEE 或 HSM 注入环境变量
浏览器端用户授权支付	Passkey（P-256）	Touch ID / Face ID 确认，零私钥管理，用户体验最佳
高安全级别批量结算	Passkey + 硬件密钥（YubiKey）	物理介质双重保护，适合大额资金操作
跨工具链兼容（ethers.js / viem）	secp256k1（传统）	EVM 兼容，现有以太坊工具链可直接复用

Machine Payments Protocol ↑ top

MPP 是 Tempo 的核心创新，也是让 HTTP 402 真正"活起来"的那层协议。它定义了一套标准的请求—挑战—结算—重试流程，让任何支持 MPP 的钱包都能自动处理付费 API，而无需在每个 API 集成时手动管理支付逻辑。

HTTP 402 支付流程 [↑]

MPP 完整的 402 支付握手：Agent 感知不到支付过程，只看到最终的 200 响应

整个流程对 Agent 透明：

Agent 发送普通 HTTP 请求
服务器返回 402 Payment Required，响应头带 X-Payment 字段（含价格、收款地址、代币类型）
MPP Engine 拦截 402，解析支付要求，向用户确认（或按策略自动批准）
Wallet 签名并广播 Tempo 链交易，获取收据
带 X-Payment-Receipt 头重试原始请求
服务器验证收据，返回 200 OK 与数据

会话级流式支付 [↑]

大语言模型的 API 按 token 计费。如果每个 token 都触发一次链上交易，成本和延迟都不可接受。 MPP 为此设计了会话支付（Session Payments）：

建立连接时预付一笔押金（voucher）
流式 token 通过 SSE（Server-Sent Events） 实时返回
每消耗一定量 token，自动追加充值（voucher top-up）
会话结束后，未消费的余额退还

核心价值:

付你实际消费的，不多付一分。传统 API 预充值方案通常要求固定额度，MPP 会话支付实现了真正的按量计费，且全程链上可审计。

Tempo Wallet CLI ↑ top

tempo-wallet 是官方提供的命令行工具，是开发者和 Agent 与 Tempo 链交互的主要入口。它不只是一个转账工具——它内置了完整的 MPP Engine，能够代理任何 HTTP 请求并自动处理 402 挑战。

官方定义

"Command-line wallet and HTTP client for the Tempo blockchain, with built-in Machine Payments Protocol support. No API keys required."

核心命令 [↑]

# 创建新钱包
tempo wallet create

# 查看余额
tempo wallet balance

# 普通稳定币转账
tempo pay --to 0xRecipient... --amount 1.00 --token USDC --memo "服务费"

# MPP 代理 HTTP 请求（自动处理 402）
tempo http GET https://api.example.com/v1/data

# 会话支付（流式 LLM API）
tempo http POST https://llm.example.com/v1/stream \
  --session --voucher 0.50 USDC

# 批量转账（单签名）
tempo pay --batch payments.json

模拟 MPP 支付流程输入 API 地址，查看 402 处理步骤

API Endpoint

应用场景 ↑ top

AI Agent 自主消费服务 [↑]

AI Agent 在执行任务过程中，可能需要调用数十个外部 API：数据提供方、算力租用、工具调用、知识库查询。传统做法是预申请每个 API 的密钥，充值，管理额度。有了 MPP，Agent 只需持有 USDC，遇到 402 就自动付款，整个服务网络对它来说就是一张无摩擦的"按需市场"。

API 按次计费 [↑]

对于 API 提供方，支持 MPP 意味着：

不需要构建账号系统，不需要 KYC
不需要管理 API Key 发放与撤销
资金直接到账，链上可审计
天然防止 API 滥用（每次调用需付费，垃圾请求成本倍增）

Note:

MPP 的付费单位可以细化到 0.001 USDC 级别。这让"每次查询收费 $0.001"这样的商业模型第一次在技术上变得可行。

流式 Token 消费 [↑]

LLM API 通常以 token 为单位计费。MPP 会话支付让这个模型在链上落地： Agent 调用 LLM，预存 voucher，按实际消费的 token 数量结算，未消费部分原路退回。这是第一个真正意义上的"按 AI token 付款"的链上原语。

对比：Tempo vs x402 ↑ top

x402 是 Coinbase 联合 Cloudflare 推出的 HTTP 原生支付协议，与 Tempo MPP 在表面上高度相似——都利用 HTTP 402 状态码，都面向 AI Agent，都用稳定币结算。但两者在架构层面有本质差异。

Tempo MPP vs x402
维度	Tempo MPP	x402（Coinbase/Cloudflare）
协议层	HTTP 402，Tempo 链上结算	HTTP 402，多链（Base / 以太坊等）
结算链	Tempo 专属 L1，专为支付优化	多链，依赖现有链基础设施
Gas 模型	无原生 Gas Token，稳定币付费	依赖目标链的 Gas Token
会话支付	原生支持 SSE 流式 voucher	协议层未定义，需自行实现
生态背书	Stripe, Paradigm, OpenAI, Anthropic…	Coinbase, Cloudflare
开放性	专属链，部分中心化	多链开放，完全去中心化可选
适用场景	深度集成 Tempo 生态的支付场景	多链环境下的轻量级 API 收费

判断视角:

Tempo 和 x402 在方向上高度一致，竞争大于互补。关键分叉点在于"是否愿意锁定在 Tempo 专属链上"。Tempo 的生态背书更强，但 x402 对多链环境更友好。

vs 传统支付（Stripe / 预充值 API Key） [↑]

对比项	Tempo MPP	传统 API Key + 预充值
适用付款方	AI Agent（无账号，无人工介入）	人类（需注册、KYC、绑卡）
接入成本	服务端加 402 响应头即可	需接入 Stripe SDK，管理 Webhook
结算速度	≈ 400ms，链上即时结算	T+1 到 T+7，银行清算周期
最小金额	$0.001 级别	通常 $0.50+ 起，手续费吞噬小额
跨境支付	链上稳定币，无国界限制	受汇率、监管、银行网络限制
可审计性	链上全透明	依赖服务商后台

Quick Reference ↑ top

概念	一句话说明
Tempo Chain	专为稳定币支付设计的 EVM 兼容 L1，2026-03 主网上线
TIP-20	Tempo 的同质化代币标准，替代 ERC-20，手续费直接用稳定币支付
Tempo Transactions	协议层原生的批量、定时、Fee Sponsorship、Passkey 等高级交易能力
MPP	Machine Payments Protocol，将 HTTP 402 变为可执行的机器支付协议
Session Payment	SSE 流式场景下的 voucher 预付 + 按消费退款机制
Tempo Wallet	内置 MPP 的命令行钱包，`tempo http GET url` 自动处理 402
Fee Sponsorship	平台代 Agent 支付链上手续费，Agent 账户零余额也能发交易
X-Payment	402 响应头，携带价格、收款地址、代币类型，MPP 解析此头完成支付

测验 ↑ top

检验对 Tempo Wallet 核心概念的理解。

1. Tempo 链上的手续费用什么支付？

2. MPP 会话支付中，SSE 流式场景的付款方式是？

3. 下列哪个命令让 Tempo Wallet 自动处理 HTTP 402 挑战？

4. Tempo MPP 和 x402 最本质的区别在于？

Summary ↑ top

维度	Tempo 的答案
链定位	支付专用 L1，非通用区块链
Gas 模型	无原生 Gas Token，全链用稳定币
核心协议	MPP — HTTP 402 机器支付标准
适用对象	AI Agent、API 提供商、金融机构
钱包工具	CLI（`tempo`）+ 浏览器（wallet.tempo.xyz）
认证方式	Passkey（Touch ID / Face ID / 硬件密钥）
结算速度	≈ 400ms，链上即时确认
最小支付单位	$0.001 USDC 级别
与 x402 关系	竞争关系，方向一致，架构不同
主网时间	2026-03 上线，融资 $500M @$5B 估值