Una explicación detallada de la cadena Tempo y el protocolo de pago de máquinas MPP

I. Cinco necesidades de pago de la economía de agentes de IA

El sistema global de pagos está atravesando una reconfiguración estructural. El crecimiento explosivo del tamaño del mercado de las stablecoins y el surgimiento de la economía de agentes de IA, conjuntamente, están impulsando una necesidad urgente de una infraestructura de pagos de la próxima generación.

Los pagos de los Agentes de IA (Autonomous AI Agents) al ejecutar tareas de forma autónoma presentan una diferencia esencial frente a los pagos tradicionales de los humanos. Las siguientes cinco necesidades centrales constituyen los requisitos básicos de la infraestructura de pagos para la economía de agentes de IA:

Las redes de pago swift tradicionales y las blockchains genéricas no pueden satisfacer por completo las necesidades de pago anteriores en la economía de agentes de IA; por ello, surge Tempo.

II. Tempo: una blockchain para construir en la era de la IA

Como una blockchain nativa de pagos lanzada por Commonware, Tempo logra finalidad de nivel sub-segundo mediante un consenso de canal en pipeline Simplex BFT, garantiza la prioridad de pagos con un espacio de bloques dedicado y un mecanismo de Gas nativo con stablecoins, y proporciona capacidades de pago de extremo a extremo sin intervención humana a los agentes inteligentes de IA mediante el protocolo MPP.

III. Arquitectura técnica de la blockchain Tempo

3.1 Panorama general de la arquitectura

Tempo utiliza una arquitectura de tipo Layer-1 dedicada; su filosofía de diseño es “pago primero”: cada decisión técnica de cada capa en la cadena tiene como objetivo optimizar los escenarios de pagos, en lugar de un diseño de propósito general para plataformas de contratos inteligentes.

3.2 Consenso en pipeline Simplex BFT

La capa de consenso de Tempo se basa en el protocolo Simplex BFT (ePrint 2023/463). Este protocolo, mediante un diseño en pipeline, hace que la latencia de confirmación de cada ronda converja a un único tiempo de ida y vuelta de la red (1Δ).

Flujo de consenso en tres fases

El consenso de una sola ronda de Simplex BFT está compuesto por tres fases secuenciales:

Comparación temporal: BFT tradicional vs Simplex en pipeline

La siguiente figura muestra la diferencia de latencia entre el BFT tradicional de tres fases y el pipeline de Simplex. El eje vertical representa las rondas de consenso y el eje horizontal representa el paso de tiempo de la red (Δ).

Clave para la mejora de desempeño: en modo pipeline, el Propose de B₂ se superpone con la fase Vote de B₁. Cada ronda solo necesita esperar 1Δ para pasar a la propuesta del siguiente bloque, mientras que el BFT tradicional necesita esperar en serie y de forma completa 3Δ por ronda.

Optimización del cambio de vista (View-Change)

El cambio de vista (View-Change) se activa en dos casos: (1) el líder actual (Leader) no logra difundir una propuesta válida dentro del tiempo de espera estipulado; (2) el nodo detecta un comportamiento anómalo del líder (por ejemplo, propuestas duplicadas o formato de mensaje inválido).

3.3 Firmas agregadas BLS

Se adopta el esquema BLS (Boneh-Lynn-Shacham) para agregar las firmas de N validadores en una única firma; solo se requieren dos operaciones de emparejamiento en curvas elípticas para verificarla, lo que reduce significativamente el ancho de banda y la carga computacional. Esto es especialmente importante para escenarios de micropagos de alta frecuencia, ya que puede reducir de manera efectiva el costo de cómputo y ancho de banda por cada transacción.

Principio de las firmas BLS

Visualización del flujo de firmas agregadas

3.4 Mecanismo de ejecución paralela de transacciones

La capacidad de ejecución paralela de Tempo proviene de dos diseños técnicos oficiales documentados de forma explícita:

1. Tipos de transacciones personalizadas EIP-2718 (Transaction Type 0x76)

El formato Crypto-Native Transaction definido por Tempo amplía tres capacidades nativas sobre las transacciones EVM estándar:

• Ejecución por lotes (Batch): ejecución atómica de múltiples instrucciones dentro de una sola transacción
• Ejecución programada (Scheduled): especifica que se dispare la ejecución en un bloque futuro
• Ejecución en paralelo (Parallel): declara dependencias sin estado, permitiendo procesar en concurrencia con otras transacciones

2. Sistema de Nonce con caducidad (Expiring Nonce System)

El nonce estrictamente incremental del EVM tradicional obliga a que todas las transacciones de la misma cuenta se ejecuten en serie. Tempo cambia el nonce a un “rango de bloques efectivo”: solo exige que el nonce sea único dentro de su vigencia. Varias transacciones independientes de la misma cuenta pueden enviarse simultáneamente y ejecutarse en paralelo, eliminando el cuello de botella de serialización a nivel de cuenta.

3. Canales de pago dedicados (Payment Lanes)

