Tempo, Arc and Base offer different routes for stablecoin payments. Compare the supported payment asset, gas funding, wallet integration and settlement policy for the same customer journey before ranking transaction fees.
Tempo and Arc place stablecoin payments near the center of their designs. Base is a broader Ethereum layer-two network with payment and agent infrastructure available around it. The comparison needs the complete route from the payer's balance to the recipient's usable funds.
I would start with a particular customer and payment asset. Which network can complete that transaction with the fewest operational dependencies and an acceptable settlement rule? That question is more useful than choosing a winner from advertised throughput.
Three networks, different starting points
Tempo's reference materials describe a blockchain designed for stablecoin payments, including the TIP-20 asset standard and a fee mechanism allowing supported dollar-denominated stablecoins to pay gas. Its payment tooling includes the ecosystem around MPP. Tempo implementation overview.
Arc describes stablecoin-native finance with USDC as the gas asset and an EVM-compatible development environment. Its documentation homepage announces mainnet live on September 16, while the gas reference still identifies its listed parameters as testnet configuration. Use the current production route for a fee quote rather than copying those reference values into a benchmark. Arc documentation, gas and fees.
Base uses the Ethereum rollup model. Its fees include execution and data-related costs, with the exact current fee model documented by the network. ETH is the gas asset for ordinary transactions, while wallet and payment services can sponsor or abstract that requirement for users. Base network fees.
These are architectural distinctions reviewed on October 13, 2026. They don't establish that every wallet, stablecoin or payment service is available on each route.
The fee asset changes the funding route
Compare the route the payer can actually use, including a wallet or sponsor.
The gas asset changes operations
For a user holding only a payment stablecoin, paying gas in another token adds a funding step. A sponsored wallet can hide that step, but an operator still needs a way to cover it and recover the cost.
Tempo's Fee AMM supports conversion between an accepted fee asset and the validator's preferred stablecoin under the design. An issuer or payment service should check eligible assets and liquidity rather than assume every stablecoin is accepted equally. Tempo fee design.
Arc's USDC-denominated gas makes the fee asset familiar to a USDC payment user. The service still has to estimate the actual gas consumption and price of its transaction. Stable denomination doesn't mean the fee is fixed or every contract call costs the same.
On Base, the relevant comparison can be the sponsored user route instead of an ordinary account sending raw transactions. That can deliver a smooth experience while adding dependence on the wallet or paymaster service. Coinbase Agentic Wallets.
Compare one payment across the full path
| Dimension | Tempo | Arc | Base |
|---|---|---|---|
| Network emphasis | Stablecoin payment-oriented blockchain | Stablecoin-native financial applications | Broad Ethereum L2 applications and payment tooling |
| Gas model to inspect | Supported USD-denominated TIP-20 fee assets and Fee AMM | USDC gas with network fee dynamics | ETH gas; sponsorship can change the user experience |
| Integration check | Token policy, fee liquidity, wallet and MPP support | USDC representation, current deployment and app tooling | Stablecoin deployment, wallet/paymaster and L2 route |
| Settlement check | Actual consensus and provider confirmation policy | Actual network finality and current RPC route | L2 inclusion, Ethereum-related finality and withdrawal route |
| Distribution question | Can the payer fund and use the selected stablecoin? | Can the payer reach USDC and the intended application? | Does the payer already use supported wallets and balances? |
The table intentionally excludes a live TPS or fee ranking. Comparing different transaction types or test environments would produce precise-looking figures with weak meaning.
Inclusion and finality answer different questions
A wallet can show a transaction quickly while the merchant follows a later acceptance rule. The application needs to define when it will release goods, API access or another financial asset.
For a rollup, distinguish the L2 transaction state from Ethereum-related settlement and a particular withdrawal process. A fast local confirmation and a canonical withdrawal deadline aren't competing measurements of one event. Base derivation and finality.
For a separate blockchain, inspect its consensus assumptions and the provider's confirmation policy. A deterministic-finality claim should be evaluated under the network's actual operating conditions rather than treated as a guarantee of uninterrupted service.
The merchant's risk depends on the transaction. Delivering a cheap cached response can tolerate a different acceptance policy from releasing a valuable asset. The service should state that policy and track pending outcomes.
Network fees aren't the full payment price
The payment can also involve conversion, a facilitator, a gateway and liquidity services. If the customer starts with funds on another chain, cross-chain movement adds a route with its own fees and failure states.
Tempo's gas parameter document describes a design target for standard payment transfers. A target in a specification isn't a quote for every production transaction. The same applies to Arc reference parameters that explicitly describe a testnet environment. Tempo gas parameters.
A useful comparison records the actual payment route, transfer size and services involved. Then it checks a normal quote and the conditions under which the quote changes. A contract action consuming more gas shouldn't be priced as a simple token transfer.
For tiny charges, settlement frequency can dominate the result. The micropayment economics article explains why batching can matter more than a small difference in chain fees.
Distribution can outweigh a technical edge
A customer with a funded wallet on one network has a practical advantage there. Moving it to another environment requires a reason strong enough to justify new funding and integration steps.
An issuer's native stablecoin deployment also differs from a representation backed by a bridge. Check which asset the recipient can redeem and through which route. A token called USDC in an unfamiliar contract shouldn't be accepted based on its name alone.
The same question applies to an agent. It needs supported credentials, a payment client and a budget policy. x402 vs MPP compares those programmatic payment paths. Neither protocol name establishes one mandatory blockchain.
For cross-chain transfers, our earlier infrastructure comparison examines the verification and delivery layer. It becomes relevant when the customer's funds aren't already where the merchant needs them.
Find who earns the fee
A stablecoin issuer, network operator and gateway can capture different parts of the transaction's economics. Payment volume shouldn't be assigned to a token without a mechanism connecting that activity to it.
Even when a network doesn't use a volatile native gas token in the user's experience, there can be infrastructure costs and commercial revenue elsewhere. The investment question needs a separate ledger identifying the beneficiary.
Our RWA value-capture framework applies here as well. Follow fees and actual allocation instead of treating transaction capacity as earnings.
Choose with a complete payment test
Begin with the customer's actual balance. Fund the wallet, buy the intended resource and make the recipient's proceeds usable. Record every service and wait state in that journey.
Repeat the test with sponsorship unavailable or one provider delayed. That shows the operating dependencies hidden by a clean demo. It also gives the merchant a realistic recovery plan.
Record the funding and recovery steps alongside the fee. Those are the parts the customer will experience when the clean demo ends.
Compare the amount the recipient can actually use
Take a fictional $10 payment. Route A costs $0.001 onchain but requires a $0.50 funding or conversion step. Route B costs $0.01 onchain and uses a balance the payer already holds. Before any other charges, those routes cost $0.501 and $0.01 respectively.
These figures do not describe Tempo, Arc or Base prices. They show why a network-fee ranking can reverse at the payment level. Record whether an extra step happens once per wallet or on every purchase, and whether the merchant can use the proceeds immediately or still needs another conversion.