Tempo: Where Specialized Blockchains Are Headed

Key Takeaways

• Institutional blockchain adoption is starting with payments. For these institutions, a blockchain is not simply a network to deploy products on. It is treated as part of the product itself.
• Instead of building on a finished framework, Tempo picks consensus, data dissemination, and cryptography as individual parts from a parts box called Commonware. The result is a payments-focused L1 that assembles an EVM execution layer and a Threshold Simplex consensus layer into a single binary.
• Tempo builds the requirements of payments into the protocol itself rather than the application layer. Deterministic half-second settlement with no reorgs, blockspace and fees that stay guaranteed regardless of congestion, and issuer policy enforcement and privacy all live inside the consensus rules and the token standard.
• A blockchain reassembled for a specialized purpose gains performance and control optimized for that purpose, but it trades away many of the values of a traditional blockchain. Decentralized networks and specialized networks are complements rather than substitutes, and Tempo is a concrete example of the technical direction specialized chains are taking.

1. Introduction: blockchains becoming part of the product

Countless blockchain networks have come and gone, and the industry appeared to be standardizing around a handful of general-purpose chains, Ethereum among them. But with institutions now entering in earnest, blockchains are once again splitting into industry-specific infrastructure.

Purpose-built chains existed before. Those earlier chains, however, were built to secure throughput and speed for a specific game or DeFi service. The institutional chains appearing today are built because financial institutions, trading platforms, and payment companies want direct control over how assets move. For them, a blockchain has to be tailored infrastructure with the right fees, settlement guarantees, access controls, privacy, and regulatory posture for their own products. To these institutions, a blockchain is not simply a network to deploy a product on. It is part of the product.

There are three main ways institutions build their own networks.

• Build an Ethereum L2 that inherits Ethereum's security and the EVM ecosystem. Robinhood Chain and GIWA fall into this category.
• Launch an independent L1 that uses an EVM execution engine for compatibility. Stable, Plasma, and Arc fall into this category.
• Launch an entirely new L1. Canton falls into this category.

Most use an EVM execution engine, but there is no single standardized stack. These projects all pursue fast settlement, low and predictable costs, regulatory compliance with controllable operations, and high programmability, yet they all chose different stacks. The independent L1s show an interesting pattern. On the execution layer, Plasma, Arc, and Tempo all adopted Reth. On the consensus layer, they split across StableBFT, PlasmaBFT, Malachite, and Commonware's Simplex.

EVM compatibility has become the de facto standard for execution, while consensus remains an open choice shaped by each chain's needs. As institutional entry accelerates, demand for custom-built blockchains will keep growing, and the networks that follow can be expected to become more modular at every layer.

This is where Commonware comes in, offering building blocks smaller than a full blockchain framework. Commonware provides consensus, networking, storage, and cryptography as independent modules, letting a development team compose a blockchain stack fitted to a specific workload.

Tempo, a payments blockchain incubated by Stripe and Paradigm, launched as a new independent L1 that combines a Reth-based EVM execution environment with Commonware's consensus and networking stack. This article walks through the stack Tempo built with Commonware and compares it with the familiar alternatives, Ethereum L2s and CometBFT-based EVM L1s, to see what differs and what gets traded away.

2. What a payments network requires

2.1 Predictability

Blockchain performance is usually discussed in averages. Average TPS and average fees become the basis for comparison. But what a payment operator needs is never the average. What determines the quality of a payment service is how long settlement can be delayed in the worst case and how high fees can spike.

On general-purpose chains like Ethereum or Solana, that worst case is driven by events that have nothing to do with payments. A popular NFT mint or a wave of liquidations during market volatility intensifies competition for blockspace, and the latency and cost of payment transactions rise with it. This is the noisy neighbor problem. For a payment operator it goes beyond inconvenience. Payments is a business with a fixed margin per transfer, and if gas fees jump to unpredictable levels, transfers can turn into losses. This is why predictability matters more than a low average fee.

2.2 The finality problem

Ethereum's slot time is 12 seconds, and finality arrives after two epochs, roughly 13 minutes later. A backend receiving those events has to manage authorization and settlement as separate states and treat the possibility of a settled transaction being reversed as a standing exception. That exception propagates into accounting, refunds, and dispute handling.

