Tempo Architecture Analysis (1) — Tempo’s Account Abstraction

Introduction

Tempo is a payment-focused Layer 1 blockchain that was announced in September 2025 as a joint development by Stripe and Paradigm. It drew wide attention when it was revealed that leading engineering teams within Paradigm, along with well-known researchers and developers from the Ethereum ecosystem such as Dankrad and Liam Horne, were involved, and that the project raised a $500M Series A round at a $5B valuation.

In December 2025, Tempo launched its testnet, and many components of the blockchain they had been building were released as open source. The core components they are building consist of:

• A consensus layer based on technology of Commonware
• An execution layer based on Reth, designed to be friendly to Account Abstraction

Among these, the most notable area in the testnet launch was Tempo’s execution layer. The Reth team, which builds Ethereum L1/L2 execution clients, and Paradigm’s Ithaca team, which previously built the passkey-based smart account Porto, combined their accumulated experience to introduce several new features.

Currently, in addition to basic EVM functionality, Tempo provides the following custom features on its testnet:

• Support for modern signature schemes
• Fee sponsorship
• Batch transactions
• Gas fees paid in stablecoins
• A built-in stablecoin DEX
• A payment-only lane

In this series, we examine how these features are implemented technically, what their respective strengths and weaknesses are, what areas might be improved, and how they differ from Ethereum L1/L2, across the following two articles:

• Tempo Architecture Analysis (1) — Tempo’s Account Abstraction
• Tempo Architecture Analysis (2) — Stablecoin Gas and the Payment-Only Lane

In the first article of the series, we focus on “Tempo Transactions,” which abstract signatures, fee sponsorship, batch transactions, and more.

Tempo Transactions

Tempo supports all basic EVM transaction types, including legacy, EIP-1559, and access list transactions, and in addition introduces its own custom “Tempo Transactions.” Tempo Transactions are implemented following the EIP-2718 format and support a variety of additional features.

In this section, we look at the functionality of Tempo Transactions and how they differ from features that have existed on Ethereum.

1. Multiple Signature Algorithms

Tempo Transactions support the secp256k1 curve–based ECDSA signatures that have been the default in the EVM, while also natively supporting two additional signature algorithms at the protocol level.

The first is P-256 (secp256r1) curve–based ECDSA, a general-purpose signature scheme widely used in hardware security modules, Secure Enclaves, smart cards, and similar environments.

The second is WebAuthN signatures, which internally use P-256 but go beyond simple signing to include passkey-based authentication features such as user presence verification, origin binding, and anti-replay counters.

Tempo directly supports accounts that use these two signature schemes as native account types at the protocol level. In other words, it is possible to create Tempo addresses using authentication methods commonly used in Web2, such as passkeys.

In Tempo, users who want to use P-256– or WebAuthN-based accounts do not need to first generate a secp256k1 key. Instead, they can generate a P-256 key from the start, derive an address from it, and then create and send transactions that include P-256 ECDSA signatures or WebAuthN signatures generated by that key.

In the current Tempo testnet, there are also signs of attempts to support this by assuming Ethereum’s default secp256k1-based EOA structure and delegating accounts to P-256 or WebAuthN keys using mechanisms like EIP-7702. However, such approaches are structurally complex and increase the risk of bugs and additional security assumptions during implementation. Rather than taking this kind of indirect approach, Tempo appears to have chosen to reduce complexity and risk by designing the protocol itself to directly understand and verify these signature algorithms.

That said, there are also downsides to natively supporting WebAuthN. WebAuthN is designed with phishing resistance as its top priority, and therefore fundamentally assumes keys that are bound to a domain (RP ID) rather than being universal signing keys. This means that a passkey generated on a specific domain can only respond to signing requests originating from that domain, and cannot be used for requests from other domains. Applied directly to the Tempo ecosystem, this would mean, for example, that a passkey-based wallet created on example.com could only be used directly on example.com, and using the same passkey on example2.com would require creating a new wallet.

