Payment Protocols: MPP, x402, and Tempo

Abstract

As artificial intelligence agents become autonomous economic actors, they require payment infrastructure designed for machine-to-machine transactions. Traditional payment rails—designed for human-initiated, low-frequency transactions—are incompatible with the high-frequency, micropayment-heavy usage patterns of AI systems. Agents need to pay per API call, per token of inference, per second of compute time, and do so across heterogeneous blockchain networks and traditional payment systems.

This whitepaper presents Tenzro's multi-protocol payment infrastructure, which supports three primary HTTP 402-based payment protocols: MPP (Machine Payments Protocol, co-authored by Stripe and Tempo), x402 (Coinbase's HTTP 402 protocol), and direct integration with the Tempo stablecoin network. Additionally, Tenzro provides native payment primitives—Direct on-chain settlement and Channel-based micropayments—optimized for per-token AI inference billing.

All payment protocols are deeply integrated with Tenzro's Decentralized Identity Protocol (TDIP), enabling identity-bound payments with fine-grained delegation scope enforcement. Machine identities can autonomously execute payments within predefined limits, while humans retain ultimate control through credential inheritance and cascading revocation.

This document provides a comprehensive specification of each protocol, including message formats, cryptographic verification procedures, settlement flows, session management, HTTP middleware integration, and identity-bound payment validation.

1. Introduction

1.1 Motivation

The AI age presents novel payment challenges:

• High transaction frequency: Agents may execute thousands of micropayments per second for inference tokens, API calls, or data access.
• Sub-cent amounts: A single inference token may cost fractions of a cent, requiring payment rails that support micropayments without prohibitive fees.
• Cross-chain interoperability: AI providers may accept payment in TNZO, USDC, ETH, or other assets across multiple blockchains.
• Machine autonomy: Agents must pay autonomously without human intervention, yet remain accountable to delegating humans.
• HTTP-native integration: Most AI APIs use HTTP, requiring payment protocols that integrate seamlessly with REST/JSON-RPC interfaces.

Existing payment systems fail to meet these requirements. Credit card networks charge 2-3% plus fixed fees, making micropayments uneconomical. Traditional blockchain transactions have high latency and gas costs. Custodial API keys lack accountability and revocability. Tenzro's multi-protocol approach addresses these gaps.

1.2 Supported Protocols

1.3 Design Principles

• Protocol-agnostic routing: PaymentGateway provides unified interface across all protocols
• Identity-first security: All payments bound to TDIP identities with delegation enforcement
• HTTP-native integration: axum middleware enables automatic 402 challenge/verification
• Cryptographic verifiability: All credentials signed and verified using Ed25519/Secp256k1
• Pluggable settlement: Backend settlement can use on-chain transactions, payment channels, or external rails

2. HTTP 402 Payment Flow

HTTP 402 (Payment Required) is a standard status code defined in RFC 7231 but historically unused. Modern machine payment protocols leverage 402 to create a standardized challenge/credential/receipt flow for resource access gating.

2.1 Generic Flow

Client                                    Server
  |                                           |
  |  (1) HTTP GET /api/resource              |
  | ----------------------------------------> |
  |                                           |
  |  (2) 402 Payment Required                |
  |      + PaymentChallenge (amount, asset)  |
  | <---------------------------------------- |
  |                                           |
  |  (3) Create PaymentCredential            |
  |      (sign with wallet, submit proof)    |
  |                                           |
  |  (4) HTTP GET /api/resource              |
  |      + PaymentCredential                 |
  | ----------------------------------------> |
  |                                           |
  |      (5) Verify credential & settle      |
  |                                           |
  |  (6) 200 OK + PaymentReceipt             |
  | <---------------------------------------- |
  |                                           |
  |  (7) Access resource with session token  |
  | ----------------------------------------> |
  |                                           |
  |  (8) 200 OK + Resource data              |
  | <---------------------------------------- |

2.2 Core Abstractions

Tenzro defines a unified payment protocol interface implemented by all payment methods:

Payment Protocol Interface:
    - Create payment challenge for resource access
    - Verify payment credential and complete settlement
    - Execute settlement (on-chain, channel, or external rail)
    - Generate payment credential from challenge (client-side)

The payment gateway routes requests to the appropriate protocol implementation based on the selected payment method (MPP, x402, Tempo, Direct, or Channel).

3. MPP (Machine Payments Protocol)

MPP is a session-based payment protocol co-authored by Stripe and Tempo. It builds on HTTP 402 to enable recurring access to resources through session tokens and voucher-based top-ups.

3.1 Protocol Overview

MPP introduces three core concepts:

• Challenges: Server-issued payment requirements with amount, currency, recipient, and expiration
• Credentials: Client-signed payment proofs referencing a challenge
• Sessions: Time-bound access tokens granted after successful payment verification