Deterministic finality removes the exception path itself. If a finalized block is guaranteed never to revert, authorization and settlement can collapse into a single state. This is why finality in a payment system is a matter of system complexity, not just user experience.

BFT-family consensus provides deterministic finality. A block is confirmed the moment its vote completes. In exchange, BFT consensus pays a serious price: the chain can halt easily. If more than a certain fraction of validators stop responding, the chain stops producing blocks. The judgment built into this design is that a halted network is a loss, but a double settlement is worse. Traditional banking makes a similar choice, pausing transfers during settlement cutoffs and maintenance windows. A temporarily unavailable transfer is inconvenient, but it costs less than unwinding a transfer that was processed incorrectly.

Ethereum itself acknowledges that these requirements conflict with the goals of a general-purpose chain. Vitalik Buterin has said that Ethereum L1 should not target sub-second finality and that applications needing very low latency should use L2s. That has long been Ethereum's position, prioritizing decentralization and stability, but it also means some payment requirements are hard to satisfy on a general-purpose chain.

2.3 Privacy

Pay salaries onchain and every employee's compensation is public. Settle with merchants onchain and volumes and unit prices are exposed to competitors. The transparency of existing blockchains does not solve this. For a business, a public ledger is less about transparency and closer to a continuous leak of commercial information.

Regulation pulls in the opposite direction at the same time. Assets of sanctioned addresses must be freezable, the Travel Rule attaches sender and receiver information to transfers above a threshold, and allowlists differ by jurisdiction. The issuer needs to define who can see what and who can block what.

On general-purpose chains these requirements are usually handled in smart contracts. But controls layered onto contracts are implemented separately for each token, and different implementations mean diverging policies. A rule the protocol does not know about is a rule the protocol cannot enforce. That gap is why payment chains try to handle policy enforcement and confidentiality at the protocol layer rather than the application layer.

Regulatory requirements do not stop at one layer, though. At the asset layer, the question is who may hold and transfer what. At the data layer, it is what information a transaction carries and who may read it. And then the operational layer remains. Who validates the chain matters too. A payments-only blockchain carries a requirement that its validator set consist of identifiable, regulated institutions. This is where it departs most sharply from permissionless general-purpose chains.

2.4 Five requirements

The demands a payment workload places on its infrastructure come down to five things.

1. Deterministic settlement: finality that never reverts, so authorization and settlement need not be separated
2. Predictable costs: fees that are predictable, with a stable ceiling
3. Guaranteed capacity under congestion: blockspace payments can always use, even when other activity fills blocks
4. Policy enforcement and confidentiality: transactions can stay private while issuer-defined controls and regulator audit access remain intact
5. Operational continuity: individual validator failures do not become a full service outage

3. Tempo's architecture: EVM compatible, specialized consensus

3.1 Tempo's execution layer

Tempo did not build a new execution layer. The EVM code, audit experience, and engineering skills that payment operators and stablecoin issuers already have remain valid here.

Tempo uses Reth, one of Ethereum's execution clients, for its execution layer, but it does not run a fork of Reth. Its dependency list pins about 50 Reth crates to a specific commit of Paradigm's upstream repository, and the Tempo node is assembled through the component builder that the Reth SDK provides (reth-node-builder).

Components like the transaction pool, the payload builder, and the executor are replaced with Tempo's own implementations, while the rest is used as is. REVM handles EVM execution and Alloy handles types and encoding. Because the dependency is a library, Tempo follows upstream Reth improvements by moving the pinned commit.

3.2 The two engines inside a Tempo node

A Tempo node runs as a single binary. This differs from the many EVM L1s that run a consensus engine and an execution client as separate, connected processes. When the process starts, the Reth node comes up first, then Commonware's runtime starts on a separate thread and runs the consensus stack.

The execution layer handles transaction pool management, payload construction, EVM execution, state storage, and JSON-RPC serving. The consensus layer handles the Simplex consensus engine, the epoch manager, the DKG manager, and validator-to-validator P2P. Two systems doing different jobs coexist in one process, which makes the boundary where they meet the important thing.

3.3 The boundary between consensus and execution

In a modular blockchain, the boundary between consensus and execution takes one of three broad forms.