However, this issue is not necessarily unsolvable, nor is it clearly a problem in all cases.

In practice, the issue of “app accounts locked to a domain” has already been addressed through patterns that are widely used across the industry.

One of the most widely used passkey-based wallets in today’s blockchain ecosystem, the Base App (formerly Coinbase Wallet), is not confined to a single app or domain. Users can use the same account through the Base App to send transactions on applications hosted on other domains, such as Uniswap. When a passkey-based signing request is initiated from another domain, the system opens a popup for the domain associated with the passkey and performs the WebAuthN signature there. This structure is also commonly used in OAuth-style WebAuthN-based services such as “Sign in with Apple.” Therefore, if a service within the Tempo ecosystem wants users to reuse an existing passkey account across different services, supporting a popup-based authentication flow is sufficient to address the issue.

Furthermore, it is not realistic to assume that all services will necessarily prefer a shared, universal wallet. Looking at the user experience of everyday payment applications, most services encourage users to create app-specific accounts or balances. Once funds are accumulated within the app, the payment provider can generate revenue by depositing or managing those funds in various financial products. Payment apps built on Tempo are likely to have similar incentive structures. Given the nature of blockchain accounts, final ownership of funds remains with the user, but mechanisms such as session keys or delegated permissions could allow apps to manage a certain amount of funds on the user’s behalf. In other words, payment apps built on Tempo may prefer domain-bound, app-specific wallets over global wallets.

Overall, passkeys are rapidly replacing password-based logins across both financial and non-financial services, and Tempo’s decision to support this authentication method at the protocol-native level appears quite reasonable. While WebAuthN’s domain-binding property can be a constraint, it can be mitigated through popup-based authentication patterns and, in some cases, may even be advantageous from an app business perspective.

These passkey features are also supported on Ethereum. Although the protocol itself only supports secp256k1 curve–based ECDSA signatures, passkey signature precompiles (RIP-7212 / EIP-7951) are supported across L1 and L2, making it possible to build passkey-based wallets in the form of ERC-4337 smart accounts. The Base App mentioned above, as well as Ithaca’s Porto wallet, are examples of this approach.

2. Batch Transactions

Tempo Transactions include a so-called “batch transaction” feature, which allows multiple calls to be executed within a single transaction. By sequentially placing multiple calls into an array field called calls, the protocol bundles them into one transaction and executes them all together. This allows users to process multiple state changes with a single signature and a single transaction.

A representative use case for this feature is performing an ERC-20 token approval and swap in one go. In the existing EVM model, when using DeFi applications such as Uniswap, users typically have to follow a “two-step” process: first approving the token, and then executing the transfer or swap. With batch transactions, these two steps can be executed with a single signature. In addition, multiple payment transactions can also be bundled into a single transaction.

The same functionality also exists on Ethereum and is already used by major applications. After the Pectra upgrade, Ethereum supports EIP-7702, which allows code to be installed on accounts. When EIP-7702 code is installed by a wallet, batch-transaction-supporting logic is deployed directly to the user’s EOA account, enabling scenarios where approval → execution steps can be completed with a single confirmation, as shown below. This is one of the most representative use cases of EIP-7702.

The key difference between Tempo and Ethereum lies in whether the user needs to perform additional actions to enable batch calls. In the case of Tempo Transactions, batch calls can be made without extra steps such as installing code, which is required in the Ethereum ecosystem. This can be seen as a clear advantage.

3. Fee Sponsorship

Tempo Transactions also support gas fee sponsorship. A Tempo Transaction includes fields called fee_payer_signature and fee_token. By filling these fields with the appropriate information, gas fees can be paid by a different account.

The process works as follows. A user who wants their gas fees to be sponsored first constructs a transaction and then sends it to the sponsor (the fee payer) to obtain a signature over the transaction payload. When this signature is included in the fee_payer_signature field of the Tempo Transaction, the protocol deducts the gas fee from the sponsor’s account instead of the transaction sender’s account. In addition, by specifying fee_token, the transaction can indicate which token should be used to pay the sponsored fees.