3.2 Message Formats

MppChallenge

{
  "challenge_id": "chal_1a2b3c4d5e6f",
  "amount": "0.05 TNZO",
  "currency": "TNZO",
  "recipient": "tenzro1qz8x9v...c2w3a4s5d6",
  "chain_id": 1337,
  "expires_at": "2026-03-22T15:30:00Z",
  "payment_methods": ["direct", "channel"],
  "metadata": {
    "resource": "/api/inference",
    "model": "llama-3-70b-instruct",
    "estimated_tokens": 1000
  }
}

MppCredential

{
  "challenge_id": "chal_1a2b3c4d5e6f",
  "payer": "did:tenzro:machine:did:tenzro:human:550e8400...:agent_7f8g9h",
  "amount": "0.05 TNZO",
  "payment_proof": "0x7a8b9c0d1e2f3a4b5c6d...",
  "signature": "0x3f4e5d6c7b8a9f0e1d2c...",
  "timestamp": "2026-03-22T14:45:30Z",
  "nonce": "0x9a8b7c6d5e4f3a2b1c0d"
}

The payment_proof contains the transaction hash (for Direct settlement) or channel state commitment (for Channel settlement). The signature is an Ed25519 or Secp256k1 signature over the credential fields, signed by the payer's MPC wallet.

MppReceipt

{
  "receipt_id": "rcpt_9z8y7x6w5v4u",
  "challenge_id": "chal_1a2b3c4d5e6f",
  "amount": "0.05 TNZO",
  "settlement_tx": "0xabc123def456...",
  "session_token": "sess_3t4r5e6w7q8p",
  "session_expires_at": "2026-03-22T16:00:00Z",
  "usage_limits": {
    "max_requests": 100,
    "max_tokens": 50000
  }
}

3.3 Session Management

MPP sessions enable amortized payment costs by allowing multiple resource accesses per payment. The MppSessionManager tracks active sessions:

MPP Session Structure:
    - Session identifier
    - Payer identity reference
    - Recipient address
    - Total amount paid
    - Creation timestamp
    - Expiration timestamp
    - Usage tracking (requests, tokens consumed, last access)

Sessions support vouchers for top-ups without new challenges:

Session Voucher:
    - Session identifier
    - Additional payment amount
    - Payment proof (transaction hash or channel state)
    - Cryptographic signature

Vouchers enable session top-ups without new challenges.

3.4 Server Implementation

Server Flow:
1. Initialize MPP payment server with settlement engine
2. Client requests protected resource
3. Server creates payment challenge (amount, currency, recipient)
4. Respond with HTTP 402 and challenge in X-Payment-Challenge header

3.5 Client Implementation

Client Flow:
1. Initialize MPP client with wallet
2. Parse challenge from 402 response header
3. Create credential by signing challenge with wallet
4. Retry request with credential in X-Payment-Credential header
5. Extract session token from receipt for future requests

4. x402 Protocol (Coinbase)

x402 is Coinbase's stateless HTTP 402 payment protocol optimized for one-time payments and public APIs. Unlike MPP, x402 does not use sessions—each resource access requires a separate payment.

4.1 Protocol Flow

4.2 Message Formats

X-Payment-Required Header

HTTP/1.1 402 Payment Required
X-Payment-Required: {
  "amount": "0.05",
  "currency": "TNZO",
  "recipient": "tenzro1qz8x9v...c2w3a4s5d6",
  "payment_id": "pay_1a2b3c4d",
  "chain_id": 1337,
  "methods": ["onchain", "lightning", "channel"]
}

X402PaymentPayload

POST /api/x402/pay
Content-Type: application/json

{
  "payment_id": "pay_1a2b3c4d",
  "payer": "did:tenzro:machine:did:tenzro:human:550e8400...:agent_7f8g9h",
  "amount": "0.05",
  "currency": "TNZO",
  "tx_hash": "0x7a8b9c0d1e2f3a4b...",
  "method": "onchain",
  "timestamp": "2026-03-22T14:50:00Z"
}

X-Payment-Receipt Header

HTTP/1.1 200 OK
X-Payment-Receipt: {
  "payment_id": "pay_1a2b3c4d",
  "confirmed": true,
  "amount": "0.05",
  "tx_hash": "0x7a8b9c0d1e2f3a4b...",
  "block_height": 12345,
  "timestamp": "2026-03-22T14:50:05Z"
}

4.3 Implementation

x402 Flow:
Server:
1. Create payment requirement with amount, currency, recipient, chain ID
2. Respond with 402 and X-Payment-Required header

Client:
1. Create payment payload with transaction proof
2. Submit payment via POST to payment endpoint

