Vol. 1 · 7 Jun 2026

Field guide

Learn Tempo

A sourced, neutral guide to how Tempo works — from stablecoin gas to consensus to connecting your wallet. Read the long-form field guide below, or jump straight to any concept's cited dossier.


Long-form

Explainers

What is Tempo?

Tempo is a payments-first, EVM-compatible Layer 1 blockchain incubated by Stripe and Paradigm, built for stablecoin payments at scale. Mainnet launched 18 March 2026.

Read · 5 min →

Stablecoin gas & the Fee AMM

Tempo has no native gas token: fees are paid in USD-denominated TIP-20 stablecoins, and a protocol-native Fee AMM converts a payer's fee token into the validator's preferred one.

Read · 5 min →

TIP-20 & TIP-403 token standards

TIP-20 is Tempo's stablecoin-focused ERC-20 superset; TIP-403 is the shared compliance policy registry that TIP-20 tokens point at for allowlist/blocklist checks on every transfer.

Read · 6 min →

The Machine Payments Protocol (MPP)

MPP is an open standard co-authored by Stripe and Tempo for machine-to-machine payments. Built on HTTP 402, it lets any client pay for a service inline with its request — no API keys or signup flow.

Read · 6 min →

Simplex BFT consensus & finality

Simplex BFT, provided by the Commonware library, is Tempo's consensus: deterministic sub-second finality with VRF leader election, favouring safety over liveness.

Read · 5 min →

Validators & the permissioned set

Tempo launched with a permissioned validator set — approved operators including Stripe, Visa, Zodia Custody, and MoneyGram — with a stated roadmap toward permissionless validation.

Read · 4 min →

Build on Tempo: connect & deploy

Tempo is EVM-compatible: connect to mainnet (chain ID 4217) or the Moderato testnet (42431) with standard tooling. State-creating operations cost more by design to deter state bloat.

Read · 5 min →

Tempo vs other payment rails

How Tempo's payments-first design — stablecoin gas, deterministic finality, and a permissioned validator set — differs from general-purpose blockchains, neutrally and with the trade-offs named.

Read · 5 min →

Virtual addresses & MPP Sessions

Two Tempo scaling primitives: virtual (forwarding) addresses let a business derive unlimited deposit addresses off-chain, and MPP Sessions collapse many micropayments into two on-chain transactions.

Read · 6 min →

Zones — private execution

Tempo Zones are private, EVM-compatible parallel blockchains connected to mainnet: a Zone operator sees its transactions while the public sees only cryptographic proofs of validity.

Read · 4 min →

Start here


The protocol

Core concepts

Connect to Tempo

Chain IDs, RPC endpoints, predeployed contracts, and one-click add-to-wallet for mainnet (4217) and the Moderato testnet (42431).


Answer-first

Tempo, explained

What is Tempo?
Tempo is a payments-first, EVM-compatible Layer 1 blockchain incubated by Stripe and Paradigm. Mainnet launched 18 March 2026. It is designed for stablecoin payments at scale: ~600ms blocks, deterministic finality, and gas paid in USD-denominated stablecoins rather than a native token.
Does Tempo have a native token?
No. Tempo has no native gas token and no announced airdrop. Transaction fees are paid in USD-denominated TIP-20 stablecoins, and a Fee AMM converts a user's fee stablecoin into the validator's preferred one. At the VM, BALANCE/SELFBALANCE return 0.
What is TIP-20?
TIP-20 is Tempo's token standard: an ERC-20 superset adding token memos, reward distribution, role-based controls, currency identifiers, and TIP-403 policy hooks (allowlist/blocklist/freeze). It is how stablecoins are issued on Tempo.
What is the Machine Payments Protocol (MPP)?
MPP is an open standard co-authored by Stripe and Tempo for high-frequency machine payments. MPP Sessions collapse many micropayments into two on-chain transactions (open a session, then settle with a final signed voucher). It launched with mainnet alongside a Payments Directory of 100+ services.
How fast is Tempo and is it final?
Tempo targets ~600ms block times using Simplex BFT consensus (built with Commonware) with VRF leader election and deterministic finality. It favours safety over liveness: the chain halts if more than one-third of validators are unavailable. The initial validator set is permissioned.