EVM Differences
Tempo is fully compatible with the Ethereum Virtual Machine (EVM), targeting the Osaka EVM hard fork. Developers can deploy and interact with smart contracts using the same tools, languages, and frameworks they use on Ethereum, such as Solidity, Foundry, and Hardhat. All Ethereum JSON-RPC methods work out of the box.
While the execution environment mirrors Ethereum's, Tempo introduces some differences optimized for payments, described below.
Wallet Differences
By default, all existing functionality will work for EVM-compatible wallets, with only a few quirks. For developers of wallets, we strongly encourage you to implement support for Tempo Transactions over regular EVM transactions. See the transaction differences for more.
Handling ETH (native token) Balance Checks
Remember that on Tempo, there is no native gas token.
Many wallets and applications check a user's "native account balance" before letting them complete some action. In this scenario, you might see an error message like "Insufficient balance".
This stems from the return value of the eth_getBalance RPC method. When a wallet calls this method, it expects a hex string representing the "native token balance", hard-coded to be represented as an 18-decimal place number.
On Tempo, the eth_getBalance method returns a hex string representing an extremely large number. Specifically it returns: 0x9612084f0316e0ebd5182f398e5195a51b5ca47667d4c9b26c9b26c9b26c9b2 which is represented in decimals as 4.242424242424242e+75.
Our recommendation to wallets and to applications using this method is to remove this balance check, and to not represent any "native balance" in your user's UI. This will allow users to complete actions without being blocked by balance checks.
We endorse this proposed ERC to standardize this behavior.
Specifying a Native Token Currency Symbol
Sometimes wallets will need to specify the currency symbol for the native token. On Tempo, there is no native token, but fees are denominated in USD. So, we recommend using the currency symbol "USD".
Transaction Differences
We strongly recommend using Tempo Transactions over legacy Ethereum transactions if you have control over the transaction submission, in order to leverage features like native gas sponsorship.
Dealing with the fee token selection
Tempo does not have a native gas token. Instead, fees are denominated in USD and fees can be paid in an stablecoin. For Tempo Transactions, the fee_token field can be set to any TIP-20 token, and fees are paid in that token.
If your transactions are not using Tempo Transactions, there is a cascading fee token selection algorithm that determines the default fee token based on the user's preferences and the contract being called.
This preference system is specified here in detail.
Consideration 1: Setting a user default fee token
As specified in the preference system above, the simplest way to specify the fee token for a user is to set the user default fee token. Read about how to do that here on behalf of an account.
Consideration 2: Paying fees in the TIP-20 contract being interacted with
If the user is calling a method on a TIP-20 token (e.g., transfer), the default fee token is that token itself. For example, if the user is calling the transfer method on a TIP-20 token with a symbol of "USDC", the default fee token would be "USDC".
Importantly, note that the amount field in this case is sent in full. So, if the user is calling the transfer method on a TIP-20 token with a symbol of "USDC" with the amount field set to 1000, the full amount of the token will be transferred and the sender's balance will be reduced by the amount spent in fees. So, the recipient will receive 1000 USDC.
Consideration 3: The fallback in the case of a non-TIP-20 contract
If the user is calling a contract that is not a TIP-20 token, the EVM transaction will default to the PathUSD token. Thus, in order to send transactions to non-TIP-20 contracts, the wallet must hold some balance of PathUSD.
On the Tempo Testnet, PathUSD is available from the faucet.
If a wallet wants to submit a non-TIP20 transaction without having to submit the above transaction, we recommend investing in using Tempo Transactions instead.
VM Layer Differences
At the VM layer, all opcodes are supported out of the box. Due to the lack of a native token, native token balance is always returning zero balances.
Balance Opcodes and RPC Methods
| Feature | Behavior on Tempo | Alternatives |
|---|---|---|
BALANCE and SELFBALANCE | Will always return 0 | Use TIP-20 balanceOf instead |
CALLVALUE | Will always return 0 | There is no alternative |
Consensus & Finality
Tempo uses Simplex BFT consensus with a permissioned validator set at launch, providing deterministic finality, unlike Ethereum's finality gadget which takes approximately 12 minutes.
Block times are targeted at ~0.5 seconds compared to Ethereum's ~12 second slots.