A Detailed Explanation of the Tempo Chain and MPP Machine Payment Protocol

I. Five Payment Requirements for the AI Agent Economy

The global payments system is undergoing a structural reshaping. The explosive growth in stablecoin volume and the rise of the AI agent economy together have created an urgent need for next-generation payments infrastructure.

When AI agents (Autonomous AI Agents) carry out autonomous tasks, their payment behavior differs fundamentally from traditional human payments. The following five core needs form the basic requirements that the AI agent economy places on payments infrastructure:

Conventional swift payment networks and general-purpose blockchains cannot fully meet the above payment needs under the AI agent economy; thus, Tempo was created.

II. Tempo: A Blockchain Built for the AI Era

As a payments-native blockchain launched by Commonware, Tempo achieves sub-second finality through a Simplex BFT pipelined consensus. It ensures payment priority with a dedicated block space and a stablecoin-native Gas mechanism, and provides end-to-end payments for AI agents with no human intervention through the MPP protocol.

III. Tempo Blockchain Technical Architecture

3.1 Overview of the Overall Architecture

Tempo adopts a dedicated Layer-1 architecture. Its design philosophy is “payment-first”—each technical decision at every layer on-chain is aimed at optimizing payment scenarios, rather than following a generic design intended for a universal smart contract platform.

3.2 Simplex BFT Pipelined Consensus

Tempo’s consensus layer is based on the Simplex BFT protocol (ePrint 2023/463). Through a pipelined design, the confirmation latency in each round converges to a single network round trip time (1Δ).

Three-Stage Consensus Process

A single-round consensus of Simplex BFT consists of three sequential phases:

Timing Comparison: Traditional BFT vs. Simplex Pipelining

The diagram below shows the latency difference between the traditional three-stage BFT and the Simplex pipeline. The vertical axis represents the consensus round, and the horizontal axis represents the network time step (Δ).

Key Performance Improvement: In the pipeline mode, the B₂ Propose phase overlaps with the B₁ Vote phase. Each round only needs to wait for 1Δ to enter the proposal of the next block, whereas traditional BFT requires a full 3Δ serial wait per round.

View-Change Optimization

View-change (View-Change) is triggered in two cases: (1) the current leader (Leader) fails to broadcast a valid proposal within the specified timeout; (2) a node detects anomalous leader behavior (e.g., repeated proposals or an invalid message format).

3.3 BLS Aggregate Signatures

The system adopts the BLS (Boneh-Lynn-Shacham) scheme to aggregate N validators’ signatures into a single signature, requiring only two elliptic-curve pairing operations for verification, which significantly reduces bandwidth and computational overhead. This is especially important for high-frequency micro-payment scenarios, effectively lowering per-transaction computation and bandwidth costs.

Principle of BLS Signatures

Visualization of the Aggregate Signature Process

3.4 Parallel Transaction Execution Mechanism

Tempo’s parallel transaction execution capability comes from two explicitly documented official technical designs:

1. EIP-2718 Custom Transaction Type (Transaction Type 0x76)

The Crypto-Native Transaction format defined by Tempo extends three native capabilities on top of standard EVM transactions:

• Batch Execution: Atomically executes multiple instructions within a single transaction
• Scheduled Execution: Specifies future blocks to trigger execution
• Parallel Execution: Declares no state dependencies, allowing concurrent processing with other transactions

2. Expiring Nonce System

Traditional EVM’s strict incrementing Nonce forces all transactions from the same account to execute serially. Tempo changes Nonce into an “effective block range.” It only requires Nonces to be unique within their validity period. Multiple independent transactions from the same account can be submitted simultaneously and executed in parallel, removing the account-level serial bottleneck.

3. Dedicated Payment Lanes

ayment Lanes are block space that Tempo reserves at the protocol layer specifically for TIP-20 payment transactions. Unlike Ethereum, where all transactions compete for the same gas pool, Tempo splits the block gas budget into multiple independent lanes, ensuring that payment transactions are not disturbed by “noisy neighbors” such as DeFi operations, NFT minting, or high-frequency smart contract calls.

Block Gas Partition Structure

Tempo’s block header carries independent gas limit fields, dividing the 500M total gas budget into three non-interfering regions:

3.5 Stablecoin-Native Design

Tempo treats stablecoins as a first-class citizen in the protocol. From Gas fees, on-chain exchange, to token standards, the entire end-to-end flow is redesigned around stablecoins as the core

IV. Machine Payments Protocol (MPP)

4.1 Protocol Positioning and Core Principles

MPP (Machine Payments Protocol) is an open payments standard jointly designed by Stripe and Tempo, and is referred to by the industry as “OAuth for the payments world.” Its core goal is to provide standardized payment capabilities for autonomous AI agents—without requiring human intervention.

4.2 Full MPP Interaction Workflow

JWT Payload Structure

4.3 Session Mechanism

The Session mechanism is one of the core innovations in the MPP protocol. It addresses the payment efficiency problem when AI agents consume resources for long periods continuously:

This design means that during long-running task execution, on-chain confirmation does not need to be triggered for every interaction, greatly improving payment efficiency.

4.4 Cross-Rail Payment Routing