• Ethereum separates the consensus client (CL) and the execution client (EL) into different processes connected by a JSON-RPC interface called the Engine API. This is a process boundary. The two clients can be developed independently and combined freely, which secures client diversity, but every interaction becomes an RPC call over a local socket.
• The Cosmos SDK family connects application logic to CometBFT through ABCI (Application Blockchain Interface). Every time the consensus engine calls the application, messages are serialized back and forth. This is a serialization boundary. The processes can be merged into one, but the interface stays fixed as a language-neutral protocol.
• In Tempo, consensus is a library inside the same process, so consensus and execution interact through function calls. That does not mean the Engine API was discarded. Tempo keeps the interface semantics and removes only the boundary. When a block is confirmed, the consensus stack calls fork_choice_updated on the execution node's engine handle, and when a new payload arrives it calls new_payload. These are the same kinds of messages an Ethereum CL sends to an EL, but they travel as function calls within one address space instead of JSON-RPC over a socket. From Reth's point of view, the consensus client has moved inside the process.

This boundary matters for two reasons.

The first is the precision of the latency budget. Tempo's target block time is 550ms. Setting aside 50ms as a propagation budget leaves 500ms for proposal handling and payload building. When its turn to propose arrives, consensus subtracts the time already spent, computes what remains, and passes it to the payload builder as a function argument. The builder then decides adaptively when to stop executing transactions within that budget. At sub-second block times, negotiating budgets at millisecond granularity across a process boundary is wasteful. Ethereum's Engine API was designed around 12-second slots, and with that much headroom the problem never needed solving.

The second is freedom to customize. Tempo's block header is an extended type that adds payment-specific fields to the standard Ethereum header (covered in chapter 6), and its transaction type is also its own. Because consensus and execution share one Rust type system, extensions land on both sides at once. Under ABCI this would be a serialization schema problem. Under the Engine API it would mean negotiating extensions to a standard interface.

The choice has costs. The fault isolation and client diversity that process separation provided are given up, and consensus and execution upgrades ship as a single unit. Chapter 7 returns to this trade-off in more detail.

3.4 Somewhere between general purpose and specialized

Tempo's execution environment is the same general-purpose EVM used everywhere. Its blockspace and transaction rules, however, are payment-specific. The header field that reserves blockspace for payments, stablecoin fees, and the payment transaction classification rules belong here (chapter 6). And its consensus and validator network are optimized separately around the finality and operational conditions payments demand (chapter 5).

That boundary makes Tempo hard to file under existing labels. Tempo is not an "EVM appchain." The word appchain suggests an application built on the default structure of a framework like the Cosmos SDK or the OP Stack, and Tempo has no such framework. It picked its consensus engine, dissemination layer, committee rotation, and key management as individual parts and assembled them into its own node. The parts box it used is Commonware. The next chapter looks at how Commonware differs from existing blockchain SDKs.

4. Commonware: a parts box for blockchains

4.1 How existing blockchain SDKs work

Teams building a new chain usually start from a framework. The Cosmos SDK provides an application skeleton with accounts, staking, and governance modules on top of CometBFT consensus. The OP Stack packages the standard composition of an Ethereum L2, and Substrate composes runtime modules called pallets. In general, the framework supplies the skeleton of the chain and the team fills in its logic at the designated spots.

The biggest advantage of a framework is speed. Starting from a proven base, a team can finish building a chain quickly. The cost begins the moment the chain's requirements leave the defaults. A framework fixes the list of what can be changed, and changes outside that list are hard. Changing the block structure or touching the consensus message flow are the classic examples.

The problem is that payment requirements mostly live outside that list. Putting a payment-only gas limit into the block header. Subtracting a propagation budget from the target block time and handing the rest to the payload builder. Rotating the validator committee with threshold signatures. None of these are things an existing framework makes easy.

4.2 Commonware's approach

Commonware was founded in 2024 by Patrick O'Grady, who built Rosetta (now the Coinbase Mesh API) at Coinbase. The team raised a $9 million seed round from Haun Ventures and Dragonfly and describes itself as an "anti-framework."

True to that label, Commonware provides no chain skeleton. It imposes no fixed layer structure and assumes no particular consensus protocol or security model. Block format, state structure, the definition of finality, the mempool, execution rules, fee policy: none of it is predetermined.

