I. Five Payment Needs of the AI Agent Economy
The global payment system is undergoing a structural transformation. The explosive growth of stablecoins and the rise of AI agent economies are jointly driving an urgent need for next-generation payment infrastructure.

When autonomous AI agents perform self-directed tasks, their payment behaviors differ fundamentally from those of traditional human payments. The following five core requirements form the foundational payment infrastructure needs for an AI agent economy:

Traditional SWIFT payment networks and general-purpose blockchains struggle to fully meet the above payment requirements under an AI agent economy, giving rise to Tempo.
II. Tempo: A Blockchain Built for the AI Era
As a payment-native blockchain launched by Commonware, Tempo achieves sub-second finality through the Simplex BFT pipeline consensus, ensures payment priority with dedicated block space and a native stablecoin gas mechanism, and enables end-to-end, human-free payments for AI agents via the MPP protocol.

Three, Tempo Blockchain Technology Architecture
3.1 Overall Architecture Overview
Tempo employs a dedicated Layer-1 architecture, guided by a "payments-first" philosophy—every technical decision on the chain is optimized for payment scenarios, rather than prioritizing the general-purpose design of a universal smart contract platform.

3.2 Simplex BFT Pipeline Consensus
Tempo's consensus layer is based on the Simplex BFT protocol (ePrint 2023/463). This protocol achieves a confirmation latency that converges to a single network round-trip time (1Δ) through its pipelined design.
Three-phase consensus process
The single-round consensus of Simplex BFT consists of three sequential phases:

Temporal Comparison: Traditional BFT vs. Simplex Pipeline
The diagram below illustrates the latency difference between traditional three-phase BFT and the Simplex pipeline. The vertical axis represents consensus rounds, and the horizontal axis represents network time steps (Δ).

Key performance improvement: In pipeline mode, the Propose phase of B₂ overlaps with the Vote phase of B₁. Each round requires waiting only 1Δ to proceed to the next block’s proposal, whereas traditional BFT requires a full 3Δ of sequential waiting per round.
View-Change Optimization

A view change is triggered in two scenarios: (1) the current leader fails to broadcast a valid proposal within the specified timeout period; (2) a node detects abnormal leader behavior, such as duplicate proposals or malformed messages.
3.3 BLS Aggregate Signature
Aggregates N validator signatures into a single signature using the BLS (Boneh-Lynn-Shacham) scheme, requiring only two elliptic curve pairings for verification, significantly reducing bandwidth and computational overhead. This is particularly important for high-frequency micropayment scenarios, effectively lowering the computation and bandwidth cost per transaction.
BLS Signature Principle

Visualization of the aggregated signature process

3.4 Parallel Transaction Execution Mechanism
Tempo's parallel transaction execution capability stems from two officially documented technical designs:
1. EIP-2718 Custom Transaction Type (Transaction Type 0x76)
The Crypto-Native Transaction format defined by Tempo extends three native capabilities beyond standard EVM transactions:
- Batch Execution: Execute multiple instructions atomically within a single transaction.
- Scheduled: Execute at a specified future block.
- Parallel Execution: Declares stateless dependencies, allowing concurrent processing with other transactions.
2. Expiring Nonce System
Traditional EVM enforces a strictly incrementing nonce, requiring all transactions from the same account to be executed sequentially. Tempo replaces the nonce with a "valid block range," requiring only that the nonce be unique within its validity period. This allows multiple independent transactions from the same account to be submitted and executed concurrently, eliminating the serial bottleneck at the account level.

3. Dedicated Payment Channels
Payment Lanes are dedicated block space reserved by Tempo at the protocol level specifically for TIP-20 payment transactions. Unlike Ethereum, where all transactions compete for the same gas pool, Tempo divides the block gas budget into multiple independent channels, ensuring that payment transactions are not disrupted by "noisy neighbors" such as DeFi operations, NFT minting, or high-frequency contract calls.
Block Gas Partition Structure
The Tempo block header includes an independent gas limit field, dividing the total gas budget of 500M into three non-interfering regions:

3.5 Native Design of Stablecoins
Tempo treats stablecoins as first-class citizens of the protocol, redesigning the entire experience—from gas fees and on-chain swaps to token standards—with stablecoins at the core.

Four, Machine Payments Protocol (MPP)
4.1 Protocol Positioning and Core Philosophy
MPP (Machine Payments Protocol) is an open payment standard co-designed by Stripe and Tempo, widely regarded in the industry as the "OAuth of payments." Its core objective is to provide standardized, human-free payment capabilities for autonomous AI agents.

4.2 MPP Full Interaction Flow

JWT payload structure

4.3 Session Mechanism
The session mechanism is one of the core innovations of the MPP protocol, addressing the payment efficiency issue when AI agents consume resources continuously over extended periods:

This design eliminates the need for on-chain confirmation with each interaction during long-running tasks, significantly improving payment efficiency.
4.4 Rail Cross-Payment Routing
The core design of MPP is to fully decouple the protocol from payment rails. The core layer defines only the HTTP challenge-response flow, error handling, and security model, without binding to any specific payment network. Therefore, adding a new payment method requires only registering a method identifier and publishing the corresponding schema and validation logic—no changes to the protocol itself are needed. During payment, agents do not need to concern themselves with the underlying rail; instead, the server declares acceptable methods in the 402 response, and the client matches them as needed. This is precisely what distinguishes MPP from single-chain or single-network solutions.
Payment rails currently supported by MPP

