Tempo 钱包：账户模型、CLI 工作流与 RPC 验证

Tempo 钱包实际管理的内容

Tempo 是由 Stripe 和 Paradigm 孵化的支付优先 Layer 1 区块链，定位围绕稳定币支付、稳定币账户、代理支付和机构结算。位于 wallet.tempo.xyz 的 Tempo 钱包是该链的第一方界面：它持有 Tempo 余额、发送和接收资金、通过支持的通道接受存款、在 Zones 产品下暴露私有余额，并通过通行密钥登录集中管理账户控制。

对于开发者而言，重要的区别在于钱包作为面向用户的产品与钱包作为链上状态的账户抽象。UI 显示余额和最近活动流；在底层，每个钱包都是一个链上账户，其余额、nonce 和授权状态可以通过 Tempo RPC 端点读取。将这两层分开对待，才能使钱包行为可调试。

本文范围限于技术机制：Tempo 钱包账户如何构成、tempoctl 命令行钱包如何映射到它、私有余额与公共余额有何不同，以及如何验证 UI 报告的内容。它不是托管建议，也不断言 Tempo 自身文档所述之外的通道、地区或资产支持情况。

• 公共余额：链上可见，可通过标准账户查询读取。
• 私有余额（Zones）：根据 Tempo 的产品描述，余额和支付活动在合规控制下保持私密。
• 账户控制：在钱包产品中管理通行密钥登录和访问控制。
• CLI 界面：tempoctl 创建钱包、管理密钥，并发出自动支付的 HTTP 请求。

开始前的假设与前提条件

以下工作流假设您拥有 Tempo 账户或可以创建一个，拥有一个可用 Node.js 或 Python 的终端，并且可以访问 Tempo RPC 端点。它们还假设您理解钱包地址是公开的而其密钥材料不是，并且任何签名交易的命令都必须在您控制的环境中运行。

在诊断步骤有意义之前，您需要配置三件事：指向您信任的 Tempo 端点的 RPC_URL、保存在版本控制之外的 PRIVATE_KEY 或密钥库引用，以及链标识符，以免您的工具意外指向不同的网络。如果您尚未选择端点，端点选择本身是一个单独的决定，由 RPC Assistant 而非本页涵盖。

• 一个 Tempo RPC_URL（如果包含 API 密钥，切勿提交）。
• 一个用于写操作的有资金测试账户；只读检查不需要资金。
• 如果您打算遵循 CLI 部分，请安装 tempoctl。
• 一个带有 curl 和 jq 的 shell，或用于 JSON-RPC 示例的 Python/Node 运行时。

心智模型：钱包、密钥与账户状态

最好将 Tempo 钱包理解为三个可分离的事物。第一，密钥材料：授权操作的通行密钥或私钥。第二，账户：Tempo 上的地址，其余额和 nonce 是链上状态。第三，展示层：渲染该状态并构建交易的钱包 UI 或 CLI。

这种分离很重要，因为大多数钱包问题都是层混淆问题。UI 中看起来错误的余额可能在链上正确而在客户端中过时。一个“失败”的转账可能已被签名并广播，但因资金不足或 nonce 缺口被节点拒绝。一个看似缺失的私有余额可能只是存在于公共余额查询不覆盖的 Zones 上下文中。

实用规则：当钱包 UI 和您的工具不一致时，信任链上查询，然后协调客户端。链上查询是可复现的；UI 状态是缓存。

通过 JSON-RPC 读取钱包状态

确认 Tempo 钱包持有内容的最可靠方式是直接查询账户。下面的示例使用标准的以太坊兼容 JSON-RPC 方法，这是大多数 EVM 风格工具所期望的形式；在生产环境中依赖它们之前，请在 Tempo 自己的开发者文档中确认确切的方法集和任何 Tempo 特定扩展。

将 RPC_URL 替换为您的端点，将 WALLET_ADDRESS 替换为钱包中显示的地址。余额以最小单位返回，因此在与 UI 比较之前，请除以代币的小数位数。