What Commonware provides instead is a set of primitives, each built to solve one problem. Authenticated P2P connections, consensus, data dissemination, storage, cryptography, and an async runtime each exist as an independent crate. As of February 2026 the library had 17 primitives, over 50 dialects, and 93% test coverage, and by the time of writing the primitive count has grown to 19. Everything is written in Rust and released as open source.

The relationship between primitives, crates, and dialects works like this.

• Primitive: a category of part responsible for one problem. Consensus, P2P, and storage are each a primitive.
• Crate: Rust's unit for distributing a library. Commonware ships one primitive as one crate (for example, the consensus primitive ships as the commonware-consensus crate).
• Dialect: the different implementations of the same problem that live inside a primitive, as modules within the crate.

The word dialect captures Commonware's character well. A dialect is an alternative implementation of the same problem. The simplex engine in the consensus primitive, for example, takes its certificate signing scheme as a plug-in. The signing scheme is not fixed by a framework. You plug in whichever of the available schemes fits the workload. Threshold Simplex, the variant Tempo runs, is not a separate protocol but the simplex engine with the BLS threshold scheme plugged in.

The runtime primitive shows how these parts work together. Every Commonware component runs on its own runtime that abstracts async execution, and the same code runs on both the production runtime and a deterministic simulation runtime. That means consensus code can be tested while simulating network delays and failures reproducibly.

4.3 The components Tempo uses

Tempo's dependency list includes 12 Commonware crates.

Tempo assembles these crates inside its own consensus crate. The Simplex engine and the DKG primitives come from Commonware, but the epoch manager and DKG manager that tie them together, along with the connection to the execution layer, are Tempo's own code.

4.4 What modularity means here

It is worth pinning down what modularity means in Commonware's case, because it differs from the "modular blockchain" of common discussion. The modular blockchain thesis splits DA, execution, and settlement across different chains or networks. That is modularity at the network level, and by that definition Tempo is hard to call a modular blockchain. Commonware's modularity is the replaceability of components inside the node software. Seen from outside, Tempo is a monolithic L1. Seen from inside, it is a modular node.

What this modularity buys is component-level customization. Workload-specific optimizations can happen at the level of individual parts, and each part can be benchmarked and upgraded independently.

In exchange, the integration work a framework would normally absorb lands on the chain's developers. With Commonware, the team designs how the parts work together, the operating model, and the failure conditions. The conditions under which consensus halts, the recovery procedure when a committee transition fails, the hardware and monitoring requirements for validators: all of it must be defined and built by the chain itself. That cost is not small.

Of all the parts Tempo picked from the Commonware box, the most important is consensus. The next chapter takes apart how Threshold Simplex delivers the first payment requirement, deterministic settlement.

5. The core of Tempo's consensus: Threshold Simplex BFT

5.1 The basic flow of Simplex: the lifecycle of a block

Simplex proceeds in views. Each view has one leader (leader election is covered in 5.5) and attempts to confirm one block. The lifecycle of a Tempo block looks like this.

1. The leader builds a block and broadcasts it as a notarize message. In Simplex, the proposal and the leader's own vote are the same message, not two separate ones.
2. Validators verify the proposal and broadcast their own notarize votes.
3. Once 2f+1 notarize votes arrive, a notarization certificate forms. The block is notarized and the network moves to the next view.
4. Alongside notarization, each validator broadcasts a finalize vote. Once 2f+1 arrive, a finalization certificate forms. From this point the block cannot be reverted.

If the leader goes silent or sends an invalid proposal, validators broadcast nullify votes on a timer. Once 2f+1 nullify votes arrive, a nullification certificate forms and the view moves on without confirming anything. There is no separate view change protocol. Nullification is the view change.

Counting hops, propagating the proposal is hop one and propagating notarize votes is hop two. A block is produced and the next view begins after just two hops. Finalize votes complete at hop three. Two hops to a block, three hops to finality, and three-hop finality is optimal in a partially synchronous network.