Ethereum can provide a similar UX through ERC-4337 paymasters. However, there are some differences:

• ERC-4337 requires either a smart account compatible with ERC-4337 or an EOA with EIP-7702 code installed.
• Deploying a separate paymaster contract introduces additional gas and overhead.
• On the other hand, paymaster contracts allow for much more flexible and expressive logic.

In other words, Tempo Transactions may not offer the same level of flexibility as ERC-4337, but by abstracting fee sponsorship into the transaction type itself, they reduce both cost overhead and complexity.

4. Session Keys

Tempo Transactions include a field called key_authorization, which allows a portion of an account’s token usage authority to be delegated to another account. For example, a user could delegate the authority to manage a certain amount of USDC in their account to a specific bot.

The types of permissions that can be configured through Tempo Transactions include:

• Which tokens can be used
• The maximum amount of those tokens that can be spent
• When the permission expires (validity period)

This structure is particularly useful for implementing common payment models such as monthly or annual subscriptions. For example, if we assume a Netflix subscription built on Tempo, a user could use the key_authorization field to grant the Netflix account permission to spend “up to X USDC over the next year or several months.” Within the scope of this authorization, the service provider could execute monthly payments without requiring a separate user signature each time.

Conceptually, this feature is very similar to the “session key” model most widely used in ERC-4337. Session keys are also designed to avoid exposing full account authority while allowing only specific actions under constrained conditions. Functionally, the two approaches are almost identical. The key difference is that in Tempo, this permission delegation mechanism is provided natively at the transaction level, whereas in ERC-4337 it is achieved through smart accounts and custom logic.

5. Parallel Transactions

On Ethereum, when many transactions are sent in rapid succession, some transactions may fail to be processed properly depending on network or mempool conditions. This is because Ethereum manages transaction nonces per account as a single, strictly ordered sequence, and transactions must be processed in nonce order. If a transaction with a particular nonce remains in the mempool for a long time or is dropped due to network congestion, low gas fees, or propagation issues, all subsequent transactions are forced to wait until that nonce is processed. As a result, users may experience situations where some transactions appear to be “stuck,” even though multiple transactions have already been sent.

To mitigate this issue, Tempo Transactions introduce a so-called “two-dimensional nonce” structure. In Ethereum, a nonce is a single 64-bit integer that monotonically increases per account. In Tempo Transactions, an additional 256-bit “nonce key” is introduced. Even if the same nonce value is used, transactions with different nonce keys are treated by the protocol as belonging to different transaction sequences. This allows users to send multiple transactions in parallel by assigning different nonce keys, without running into nonce conflicts or ordering issues.

With this structure, even if one transaction is delayed or fails, other transactions using different nonce keys can be processed independently without being affected. As a result, a single account can operate multiple transaction streams in parallel, providing a much more stable UX for high-frequency transactions or scenarios involving multiple types of operations.

Furthermore, this nonce key is also used in Tempo’s “validator sub-block” structure. Beyond simple transaction ordering, it serves as a mechanism for more flexible separation and ordering of transactions during block production and validation. This aspect will be explained in more detail in the next article.

The concept of a two-dimensional nonce did not originate with Tempo. It was first introduced in ERC-4337, and later proposals such as RIP-7712 have discussed the possibility of including it natively in rollup environments and, in the long term, on the Ethereum mainnet itself. In that sense, this feature is conceptually shared between Tempo and Ethereum. The difference is that Tempo provides it as a default, protocol-level feature, whereas Ethereum is still in the stage of implementing it through standards proposals or higher-level abstractions. If proposals like RIP-7712 are eventually adopted by Ethereum, the two-dimensional nonce would have almost the same meaning and role in both systems.

Tempo Transactions vs. Ethereum Native AA: Which Direction Is “Right”?