MPP’s core design fully decouples the protocol from the payment rail. The core layer only defines the HTTP challenge-response flow, error handling, and the security model, without binding to any specific payment network. Therefore, adding a new payment method only requires registering a method identifier and publishing the corresponding Schema and verification logic—without changing the protocol itself. When making payments, the agent does not need to care about the underlying rail; instead, the server declares acceptable methods in the 402 response, and the client then matches as needed. This is exactly the key difference between MPP and a single-chain or single-network solution.

Payment rails supported by MPP currently

V. Application Scenarios Analysis

Scenario 1: Cross-Border Enterprise Payments

Traditional cross-border payments usually require going through multiple steps, such as the paying bank, the SWIFT message network, correspondent banks, and the receiving bank. This often takes 3 to 5 business days. Fees are typically between 0.5% and 3%, and real-time processing is not supported on weekends and public holidays.

By contrast, Tempo aims to provide an alternative path: if both the payer and payee use stablecoins for settlement, then according to the target design of the current testnet, a USDC-to-USDC cross-border payment can theoretically be completed in about 0.5 seconds, with an estimated per-transaction fee of about $0.001.

Scenario 2: 7×24 Tokenized Deposit Clearing

Tokenized deposits are financial assets that digitize bank deposit receivables on the blockchain. Such assets face a real-world obstacle: the Fedwire system of the Federal Reserve has fixed business hours and cannot process clearing during non-business days or at night.

But blockchains can naturally run 24/7, year-round without downtime. Moreover, Tempo’s built-in exchange module can also support protocol-layer conversion between different tokenized deposits, making around-the-clock clearing possible.

Scenario 3: High-Frequency Automated Micro-Payments

Credit card processing fees usually include a fixed fee of about $0.2 per transaction plus a percentage-based fee of 1.5% to 3%, making transactions below $1 not commercially viable—this is the fundamental reason why a “micro-payments” market has long had a gap. Tempo’s fee design target of about $0.001 per transaction makes the following scenarios commercially feasible for the first time:

Scenario 4: Autonomous Payments by AI Agents

As more and more AI agents are used to carry out complex business tasks (booking resources, purchasing supplies, calling external services), these agents generate real payment demand. Tempo’s EVM-compatible architecture and dedicated payment interfaces enable agents to trigger payments autonomously via smart contracts, without needing human approval for every transaction.

VI. Competitive Landscape Analysis

In 2025–2026, the payment-specific chain track will see a dense wave of new entrants. This chapter provides a horizontal comparison of three types of competitors from a technical architecture perspective.

6.1 Payment-Specific Chains: Tempo vs Circle Arc vs Stable

All three chains are payment-specific L1s, but their underlying technical routes differ significantly. Below, we break down each chain’s technical choices across three dimensions: consensus engine, fee mechanism, and core architecture innovations.

Competitive Positioning Matrix

The three chains converge highly on performance metrics. The real differentiation lies in target customers, stablecoin binding strategy, core bets, and known risks.

6.2 Comparison with General-Purpose Blockchains: Ethereum L2 and Solana

Ethereum L2 and Solana are two categories of general-purpose chains that are widely used today in payment scenarios. The core gap versus payment-specific chains is reflected in the following dimensions:

VII. Conclusion

The value proposition of a payment-specific chain has never been whether it is “faster than Ethereum” or “cheaper than Solana.” Rather, it is whether it can internalize payment semantics into the protocol itself as design constraints.

Tempo and MPP’s core judgment is this: when general-purpose blockchains process payment scenarios, it is not that they lack functions—it is that they have an incorrect abstraction level. They treat “asset transfer” as the entirety of payment, while overlooking aspects that have already been deeply engineered in traditional finance, such as authorization, sessions, routing, and reconciliation.

The AI agent economy injects new urgency into this track. When software agents begin to replace humans to complete economic behaviors such as purchasing, subscriptions, and service calls, the authorization model of traditional payment systems—built on human identity verification and manual confirmation—will face a systemic structural mismatch. What the MPP protocol attempts to solve is precisely this layer of “agent sovereignty”: who is qualified to initiate payments, within what scope, for how long continuously, and how it can be revoked. This logic is highly homologous to the way OAuth solves API authorization.

However, it must be pointed out that the large-scale deployment of autonomous AI-agent payments depends on clearly defining the legal status of agent identities, responsibility allocation, and anti–money laundering compliance paths. Tempo’s challenges are structural rather than merely execution-layer. First, regulatory uncertainty remains a core variable: Tempo’s stablecoin-native design means Tempo must directly engage with currency regulators in different regions, instead of hiding behind the narrative of “neutral infrastructure.” Second, the tension in EVM compatibility has not been resolved—giving up EVM could allow a cleaner design space, but it also means giving up years of developer inertia in the Ethereum ecosystem and toolchain support. Third, the partnership with Stripe provides rare commercial backing, but that heavy reliance is also a source of fragility; there is an inherent tension between the protocol’s openness and the boundaries of commercial partners’ interests, which needs long-term observation.

For practitioners in the industry, what Tempo/MPP is most worth studying may not be whether it ultimately becomes the “winner of the payment public chain,” but the question it raises itself: after on-chain payment infrastructure enters the era of specialized division of labor, how should protocol design competitiveness be evaluated? Beyond performance benchmarks, the precision of expressing payment semantics, compliance plug-and-play capability, and the agent authorization model may be the true differentiators of next-generation payments infrastructure.

References

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