Server:
3. Verify payment on-chain or via channel
4. Return receipt with confirmation

5. Tempo Network Integration

Tempo is a stablecoin payment network enabling instant, low-cost transfers of TIP-20 tokens (USDC, USDT, etc.). Tenzro integrates directly with Tempo for cross-chain stablecoin settlement.

5.1 Architecture

Tenzro's Tempo integration consists of three components:

• TempoBridgeAdapter: Cross-chain bridge enabling TNZO ↔ Tempo asset transfers
• Tip20Token: Abstraction over TIP-20 stablecoins (USDC, USDT, DAI)
• TempoParticipant: Direct participation in Tempo network consensus and settlement

5.2 Configuration

Tempo Configuration:
    - Tempo network RPC endpoint
    - Tenzro's participant address on Tempo
    - Supported TIP-20 tokens (USDC, USDT, DAI)
    - Bridge contract address on Tenzro Ledger
    - Minimum confirmations for finality (default: 2)

Supported tokens maintain full decimal precision
(USDC/USDT: 6 decimals, DAI: 18 decimals)

5.3 Transfer Flow

Tempo Transfer Flow:
1. Initialize bridge adapter with configuration
2. Execute transfer (sender, recipient, amount, asset)
3. Bridge locks tokens on source chain
4. Tempo network finalizes transfer (2+ confirmations)
5. Recipient receives tokens on destination chain
6. Return transfer result with transaction hash and finality status

5.4 Balance Queries

Balance Query:
    - Query TIP-20 token balance on Tempo network
    - Returns balance in smallest units (respects token decimals)
    - Example: 100.00 USDC = 100_000_000 units (6 decimals)

5.5 Finality Model

Tempo uses instant finality with 2+ confirmations for production settlement:

6. Native Payment Primitives

6.1 Direct Settlement

Direct settlement uses standard on-chain transactions on Tenzro Ledger. Each payment is a blockchain transaction with immediate finality (post-consensus).

Direct Payment Flow:
1. Create transaction with sender, recipient, amount
2. Set gas parameters (limit, price)
3. Include nonce for replay protection
4. Sign transaction with MPC wallet
5. Submit to blockchain node
6. Receive transaction hash for tracking

6.2 Micropayment Channels

Payment channels enable off-chain micropayments for per-token AI inference billing. Channels avoid blockchain transaction costs by settling only the final state on-chain.

Channel Lifecycle

State Updates

Channel State Structure:
    - Channel identifier
    - Payer and payee identities
    - Current balances for both parties
    - Nonce (incremented per state update)
    - Timeout timestamp

State Update Process:
1. After each payment, create new state with updated balances
2. Increment nonce to prevent replay
3. Sign state with wallet
4. Exchange signed state off-chain (no blockchain transaction)

For detailed channel implementation, see the Micropayment Channels documentation.

7. Identity-Bound Payments

All Tenzro payment protocols integrate with TDIP (Tenzro Decentralized Identity Protocol) to enforce delegation scopes on machine payments. When a machine identity initiates a payment, the system validates:

• Transaction value: Payment amount ≤ max_transaction_value
• Daily spend: Daily accumulated spend ≤ max_daily_spend
• Protocol allowlist: Payment protocol ∈ allowed_payment_protocols
• Chain allowlist: Target chain ∈ allowed_chains
• Operations allowlist: Payment operation ∈ allowed_operations

7.1 Delegation Scope

Delegation Scope:
    - Maximum transaction value per payment
    - Maximum daily spending limit
    - Allowed operations (e.g., inference, storage)
    - Allowed smart contracts
    - Time-based restrictions (not before / not after)
    - Allowed payment protocols (MPP, x402, etc.)
    - Allowed blockchain networks

7.2 Validation Logic

Validation Logic:
1. Retrieve payer identity and delegation scope
2. Check transaction amount against maximum limit
3. Check daily spending against daily limit
4. Verify operation type is in allowed list
5. Verify payment protocol is in allowed list
6. Verify target chain is in allowed list
7. Check current time is within time bounds

Validation Results:
    - Valid: Payment allowed to proceed
    - ExceedsTransactionLimit: Single payment too large
    - ExceedsDailyLimit: Daily spending cap reached
    - ProtocolNotAllowed: Payment method not permitted
    - ChainNotAllowed: Target blockchain not permitted
    - TimeBoundViolation: Outside allowed time window

7.3 Example Scenarios

Payer: did:tenzro:machine:did:tenzro:human:550e8400...:agent_ai
Amount: 25.0 TNZO
Protocol: Mpp
Chain: 1337 (Tenzro Ledger)

Delegation Scope:
  max_transaction_value: "100.0 TNZO"
  max_daily_spend: "500.0 TNZO"
  allowed_payment_protocols: [Mpp, X402]
  allowed_chains: [1337]