ayment Lanes es el espacio de bloques reservado de manera específica por Tempo a nivel de protocolo para las transacciones de pago de TIP-20. A diferencia de Ethereum, que hace que todas las transacciones compitan por el mismo pool de gas, Tempo divide el presupuesto de gas del bloque en múltiples canales independientes, de modo que las transacciones de pago no se vean interferidas por el “vecino ruidoso” de operaciones DeFi, acuñación de NFTs o llamadas frecuentes a contratos de alta frecuencia.

Estructura de partición del gas del bloque

El encabezado del bloque de Tempo incluye campos de límite de gas independientes, dividiendo el presupuesto total de 500M gas en tres zonas que no interfieren entre sí:

3.5 Diseño nativo de stablecoins

Tempo trata las stablecoins como ciudadanos de primera clase del protocolo. Desde el costo de Gas, el intercambio on-chain y hasta el estándar de Token, toda la cadena se rediseña con las stablecoins como núcleo

IV. Machine Payments Protocol (MPP)

4.1 Posicionamiento del protocolo e idea central

MPP (Machine Payments Protocol, protocolo de pagos para máquinas) es un estándar abierto de pagos diseñado conjuntamente por Stripe y Tempo. En la industria se le conoce como el “OAuth de la industria de pagos”. Su objetivo central es proporcionar a agentes autónomos de IA una capacidad estandarizada de pagos, sin necesidad de intervención humana.

4.2 Flujo completo de interacción del MPP

Estructura de carga JWT

4.3 Mecanismo de sesiones (Session)

El mecanismo de Session es una de las innovaciones centrales del protocolo MPP; resuelve el problema de la eficiencia de pago cuando los agentes de IA consumen recursos durante largos periodos de tiempo en forma continua:

Este diseño permite que, durante la ejecución de tareas de larga duración, no sea necesario activar confirmaciones en cadena en cada interacción, lo que mejora de forma significativa la eficiencia del pago.

4.4 Enrutamiento de pagos entre Rails

El diseño central de MPP consiste en desacoplar por completo el protocolo de las vías de pago. La capa central solo define el flujo de desafío-respuesta HTTP, el manejo de errores y el modelo de seguridad, sin vincularlo a ninguna red de pago específica. Por tanto, al añadir un nuevo método de pago, solo es necesario registrar un identificador de método y publicar el esquema (Schema) y la lógica de verificación correspondiente; no es necesario modificar el propio protocolo. Al realizar el pago, el agente no necesita preocuparse por la vía subyacente: el servidor declara los métodos aceptables en la respuesta 402, y el cliente luego hace la coincidencia según sea necesario. Esta es precisamente la clave por la cual MPP se diferencia de una solución de una sola cadena o de una sola red.

Vías de pago actuales admitidas por MPP

V. Análisis de casos de uso

Caso 1: Pagos empresariales transfronterizos

Los pagos transfronterizos tradicionales normalmente requieren pasar por múltiples etapas como bancos emisores, la red de mensajes SWIFT, bancos corresponsales y bancos receptores; por lo general, requieren de 3 a 5 días laborables, las comisiones suelen estar entre 0.5% y 3%, y no admiten el procesamiento en tiempo real durante fines de semana y días festivos.

En cambio, Tempo intenta ofrecer otra ruta: si tanto el pagador como el receptor utilizan stablecoins para la liquidación, según el objetivo del diseño de la red de pruebas actual, un pago transfronterizo de USDC a USDC teóricamente puede completarse en aproximadamente 0.5 segundos, con una comisión por transacción de alrededor de 0.001 dólares.

Caso 2: Compensación 7×24 de depósitos tokenizados

Los depósitos tokenizados son activos financieros en los que los derechos de acreencia por depósitos bancarios se digitalizan sobre blockchain. Estos activos en sí tienen un obstáculo del mundo real: el Fedwire de la Reserva Federal tiene horarios fijos de operación y no puede procesar la compensación en días no laborables o durante la noche.

Pero las blockchains pueden soportar de forma natural funcionamiento 7×24, todo el año, sin descanso; además, el módulo de intercambio integrado de Tempo puede soportar conversiones a nivel de protocolo entre distintos depósitos tokenizados, lo que hará posible la compensación de todo el día.

Caso 3: Pagos automatizados de micropagos de alta frecuencia

Las tarifas de procesamiento con tarjeta de crédito normalmente incluyen una tarifa fija de aproximadamente 0.2 dólares por transacción más una tarifa proporcional del 1.5% al 3%, de modo que las transacciones con montos inferiores a 1 dólar no son viables comercialmente; esta es la razón fundamental por la que existe un vacío a largo plazo en el mercado de “pagos pequeños”. El objetivo de diseño de Tempo de alrededor de 0.001 dólares por transacción hace que, por primera vez, los siguientes escenarios sean comercialmente viables:

Caso 4: Pagos autónomos para agentes de IA

A medida que más agentes de IA se utilizan para ejecutar tareas empresariales complejas (reservar recursos, comprar suministros, llamar servicios externos), estos agentes generan necesidades reales de pago. La arquitectura compatible con EVM de Tempo y las interfaces de pago dedicadas permiten que los agentes disparen pagos de forma autónoma mediante contratos inteligentes, sin necesidad de aprobaciones manuales de cada transacción.

