Um guia completo sobre a cadeia Tempo e o protocolo de pagamento de máquinas MPP

1. Requisitos de pagamento em cinco pontos da economia de agentes de IA

O sistema de pagamentos global está a passar por uma reestruturação estrutural. O crescimento explosivo da escala das stablecoins e o surgimento da economia de agentes de IA criaram, em conjunto, uma necessidade urgente de infraestruturas de pagamentos da próxima geração.

Os pagamentos dos Agentes de IA (Autonomous AI Agents) apresentam diferenças fundamentais em relação aos pagamentos tradicionais efetuados por seres humanos quando executam tarefas de forma autónoma. Os cinco requisitos principais a seguir constituem as exigências base da economia de agentes de IA para a infraestrutura de pagamentos:

As redes de pagamento swift tradicionais e as blockchains genéricas dificilmente conseguem satisfazer plenamente os requisitos de pagamento acima na economia de agentes de IA; assim, a Tempo surgiu.

2. Tempo: uma blockchain construída para a era da IA

Como uma blockchain de pagamentos nativa lançada pela Commonware, a Tempo alcança finalização a nível de subsegundos com consenso em pipeline Simplex BFT. Garante a prioridade dos pagamentos com um espaço de blocos dedicado e um mecanismo nativo de Gas de stablecoins, e fornece aos agentes de IA capacidades de pagamento ponta-a-ponta sem intervenção humana através do protocolo MPP.

3. Arquitetura técnica da blockchain Tempo

3.1 Visão geral da arquitetura

A Tempo adota uma arquitetura Layer-1 do tipo dedicado. A sua filosofia de design é “pagamento em primeiro lugar” — cada decisão técnica em cada camada da cadeia tem como objetivo otimizar cenários de pagamentos, e não a generalidade de plataformas de contratos inteligentes.

3.2 Consenso em pipeline Simplex BFT

A camada de consenso da Tempo baseia-se no protocolo Simplex BFT (ePrint 2023/463). Este protocolo, através de uma conceção em pipeline, faz com que a latência de confirmação em cada ronda convirja para o tempo de uma única ida e volta na rede (1Δ).

Processo de consenso em três fases

O consenso de uma única ronda do Simplex BFT é composto por três fases sequenciais:

Comparação de temporização: BFT tradicional vs Simplex em pipeline

A figura abaixo mostra a diferença de latência entre o BFT tradicional em três fases e o Simplex em pipeline. O eixo vertical representa as rondas de consenso; o eixo horizontal representa o passo temporal da rede (Δ).

Fator-chave de melhoria de desempenho: No modo em pipeline, a fase Propose de B₂ sobrepõe-se à fase Vote de B₁. Em cada ronda, basta esperar 1Δ para entrar na proposta do bloco seguinte; ao passo que o BFT tradicional requer, em cada ronda, uma espera serial completa de 3Δ.

Otimização de mudança de vista (View-Change)

A mudança de vista (View-Change) é acionada em duas situações: (1) o líder atual (Leader) não consegue difundir uma proposta válida dentro do tempo limite definido; (2) o nó deteta comportamento anómalo do líder (por exemplo, propostas duplicadas ou formato de mensagens inválido).

3.3 Assinaturas agregadas BLS

A solução BLS (Boneh-Lynn-Shacham) agrega as assinaturas de N validadores numa única assinatura; basta verificar com apenas duas operações de emparelhamento em curvas elípticas, reduzindo significativamente a largura de banda e o custo computacional. Isto é especialmente importante em cenários de micro-pagamentos frequentes, permitindo reduzir eficazmente os custos de computação e de largura de banda por transação.

Princípio das assinaturas BLS

Visualização do processo de assinatura agregada

3.4 Mecanismo de execução paralela de transações

A capacidade de execução paralela de transações da Tempo provém de duas conceções técnicas oficiais que se encontram claramente registadas:

1. Tipo de transação personalizado EIP-2718 (Transaction Type 0x76)

O formato Crypto-Native Transaction definido pela Tempo, sobre o EVM transacional padrão, expande três capacidades nativas:

• Execução em lote (Batch): execução atomizada de múltiplas instruções dentro de uma única transação
• Execução agendada (Scheduled): especificar execução acionada em blocos futuros
• Execução paralela (Parallel): declarar dependências sem estado, permitindo processamento concorrente com outras transações

2. Sistema de Nonce com expiração (Expiring Nonce System)

O EVM tradicional impõe execução serial para todas as transações da mesma conta com Nonce estritamente crescente. A Tempo transforma o Nonce numa “janela de intervalo de blocos efetiva”, exigindo apenas que o Nonce seja único dentro do período de validade; várias transações independentes da mesma conta podem ser submetidas em simultâneo e executadas em paralelo, eliminando o gargalo de serialização ao nível da conta.

3. Canais de pagamento dedicados (Payment Lanes)

