# Tempo is an EVM chain designed around stablecoin payments

> Tempo is a Rust blockchain built for payments, with a TIP-20 token standard that reserves dedicated payment lanes so transfers do not contend with everything else on the chain, a fee AMM that lets users pay gas in a USD stablecoin and converts to the validator's preferred one, and Tempo Transactions that give native accounts batched payouts, fee sponsorship, scheduled payments and passkey authentication. It runs on the Reth SDK, targets the Osaka hardfork, and every Ethereum JSON-RPC method works as expected.

**tempoxyz/tempo** — the blockchain for payments

- Repository: https://github.com/tempoxyz/tempo
- Website: https://docs.tempo.xyz
- Stars: 1,037 · Forks: 376
- Language: Rust
- License: Apache-2.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/tempoxyz-tempo

## Everything is oriented around the payment

The description is the blockchain for payments at scale, and the architecture focuses on high throughput, low cost, and the features that financial institutions, payment service providers and fintech platforms expect from modern payment infrastructure. The token standard is the TIP-20, which the README describes as enshrined ERC-20 extensions, and it brings three things. There is predictable payment throughput through dedicated payment lanes reserved for TIP-20 transfers, which eliminates noisy-neighbor contention, so a payment does not queue behind an unrelated transaction. There is native reconciliation with on-transfer memos and commitment patterns using a hash or a locator for off-chain PII and large data, which is how a payment can be reconciled without putting the data on the chain. And there is built-in compliance through the TIP-403 Policy Registry, where a single policy is shared across multiple tokens, updated once and enforced everywhere, which is the model a compliance team actually wants and which a per-token freeze cannot give.

## Fees paid in a stablecoin, converted by an AMM

The fee model is the part that differs most from a typical chain. Users pay gas directly in USD stablecoins at launch, and the Fee AMM automatically converts to the validator's preferred stablecoin, so the user does not have to hold the asset the validator wants. The cost target is stated as sub-millidollar for TIP-20 transfers, under $0.001, and the property that matters is predictability rather than the absolute number. A payment processor that has to model a fee in a volatile token is modelling risk, and a chain where the fee is denominated in a dollar stable and converted at the point of settlement removes that exposure from the payer. The tradeoff is that the chain now depends on a stablecoin market and on the AMM's behaviour, and the README is candid that non-USD stablecoin support and on-chain FX are coming soon rather than available, so today the fee story is a dollar stablecoin story.

## Tempo Transactions are native accounts with payment features

The third block of differences is Tempo Transactions, described as native smart accounts, and each of the four capabilities is something a payment product needs and an EVM transaction does not give you. Batched payments are atomic multi-operation payouts, which covers payroll, settlements and refunds, and atomicity matters there because a half-executed payroll is worse than a failed one. Fee sponsorship lets an app pay the user's gas, which is how an onboarding flow avoids asking a new user to fund a wallet. Scheduled payments use protocol-level time windows for recurring and timed disbursements, so the recurrence is enforced by the chain rather than by a cron job. And modern authentication uses passkeys through WebAuthn with P256, giving biometric sign-in, secure enclave use and cross-device sync, which is the part that decides whether a consumer-facing payment app can be used at all.

## EVM compatible, but on its own execution stack

The compatibility story is the familiar one. Tempo is fully compatible with the Ethereum Virtual Machine and targets the Osaka hardfork, so you deploy and interact with smart contracts with the same tools, languages and frameworks used on Ethereum, such as Solidity, Foundry and Hardhat, and all Ethereum JSON-RPC methods work out of the box. The README is careful to say that while the execution environment mirrors Ethereum's, Tempo introduces some differences optimized for payments, with a page describing them. The execution layer is built on the Reth SDK, which the README calls the most performant and flexible EVM execution client, and the consensus is Simplex Consensus via Commonware, giving fast, sub-second finality in normal conditions with graceful degradation under adverse networks. The Rust workspace confirms the shape, with crates for consensus, the node and node launcher, the transaction pool, primitives, the payload builder, precompiles, the faucet, the hardfork definition and a set of zones/ crates for the zone architecture, plus a prover, an enclave binary and a vsock proxy.

## Network identities are published keys, not just certificates

The feature that is easy to miss is at the top of the README, that Tempo nodes use published network identities to verify consensus finalisation and authenticate snapshots. The network identities are BLS threshold public keys, and they are built into Tempo nodes and used by both the follow and RPC nodes and the validators to verify consensus finalisation certificates, including those used to authenticate snapshots. The README then lists the mainnet identity from epoch 0 as a hex string:

```text
0xa217bb85001d4dcf8e5c50136f77af88cb2cab1857279b91c6240f41cca95c4f43f6dcab3e0dfb87dafb3ecbe
```