The implementation splits into four actors. The Batcher collects messages from other validators and defers signature verification until a quorum arrives, then verifies in one batch. The Voter runs the current view's voting. The Resolver fetches missing certificates from other nodes. The Application, which builds and verifies blocks, is what the integrator implements. All interactions between the four are non-blocking, so the Voter keeps processing messages even while the Application is verifying a proposed block.

5.2 Why notarization and finality are separate

Notarization certifies that the next view may proceed on this block. Finality certifies that the block's settlement is confirmed. Splitting the two creates a pipeline. View v+1 starts on v's notarization alone, while v's finalize votes accumulate independently behind it. Commonware calls this unchained finalization. Blocks are produced on a two-hop cadence and finality follows one beat behind.

Nullification acts as the safety mechanism. A finalized block can never be nullified. Both the finalization certificate and the nullification certificate require a 2f+1 quorum, so for both to exist in the same view, more than f+1 honest nodes would have to vote for both, and honest nodes do not do that. A nullification certificate is cryptographic proof that nothing was confirmed in the view, which lets the next leader safely re-propose the same block or build a new one.

What happens when the network slows down? Timers expire, views burn through nullifications, and the interval between blocks stretches. But only time is lost. Without a quorum no certificate of any kind can form, so no incorrect confirmation can happen. The BFT trade-off still applies, though. If more than a third of validators go offline, neither notarization nor nullification can form and the chain halts.

5.3 What differs from Tendermint

Tendermint, used across the Cosmos SDK world, and its implementation CometBFT confirm a height through three phases, propose, prevote, and precommit, and voting on height h+1 begins only after h is finalized. Block production itself is coupled to finality. Simplex uncouples them. In Commonware's phrasing, Simplex starts voting on the next height at the point where, in Tendermint terms, 2f+1 PREVOTEs exist but 2f+1 PRECOMMITs do not yet. Block production runs on two hops and finality on three, each on its own cadence, and that structure is why Simplex delivers faster block times.

The second difference is in failure handling. When a Tendermint round fails, the protocol falls back to a separate round-change mechanism. Simplex's nullify is a vote of the same shape as notarize and finalize, so the failure path uses the same message handling, the same quorum rule, and the same certificate format as the normal path. The protocol gets simpler, and recovering from a failed leader costs one ordinary voting round.

Many payment-focused L1s besides Tempo chose the Tendermint family. What separates Tempo from them is how many hops the same finality takes and how quickly the chain recovers when a leader fails. Tempo targets both block time and finality in the half-second range. Decoupling block production from finality is what makes Simplex structurally better suited to that goal.

5.4 Threshold BLS

As described in 4.2, Tempo plugs a BLS threshold signature scheme into the simplex engine. In the basic configuration, a certificate is a bundle of 2f+1 individual signatures. In the threshold scheme, each validator produces a partial signature with a signing share received through DKG (Distributed Key Generation), and 2f+1 partial signatures recover into a single threshold signature. The quorum is 2f+1 out of 3f+1.

The recovered certificate is about 240 bytes and verifies with a single BLS check against the committee's one static public key. Nobody needs to track who the validators are, how many there are, or when they changed. This property pays off outside consensus. Systems that need to confirm finality without running a node, such as custody platforms, bridges, or settlement attestations, can verify a block's confirmation from the certificate alone.

The cost moves into key management. Threshold signatures require an initial DKG, shares must be redistributed (resharing) whenever the committee changes, and a validator's key lifecycle shifts from keeping one key to managing a share that refreshes every epoch.

5.5 Leader election and MEV

In the vrf dialect Tempo uses, every vote carries one extra partial signature over the view, called an attestation. When 2f+1 arrive, a threshold signature called the seed is recovered, and the seed determines the next view's leader. Read straight from the code, the leader of view v+1 is the output of a random election (elector::Random) keyed on the seed signature inside v's certificate.

This design has two advantages. The next leader is unknown until the current view ends, so there is effectively no time to stage a DoS attack against a specific leader. And because the seed is itself a 2f+1 threshold signature, neither the leader nor a small coalition can bias its value.

