How Does Tempo Work?

Simplex Consensus via Commonware — a Byzantine Fault Tolerant consensus engine providing sub-second finality (~0.5s block times) with deterministic block production and graceful degradation under adverse network conditions

Simplex is a novel BFT consensus algorithm developed by Commonware (in which Tempo invested $25M). Unlike Tendermint or HotStuff variants, Simplex is designed specifically for high-throughput payments workloads. On testnet, Tempo benchmarks 20,000 TPS with a stated roadmap to 100,000+ TPS at mainnet. The tight coupling between Tempo and a single external consensus provider creates dependency risk.

Reth-based EVM targeting Osaka hard fork — Tempo uses Reth (Rust Ethereum client) as its execution layer, maintaining full EVM compatibility with Solidity tooling, Foundry, and Hardhat while adding payment-specific extensions

Using Reth as the execution client is increasingly common (Base, Arc also use it). EVM compatibility reduces developer friction but means Tempo inherits Ethereum EVM limitations. The payment-specific fork diverges from standard EVM by adding TIP-20 and payment lanes.

TIP-20 — a superset of ERC-20 designed specifically for stablecoins and payment instruments, adding a 32-byte memo field for invoice IDs and an opt-in reward distribution mechanism that distributes in O(1) regardless of holder count

TIP-20 is a genuine innovation over ERC-20. The memo field enables on-chain reconciliation of payments against invoices, a critical primitive for institutional payment systems. The O(1) reward distribution solves gas scalability issues with dividend-style distributions. Tempo has dedicated payment lanes in every block reserved exclusively for TIP-20 transfers, targeting sub-$0.001 fees.

Dual-lane block architecture — block headers carry separate gas limits for general EVM execution and payment lanes; block bodies begin with system transactions, then general proposer transactions, then sub-blocks from other proposers, then end-of-block system transactions

This carve-out ensures payments get deterministic block placement and cannot be starved by general smart contract activity. This is a meaningful architectural novelty over conventional single-lane EVM chains and comparable payment chains like Celo. The sub-block architecture enables composability across multiple proposers.

Enshrined AMM for gas abstraction — an AMM baked directly into the protocol allows gas fees to be paid in any supported stablecoin; the AMM automatically converts to the validator's preferred denomination

Gas abstraction via AMM eliminates the need for a native gas token and avoids account abstraction complexity. Similar approaches exist on other chains but Tempo makes this a core protocol primitive rather than an optional layer. The enshrined AMM introduces a protocol-level liquidity mechanism with its own risks around price manipulation during low-liquidity periods.

Protocol-level access control lists — regulated businesses can register blocklists and allowlists at the chain layer, preventing funds from flowing to blacklisted addresses or requiring KYC verification on specific accounts

ACLs at the protocol layer are a deliberate compliance feature that distinguishes Tempo from permissionless chains. This enables institutional adoption (banks, payment processors) but introduces a fundamentally different trust model: users must trust that ACL administrators will not abuse censorship powers. This feature is controversial and draws direct comparisons to Libra's compliance-first architecture.

Validator censorship via ACL enforcement — permissioned validators operating under Stripe/Paradigm control can selectively censor transactions by coordinating with ACL blocklists, creating a protocol-native censorship mechanism with no on-chain recourse for affected users

Payment lane starvation under adversarial load — while the dual-lane architecture reserves blockspace for TIP-20 transfers, a malicious or overwhelmed validator set could fail to honor payment lane priorities during a consensus disruption, breaking the latency guarantees that institutional partners rely on

Enshrined AMM price manipulation during low liquidity — if the enshrined AMM's liquidity pools are thin (especially for less-common stablecoins), an attacker could temporarily skew AMM prices to extract value from transactions using those stablecoin denominations for gas, distorting payment lane economics

TIP-20 and ERC-20 composability gaps — smart contracts written against ERC-20 may not properly handle TIP-20's extended fields (memo, reward distribution), creating silent compatibility failures when TIP-20 tokens interact with standard DeFi protocols or cross-chain bridges that expect pure ERC-20 behavior

ACL-based stablecoin delistings — if a stablecoin issuer (USDC, USDT) adds a counterparty to their own blacklist, it interacts unpredictably with Tempo's enshrined AMM: transactions routed through the AMM using that stablecoin could fail in mid-execution, leaving payment state inconsistent