Differences from Ethereum

Key differences between Taiko and Ethereum that affect smart contract development.

EVM Version: Shanghai

Taiko runs the Shanghai EVM. Cancun opcodes are not available:

Opcode	Status
`TSTORE`	Not available
`TLOAD`	Not available
`MCOPY`	Not available
`BLOBHASH`	Not available
`BLOBBASEFEE`	Not available

Solidity 0.8.24+ defaults to Cancun. Deploying with default settings causes runtime reverts on Taiko. Set the EVM version explicitly.

Foundry Configuration

Add a [profile.taiko] section to foundry.toml:

[profile.taiko]
evm_version = "shanghai"

Then compile and deploy with:

FOUNDRY_PROFILE=taiko forge build
FOUNDRY_PROFILE=taiko forge script ...

Hardhat Configuration

Set evmVersion in your Hardhat config:

module.exports = {
  solidity: {
    version: "0.8.27",
    settings: {
      evmVersion: "shanghai",
    },
  },
}

Impact on OpenZeppelin v5

OpenZeppelin Contracts v5 uses transient storage (TSTORE/TLOAD) in the ReentrancyGuard and other contracts. Use OpenZeppelin v4 or pin to v5 releases that support Shanghai-compatible fallbacks.

No Centralized Sequencer

Taiko is a based rollup -- L1 Ethereum validators sequence blocks. There is no centralized sequencer.

Blocks are proposed by whitelisted proposers through preconfirmation infrastructure.
Anyone can force-include transactions via the ForcedInclusionStore contract on L1.
Transaction ordering follows L1 inclusion order.

Block Time

Taiko produces blocks every 2 seconds, with 1-second block times coming soon. Block timing is driven by based preconfirmations anchored to L1 inclusion, so don't hardcode exact intervals.

Proving System

Taiko uses a multi-proof system requiring multiple independent proof types to agree on every state transition:

Proof Type	Description
SGX (Reth)	TEE-based attestation, Rust client
SGX (Geth)	TEE-based attestation, Go client
ZK (RISC0)	RISC Zero zkVM proof
ZK (SP1)	Succinct SP1 proof

Every batch requires proofs from at least two independent proof systems.
The ComposeVerifier contract orchestrates verification across sub-verifiers.
This provides both proof diversity and client diversity, reducing correlated failure risk.

Gas and Fee Model

Taiko uses EIP-1559 for L2 gas pricing.
L1 data costs apply for calldata posted to Ethereum.
No L1 blob fees (since BLOBBASEFEE is unavailable on Taiko L2 itself).

Account Abstraction (ERC-4337)

Taiko supports ERC-4337 account abstraction, enabling smart contract wallets, gas sponsorship, batched user operations, and custom authentication flows.

The singleton EntryPoint contract is deployed on Taiko mainnet at:

0x4337084D9E255Ff0702461CF8895CE9E3b5Ff108

Because Taiko is Ethereum-equivalent, standard ERC-4337 tooling (bundlers, paymasters, wallet SDKs) works without modification. Point your bundler at the Taiko RPC and configure the EntryPoint address above. See Contract Addresses for a full list of deployed contracts.

Execution Engine Diff

For a complete list of modifications to go-ethereum, see the taiko-geth diff:

https://geth.taiko.xyz/