ayment Lanes é o “espaço de blocos” reservado pela Tempo ao nível do protocolo para transações de pagamento dedicadas para TIP-20. Em vez de a Ethereum fazer com que todas as transações concorram pelo mesmo pool de gas, a Tempo divide o orçamento de gas do bloco em múltiplos canais independentes, de modo a que as transações de pagamento não sejam interferidas pelos “vizinhos barulhentos” de operações DeFi, cunhagem de NFTs ou chamadas de contratos frequentes.

Estrutura de segmentação de gas por bloco

O cabeçalho do bloco da Tempo inclui campos de limite de gas independentes, dividindo o orçamento total de 500M gas em três regiões que não interferem entre si:

3.5 Design nativo de stablecoins

A Tempo trata as stablecoins como um cidadão de primeira classe no protocolo. Do pagamento de Gas, à troca on-chain até ao padrão Token, toda a cadeia é redesenhada com as stablecoins no centro

4. Machine Payments Protocol (MPP)

4.1 Posicionamento do protocolo e ideia central

MPP (Machine Payments Protocol, Protocolo de Pagamentos para Máquinas) é um padrão aberto de pagamentos concebido em conjunto pela Stripe e pela Tempo. É descrito na indústria como o “OAuth do setor dos pagamentos”. O seu objetivo central é fornecer capacidade de pagamentos padronizada e sem intervenção manual para agentes de IA autónomos.

4.2 Fluxo completo de interação do MPP

Estrutura do payload JWT

4.3 Mecanismo de sessões (Session)

O mecanismo de Session é uma das principais inovações do protocolo MPP, resolvendo o problema de eficiência de pagamento quando agentes de IA consomem recursos de forma contínua durante muito tempo:

Este desenho significa que, durante a execução de tarefas longas, não é necessário acionar confirmações on-chain em cada interação, melhorando significativamente a eficiência dos pagamentos.

4.4 Roteamento de pagamentos entre Rail

O design central do MPP consiste em desacoplar completamente o protocolo das “faixas” de pagamento (payment rails). A camada central define apenas o fluxo de desafio-resposta HTTP, o tratamento de erros e o modelo de segurança, sem se associar a qualquer rede de pagamento específica. Assim, para adicionar um novo método de pagamento, basta registar um identificador de método e publicar o Schema e a lógica de validação correspondentes, sem necessidade de alterar o próprio protocolo. No momento do pagamento, o agente não precisa de se preocupar com a camada de base; o servidor declara, na resposta 402, as opções aceites e o cliente faz a correspondência conforme necessário. Esta é exatamente a chave que distingue o MPP de uma solução de uma única cadeia ou de uma única rede.

Payment rails atualmente suportadas pelo MPP

5. Análise de cenários de aplicação

Cenário 1: Pagamentos empresariais transfronteiriços

Os pagamentos transfronteiriços tradicionais normalmente precisam de passar por vários intervenientes, como o banco pagador, a rede de mensagens SWIFT, bancos intermediários e bancos recebedores. Em geral, demoram 3 a 5 dias úteis; as comissões costumam situar-se entre 0,5% e 3%, e não suportam processamento em tempo real durante fins de semana e feriados.

Em comparação, a Tempo tenta proporcionar outra via: se ambas as partes, pagadora e recebedora, utilizarem stablecoins para liquidação, de acordo com o objetivo desenhado para a rede de testes atual, um pagamento transfronteiriço de USDC para USDC poderá, em teoria, ser concluído em cerca de 0,5 segundos, com uma comissão por transação de aproximadamente 0,001 dólares.

Cenário 2: Compensação 7×24 de depósitos tokenizados

Depósitos tokenizados são ativos financeiros em que créditos de depósitos bancários são digitalizados numa blockchain. Estes ativos, por si, têm um obstáculo do mundo real: o Fedwire da Reserva Federal tem horários fixos de funcionamento e não consegue processar a compensação em dias sem expediente ou durante a noite.

Mas a blockchain pode, naturalmente, suportar operação 7×24, todos os dias do ano. Além disso, o módulo embutido de troca da Tempo também consegue suportar conversão ao nível do protocolo entre diferentes depósitos tokenizados, tornando possível a compensação contínua.

Cenário 3: Pagamentos automatizados de pequeno montante em alta frequência

A taxa de processamento de cartões de crédito normalmente inclui uma taxa fixa de cerca de 0,2 dólares por transação, mais uma taxa percentual de 1,5% a 3%. Assim, transações com montantes inferiores a 1 dólar tornam-se inviáveis do ponto de vista comercial — esta é a razão fundamental pela qual existe uma lacuna de longa data no mercado de “pagamentos de pequena dimensão”. O objetivo de design de comissões de cerca de 0,001 dólares por transação da Tempo torna os seguintes cenários, pela primeira vez, comercialmente viáveis:

Cenário 4: Pagamentos autónomos de agentes de IA