curl -s RPC_URL \
  -H 'Content-Type: application/json' \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "eth_getBalance",
    "params": ["WALLET_ADDRESS", "latest"]
  }' | jq

curl -s RPC_URL \
  -H 'Content-Type: application/json' \
  -d '{
    "jsonrpc": "2.0",
    "id": 2,
    "method": "eth_getTransactionCount",
    "params": ["WALLET_ADDRESS", "pending"]
  }' | jq

Python 中的脚本化余额与 nonce 检查

对于重复检查，将相同的调用包装在一个小脚本中，以便您可以随时间比较结果。下面的脚本读取余额和 nonce，以稳定的格式打印它们，并在端点返回错误对象而不是结果时大声失败。当缺少 API 密钥或达到速率限制时，这种失败模式很常见，如果您只打印结果字段，很容易将其误认为零余额。

import json, os, urllib.request

RPC_URL = os.environ["RPC_URL"]
ADDRESS = os.environ["WALLET_ADDRESS"]

def call(method, params):
    body = json.dumps({"jsonrpc": "2.0", "id": 1, "method": method, "params": params}).encode()
    req = urllib.request.Request(RPC_URL, data=body, headers={"Content-Type": "application/json"})
    with urllib.request.urlopen(req, timeout=15) as resp:
        payload = json.load(resp)
    if "error" in payload:
        raise RuntimeError(payload["error"])
    return payload["result"]

balance = int(call("eth_getBalance", [ADDRESS, "latest"]), 16)
nonce = int(call("eth_getTransactionCount", [ADDRESS, "pending"]), 16)
print(f"address={ADDRESS} balance_wei={balance} pending_nonce={nonce}")

使用 tempoctl 进行钱包和支付工作流

Tempo 还附带一个命令行钱包 tempoctl，被描述为一个 CLI，可以创建钱包、管理密钥，并发出无需 API 密钥即可自动支付的 HTTP 请求。最后这项能力对代理和自动化来说很有趣：客户端不是将凭证嵌入脚本，而是从钱包按请求付费。

确切的子命令和标志应从 tempoctl 仓库获取，而不是假设。下面的模式说明了典型流程的形状——创建或导入钱包、检查其地址，然后发出付费请求——在您的安装语法适用的地方使用占位符。首先运行 tempoctl --help 并替换为真实的子命令。

# Illustrative flow — confirm subcommands with `tempoctl --help`
tempoctl wallet create --name agent-wallet
tempoctl wallet address --name agent-wallet

# Issue an HTTP request that pays from the wallet
tempoctl request GET https://example.com/paid-endpoint \
  --wallet agent-wallet \
  --max-spend 0.01

Tempo Zones 中的公共余额与私有余额

Tempo Zones 是隐私层：根据 Tempo 的产品信息，它们让企业保持客户稳定币余额和支付的私密性，同时保留合规控制和对流动性的访问。钱包将其作为公共余额之外的单独私有余额暴露出来。

在操作上，这意味着单个钱包可以呈现两种不同的资金视图。针对账户地址的公共余额查询不会反映 Zones 上下文中持有的私有余额，而钱包中显示的私有余额也不会出现在简单的链上读取中。对账时，始终记录数字来自哪个上下文。

合规角度并非偶然。与控件脱钩的隐私在受监管的支付中难以操作，因此任何涉及 Zones 的集成都应记录谁可以查看什么，并应在金额旁边记录上下文标识符，以便审计可以重建流程。

• 为每条余额记录标记其上下文：公共账户或 Zones。
• 不要将公共和私有余额汇总为单一数字而不加标签。
• 在设计围绕它之前，请在 Tempo 的文档中确认当前的 Zones 可用性和访问要求。

验证程序与结果表

要端到端验证钱包，请运行以下序列并记录每个结果。目的不是产生单一数字，而是确认 UI、CLI 和 RPC 端点一致，或定位它们分歧的地方。

