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

特邀专栏作者

2026-04-07 13:25

This article is about 4634 words, reading the full article takes about 7 minutes

In March 2026, the payment blockchain Tempo announced its mainnet launch and jointly released the open protocol for machine-to-machine payments, MPP, with Stripe. This article systematically deconstructs the technical architecture of the payment-native blockchain Tempo, as well as the background, design logic, key technical points, application scenarios of the MPP (Machine Payment Protocol), and provides a comparative analysis with other chains.

AI Summary

Expand

Core Viewpoint: The article provides an in-depth analysis of the Tempo blockchain and its MPP protocol, arguing that it is designed to address the unique payment demands of the AI agent economy (such as automation, high frequency, and micro-transactions). By internalizing payment semantics, natively supporting stablecoins, and employing a dedicated architecture, it aims to build the next-generation payment infrastructure. However, its success faces structural challenges including regulation, ecosystem compatibility, and commercial dependencies.
Key Elements:
1. Payment Demands of AI Agents: AI agents require automated, programmable, high-frequency, micro-transactions that do not require human intervention, which traditional payment networks and general-purpose blockchains struggle to fully satisfy.
2. Technical Core of Tempo: Adopts a payment-first, dedicated L1 architecture, achieving sub-second finality through the Simplex BFT consensus, and ensuring payment priority and efficiency via dedicated payment channels and parallel execution mechanisms.
3. Innovation of the MPP Protocol: Positioned as the "OAuth for payments," MPP provides AI agents with standardized, end-to-end, non-intervention payment capabilities. Its core lies in the Session mechanism and a routing design decoupled from payment rails.
4. Advantages in Application Scenarios: Demonstrates commercial viability in scenarios such as cross-border payments (completed in 0.5 seconds with fees around $0.001), 24/7 settlement of tokenized deposits, and high-frequency micro-transactions.
5. Positioning in the Competitive Landscape: Competes with payment-specific chains like Circle Arc and Stable. Its value proposition is not about being faster or cheaper than general-purpose chains, but about deeply internalizing payment semantics into its protocol design.
6. Major Challenges Faced: Include regulatory uncertainty surrounding stablecoins, the tension between EVM compatibility and design simplicity, and potential risks stemming from strong dependencies on commercial partners like Stripe.

1. Five Major Payment Needs of the AI Agent Economy

The global payment system is undergoing structural reconstruction. The explosive growth of stablecoin scale and the rise of the AI agent economy have jointly created an urgent demand for next-generation payment infrastructure.

When Autonomous AI Agents execute autonomous tasks, their payment behavior is fundamentally different from traditional human payments. The following five core needs constitute the basic requirements of the AI agent economy for payment infrastructure:

Traditional SWIFT payment networks and general-purpose blockchains struggle to fully meet the aforementioned payment needs of the AI agent economy. Hence, Tempo was born.

2. Tempo: A Blockchain Built for the AI Era

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

3. Tempo Blockchain Technical Architecture

3.1 Overall Architecture Overview

Tempo adopts a specialized Layer-1 architecture. Its design philosophy is "payment-first" — every technical decision at each layer of the chain aims to optimize payment scenarios, rather than pursuing the generality of 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 its pipelined design, this protocol converges the confirmation delay of each round to a single network round-trip time (1Δ).

Three-Phase Consensus Process

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

Timing 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 only needs to wait 1Δ to proceed to the proposal of the next block, whereas traditional BFT requires a full 3Δ of serial waiting per round.

View-Change Optimization

View-Change is triggered in two situations: (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 illegal message formats).

3.3 BLS Aggregate Signatures

Using the BLS (Boneh-Lynn-Shacham) scheme, signatures from N validators are aggregated into a single signature, requiring only two elliptic curve pairing operations for verification, significantly reducing bandwidth and computational overhead. This is particularly important for high-frequency micropayment scenarios, effectively lowering the computational and bandwidth cost per transaction.

BLS Signature Principle

Aggregate Signature Process Visualization

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 types of native capabilities on top of standard EVM transactions:

Batch Execution: Atomically execute multiple instructions within a single transaction.
Scheduled Execution: Trigger execution at a specified future block.
Parallel Execution: Declare no state dependencies, allowing concurrent processing with other transactions.

2. Expiring Nonce System

The traditional EVM's strictly incrementing Nonce forces all transactions from the same account to be executed serially. Tempo changes the Nonce to a "valid block range," only requiring the Nonce to be unique within its validity period. Multiple independent transactions from the same account can be submitted and executed concurrently, eliminating account-level serial bottlenecks.

3. Dedicated Payment Lanes

Payment Lanes are block space specifically reserved at the protocol level for TIP-20 payment transactions on Tempo. Unlike Ethereum where all transactions compete for the same gas pool, Tempo splits the block gas budget into multiple independent lanes, ensuring payment transactions are not interfered with by "noisy neighbors" like DeFi operations, NFT mints, or high-frequency contract calls.

Block Gas Partition Structure

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

3.5 Stablecoin-Native Design

Tempo treats stablecoins as first-class citizens of the protocol, redesigning the entire stack—from Gas fees and on-chain swaps to token standards—with stablecoins at its core.

4. Machine Payments Protocol (MPP)

4.1 Protocol Positioning and Core Philosophy

MPP (Machine Payments Protocol) is an open payment standard jointly designed by Stripe and Tempo, referred to by the industry as "OAuth for payments." Its core goal is to provide autonomous AI agents with standardized, human-intervention-free payment capabilities.

4.2 Complete MPP 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 continuously consume resources over extended periods:

This design allows for long-running tasks without requiring on-chain confirmation for every interaction, significantly improving payment efficiency.

4.4 Cross-Rail Payment Routing

The core design of MPP is the complete decoupling of the protocol from specific payment rails. The core layer only defines the HTTP challenge-response flow, error handling, and security model, without binding to any concrete payment network. Therefore, adding a new payment method only requires registering a method identifier and publishing the corresponding Schema and validation logic, without modifying the protocol itself. During payment, the agent does not need to care about the underlying rail; the server declares acceptable methods in the 402 response, and the client matches accordingly. This is precisely the key difference between MPP and single-chain or single-network solutions.

Payment Rails Currently Supported by MPP