It has limits as well. The seed is not safe as randomness consumed within the same view. With f Byzantine partial signatures plus f+1 honest ones, the value can leak before the view ends, so it is only sound for uses one beat later, such as electing the next leader. The same caution applies to MEV. Unpredictable leaders shrink the room for premeditated collusion or targeted attacks, but the leader still holds the power to order transactions within its own view. Randomized leader election mitigates MEV. It does not remove it. In Tempo's case, inclusion of payment transactions is guaranteed by the payment lane rules as a consensus validity condition (explained in chapter 6), so what remains is the profit that comes from ordering.

5.6 Separating consensus from block dissemination

Simplex votes on a block's digest, not the block itself. The broadcast primitive disseminates actual block data on a channel separate from consensus, and the resolver and marshal backfill missed blocks and certificates. The data path stays off the consensus critical path so that propagation delays for large blocks do not turn into voting delays.

This separation matters more for tail latency and failure recovery than for average throughput. Vote messages are small and fixed in shape, so consensus keeps a steady pace even when network load swings, and a node that falls behind catches up by fetching only the blocks it needs, using certificates as reference points. The Batcher's deferred batch verification follows the same logic. Instead of verifying signatures one at a time, it verifies in a single batch once quorum arrives, and if the batch fails it finds the bad signer by binary search and blocks that peer.

To sum up, Threshold Simplex BFT gives Tempo blocks roughly every 600ms against a 550ms target, with half-second deterministic finality and no reorgs. The moment a finalization certificate forms is the moment of settlement, so the split between authorization and settlement, and the exceptions that split pushes into accounting and dispute handling, disappear altogether.

6. Tempo's payment-specific features

6.1 The application defines the block

Commonware's consensus engine does not know what a block is. Simplex handles digests, and the format and validity of the block a digest points to are entirely the application's business, meaning code Tempo writes. What Tempo defines is the logic of which transactions are valid, how payloads are constructed, when EVM execution results are handed to consensus, and how the block time budget is allocated.

Tempo's block header is an extended type that prepends three fields to the standard Ethereum header: a gas ceiling for non-payment transactions (general_gas_limit), a gas limit for the subblock section (shared_gas_limit), and the millisecond-precision timestamp that sub-second blocks require.

The time budget works as chapter 3 described. From the 550ms target block time, 50ms goes to propagation, the remainder funds proposal handling and payload building, and the builder watches the remaining budget to decide when to stop executing transactions. The discipline of block time lives in application code, not in a consensus setting.

6.2 The payment lane: protecting blockspace with consensus rules

On a general-purpose chain, payment transactions compete for blockspace with NFT mints and liquidation waves. Tempo puts a ceiling called general_gas_limit on the gas that non-payment transactions can use, separate from the block's total gas limit. However much other traffic surges, it can only fill the block up to that ceiling, and the remaining capacity stays reserved for payment transactions. Unlike a priority mempool, this does not reorder anything. It limits the space general transactions can take, structurally leaving room for payments.

Making this work requires deciding quickly and reliably what counts as a payment transaction. Tempo classifies from the transaction payload alone, with no state lookups. It checks whether the call target sits in the TIP-20 address space (the 0x20c0 prefix) and whether the call shape matches the allowlist of payment functions, reading only bytes. Since no state is read, classification costs a constant amount, and there is no way to manipulate the classification by changing state.

What matters is that this classification rule is a consensus validity condition. A block that exceeds general_gas_limit with general transactions is invalid no matter who the leader is, and it cannot even be notarized, regardless of validator goodwill or mempool policy. Guaranteed capacity under congestion, one of the payment requirements, is delivered at the protocol level.

6.3 The fee model and fee sponsorship

On Tempo, gas fees and priority fees are paid in stablecoins. The eligible tokens are not fixed. Any USD-denominated native TIP-20 with sufficient liquidity in the Fee AMM qualifies.

The Fee AMM solves the problem of validators preferring different stablecoins. Whatever stablecoin the user pays with, the protocol converts it at a fixed rate into the validator's preferred token. When a user pays 1.0, the validator receives 0.9970 and liquidity providers take 0.3%. Conversions execute in per-block batches rather than per transaction, which shrinks the room for MEV attacks that target conversion timing.

The cost level itself is close to fixed. Instead of an Ethereum-style congestion auction, the base fee moves inside a band with a ceiling and a floor. For a standard transfer the ceiling is about $0.0006 and the quiet-time floor is about $0.00003, so a TIP-20 transfer stays under $0.001 regardless of network load. The payment lane guarantees capacity and the fee band guarantees price, which is what makes fees predictable.