VI. Análisis del panorama competitivo

En 2025–2026, el segmento de cadenas dedicadas de pagos está entrando en una fase de incorporación masiva. Este capítulo realiza una comparación horizontal de tres tipos de competidores desde una perspectiva de arquitectura técnica.

6.1 Cadena dedicada de pagos: Tempo vs Circle Arc vs Stable

Las tres cadenas son L1 dedicadas a pagos, pero las diferencias en sus rutas técnicas subyacentes son notables. A continuación, se descomponen sus elecciones técnicas desde tres dimensiones: motor de consenso, mecanismo de comisiones y principales innovaciones de arquitectura.

Matriz de posicionamiento competitivo

Las tres cadenas convergen mucho en sus indicadores de desempeño; la división real está en las características del cliente objetivo, la estrategia de vinculación a stablecoins, las apuestas centrales y los riesgos conocidos.

6.2 Comparación con blockchains genéricas: Ethereum L2 y Solana

Ethereum L2 y Solana son dos tipos de cadenas genéricas que actualmente se usan ampliamente en escenarios de pagos; la brecha con las cadenas dedicadas a pagos se refleja en las siguientes dimensiones:

VII. Conclusión

La propuesta de valor de las cadenas dedicadas a pagos nunca consiste en si son “más rápidas” que Ethereum o “más baratas” que Solana; consiste en si pueden convertir el significado de los pagos en restricciones de diseño del propio protocolo.

La conclusión central de Tempo y MPP es: cuando las blockchains genéricas procesan escenarios de pagos, el problema no es una falta de funcionalidad; es un error de nivel de abstracción. Tratan la “transferencia de activos” como si fuera todo lo que constituye un pago, pero pasan por alto la autorización, las sesiones, el enrutamiento y la conciliación, que ya han sido profundamente ingenierizadas en las finanzas tradicionales.

La economía de agentes de IA inyecta una nueva urgencia temporal en este sector. Cuando los agentes de software comienzan a sustituir a los humanos para completar comportamientos económicos como compras, suscripciones y llamadas a servicios, el modelo de autorización de los sistemas de pagos tradicionales —basado en la verificación de identidad de las entidades humanas y la confirmación manual— se enfrentará a una desalineación estructural sistémica. Lo que el protocolo MPP intenta resolver es precisamente este problema de “soberanía del agente”: quién tiene el derecho de iniciar pagos, dentro de qué alcance, durante cuánto tiempo de forma continua y cómo se puede revocar. Esta lógica es altamente homóloga a la que OAuth resuelve para la autorización de APIs.

Pero es necesario señalar que el despliegue a gran escala de pagos autónomos por agentes de IA se basa en que la situación legal de la identidad del agente, la asignación de responsabilidades y las rutas de cumplimiento contra el lavado de dinero estén claramente definidas. El desafío que enfrenta Tempo es estructural, no solo de ejecución. Primero, la incertidumbre regulatoria sigue siendo una variable central: el diseño nativo de stablecoins significa que Tempo debe dialogar directamente con los organismos reguladores de monedas de cada jurisdicción, en lugar de esconderse detrás de la narrativa de “infraestructura neutral”. Segundo, la tensión de la compatibilidad con EVM aún no se ha resuelto: abandonar EVM permitiría un espacio de diseño más limpio, pero también implica renunciar a la inercia de desarrolladores y al soporte de la cadena de herramientas que se han acumulado durante años en el ecosistema de Ethereum. Tercero, la colaboración con Stripe brinda al protocolo MPP un respaldo comercial poco común, pero esta fuerte dependencia también es una fuente de fragilidad: existe una tensión endógena entre la apertura del protocolo y los límites de intereses de los socios comerciales, que requiere observación a largo plazo.

Para los profesionales de la industria, lo más digno de investigar sobre Tempo/MPP quizá no sea si finalmente puede convertirse en el “ganador de la blockchain de pagos”; sino el propio problema que plantea: después de que la infraestructura de pagos on-chain entra en la era de la especialización profesional, ¿cómo debería evaluarse realmente la competitividad del diseño del protocolo? Más allá de los benchmarks de desempeño, la precisión con la que se expresa el significado de los pagos, la capacidad de cumplimiento como módulo intercambiable y el modelo de autorización de agentes, quizás sean la división real de la próxima generación de infraestructura de pagos.

Referencias

1. Tempo Sitio Web Oficial:
2. Blog de Lanzamiento de Tempo Mainnet: /blog/mainnet/
3. Especificación Técnica del Protocolo MPP:
4. Fortune: Stripe-backed Tempo releases AI payments protocol (2026.03.18)
5. The Block: Tempo Mainnet goes live with Machine Payments Protocol for agents
6. Privy Blog: Building on Privy with Tempo’s Machine Payments Protocol (MPP)
7. Medium (jrodthoughts): The Architecture of Autonomous Wealth — Inside Tempo’s MPP
8. McKinsey & Artemis Analytics: 2025 Stablecoins in Payments Report
9. CoinGecko Stablecoins Market Data
10. DeFiLlama On-chain Stablecoins Data