Tempo Wallet: modelo de cuenta, flujos de trabajo con CLI y verificación mediante RPC

Qué gestiona realmente Tempo Wallet

Tempo es una cadena de bloques de capa 1 centrada en pagos incubada por Stripe y Paradigm, posicionada en torno a pagos con stablecoins, cuentas de stablecoins, pagos agénticos y liquidación institucional. Tempo Wallet en wallet.tempo.xyz es la interfaz de primera parte para esa cadena: mantiene saldos de Tempo, envía y recibe fondos, acepta depósitos a través de los rieles admitidos, expone saldos privados bajo el producto Zones y centraliza los controles de cuenta con inicio de sesión mediante passkey.

Para un desarrollador, la distinción importante es entre la billetera como producto de cara al usuario y la billetera como abstracción de cuenta sobre el estado de la cadena. La interfaz muestra un saldo y un feed de actividad reciente; en el fondo, cada billetera es una cuenta en cadena cuyo saldo, nonce y estado de autorización se pueden leer a través de un endpoint RPC de Tempo. Tratar esas dos capas por separado es lo que hace que el comportamiento de la billetera sea depurable.

Este artículo se limita a la mecánica técnica: cómo se estructura una cuenta de Tempo Wallet, cómo la billetera de línea de comandos tempoctl se asigna a ella, en qué se diferencian los saldos privados de los públicos y cómo verificar lo que informa la interfaz. No es una recomendación de custodia y no afirma qué rieles, regiones o activos son compatibles más allá de lo que indica la propia documentación de Tempo.

• Saldo público: visible en cadena y legible mediante consultas de cuenta estándar.
• Saldo privado (Zones): saldos y actividad de pago mantenidos en privado con controles de cumplimiento, según la descripción del producto de Tempo.
• Controles de cuenta: inicio de sesión con passkey y controles de acceso gestionados en el producto de billetera.
• Superficie de CLI: tempoctl crea billeteras, gestiona claves y emite solicitudes HTTP que pagan automáticamente.

Suposiciones y requisitos previos antes de comenzar

Los flujos de trabajo a continuación suponen que tiene una cuenta de Tempo o puede crear una, una terminal con Node.js o Python disponible y acceso a un endpoint RPC de Tempo. También suponen que comprende que una dirección de billetera es pública mientras que su material de clave no lo es, y que cualquier comando que firme una transacción debe ejecutarse en un entorno que usted controle.

Necesita tres cosas configuradas antes de que los pasos de diagnóstico tengan sentido: un RPC_URL que apunte a un endpoint de Tempo en el que confíe, una referencia PRIVATE_KEY o de keystore mantenida fuera del control de versiones, y un identificador de cadena para que sus herramientas no apunten accidentalmente a una red diferente. Si aún no ha elegido un endpoint, la selección del endpoint en sí es una decisión separada cubierta por el Asistente RPC en lugar de esta página.

• Un RPC_URL de Tempo (nunca lo confirme si contiene una clave de API).
• Una cuenta de prueba con fondos para operaciones de escritura; las comprobaciones de solo lectura no necesitan fondos.
• tempoctl instalado si pretende seguir las secciones de CLI.
• Un shell con curl y jq, o un entorno de ejecución de Python/Node para los ejemplos de JSON-RPC.

Modelo mental: billetera, clave y estado de cuenta

Una billetera Tempo se entiende mejor como tres cosas separables. Primero, el material de clave: la passkey o clave privada que autoriza acciones. Segundo, la cuenta: una dirección en Tempo cuyo saldo y nonce son estado de la cadena. Tercero, la capa de presentación: la interfaz de la billetera o la CLI que representa ese estado y construye transacciones.

Esta separación importa porque la mayoría de los problemas de billetera son problemas de confusión de capas. Un saldo que parece incorrecto en la interfaz puede ser correcto en cadena y estar desactualizado en el cliente. Una transferencia que "falló" puede haber sido firmada y transmitida pero rechazada por el nodo por fondos insuficientes o un hueco de nonce. Un saldo privado que parece faltar puede simplemente residir en un contexto de Zones que la consulta de saldo público no cubre.

La regla práctica: cuando la interfaz de la billetera y sus herramientas no coinciden, confíe en la consulta de la cadena y luego reconcilie el cliente. La consulta de la cadena es reproducible; el estado de la interfaz es una caché.

