Tempo (the Stripe × Paradigm payment chain) and Ethereum both support gasless transactions, passkey logins, session keys, and batch calls. But the implementation gap between "protocol-native" and "application-layer bolted-on" is wider than you think.
Austin · Jadeofwallstreet
In September 2025, Stripe and Paradigm jointly announced Tempo a payment-focused Layer 1 blockchain. The team includes Ethereum researchers like @dankrad and @liamihorne, and the project raised a $500M Series A at a $5B valuation. Its December 2025 testnet launch revealed something genuinely interesting: a chain where nearly everything the Ethereum ecosystem has been bolting on top of ERC-4337 is just... built in.
I've been thinking about what this means for how I build @monipay_xyz on Base and BSC. Let's break it down feature by feature.
1. The Core Split
Before getting into specifics, you need to understand the structural difference between Tempo's AA and Ethereum's AA.
2. Passkey Login
This is where the UX gap is most visceral. The "sign in with Face ID" experience users expect from fintech apps requires P-256 or WebAuthN signatures and Ethereum's protocol only understands secp256k1.
Tempo
Tempo natively supports three signature types at the protocol level: standard secp256k1 ECDSA, P-256 (secp256r1) the curve used in Apple's Secure Enclave and most hardware security modules and WebAuthN, which adds passkey-specific features like user presence verification, origin binding, and anti-replay counters. A user can generate a P-256 key from scratch, derive a chain address from it, and start transacting. No secp256k1 key required. The protocol itself understands and verifies the signature.
Ethereum
Passkey support exists on Ethereum via the RIP-7212 precompile (P-256 verification), deployed across many major L2s. Projects like Coinbase's Base App (formerly Coinbase Wallet) and Paradigm's own Porto wallet have shipped passkey-based accounts but they're implemented as ERC-4337 smart accounts sitting on top of the precompile. You're deploying a contract to wrap the passkey logic. More attack surface, more deployment cost, more moving parts.
UX Impact: On Tempo, Face ID = native chain address, zero ceremony. On Ethereum/Base, Face ID = smart contract wallet deployment + passkey binding. The end result can look identical to the user, but the implementation burden on the developer is meaningfully different.
WebAuthN's domain-binding property (a passkey created on example.com can only respond to signing requests from example.com) is worth noting. Tempo's team acknowledges this but the standard mitigation (popup-based auth flows, as used in Sign-in with Apple and the Base App itself) is mature and widely deployed.
3. Batch Transactions
The "approve + swap in one click" pattern is the most visible AA feature in DeFi today. Currently on Ethereum, that two-step flow (approve ERC-20 allowance, then execute) is a constant UX tax.
Tempo
Tempo Transactions include a calls array field a list of sequential calls bundled into a single transaction at the protocol level. This is available to every account, on every transaction, by default. No setup required. Multiple payment disbursements, approve + transfer, any arbitrary call sequence one signature, one transaction.
Ethereum (post-Pectra)
EIP-7702, activated in the Pectra upgrade, allows code delegation to EOAs. When a wallet installs batch-call logic via EIP-7702, a user can execute approve → transfer in a single confirmation same UX as Tempo. But the key word is "when a wallet installs." The user needs to already have this delegation active, which means they either need to be on a compatible wallet, or the dApp needs to prompt for setup. Legacy wallets (non-upgraded MetaMask, Trust Wallet, raw EOAs) still require two transactions.
Tempo's batch calls work for everyone immediately. Ethereum's work for users who've opted into an EIP-7702 or ERC-4337 compatible wallet a meaningful but still incomplete slice of real users.
4. Gas Fee Sponsorship (Gasless Transactions)
This is arguably the biggest UX unlock in the whole AA stack. "The user shouldn't need to hold ETH to pay gas" it's obvious, and finally achievable. But the implementation path differs sharply.
Tempo
Tempo Transactions include fee_payer_signature and fee_token fields. To sponsor a user's gas: the user constructs their transaction, the sponsor signs the payload, the sponsor's signature goes in the fee_payer_signature field, and the protocol deducts gas from the sponsor. No contract needed. No bundler needed. The entire mechanic lives in the transaction format itself.
Ethereum
Ethereum achieves gas sponsorship through ERC-4337 paymasters smart contracts that contain logic for deciding whether to pay a user's gas. Paymasters are powerful: they can check allowlists, require payment in USDC, implement subscription checks, gate by transaction type, and more. But they require deployment, ongoing management, staking ETH in the EntryPoint, and integration with a bundler network (Pimlico, Alchemy, Gelato, etc.).
The Tradeoff: Tempo's model is cheaper and simpler. Ethereum's paymaster model is significantly more expressive you can build complex sponsor logic that Tempo's flat field structure can't encode. For a payments startup, Ethereum's model means more infrastructure to manage but also more control over sponsor policy.
5. Session Keys & Permission Delegation
This feature is closest to my heart as @monipay_xyz's founder, because it's the foundation @monibot is built on.
Session keys let a user pre-authorize an agent (a bot, an app, a smart contract) to spend a defined amount of a defined token within a defined time window without exposing the user's private key. Think: "authorize Netflix to charge me up to $15/month for the next 12 months in USDC."
Tempo
Tempo Transactions include a native key_authorization field. Users can specify: which token, maximum spend amount, and expiry time. This works for any account, any transaction, at the protocol level. Subscription payment use cases are first-class citizens of the transaction format.
Ethereum
Session keys on Ethereum require ERC-4337 smart accounts with custom session key modules (e.g., ZeroDev's Kernel, Biconomy's Nexus, or Safe with plugins). The user must be on a smart account. The session key logic must be encoded in the account's contract. This works well ZeroDev in particular has excellent session key infrastructure — but it requires your users to be on ERC-4337 smart accounts, which rules out any user who connected with a raw MetaMask or Trust Wallet EOA.
6. Parallel Transactions (2D Nonces)
An underappreciated problem for payment bots and high-frequency senders: Ethereum's nonce model is a single, strictly ordered sequence per account. If one transaction stalls or gets dropped from the mempool, every subsequent transaction from that address is blocked until it resolves.
Tempo
Tempo introduces a two-dimensional nonce: the standard 64-bit nonce plus a 256-bit "nonce key." Transactions with different nonce keys are treated as entirely independent sequences. A single account can run multiple transaction streams in parallel, and a stalled transaction in one stream doesn't block another.
Ethereum
ERC-4337 also supports multidimensional nonces, so smart account users get this capability. A proposal (RIP-7712) has been floated to bring it to rollup environments natively. But again default EOA users are still stuck with the linear nonce model.
7. The Summary Table
| Feature | Tempo | Ethereum / EVM L2 |
|---|---|---|
| Passkey / biometric auth | Protocol-native | RIP-7212 + smart account |
| Batch transactions | Default all accounts | EIP-7702 or smart account |
| Gas sponsorship | Built into tx format | ERC-4337 paymaster contract |
| Session keys | Native field | Smart account + modules |
| Parallel nonces | 2D nonce by default | ERC-4337 smart accounts |
| Sponsor logic flexibility | Low (opinionated fields) | High (full contract logic) |
| Infrastructure overhead | None, it's the protocol | Bundlers, paymasters, EntryPoint |
| Mainnet status (Mar 2026) | Mainnet live (Mar 2026), validator set still curated | Fully live, battle-tested, permissionless |
7.5 Tempo's Permissioned Reality
The testnet launched in December 2025 with four validators, all run by the Tempo team itself. The roadmap was always: Tempo-run validators, design partners, then permissionless. That middle stage is where things get interesting. Design partners are the companies Tempo hand-selected to build on the network and they include Deutsche Bank, Visa, Shopify, OpenAI, Revolut, Anthropic, Nubank, and Standard Chartered, with Mastercard, UBS, and Klarna added at testnet launch. These aren't random participants; they're institutional validators being onboarded in a controlled sequence before the network opens fully.
What this means in practice: Tempo mainnet is live, but validator participation is still curated. The network is not yet permissionless in the way Ethereum is, where anyone can run a validator with 32 ETH and join the set. Tempo's path to full decentralization runs through its design partner relationships first.
This isn't necessarily a flaw. Ethereum itself launched with a small trusted set before opening up. And Tempo's institutional partner list, Stripe, Visa, Mastercard, Deutsche Bank, is arguably the most credible validator bootstrapping roster in blockchain history. But it does mean that for now, Tempo's "zero infrastructure overhead" narrative comes with a catch: the chain itself is still in a managed growth phase. For an independent developer or a startup like MoniPay, you can build on Tempo, but you can't yet participate in its consensus the way you can on Ethereum. That distinction matters when you're thinking about long-term alignment and censorship resistance.
Building in the Ethereum AA world and what I'd gain on Tempo
MoniPay is live on Base and BSC today. That means I'm building in the Ethereum AA model — ERC-4337, EIP-7702, paymasters, bundlers. This isn't a limitation so much as a deliberate position: the Ethereum tooling ecosystem is years ahead of Tempo's, and Base in particular has the best USDC integration on any chain right now.
But reading Tempo's architecture honestly forces me to confront where the friction is in my stack, and what I'd get for free if the chains I build on had native AA.
Gasless UX Requires Infrastructure
For MoniPay users to send USDC without holding ETH, I need a paymaster. On Base that means integrating Pimlico, Alchemy Gas Manager, or Gelato Relay — or in my case building custom smart gas relayers and maintaining it. On Tempo, I'd just set a fee_payer_signature field. The end-user experience is identical; my operational overhead is not.
🤖 MoniBot Session Keys Require Smart Accounts
MoniBot's autonomous payment capability depends on session keys — delegating spend authority to the bot without exposing the user's private key. On Ethereum/Base, this requires users to be on ERC-4337 smart accounts (ZeroDev Kernel, Biconomy Nexus, etc.). Any user who connected with a raw EOA can't use this feature without an account upgrade. On Tempo, the key_authorization field is available to every account natively — MoniBot would work for everyone from day one.
🔀 MoniBot Concurrency Is Limited by Nonce Model
As MoniBot scales to handling many user transactions simultaneously, the linear EOA nonce model on Ethereum becomes a bottleneck. ERC-4337 smart accounts get around this — but it's another reason every MoniBot user needs a smart account, not just a raw EOA. Tempo's 2D nonce is default for every account.
🔑 Passkey Onboarding Is Achievable But Complex
The "sign up with Face ID" onboarding flow I want for MoniPay is possible on Base via RIP-7212 + a smart account wrapper. Projects like Porto and the Base App have shipped this. But it's still a smart account deployment — there's gas cost, there's contract complexity, and there's a dependency on the passkey-supporting wallet infrastructure. On Tempo, Face ID creates a native address directly.
The honest bottom line: Tempo is the blueprint for what AA-native payments infrastructure should look like. But it's permissioned, built by a $5B company from scratch, and it doesn't have stablecoin liquidity, ecosystem depth, or battle-tested paymaster tooling. For MoniPay today, building on Base is the right call — and the Ethereum AA tooling ecosystem (Pimlico, ZeroDev, Alchemy, Biconomy) is good enough to close most of the UX gap. But the gap is real, and Tempo's architecture is a useful measuring stick for where EVM chains need to evolve.
Every UX compromise I make today because "it requires a smart account" or "the user needs to hold ETH for gas" is a UX compromise Tempo would eliminate by default. That's a useful lens to build with.
08. Closing Thought
The deeper lesson from Tempo's architecture isn't "Tempo is better than Ethereum." It's that the Ethereum ecosystem chose a different philosophy: keep the base layer simple and maximally permissive, and let application-layer standards (ERC-4337, EIP-7702) handle the UX complexity. Tempo made the opposite bet — opinionated, payment-optimized defaults baked into the protocol.
Both bets are coherent. Ethereum's gives you flexibility and composability at the cost of infrastructure overhead. Tempo's gives you zero-overhead UX defaults at the cost of expressiveness and (currently) an unproven mainnet.
If you're building a payment product today, you're building on Ethereum tooling. But Tempo's architecture is the clearest picture we've had of what payment-native infrastructure actually looks like — and it should influence the standards we push for on EVM chains next.
Written by Jadeofwallstreet
#Tempo #Ethereum #AA #ERC4337 #MoniPay #Payments #AccountAbstraction
Originally published at blog.monipay.xyz
Top comments (0)