Fee sponsorship is also supported. The sender signs the transaction and the fee payer signs over it in a separate signature domain, so a business can cover fees for users who hold no gas balance. Atomic call batching, parallel nonces, and scheduled execution all ship in a single EIP-2718 type called the Tempo transaction.

6.4 Policy enforcement: TIP-20 and TIP-403

A general-purpose chain cannot enforce rules the protocol does not know about. Application code written as smart contracts is exactly that kind of rule. Tempo instead writes control rules into the token standard itself. TIP-20 is Tempo's token standard with role-based access control (RBAC) built in. Minting and burning (the ISSUER role), pausing and unpausing transfers (the PAUSE/UNPAUSE roles), and compliance burns of blocked addresses' balances (the BURN_BLOCKED role) exist as standard powers. Features that used to be reimplemented contract by contract become, on Tempo, part of a standard the protocol defines.

The TIP-403 policy registry lifts these controls from the token level to the policy level. Whitelist and blacklist policies are registered in the registry at the protocol level, and multiple tokens reference the same policy. When jurisdiction rules change and the issuer updates a list, the change applies at once to every token using that policy. The problem of policies drifting apart token by token disappears structurally. Jurisdiction-specific requirements like Travel Rule compliance can also be built by combining these tools.

A control layered onto a contract depends on that contract being implemented well. A control written into the standard becomes a consensus rule of the chain. And since the call shapes that classify as payments are themselves defined by TIP-20's functions, policy enforcement and the payment lane end up following the same standard.

6.5 Tempo Zones: trading interoperability for privacy

What remains is the problem of a public ledger continuously leaking business information. Tempo Zones are parallel private execution environments connected to mainnet. Each zone is operated by a designated sequencer, and deposited funds are locked in the Zone Portal contract on mainnet. State transitions inside a zone are turned into validity proofs and verified on mainnet. The proof is generated by running a Rust state transition function in a ZKVM or a TEE, and the portal contract verifies it onchain at constant cost. Mainnet validators carry no burden beyond ordinary transaction execution.

Structurally, a Tempo Zone resembles an Ethereum ZK rollup. Funds lock in a parent-chain contract, a sequencer executes outside, and state transitions are verified on the parent chain in the form of proofs (in existing taxonomy it is closest to a validium, since data stays off the chain). The mechanics are similar but the purpose differs. A rollup moves execution out to scale throughput, and in exchange posts transaction data publicly to the parent chain, which lets anyone reconstruct the rollup's state. A zone moves data out for privacy and posts only the proof. Rollups are mainly about scalability. Tempo Zones are about privacy.

The sequencer's powers are limited to including and ordering valid transactions. It cannot steal funds or forge state, and issuer token policies are mirrored inside the zone with the proof committing to their enforcement. One power remains with the sequencer: censorship. It can delay a withdrawal by leaving it out, and the documentation describes no forced-withdrawal mechanism. Theft and forgery are impossible, but censorship is possible. That is the zone's exact trust model.

The privacy boundary is equally precise. From outside, balances, transfers, and history inside a zone are invisible to explorers and indexers, and only validity proofs can be observed. Running payroll or merchant settlement inside a zone solves the leakage problem. But this privacy is measured from the outside. The sequencer sees every transaction in its zone. What a zone provides is a system visible only to the operator and the transacting parties, about the level of confidentiality of a traditional payment processor's data access. The price of private transfers through zones is interoperability. Moving funds between a zone and mainnet, or between zones, goes through the portal and follows the proof generation cycle.

6.6 Other payment features

Tempo carries several more features built for payments. Transactions accept standardized memos that connect to corporate reconciliation processes (a design made with ISO 20022 compatibility in mind), and scheduled payments let recurring payroll or subscription billing run on an onchain schedule. Passkey (WebAuthn/P256) signing support lets transactions be signed with hardware security modules or a phone's biometric authentication, so payment businesses never need to hand users a seed phrase. The common thread is that these features help a payment operator reproduce its existing operating procedures onchain.

7. Trade-offs: what a specialized network gives up

7.1 What customization buys and costs