Lectura del estado de la billetera mediante JSON-RPC

La forma más fiable de confirmar qué tiene una billetera Tempo es consultar la cuenta directamente. El ejemplo siguiente utiliza métodos JSON-RPC estándar compatibles con Ethereum, que es la forma que esperan la mayoría de las herramientas de estilo EVM; confirme el conjunto exacto de métodos y cualquier extensión específica de Tempo en la documentación para desarrolladores de Tempo antes de confiar en ellos en producción.

Reemplace RPC_URL con su endpoint y WALLET_ADDRESS con la dirección que se muestra en la billetera. El saldo se devuelve en la unidad más pequeña, así que divídalo por los decimales del token antes de compararlo con la interfaz.

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

Comprobaciones de saldo y nonce con script en Python

Para comprobaciones repetidas, envuelva las mismas llamadas en un pequeño script para poder comparar resultados a lo largo del tiempo. El script siguiente lee el saldo y el nonce, los imprime en un formato estable y falla de forma ruidosa si el endpoint devuelve un objeto de error en lugar de un resultado. Ese modo de fallo es común cuando falta una clave de API o se alcanza un límite de velocidad, y es fácil confundirlo con un saldo cero si solo imprime el campo de resultado.

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}")

Uso de tempoctl para flujos de trabajo de billetera y pagos

Tempo también incluye una billetera de línea de comandos, tempoctl, descrita como una CLI que crea una billetera, gestiona claves y realiza solicitudes HTTP que pagan automáticamente sin claves de API. Esa última capacidad es la interesante para agentes y automatización: en lugar de incrustar una credencial en un script, el cliente paga por solicitud desde la billetera.

Los subcomandos y flags exactos deben tomarse del repositorio de tempoctl en lugar de asumirse. El patrón siguiente ilustra la forma de un flujo típico —crear o importar una billetera, inspeccionar su dirección y luego emitir una solicitud de pago— con marcadores de posición donde se aplica la sintaxis de su instalación. Ejecute primero tempoctl --help y sustituya los subcomandos reales.

# 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

Saldos públicos frente a privados en Tempo Zones

Tempo Zones es la capa de privacidad: según la comunicación del producto de Tempo, permiten a las empresas mantener los saldos de stablecoins y los pagos de los clientes en privado mientras conservan controles de cumplimiento y acceso a liquidez. La billetera expone esto como un saldo privado separado junto al público.

Operativamente, esto significa que una sola billetera puede presentar dos vistas diferentes de los fondos. Una consulta de saldo público contra la dirección de la cuenta no reflejará los saldos privados mantenidos en un contexto de Zones, y un saldo privado mostrado en la billetera no aparecerá en una lectura ingenua en cadena. Al conciliar, registre siempre de qué contexto proviene un número.

El ángulo de cumplimiento no es incidental. La privacidad desacoplada de los controles es difícil de operar en pagos regulados, por lo que cualquier integración que toque Zones debe documentar quién puede ver qué, y debe registrar identificadores de contexto junto con los importes para que las auditorías puedan reconstruir el flujo.

• Etiquete cada registro de saldo con su contexto: cuenta pública o Zones.
• No sume saldos públicos y privados en una sola cifra sin etiquetarla.
• Confirme la disponibilidad actual de Zones y los requisitos de acceso en la documentación de Tempo antes de diseñar en torno a ello.

Procedimiento de verificación y tabla de resultados

Para verificar una billetera de extremo a extremo, ejecute la siguiente secuencia y registre cada resultado. El objetivo no es producir un único número sino confirmar que la interfaz, la CLI y el endpoint RPC coinciden, o localizar dónde divergen.

Paso uno: lea la dirección desde la interfaz de la billetera y desde tempoctl, y confirme que coinciden. Paso dos: consulte el saldo y el nonce por RPC y compárelos con la interfaz. Paso tres: envíe una transferencia pequeña y confirme que el nonce se incrementa exactamente en uno. Paso cuatro: vuelva a consultar después de que se incluya la transacción y confirme que el delta del saldo coincide con el importe más las comisiones. Paso cinco: si se utilizan saldos privados, repita la comprobación de saldo dentro del contexto de Zones.