The point of publishing it is that a client can check that the finality certificate it was handed came from the network it thinks it is talking to, without trusting the node that served the data, and the same mechanism authenticates the snapshots the nodes exchange. For a chain whose whole argument is that a payment cannot be replayed or forged, having the identity of the network be a key rather than a certificate authority is a structural choice rather than a detail.

## Running a node, a localnet and the prover devnet

There are three installation paths for an operator, a pre-built binary, building from source, and a Docker image, with the node documentation linked. For local development and CI, the bootstrapped localnet container is the quick path:

```bash
docker run --rm -p 127.0.0.1:8545:8545 ghcr.io/tempoxyz/tempo-localnet:latest
```

For developer work on the prover there is a separate devnet image, ghcr.io/tempoxyz/tempo-devnet, which contains the Tempo L1 binary built with custom-pcrs, published with matching tags including sha-<short-sha> and nightly. The prover measurements are passed with --zone-verifier.custom-pcrs or the TEMPO_ZONE_VERIFIER_CUSTOM_PCRS variable, and this variant refuses to start on mainnet and Moderato, while the regular images keep the compiled-in PCR policy. That refusal is a good design detail, since the devnet image is deliberately not runnable against a network with real value.

## Building from source, and the shape of the repository

The contributor path is a clone, then just, then the hooks, then the build and the tests:

```bash
git clone https://github.com/tempoxyz/tempo
cd tempo
just
./scripts/setup-hooks.sh
just build-all
cargo nextest run
just localnet
```

The repository is a large Rust workspace on edition 2024 with a rust-version of 1.95.0 and the package licence MIT or Apache-2.0, and the workspace members give the scale of it, with the tempo and tempo-sidecar binaries, an xtask, and crates for the alloy integration, chainspec, consensus and its config, the DKG on-chain artifacts, the EVM, the hardfork, end-to-end tests, the faucet, the node and node launcher, nitro attestation, the payload builder and types, precompiles and their macros, primitives, contracts, telemetry utilities, the transaction pool, revm, state bloat, and the whole set of zone crates covering chainspec, checker, EVM, exit hatch, L1, p2p, payload, precompiles, primitives, prover, RPC, sequencer and spf. Around that there is a Justfile, a Docker build with several stages including a reproducible variant, a docker bake configuration, deny.toml for dependency policy, typos.toml, a Cross.toml for cross compilation, and a .changelog/ directory for release notes.

## Conclusion

Tempo is worth studying if you are building payment infrastructure, because the design decisions are aimed at the specific problems of stablecoin settlement, lane contention, fee currency and batched disbursement, rather than at general purpose execution. It is the wrong choice if you need a chain with an existing ecosystem and deep liquidity, since everything here is new, and the wrong choice if your requirements include what the README lists as coming soon, namely on-chain FX and non-USD stablecoins and the native private token standard. Before integrating, read the EVM compatibility notes, because the execution environment mirrors Ethereum while the differences are deliberate, and set the gas currency assumptions explicitly, since the fee AMM introduces a conversion step your accounting has to model.

## FAQ

### What is Tempo?

It is a blockchain designed specifically for stablecoin payments, with an architecture focused on high throughput, low cost, and the features that financial institutions, payment service providers and fintech platforms expect. It runs on the Reth SDK with Simplex Consensus and targets the Osaka hardfork.

### How much does a transaction cost on Tempo?

TIP-20 transfers are documented as targeting sub-millidollar costs, under $0.001. Users pay gas directly in USD stablecoins at launch, and the Fee AMM automatically converts to the validator's preferred stablecoin, so the fee is predictable rather than denominated in a volatile asset.

### What can Tempo Transactions do that a plain EVM transaction cannot?

They are native smart accounts with atomic multi-operation payouts for things like payroll, settlements and refunds, fee sponsorship so an app can pay a user's gas, protocol-level scheduled payments with time windows for recurring disbursements, and passkey authentication through WebAuthn with P256 for biometric sign-in and cross-device sync.

### How do I connect to the Tempo testnet?

The testnet is called Tempo Testnet (Moderato), with chain ID 42431, the HTTP URL at https://rpc.moderato.tempo.xyz, the WebSocket URL at wss://rpc.moderato.tempo.xyz and the block explorer at https://explore.tempo.xyz. Testnet stablecoins come from the Tempo faucet, or you can fund an address with cast rpc tempo_fundAddress.

## Sources

- [License: Apache-2.0](https://github.com/tempoxyz/tempo/blob/main/LICENSE)
- [Project website](https://docs.tempo.xyz)
- [README](https://github.com/tempoxyz/tempo/blob/main/README.md)
- [Releases](https://github.com/tempoxyz/tempo/releases)
- [tempoxyz/tempo on GitHub](https://github.com/tempoxyz/tempo)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tempoxyz-tempo