Daily Spend Before: 75.0 TNZO
Daily Spend After: 100.0 TNZO

Result: APPROVED ✓

Payer: did:tenzro:machine:did:tenzro:human:550e8400...:agent_ai
Amount: 150.0 TNZO
Protocol: Mpp

Delegation Scope:
  max_transaction_value: "100.0 TNZO"

Result: REJECTED - ExceedsTransactionLimit ✗
Error: "Amount 150.0 TNZO exceeds max_transaction_value 100.0 TNZO"

Payer: did:tenzro:machine:did:tenzro:human:550e8400...:agent_ai
Amount: 50.0 TNZO
Protocol: Tempo

Delegation Scope:
  max_transaction_value: "100.0 TNZO"
  allowed_payment_protocols: [Mpp, X402]

Result: REJECTED - ProtocolNotAllowed ✗
Error: "Payment protocol Tempo not in allowed_payment_protocols [Mpp, X402]"

Payer: did:tenzro:machine:did:tenzro:human:550e8400...:agent_ai
Amount: 50.0 TNZO
Protocol: Mpp

Delegation Scope:
  max_transaction_value: "100.0 TNZO"
  max_daily_spend: "500.0 TNZO"

Daily Spend: 475.0 TNZO
Attempted Spend: 50.0 TNZO
Total: 525.0 TNZO

Result: REJECTED - ExceedsDailyLimit ✗
Error: "Daily spend 525.0 TNZO exceeds max_daily_spend 500.0 TNZO"

For comprehensive identity specification, see the TDIP whitepaper.

8. HTTP Middleware Integration

Tenzro provides axum middleware for automatic payment challenge/verification on HTTP routes. This enables seamless 402-gated API endpoints without manual challenge/credential handling.

8.1 Server Middleware

Server Middleware:
1. Configure payment gateway with settlement and identity systems
2. Apply middleware to protected routes
3. Specify payment protocol (MPP, x402, etc.)
4. Set price per request

Middleware automatically:
    - Issues 402 challenge if no valid credential/session
    - Verifies credentials and creates sessions
    - Passes verified payment context to request handler

8.2 Client Middleware

Client Middleware:
1. Initialize client with wallet and protocol selection
2. Make requests to protected endpoints

Client automatically:
    - Detects 402 responses
    - Creates payment credentials using wallet
    - Retries request with credentials
    - Caches session tokens for future requests

No manual payment handling required.

9. Implementation Architecture

Payment protocols are modular components that can be enabled independently based on deployment requirements. The system supports:

10. Security Considerations

11.1 Replay Protection

All payment credentials include nonces and timestamps to prevent replay attacks:

Replay Protection:
1. Each credential includes unique nonce and timestamp
2. Server tracks seen nonces
3. Duplicate nonces are rejected as replay attacks
4. Expired credentials (old timestamps) are rejected
5. Nonce tracking prevents credential reuse

11.2 Signature Verification

All credentials must be signed by the payer's MPC wallet. Verification uses Ed25519 or Secp256k1:

Signature Verification:
1. Reconstruct signed message from credential fields
2. Resolve payer identity to retrieve public key
3. Verify signature using Ed25519 or Secp256k1
4. Reject invalid signatures

This ensures credentials are created by legitimate payer identities
and cannot be forged.

11.3 Channel Dispute Resolution

Micropayment channels use challenge periods to prevent cheating:

Dispute Resolution:
1. Payee submits final state to close channel
2. Challenge period begins (7 days default)
3. Payer can dispute by submitting higher-nonce state
4. Highest nonce state wins (most recent agreement)
5. After challenge deadline, settlement executes with final state
6. Balances disbursed according to final state

This prevents payees from submitting outdated states
to claim more funds than owed.

11. Performance Characteristics

12.1 Latency Comparison

12.2 Cost Analysis

12. Conclusion

Tenzro's multi-protocol payment infrastructure addresses the unique requirements of AI-age machine payments through HTTP 402-based protocols (MPP, x402), direct stablecoin settlement (Tempo), and native micropayment channels optimized for per-token billing. Deep integration with TDIP enables fine-grained delegation scope enforcement, allowing machine identities to pay autonomously within human-defined limits.

The current implementation establishes the architectural foundation with well-defined message formats and protocol abstractions. Ongoing development focuses on cryptographic verification, persistent state storage, and integration with live payment networks.

By supporting multiple payment protocols through a unified gateway, Tenzro enables developers and AI agents to choose the optimal payment rail for each use case—balancing latency, cost, finality, and interoperability requirements. This flexibility is essential for the diverse payment patterns of autonomous AI systems operating across global infrastructure.