Registre los resultados en una tabla como la siguiente. Deje la columna de medición vacía hasta que la ejecute; no copie cifras de ningún artículo, incluido este.

• | Comprobación | Fuente A | Fuente B | ¿Coincide? | Valor medido |
• | Dirección | Interfaz de billetera | tempoctl | | |
• | Saldo público | Interfaz de billetera | eth_getBalance | | |
• | Nonce pendiente | Interfaz de billetera | eth_getTransactionCount | | |
• | Delta posterior a la transferencia | Esperado | Observado | | |
• | Saldo privado | Vista de Zones | Consulta de Zones | | |

Solución de discrepancias comunes en la billetera

La mayoría de las discrepancias se deben a un pequeño conjunto de causas. Una caché de interfaz desactualizada muestra un saldo antiguo después de una transferencia confirmada; refrescar o volver a consultar lo resuelve. Un hueco de nonce deja una transacción pendiente indefinidamente porque una transacción anterior se descartó; comparar los nonces pendiente y más reciente lo expone. Un endpoint que devuelve errores se malinterpreta como saldo cero cuando el script ignora el campo de error.

Una cuarta causa es la confusión de contexto: consultar la cuenta pública cuando los fondos se mantienen de forma privada en Zones, o al revés. Una quinta es la confusión de red: apuntar las herramientas a un entorno de Tempo diferente al que usa la billetera. Cada una de estas es diagnosticable con las mismas dos consultas —saldo y nonce— siempre que también registre qué endpoint y qué contexto produjeron la respuesta.

• Interfaz desactualizada: vuelva a consultar por RPC antes de asumir pérdida de fondos.
• Hueco de nonce: compare los recuentos de transacciones pendientes y más recientes.
• Errores RPC silenciosos: compruebe siempre el campo de error, no solo el resultado.
• Desajuste de contexto: confirme si el saldo es público o está en Zones.
• Desajuste de endpoint: registre el host del RPC_URL junto a cada resultado.

Limitaciones, compensaciones y lo que esta guía no cubre

Esta guía describe la estructura de la billetera y una metodología de verificación; no certifica la compatibilidad de activos específicos, los niveles de comisiones ni la disponibilidad regional, todos los cuales cambian y deben leerse en la documentación de Tempo. Tampoco evalúa la latencia o fiabilidad del RPC. Esos son medibles, pero solo contra su propio endpoint y carga de trabajo.

La compensación entre saldos públicos y privados es real: la privacidad reduce la cantidad de estado visible para las herramientas ingenuas, lo que eleva el listón para la conciliación y el registro de auditoría. De manera similar, una CLI que paga automáticamente es conveniente para los agentes pero introduce requisitos de control de gasto que una billetera manual no tiene. Ambas son decisiones de diseño, no valores predeterminados que deban aceptarse acríticamente.

Por último, los ejemplos de JSON-RPC utilizan nombres de métodos compatibles con Ethereum como suposición de trabajo. Si Tempo expone métodos adicionales o diferentes para Zones o flujos de pago, la fuente autorizada es la documentación para desarrolladores de Tempo, y sus scripts deben ajustarse en consecuencia.

Próximos pasos para desarrolladores y operadores

Una vez que pueda reproducir la tabla de verificación contra su propio endpoint, el siguiente paso es convertir esa comprobación en parte de su rutina operativa: ejecútela después de cada despliegue que toque la lógica de la billetera y alerte sobre divergencias entre el saldo informado por la interfaz y el informado por RPC. Para los equipos que ejecutan su propia infraestructura, un nodo dedicado de Tempo elimina una dependencia compartida de ese bucle; consulte las opciones de nodo dedicado y el modelo de precios de RPC antes de dimensionar.

Para la selección de endpoints específicamente, el Asistente RPC cubre recomendaciones concretas de proveedores y redes, que esta página deliberadamente no duplica. Si aún está decidiendo cómo estructurar el acceso a múltiples redes, la guía de endpoints RPC multicadena y el directorio más amplio de redes son puntos de partida útiles.

• Lea la guía de endpoints RPC multicadena en /en/learn/multi-chain-rpc-endpoints-guide.
• Compare las opciones de nodo dedicado en /en/dedicated-node.
• Revise los precios de RPC en /en/pricing/rpc.
• Explore las redes compatibles en /en/networks.
• Descubra el servicio de API en /en/api-service.