第一步：从钱包 UI 和 tempoctl 读取地址，并确认它们匹配。第二步：通过 RPC 查询余额和 nonce，并与 UI 比较。第三步：发送一笔小额转账，并确认 nonce 恰好增加一。第四步：在交易被包含后重新查询，并确认余额变化与金额加费用匹配。第五步：如果使用了私有余额，请在 Zones 上下文中重复余额检查。

将结果记录在如下表中。在运行之前，将测量值列留空；不要复制任何文章中的数字，包括本文。

• | 检查项 | 来源 A | 来源 B | 是否匹配？ | 测量值 |
• | 地址 | 钱包 UI | tempoctl | | |
• | 公共余额 | 钱包 UI | eth_getBalance | | |
• | 待处理 nonce | 钱包 UI | eth_getTransactionCount | | |
• | 转账后变化 | 预期 | 观察 | | |
• | 私有余额 | Zones 视图 | Zones 查询 | | |

排查常见的钱包差异

大多数差异归结为少数原因。过时的 UI 缓存在确认转账后显示旧余额；刷新或重新查询即可解决。nonce 缺口使交易无限期待处理，因为先前的交易被丢弃；比较待处理和最新的 nonce 即可暴露它。端点返回错误时，如果脚本忽略错误字段，会被误读为零余额。

第四个原因是上下文混淆：当资金私下持有在 Zones 中时查询公共账户，或反之。第五个是网络混淆：将工具指向与钱包使用的不同的 Tempo 环境。只要您还记录哪个端点和哪个上下文产生了答案，这些问题都可以用相同的两个查询——余额和 nonce——来诊断。

• 过时 UI：在假设资金损失之前，通过 RPC 重新查询。
• Nonce 缺口：比较待处理和最新的交易计数。
• 静默 RPC 错误：始终检查错误字段，而不仅仅是结果。
• 上下文不匹配：确认余额是公共的还是 Zones 持有的。
• 端点不匹配：在每个结果旁边记录 RPC_URL 主机。

局限性、权衡以及本指南未涵盖的内容

本指南描述了钱包的结构和验证方法；它不证明特定的资产支持、费用水平或地区可用性，所有这些都会变化，应从 Tempo 的文档中读取。它也不对 RPC 延迟或可靠性进行基准测试。这些是可测量的，但只能针对您自己的端点和工作负载。

公共余额和私有余额之间的权衡是真实的：隐私减少了简单工具可见的状态量，这提高了对账和审计日志记录的门槛。同样，自动支付的 CLI 对代理来说很方便，但引入了手动钱包没有的支出控制要求。两者都是设计决策，而不是不加批判地接受的默认值。

最后，JSON-RPC 示例使用以太坊兼容的方法名作为工作假设。如果 Tempo 为 Zones 或支付流程暴露了额外或不同的方法，权威来源是 Tempo 的开发者文档，您的脚本应相应调整。

构建者和运营者的后续步骤

一旦您能针对自己的端点复现验证表，下一步就是将该检查纳入您的运营例行程序：在每次涉及钱包逻辑的部署后运行它，并在 UI 报告和 RPC 报告的余额之间出现分歧时发出警报。对于运行自己基础设施的团队，专用 Tempo 节点从该循环中移除了共享依赖；在确定规模之前，请参阅专用节点选项和 RPC 定价模型。

具体到端点选择，RPC Assistant 涵盖了具体的提供商和网络建议，本页有意不重复。如果您仍在决定如何构建多网络访问，多链 RPC 端点指南和更广泛的网络目录是有用的起点。

• 阅读 /en/learn/multi-chain-rpc-endpoints-guide 上的多链 RPC 端点指南。
• 在 /en/dedicated-node 比较专用节点选项。
• 在 /en/pricing/rpc 查看 RPC 定价。
• 在 /en/networks 浏览支持的网络。
• 在 /en/api-service 探索 API 服务。