To summarize, there is essentially nothing in Tempo Transactions that is a completely new concept. Batch calls, fee sponsorship, session keys, transaction validity windows, and similar features are all concepts that were already defined and used in ERC-4337; Tempo has simply brought them directly into the protocol. The key difference between the two approaches is not what is implemented, but where it is implemented.

ERC-4337 is a standard for implementing account abstraction outside the protocol. As a result, certain kinds of structural overhead are inevitable. Users must use smart accounts instead of traditional EOAs, and external actors such as bundlers and paymasters intervene in the transaction processing flow. This introduces additional external calls, increases latency, and gas costs are typically around 2–5× higher than standard EOA transactions. These costs and complexities can be seen as the price of the high flexibility and trustlessness that ERC-4337 aims to provide.

Against this backdrop, Ethereum has also continuously researched ways to move ERC-4337-like functionality into the protocol itself — i.e., “native account abstraction.” Early on, due to the complexity of introducing this directly into Ethereum L1, applying it first to rollups was discussed, and one outcome of that discussion was the rollup improvement proposal (RIP) known as RIP-7560. However, at the time RIP-7560 was proposed, many rollups were already sufficiently satisfied with ERC-4337 and did not want their execution behavior to diverge significantly from the main EVM, so the proposal was not adopted.

Afterwards, the Ethereum Foundation shifted its approach and chose a top-down strategy: introduce native account abstraction on L1 first, and then allow L2s to adopt it naturally. One result of this shift is EIP-7701. Like Tempo Transactions, EIP-7701 introduces a new transaction type, but its design goals and scope are much broader, because it aims to bring ERC-4337 itself into the protocol.

The most notable feature of EIP-7701 is its extremely high degree of flexibility in what it can support. Tempo Transactions, while supporting secp256k1-based ECDSA as well as P-256 and WebAuthN, still only support a limited set of signature algorithms. By contrast, with EIP-7701 it is theoretically possible to support any signature algorithm. One of Ethereum’s goals with EIP-7701 is to enable quantum-resistant signatures. Considering the possibility that the current default signature scheme (secp256k1) could be broken in a future where quantum computers become commercially viable, Ethereum’s view is that it may be more realistic to “smart-account-ify” all accounts and encourage the use of quantum-resistant signatures at the account level, rather than directly replacing the protocol’s base signature scheme. This kind of flexibility is difficult to achieve with Tempo Transactions as currently specified.

This extensibility is possible because ERC-4337 itself was designed with very high flexibility in mind. ERC-4337 is not limited to fee sponsorship or session keys; it aims to enable a wide range of account management and security scenarios in a trustless way, including social recovery, key rotation, multisig, conditional sponsorship, and more. In other words, Ethereum has chosen to build a general-purpose infrastructure that can cover as many use cases as possible.

Tempo Transactions, on the other hand, do not aim for that level of generality. Tempo focuses on a single, clearly defined use case — payments — and embeds only the features that are practically useful for that domain, in as simple a form as possible, directly into the protocol. As a result, the range of functionality it can express is narrower than ERC-4337 or EIP-7701, but overhead and complexity are reduced accordingly. From a system-design perspective aimed at achieving a specific purpose, this can be seen as a reasonable choice.

Ultimately, the question of EIP-7701 versus Tempo Transactions is not about what is “better” or “worse,” but about the scope of the problem each is trying to solve. If Ethereum’s goal is to build a general-purpose infrastructure that goes beyond payments and covers as many use cases as possible, then a structure like ERC-4337 or EIP-7701 — providing high flexibility in verification and execution — makes sense. Conversely, for a project like Tempo that is focused on a specific use case, especially improving payment UX and transaction UX, it may be more effective to keep EOAs as the center and natively extend only the necessary features, rather than adopting a complex smart-account model.

From this perspective, both Ethereum’s and Tempo’s choices are entirely reasonable decisions when you consider their respective goals and constraints, and it seems fair to say that each has made the best choice available given their situation.

