Taiko Alethia is a based, Type-1 ZK-EVM rollup on Ethereum — sequencing is delegated to Ethereum L1 proposers (no separate sequencer set), and every batch is settled by SNARK validity proofs. Mainnet chain ID 167000, gas token ETH, and bytecode-equivalent execution so Solidity contracts work without modification. The protocol is open-source, with multiple independent client implementations and a roadmap to permissionless proposers and provers.
- 01Ethereum-equivalent ZK L2 with no centralized sequencer
- 02DeFi forks of mainnet protocols (no opcode caveats)
- 03research / public-goods deployments (open-source end-to-end)
- 04credibly-neutral L2 with L1 censorship-resistance properties
- pnpm add viem wagmi
| Variable | Scope | Description |
|---|---|---|
| NEXT_PUBLIC_TAIKO_RPC_URL | Client | Taiko Alethia RPC URL (mainnet: https://rpc.mainnet.taiko.xyz). |
| NEXT_PUBLIC_TAIKO_CHAIN_ID | Client | Chain ID — 167000 for Taiko Alethia mainnet, 167009 for Hekla testnet. |
Use viem's built-in `taiko` / `taikoHekla` chains (`import { taiko } from 'viem/chains'`) — chain ID 167000, gas token ETH, RPC `https://rpc.mainnet.taiko.xyz`. Because Taiko is Type-1 (Ethereum-equivalent), Foundry/Hardhat/Remix workflows are unchanged: `forge create --rpc-url $TAIKO_RPC ...` produces the same bytecode as on mainnet. Bridge ETH/ERC-20s via the canonical Taiko Bridge (`bridge.taiko.xyz`) — its on-chain protocol is the SignalService + Bridge contracts in `taikoxyz/taiko-mono`. There is no centralized sequencer: anyone running a proposer can include your tx by submitting a block to L1 (currently Shanghai-EVM, with a Shasta upgrade tracking newer Ethereum forks). Indexers The Graph, Goldsky, and Envio all support chain 167000.
- ⚑Taiko is currently pinned to the Shanghai EVM, not Cancun — `tload`/`tstore` (EIP-1153 transient storage), `mcopy` (EIP-5656), and blob-related opcodes do NOT work on Alethia mainnet until the Shasta hardfork lands. Contracts that compile against `cancun` will revert; pin Solidity `evm_version: shanghai` for Taiko deploys.
- ⚑Based-rollup sequencing means there is no fast `eth_sendRawTransaction` -> instant confirmation guarantee from Taiko itself — finality depends on whichever L1 proposer picks up the next slot. Median time-to-inclusion is fine, but tail latency is L1-bound (12s + reorg risk). Build UX around Ethereum slot times, not 1s L2 blocks.
- ⚑Withdrawals to L1 require the batch to be proven and finalized on L1 — typically a few hours under healthy prover load. For fast exits, route through Across/Stargate at the cost of bridge fees rather than waiting on the canonical bridge.
- ⚑Preconfirmations (preconfs) are an emerging feature — they give faster soft-confirmation UX but rely on a proposer's economic commitment, not protocol finality. Do NOT treat a preconf as final for high-value flows; wait for the L1-included block.
- ⚑Multi-prover / multi-client setup means upgrades and circuit changes ship more often than on a single-team rollup. Watch the `taikoxyz/taiko-mono` releases and re-test gas-sensitive code around hardforks.
- ⚑Bridged USDC on Taiko is not Circle-native CCTP at the canonical bridge today — Circle ships CCTP separately. Token-route logic that assumes one canonical USDC will mismatch between the bridged variant and CCTP USDC.