What is the Tempo blockchain?
Tempo is a Layer 1 blockchain built for one job: moving stablecoins at the scale and reliability a card network is held to. It was incubated by Stripe and Paradigm, and it is deliberately not a general-purpose platform competing for trading volume. The design decisions read like they were made by people who operate payment infrastructure rather than by protocol researchers. Blocks finalize in roughly 0.6 seconds with no re-orgs, so a merchant can treat a confirmed payment as settled instead of waiting out a probabilistic window. Fees are paid in stablecoins rather than a volatile native asset, which removes the treasury problem of holding a gas token you never wanted. Payment transactions get dedicated payment lanes, meaning reserved blockspace that other applications cannot consume, so a congestion event elsewhere on the chain cannot price your payroll run out of a block. Transfers carry structured metadata, so a payment can reference an invoice rather than arriving as an anonymous number that someone has to match by hand later.
Who is behind Tempo, and why did Stripe build a blockchain?
Tempo was incubated by Stripe together with Paradigm, the crypto investment firm, and raised a 500 million dollar Series A in October 2025 at a 5 billion dollar post-money valuation, co-led by Thrive Capital and Greenoaks with participation from Sequoia Capital, Ribbit Capital and SV Angel. The strategic logic is easier to see if you stop thinking of it as a crypto project. Stripe already moves money for a very large share of US internet businesses, and the parts of that job that stay expensive are cross-border settlement, payouts and any transaction small enough that card economics stop working. A chain that settles in under a second, charges fees in dollars and reserves capacity for payments addresses exactly those three. Tempo is also positioned as neutral infrastructure rather than a Stripe product, which matters commercially: Visa, Mastercard, Deutsche Bank, Standard Chartered, Revolut, Nubank, Shopify, DoorDash, Ramp, OpenAI and Anthropic have all been named among its design partners, and several of those would never build on a rail their competitor controlled outright.
Does Tempo have a token?
Tempo has no native gas token, and that is a design choice rather than a gap. Transaction fees are paid in any USD-denominated TIP-20 stablecoin, and a Fee AMM converts your token into whichever fee token the validator prefers, so nobody has to hold a separate volatile asset just to transact. This is the single most misunderstood thing about the chain, because a large share of the searches for a Tempo coin or a Tempo price are looking for something to buy. The useful framing for a business is the opposite one: the absence of a gas token is what makes the fee predictable. You pay for a transfer in the same currency you are transferring, your finance team does not have to run a treasury position in a token to keep the payments working, and a spike in some unrelated asset cannot change what your payment costs. If you have ever tried to explain to a controller why last month’s settlement costs moved 40 percent without any change in volume, you already understand why this matters.
What is TIP-20?
TIP-20 is Tempo’s native token standard for stablecoins and payment tokens, and it is the foundation for most of what makes the chain payments-shaped. Four parts are worth knowing. Transfers can carry a 32-byte memo for a payment reference, an invoice ID or a transaction note, which is the difference between a reconcilable payment and a line item somebody has to investigate. Each token declares an immutable currency field naming the reference asset one unit is designed to be worth, and only USD-denominated tokens qualify for fee payment and for trading on the built-in stablecoin DEX. Each token also declares a quoteToken used for pricing and for routing liquidity on that DEX, so a payment denominated in one stablecoin can settle to another without a separate bridge. And TIP-20 transactions are the ones eligible for the reserved payment lanes. If you are evaluating Tempo for a real workload, the memo field is the feature to test first, because reconciliation is where most stablecoin payment projects actually fail.
What is the Machine Payments Protocol?
The Machine Payments Protocol (MPP) is an open standard for machine-to-machine payments, co-authored by Tempo and Stripe, developed in the open and submitted to the IETF standards track. The protocol is free to implement with no licensing fee. It solves a specific and slightly absurd problem: when an agent needs a paid API today, it hits an onboarding flow designed for a human, with an account to create, a pricing page to read and a subscription tier to choose. MPP replaces that with an HTTP exchange. A server answers an unpaid request with HTTP 402 and a challenge describing what payment it will accept; the client returns a credential; the server returns a receipt along with the resource. Because the negotiation happens per request, an agent can pay for exactly the calls it makes with no contract, no seat and no minimum. MPP also ships the unglamorous production primitives natively: idempotency, expiration, request-body binding and tampering mitigations. And it supports sessions, which settle a run of requests off-chain as vouchers, giving sub-100ms latency and near-zero per-request cost before a single on-chain settlement closes the batch.
What is the difference between MPP and x402?
Both revive HTTP 402 Payment Required and both let a machine pay inline for a resource, so they get treated as competitors. The real difference is scope. x402, introduced by Coinbase, is blockchain-only: the payment is a stablecoin transfer, typically USDC on Base, and that is the whole payment method surface. MPP treats the payment method as an extension point, and ships production-ready support for Tempo stablecoin payments, cards, and Lightning, with a permissionless path for anyone to define a new method without asking an intermediary for approval. That is why MPP can serve a buyer whose finance team will never approve holding crypto: the same 402 handshake settles on a card. The second difference is operational maturity rather than ideology. Idempotency, expiry and request-body binding are the things you end up building yourself around x402, and they are in MPP’s base specification. Neither protocol is a spend control, which is the point of the section below.
Is Tempo live, and who validates it?
Mainnet went live in March 2026, following a public testnet that opened in December 2025. The first external validators arrived in April 2026: Stripe, Visa, and Zodia Custody by Standard Chartered. The important qualifier for anyone doing diligence is that the validator set is permissioned today, with a stated roadmap toward permissionless validation. That is a genuinely different trust model from a public chain, and whether it counts as a drawback depends entirely on who is asking. A crypto-native team will call a permissioned set a compromise. A bank’s risk committee will call it the reason the project is approvable at all, because a known set of regulated validators is something they can write a policy about. Be honest about which of those two rooms you are presenting in. On performance, Tempo publishes the roughly 0.6 second finality figure; the throughput numbers circulating in coverage are testnet benchmarks and architectural targets rather than measured mainnet sustained rates, so treat them accordingly.
Who is building on Tempo?
The most concrete adoption signal so far is Klarna, which launched KlarnaUSD, its first stablecoin, on Tempo during the testnet phase. Klarna serves roughly 114 million customers, so this is a real consumer payments company issuing a real instrument rather than a logo on a slide. Beyond that, DoorDash, Shopify and Kalshi have been cited around live or active implementations, and Tempo’s own site lists more than 40 organizations including Visa, Mastercard, Deutsche Bank, UBS, Revolut, Nubank, Brex, Kraken, OpenAI and Anthropic. One caveat worth applying to any of those lists: Tempo does not clarify which named organizations are validators, investors, design partners or integrators, and the categories are very different commitments. Treat a name on the partner wall as interest, not as production volume. The question to ask a vendor pitching you on Tempo is not who is listed, it is which of them has settled a payment you can point at.
How much does a Tempo transaction cost?
There is no published Tempo fee schedule, and anyone quoting you a precise per-transaction number is guessing. What is documented is the shape of the cost rather than its size: fees are denominated in USD stablecoins so they do not move with a token price, Tempo describes them as low and stable, and MPP sessions push the marginal cost of an individual request close to zero by settling a batch of off-chain vouchers once rather than touching the chain per call. For a useful comparison point on the same rails, Stripe publishes minimums on its agentic payment methods: 0.50 dollars for a card charge via a Shared Payment Token and 0.01 USDC for stablecoin settlement, which is the practical floor on what a single agent purchase can be worth today. If you are modeling economics for a high-volume machine workload, model the session pattern rather than the per-transaction one, because the entire design assumes you will batch.
What Tempo and MPP do not decide
This is the part that matters if your agents are the ones spending. Read the MPP specification and the Tempo documentation looking for a spending limit and you will not find one. There is no budget, no cumulative cap, no merchant allowlist, no velocity rule and no approval threshold anywhere in the protocol, and no statement about who is responsible for setting them. That is a correct decision at the protocol layer, in exactly the same way it was correct for ACP, AP2 and x402. A payment standard that tried to encode your finance policy would be worse at both jobs. It is still a hole at the program level, and MPP makes the hole wider than usual for one structural reason: sessions and per-request pricing are designed so that an agent can make thousands of tiny payments cheaply and without friction. Friction is what used to make runaway spend visible. Remove it, and the failure mode stops looking like one bad 40,000 dollar purchase and starts looking like four hundred thousand payments of a tenth of a cent to an endpoint nobody vetted, discovered when the settlement batch closes.
Where Tempo sits among the agent payment standards
These specifications get covered as a race and they are closer to a layer cake. Tempo is settlement: the chain the value actually moves on. MPP is negotiation: how a machine and a server agree a request needs paying and what will pay for it. ACP, maintained by OpenAI and Stripe, is checkout: how an agent completes a retail purchase with a merchant. AP2, donated to the FIDO Alliance in April 2026, is authorization: cryptographic proof that a human permitted a purchase within stated limits. x402 is a narrower settlement-plus-negotiation standard on public chains. Our breakdown of AP2 vs ACP vs x402 treats them the same way. A serious 2026 stack touches several, and the layer none of them occupies is policy: the decision about whether this agent, right now, should be allowed to spend this amount with this counterparty. That gap is why agentic payments programs keep discovering they bought a rail when what they needed was a rail and a brake.
Should you build on Tempo?
An honest read. Tempo is a strong fit if you are moving stablecoins at volume and reconciliation matters, because the memo field and the dedicated payment lanes address the two things that usually break those projects. It is a strong fit if you are metering machine or agent access to an API and want per-request pricing without seats and contracts, because that is precisely what MPP was written for. It is a weak fit if you need a permissionless trust model today, since the validator set is not open yet. It is a weak fit if your counterparties cannot hold or accept stablecoins at all, in which case the card path through Stripe’s agentic commerce stack gets you further with less novelty. And it is a premature bet if you are choosing a single rail to standardize on, because the standards question is genuinely unresolved and the cost of being wrong is an integration rewrite. The design that ages well is to stay rail-neutral above the settlement layer, so switching chains is a configuration change rather than a rebuild.
How AgentsPay governs Tempo and MPP payments
AgentsPay is the control plane, not the rail. It sits above whichever standard moves the money and answers the one question none of them answer: should this specific payment happen right now? Every agent gets its own funded wallet rather than shared access to a corporate credential. Each intended payment is checked against policy before any credential exists, covering the per-transaction ceiling, the cumulative budget over a window, the counterparty allowlist and the velocity rule that catches a loop. Anything above your threshold pauses for human approval instead of settling. What the agent receives is a scoped credential, whether that is a merchant-locked virtual card or a session bounded in advance, and every decision lands in an immutable audit trail naming the agent, its human owner, the intent and the policy that allowed it. Because the policy layer is rail-neutral, adopting Tempo for settlement and MPP for negotiation does not require betting your architecture on either one winning.