V. Application Scenario Analysis
Scenario One: Cross-border Business Payments
Traditional cross-border payments typically involve multiple parties, including the remitting bank, the SWIFT messaging network, correspondent banks, and the receiving bank, often taking 3 to 5 business days to complete. Fees usually range from 0.5% to 3%, and real-time processing is not supported on weekends or holidays.
In contrast, Tempo aims to offer an alternative path: if both the sender and recipient use stablecoins for settlement, a cross-border USDC-to-USDC payment could theoretically be completed in about 0.5 seconds, with a transaction fee of approximately $0.001, according to the current testnet design goals.

Scenario Two: 7×24 Hour Settlement for Tokenized Deposits
Tokenized deposits are financial assets that digitize bank deposit claims on a blockchain. A practical limitation of these assets is that the Federal Reserve’s Fedwire operates on fixed business hours and cannot process settlements on non-business days or during nighttime hours.
However, blockchain can naturally support 24/7, year-round operation, and Tempo’s built-in exchange module enables protocol-level conversions between different tokenized deposits, making round-the-clock settlement possible.

Scenario Three: High-Frequency, Low-Value Automated Payments
Credit card processing fees typically include a fixed fee of about $0.20 per transaction plus a percentage fee of 1.5% to 3%, making transactions under $1 commercially unviable—this is the fundamental reason for the long-standing gap in the micropayments market. Tempo’s fee of approximately $0.001 per transaction is designed to make the following scenarios commercially viable for the first time:

Scenario Four: Autonomous Payment by AI Agents
As AI agents are increasingly used to perform complex business tasks—such as booking resources, procuring supplies, and invoking external services—they generate real payment requirements. Tempo’s EVM-compatible architecture and dedicated payment interface enable agents to autonomously trigger payments via smart contracts, eliminating the need for manual approval of each transaction.

Six: Competitive Landscape Analysis
Between 2025 and 2026, the payment-specific blockchain sector will enter a period of intense market entry. This chapter provides a comparative analysis of three categories of competitors from a technical architecture perspective.
6.1 Payment-Specific Chain: Tempo vs Circle Arc vs Stable
All three chains are payment-specific L1s, but their underlying technical approaches differ significantly. Below, we break down their technical choices across three dimensions: consensus engine, fee mechanism, and core architectural innovations.

Competitive Positioning Matrix
The three chains are highly similar in performance metrics; the real distinctions lie in their target customers, stablecoin pegging strategies, core bets, and known risks.

6.2 Comparison with General Blockchains: Ethereum L2 and Solana
Ethereum L2 and Solana are currently two widely used general-purpose blockchains in payment scenarios. The key differences from payment-specific blockchains are reflected in the following dimensions:

Seven, Conclusion
The value proposition of a payment-specific chain has never been whether it is "faster" than Ethereum or "cheaper" than Solana, but whether it can internalize payment semantics as design constraints within the protocol itself.
Tempo and MPP's core insight is that general-purpose blockchains do not lack functionality in handling payment scenarios—they suffer from an incorrect level of abstraction. They treat asset transfer as the entirety of payment, while overlooking authorization, session management, routing, and reconciliation—components long deeply engineered in traditional finance.
The AI agent economy has introduced new urgency to this space. As software agents begin to replace humans in performing economic actions such as purchasing, subscribing, and invoking services, the traditional payment system’s authorization model—built on human identity verification and manual confirmation—will face systemic structural misalignment. The MPP protocol aims to address this layer of "agent sovereignty": who is authorized to initiate payments, within what scope, for how long, and how such authorization can be revoked. This logic is highly analogous to how OAuth addresses API authorization.
However, it must be noted that large-scale deployment of AI agents making autonomous payments requires clear legal status, liability allocation, and anti-money laundering compliance pathways for these agents. The challenges Tempo faces are structural, not merely operational. First, regulatory uncertainty remains a core variable: the native design of stablecoins means Tempo must engage directly with monetary regulators in each jurisdiction, rather than hiding behind the narrative of a "neutral infrastructure." Second, the tension around EVM compatibility remains unresolved—abandoning EVM could yield a cleaner design space but would mean relinquishing years of developer inertia and tooling support accumulated within the Ethereum ecosystem. Third, the partnership with Stripe provides MPP protocol with rare commercial validation, yet this strong dependency is also a source of vulnerability; there is an inherent tension between the protocol’s openness and the commercial partner’s interests, requiring long-term observation.
For industry professionals, what makes Tempo/MPP most worth studying may not be whether it ultimately becomes the "winner in payment blockchains," but rather the very question it raises: After on-chain payment infrastructure enters an era of specialized division of labor, how should the competitiveness of protocol design be evaluated? Beyond performance benchmarks, the precision of payment semantics, compliance pluggability, and agency authorization models may well be the true differentiators of the next generation of payment infrastructure.
References
- Tempo Official Website: https://tempo.xyz
- Tempo Mainnet Launch Blog: https://tempo.xyz/blog/mainnet/
- MPP Protocol Technical Specification: https://docs.tempo.xyz/mpp
- Fortune: Stripe-backed Tempo launches AI payments protocol (2026.03.18)
- The Block: Tempo Mainnet goes live with the Machine Payments Protocol for agents
- Privy Blog: Building on Privy with Tempo's Machine Payments Protocol (MPP)
- Medium (jrodthoughts): The Architecture of Autonomous Wealth — Inside Tempo's MPP
- McKinsey & Artemis Analytics: 2025 Stablecoins in Payments Report
- CoinGecko Stablecoins Market Data
- DeFiLlama On-chain Stablecoins Data