Why Tempo Can Boldly Modify the EVM

Historically, there have already been many chains that modified the EVM. However, those chains paid a significant price for making changes: they also had to modify the entire set of developer tools used across the Ethereum ecosystem. As a result, developers who were used to building in the Ethereum environment had to reinstall and learn modified versions of tools like Hardhat, Foundry, and SDKs tailored to the new chain, which generally led to a worse developer experience. From an operational standpoint, maintaining those custom developer tools also required substantial manpower and time.

A common example is zkSync. When zkSync first launched its mainnet, it chose an architecture that imitated the EVM rather than implementing it faithfully, in order to maximize ZK efficiency. As a result, it did not achieve full EVM equivalence, and there were cases where contracts that worked normally on Ethereum caused unexpected issues (such as funds becoming stuck) when ported over unchanged.

At the time, developing smart contracts for zkSync required using zkSync-modified versions of Hardhat or Foundry. This was more than just “installing one more tool” — it meant that the overall development environment subtly differed from Ethereum, creating a barrier to entry. From the perspective of existing EVM developers, it was difficult to preserve their familiar development workflow, and this was inevitably perceived as a major inconvenience. Eventually, zkSync addressed the problem through later upgrades that moved toward full EVM equivalence.

In this context, Tempo arguably has a clear structural advantage. The Tempo team includes many engineers from Paradigm’s engineering teams — teams that have directly built some of the most widely used tooling in the Ethereum ecosystem today, including Foundry, wagmi, and viem. In other words, they can be seen as effectively “owning” the core tools that make up the developer experience on the EVM. Because of this background, Tempo has enough structural flexibility to make certain EVM changes while responding quickly in ways that prevent developer experience from degrading.

In fact, if you look at libraries like viem, you can see that shortly after the Tempo testnet was released, updates were made to support “Tempo’s version of the EVM.” This is an example showing how chain-level changes can be reflected naturally and quickly at the developer tooling level.

From this perspective, Tempo’s chosen approach to EVM modification can be evaluated as quite clever. Tempo did not add new opcodes. Changing or adding opcodes — the primitive operations that define EVM execution — typically requires changes not only to the runtime but also to language/compiler layers such as Solidity or Vyper. Since Tempo or the Paradigm teams are not organizations that “run” contract languages themselves, taking that approach would impose significant burden.

Instead, what Tempo added is not an opcode, but a new transaction type. This kind of change can preserve the language layer and be supported largely through developer libraries, meaning that developer experience can be improved without touching the broader language ecosystem. In other words, Tempo chose the smallest possible extension that still achieves the features it wants, without disturbing the language ecosystem.

Of course, one likely reason behind this choice is that, for their current goals, opcode changes or additions are not necessary. If Tempo later needs more fundamental EVM extensions, it could choose to fork Solidity or maintain a Tempo-specific language stack — but for now, it appears they judged there was no need to incur that cost.

Some people interpret these moves as “Paradigm is threatening Ethereum by controlling parts of the Ethereum stack,” but this is not really aligned with the facts. All Tempo-specific features added to tools like Foundry, wagmi, and viem are implemented so that they are enabled only via separate Tempo-specific flags, while existing development workflows targeting Ethereum L1 or L2 remain unchanged. In other words, Tempo support is merely an additional option, not an implementation that replaces the existing Ethereum ecosystem.

Overall, Tempo’s EVM modification strategy can be seen as a case where the team avoided the developer experience degradation that past EVM-variant chains suffered, and effectively implemented the functionality they needed based on a deep understanding of the developer ecosystem.

So far, we have examined the details of Tempo Transactions as Tempo’s implementation of account abstraction, the differences compared to Ethereum’s native account abstraction, and the respective strategies behind these approaches.

In the next article, we will take a closer look at Tempo’s native, payment-oriented features within the Tempo chain, including:

• PathUSD
• FeeAMM
• Payment-only lane
• Sub-blocks

and explore how these components are designed and used for payments on Tempo.