À medida que agentes de IA são cada vez mais utilizados para executar tarefas comerciais complexas (reservar recursos, adquirir bens, chamar serviços externos), estes agentes geram necessidades reais de pagamento. A arquitetura compatível com EVM da Tempo e as interfaces de pagamento dedicadas permitem que os agentes acionem pagamentos autonomamente via contratos inteligentes, sem necessidade de aprovação manual de cada transação.

6. Análise do panorama competitivo

Em 2025–2026, a via das cadeias dedicadas a pagamentos entrou num período de afluência intensiva de novos participantes. Este capítulo compara horizontalmente três tipos de concorrentes a partir da perspetiva da arquitetura técnica.

6.1 Cadeia dedicada a pagamentos: Tempo vs Circle Arc vs Stable

As três cadeias são cadeias L1 dedicadas a pagamentos, mas as diferenças nas escolhas de rota tecnológica na base são significativas. A seguir, decomponho as opções técnicas de cada uma nos três aspetos: motor de consenso, mecanismo de taxas e inovações-chave de arquitetura.

Matriz de posicionamento competitivo

As três cadeias convergem muito em indicadores de desempenho; a verdadeira diferença está em clientes-alvo, estratégia de vinculação a stablecoins, aposta central e riscos conhecidos.

6.2 Comparação com blockchains genéricas: Ethereum L2 e Solana

O Ethereum L2 e o Solana são atualmente dois tipos de cadeias genéricas amplamente utilizadas em cenários de pagamento. A principal diferença para as cadeias dedicadas a pagamentos reflete-se nos seguintes aspetos:

7. Conclusão

A proposta de valor das cadeias dedicadas a pagamentos nunca reside em saber se são “mais rápidas do que o Ethereum” ou “mais baratas do que o Solana”, mas sim em conseguir internalizar a semântica dos pagamentos como restrições de design do próprio protocolo.

O juízo central da Tempo e do MPP é: ao tratar cenários de pagamento, as blockchains genéricas não sofrem de falta de funcionalidade; o problema é um erro no nível de abstração — elas tratam “transferência de ativos” como se fosse tudo o que é pagamento, ignorando elementos como autorização, sessões, roteamento e reconciliação, que já foram profundamente engenharia na finança tradicional.

A economia de agentes de IA introduz uma nova urgência de tempo nesta área. Quando agentes de software começam a substituir seres humanos para concluir comportamentos económicos como compras, subscrições e chamadas a serviços, o modelo de autorização dos sistemas de pagamentos tradicionais — construído sobre verificação de identidade de sujeitos humanos e confirmações manuais — ficará sujeito a uma incompatibilidade estrutural sistémica. O problema de “soberania do agente” que o protocolo MPP tenta resolver é precisamente este: quem tem qualificação para iniciar pagamentos, em que âmbito, por quanto tempo e como pode ser revogado. Esta lógica é altamente homóloga à forma como o OAuth resolve autorizações de API.

No entanto, é necessário salientar que a adoção em larga escala do pagamento autónomo por agentes de IA só é possível se a posição legal da identidade do agente, a atribuição de responsabilidades e os caminhos de conformidade com anti-lavagem de dinheiro forem clarificados. O desafio enfrentado pela Tempo é estrutural, e não apenas de execução. Em primeiro lugar, a incerteza regulatória continua a ser uma variável central: um design nativo de stablecoins significa que a Tempo tem de dialogar diretamente com reguladores de moedas em diferentes regiões, em vez de se esconder atrás da narrativa de “infraestrutura neutra”. Em segundo lugar, a tensão da compatibilidade com EVM ainda não foi resolvida — abandonar a EVM abre espaço para um design mais limpo, mas também implica abandonar a inércia de desenvolvedores e o suporte da toolchain acumulados na ecossistema Ethereum ao longo de anos. Em terceiro lugar, a cooperação com a Stripe confere ao protocolo MPP um raro respaldo comercial; mas esta dependência forte também é uma fonte de fragilidade. Existe uma tensão inata entre a abertura do protocolo e os limites do interesse dos parceiros comerciais, que precisa de observação a longo prazo.

Para os profissionais do setor, o que a Tempo/MPP tem de mais valioso para estudar pode não ser se acabará por se tornar o “vencedor das redes públicas de pagamentos”, mas sim o próprio problema que levanta: depois de a infraestrutura de pagamentos on-chain entrar numa era de divisão profissional do trabalho, como deve ser avaliada, afinal, a competitividade do design do protocolo? Para além de benchmarks de desempenho, talvez a precisão da expressão da semântica de pagamentos, a substituibilidade de requisitos de conformidade (“compliance plug-and-play”) e o modelo de autorização do agente sejam, na realidade, a diferença essencial da próxima geração de infraestrutura de pagamentos.

Referências

1. Tempo Official Website:
2. Tempo Mainnet Launch Blog: /blog/mainnet/
3. MPP Protocol Technical Specification:
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