Using the five requirements from 2.4, compare Ethereum L2s, CometBFT-family EVM L1s, and Tempo.

It is no surprise that Tempo's column looks best. Tempo is a modular blockchain assembled and optimized for payments. The trade-offs are real, though. Here is what Tempo gives up.

• It does not inherit Ethereum's security, so security rests entirely on its own validator set.
• There is no standardized interoperability protocol like IBC, so external connections mean building bridges and certificate verification directly.
• Commonware is a young stack. There is no proven framework standard to lean on.
• Client diversity is structurally hard to achieve.

These are the price of optimizing the entire network for the single workload of payments.

7.2 The validators who run the network

From a regulatory standpoint, who validates the chain matters. Tempo's validator set is a permissioned whitelist managed by an onchain contract, and there is no staking. Tempo's anchor validators are Stripe, Visa, Zodia Custody (a Standard Chartered subsidiary), and MoneyGram, all institutions whose identities are known and who answer to financial regulators. When a payment operator has to explain to a regulator who runs the ledger, a roster of institutions that passed compliance review is a better answer than an anonymous set of nodes.

A small validator set also helps performance. The hop math in chapter 5 lands at half a second because a few high-performance nodes are linked over authenticated connections, and accountability in a failure is clear. Permissioned participation and limited geographic and jurisdictional diversity sit far from the ethos of a decentralized network, and judged by the standards of general-purpose chains, Tempo would not score well on censorship resistance.

Tempo's risk is therefore not an anonymous majority capturing consensus but identifiable institutions failing to meet their obligations. The right yardstick is closer to an interbank settlement network. Where Ethereum treats never halting as essential even if the chain forks, Tempo chooses to halt rather than be wrong.

7.3 Bottlenecks beyond throughput

Even with consensus at half a second, execution and state I/O remain. And a payment operator's real bottleneck is more likely reads than writes. This is why Tempo's recommended RPC node spec is higher than its validator spec. A payment service spends as much effort on state queries, webhooks, and checking onchain records against its own ledger as it does on submitting transactions. Judging a payment network requires the end-to-end pipeline including reads and reconciliation, not write TPS alone, and that bottleneck sits outside the consensus protocol.

7.4 Open questions

• The move to permissionless: Tempo says it will expand toward permissionless validation. But in Tempo's design, the per-epoch DKG cost grows as validators are added. Whether half-second finality and the DKG cycle hold together across a large, geographically distributed set has not been demonstrated. There is also no staking, hence no slashing, and misbehavior is punished through contracts and regulatory relationships outside the protocol. Whether that model is compatible with permissionless expansion is an open question.
• External use of threshold certificates: the 240-byte certificate verifiable without a node could serve as material for bridges and settlement attestations, but no standard consumes it yet.
• Evolution of the consensus itself: Commonware has already announced Minimmit, a successor protocol targeting lower latency. Because Commonware is a modular parts box, swapping the consensus engine is easier than on established chains. Tempo's consensus can move on from today's Threshold Simplex.

8. Closing: what it means to build a specialized system

Crypto started with a handful of cypherpunks dreaming of money beyond states and banks. The technology's main users are now changing. Governments and financial institutions are entering, and their entry point is payments. Institutions are laying payment rails on blockchains, each in its own way. Tempo, one of them, chose to reassemble the existing blockchain stack for payments alone. It kept the general-purpose execution environment and rebuilt consensus, blockspace, fees, and the token standard part by part around what payments require.

Tempo is plainly a centralized network, and by the standards of existing general-purpose chains it has shed most of what makes a blockchain feel like a blockchain. But the thing to focus on is not the centralization debate. It is how far the components of a conventional blockchain network can be redesigned to meet a specific requirement. And the arrival of parts boxes like the Commonware library Tempo adopted shows clearly that institutional networks demand customization down to the smallest details.

None of this means decentralization has stopped mattering. As specialized networks like Tempo onboard assets and mainstream users onchain, the value of the few networks with real censorship resistance and trustlessness will only rise. Even so, the performance given up for decentralization, and a censorship resistance that does not fit regulated environments, cannot carry institutional workloads like payments. The two kinds of networks are complements, not substitutes for each other. And Tempo is a strong example of the technical direction specialized blockchains are heading in.