Linea's zkEVM is designed for high EVM equivalence, but it is not identical to the Ethereum Virtual Machine. The core distinction lies in the underlying proof system: Linea compiles EVM execution into a zero-knowledge proof, which imposes constraints on certain operations that are trivial on Ethereum. This results in a specific compatibility model where most opcodes and precompiles function identically, but a defined subset behaves differently, incurs different gas costs, or is unsupported. Developers migrating contracts must treat this not as a generic L2 deployment, but as a target with a unique execution profile that requires explicit verification.
Protocols
zkEVM Compatibility and Differences from Ethereum
Practical checklist of opcode, precompile, and gas behavior differences between the Linea zkEVM and the Ethereum EVM. Covers unsupported or partially supported EIPs, custom precompile addresses and their gas costs, and edge cases in BLOCKHASH, SELFDESTRUCT, and CREATE2 behavior.
introduction
COMPATIBILITY MODEL
Understanding Linea's zkEVM Compatibility
A practical analysis of opcode, precompile, and gas behavior differences between the Linea zkEVM and the Ethereum EVM.
Key areas of divergence include the BLOCKHASH opcode, which returns a non-cryptographic hash of the L2 block, and SELFDESTRUCT, whose behavior is altered to align with post-EIP-6780 semantics, effectively acting as a balance transfer without state deletion. Custom precompiles, such as the ecPairing precompile at a specific address, have gas costs that reflect the zk-circuit complexity rather than Ethereum's precompile pricing. Furthermore, gas metering for CREATE2 and certain hashing functions can differ, leading to situations where a contract that fits within Ethereum's block gas limit may exceed Linea's constraints, or vice versa. Relying on eth_estimateGas from a Linea node is essential, as static analysis based on Ethereum's yellow paper will be inaccurate.
For teams building on Linea, a compatibility audit is a prerequisite for safe deployment. This involves testing against the canonical list of unsupported EIPs, verifying custom precompile interactions, and fuzzing edge cases in gas consumption and state transitions. Chainscore Labs performs these targeted compatibility audits, ensuring that a codebase's reliance on specific EVM behavior is explicitly validated against the Linea zkEVM's execution model before any mainnet funds are at risk.
ZKEVM VS. EVM BEHAVIORAL DIFFERENCES
Compatibility Snapshot
A practical matrix of opcode, precompile, and state transition differences that affect contract execution on Linea compared to Ethereum mainnet.
| Area | What changes | Who is affected | Action |
|---|---|---|---|
BLOCKHASH opcode | Returns zero for blocks older than 256 due to zkEVM circuit constraints, not the L1 block hash. | DeFi protocols, gaming contracts using on-chain randomness. | Verify your contract does not rely on historical L1 block hashes for entropy or state proofs. |
SELFDESTRUCT opcode | Does not immediately delete state or refund gas; behaves like a send of the remaining balance to the target. | Contract factories, upgradeable proxy patterns, state-cleanup logic. | Audit contracts for reliance on post-selfdestruct state deletion or gas refund mechanics. |
CREATE2 behavior | Address derivation is identical, but contract deployment may fail if the initcode relies on unsupported precompiles. | Factory contracts, counterfactual address systems, wallet deployers. | Test deployment of all CREATE2-based contracts against the Linea testnet to catch initcode incompatibilities. |
Custom Precompiles | Linea adds precompiles at specific addresses for zk-friendly operations (e.g., EC arithmetic) with non-standard gas costs. | Privacy solutions, ZK-proof verifiers, advanced cryptographic libraries. | Do not assume Ethereum precompile gas costs; benchmark and adjust gas limits for Linea-specific precompiles. |
Gas Metering | Intrinsic gas costs and execution gas can differ from Ethereum due to the underlying zk-circuit cost model. | Wallets, dApps, and relayers estimating gas for user transactions. | Use |
Unsupported EIPs | Certain EIPs, particularly those modifying the EVM execution layer, may be partially supported or absent. | Protocols using new or niche EVM features from recent Ethereum hard forks. | Cross-reference your contract's Solidity version and EVM target with the official Linea EIP support list. |
Event Logs | Bloom filter behavior and | Indexers, subgraphs, and off-chain monitoring services. | Implement robust reorg-handling logic and verify log completeness against a Linea node, not just a public RPC. |
technical-context
ZKEVM OPCODE AND PRECOMPILE BEHAVIOR
Key Technical Divergences
A practical analysis of the specific opcode, precompile, and gas behavior differences between the Linea zkEVM and the canonical Ethereum EVM.
Linea's zkEVM aims for high compatibility with the Ethereum Virtual Machine, but the constraints of zero-knowledge proof generation introduce specific, unavoidable divergences. Developers migrating contracts to Linea must treat these not as bugs, but as a distinct execution environment. The most impactful differences cluster around opcodes that depend on L1 state or have dynamic, hard-to-prove behavior. For instance, the BLOCKHASH opcode on Linea returns a value derived from the L2 block, not the L1 block, and its accessible range may differ from Ethereum's 256-block window. Similarly, SELFDESTRUCT behavior is modified to align with the zkEVM's state model, potentially affecting contracts that rely on its exact gas refund or state-clearing mechanics.
Precompile support is another critical area of divergence. While standard precompiles like ecRecover, SHA2-256, and modexp are generally supported, their gas costs on Linea are calibrated for the zk-proving circuit, not the EVM's historical pricing. This can lead to unexpected gas consumption for operations that are cheap on Ethereum mainnet. Furthermore, Linea introduces custom precompiles at specific addresses to enable zk-friendly operations, such as efficient elliptic curve pairing checks or hash functions. A contract that uses CREATE2 will also encounter a different address derivation scheme if it interacts with these custom precompiles or relies on the exact bytecode hash, as the zkEVM's internal representation of bytecode may differ.
The operational impact for builders is a mandatory compatibility audit before deployment. A contract that passes all tests on a local Ethereum fork may still fail on Linea due to gas metering discrepancies or an unsupported edge case in a dynamic opcode. Wallets and indexers face integration challenges in correctly estimating gas and decoding transaction traces that involve custom precompiles. Chainscore Labs can perform a targeted compatibility review of your Solidity codebase, identifying these zkEVM-specific failure modes and recommending safe, provable alternatives to ensure a seamless mainnet launch.
IMPACT BY ROLE
Who Is Affected
Builders Migrating to Linea
Developers porting Solidity contracts must audit their codebase for unsupported or partially supported opcodes. Key risks include reliance on SELFDESTRUCT, BLOCKHASH edge cases, and CREATE2 behavior that may diverge from mainnet expectations. Custom precompiles on Linea have different addresses and gas costs, which can break hardcoded calls.
Action Steps:
- Run a compatibility audit against the Linea zkEVM specification.
- Replace
blockhashusage with a Linea-aware oracle if historical randomness is critical. - Verify gas estimation logic, as zkEVM metering differs from the EVM.
Chainscore Labs can perform a targeted compatibility audit of your codebase before deployment.
implementation-impact
ZKEVM COMPATIBILITY SURFACE
Integration Impact Areas
Practical impact areas where Linea's zkEVM diverges from the Ethereum EVM, requiring explicit attention from developers, auditors, and infrastructure operators before mainnet deployment.
02
Gas Estimation and Metering Divergence
The intrinsic gas cost model on Linea differs from Ethereum mainnet due to the interaction between L2 execution gas and L1 data availability costs. Standard RPC calls like eth_estimateGas can return values that are incompatible with wallets and dApps expecting mainnet-equivalent behavior, leading to stuck or reverting transactions. Integrators must implement custom gas limit buffers and priority fee logic. A transaction reliability review from Chainscore can validate your gas estimation strategy against Linea's specific metering rules.
03
CREATE2 and Contract Address Derivation
The address derivation for contracts deployed via CREATE2 can differ on Linea if the zkEVM's state representation or precompile behavior alters the input to the address formula. This creates a risk of contract address collision or mismatch when deploying the same bytecode across Ethereum and Linea, breaking cross-chain messaging and factory patterns. Teams deploying singleton contracts or using deterministic deployment proxies must verify address parity. Chainscore can validate your deployment scripts against Linea's specific derivation logic.
04
Event Log and Indexing Integrity
Linea's compressed block data format and potential reorg semantics during sequencer failover can cause indexers to miss or duplicate event logs. The bloom filter behavior and eth_getLogs performance may deviate from Ethereum, breaking subgraphs and off-chain monitoring services that assume mainnet-equivalent indexing guarantees. Data teams must build resilient event listeners that handle L2-specific edge cases. Chainscore Labs can review your indexing architecture for trust assumptions and failure modes.
05
Finality Model and Reorg Risk
The concept of finality on Linea is layered: soft confirmations from the sequencer, L2 block finality, and ultimate L1 settlement after proof verification. A reorg can occur during a sequencer failover or proof contestation, invalidating blocks that a service considered final. Exchanges, custodians, and bridges that credit users based on L2 confirmations alone risk double-spend losses. A finality-model impact assessment from Chainscore helps you define safe confirmation depth policies for your specific use case.
06
Account Abstraction and EntryPoint Behavior
Linea's native account abstraction features interact with the ERC-4337 EntryPoint contract in ways that can alter verification gas limits and paymaster behavior. The zkEVM's proof generation constraints may impose stricter limits on user operation validation than Ethereum mainnet, causing bundler rejections. Wallet SDKs and infrastructure providers must validate their 4337 integration against Linea's specific constraints. Chainscore offers integration validation to ensure your smart accounts function reliably on the network.
ZKEVM DEVIATIONS FROM ETHEREUM MAINNET
Compatibility Risk Matrix
Operational and integration risks arising from opcode, precompile, and gas behavior differences between the Linea zkEVM and the Ethereum EVM.
| Area | What changes | Who is affected | Action |
|---|---|---|---|
BLOCKHASH Opcode | Returns zero for blocks older than 256 due to zk-circuit constraints, not the L1 block hash. | DeFi protocols, bridges, and any contract using blockhash for randomness or historical verification. | Audit contracts for reliance on historical block hashes. Replace with L1 blockhash oracle or verify against canonical source. |
SELFDESTRUCT Opcode | Does not immediately delete state or refund gas. Behavior is equivalent to sending the balance without state cleanup. | Factory contracts, upgradeable proxies, and state-cleanup patterns. | Do not rely on SELFDESTRUCT for storage deletion or gas refunds. Refactor to use a controlled self-destruct pattern. |
Custom Precompiles | Linea-specific precompiles exist for zk-friendly operations (e.g., ecAdd, ecMul, ecPairing) with different gas costs. | Protocols using precompiles for signature verification, zero-knowledge proofs, or pairing checks. | Verify gas costs and input/output encoding against the Linea precompile specification before deployment. |
CREATE2 Behavior | Contract address derivation may differ in edge cases involving constructor arguments or initcode hashing. | Factory contracts, counterfactual address systems, and cross-chain deployment tools. | Test address derivation with target bytecode and salt on Linea testnet. Do not assume mainnet address parity. |
Gas Metering | Intrinsic gas costs and execution gas can differ from Ethereum due to zk-circuit pricing and L1 data cost amortization. | Wallets, dApps, and relayers estimating gas for transactions. | Use linea_estimateGas and test with buffer. Do not rely on eth_estimateGas parity with mainnet. |
EIP Support | Some EIPs are unsupported or partially supported, including those affecting opcodes, gas schedules, or state access. | Developers using newer Solidity versions or EIP-specific features. | Check the canonical list of supported EIPs for the target Linea release. Chainscore can perform a compatibility audit. |
State Trie Structure | Uses a zk-optimized sparse Merkle tree, not the Ethereum Merkle Patricia Trie. Affects state proof generation. | Bridges, light clients, and verifiers generating or validating state proofs. | Use Linea-specific proof formats and libraries. Do not assume Ethereum state proof compatibility. |
Transaction Receipts | Status field, logs, and cumulative gas may have structural differences in edge cases like precompile failures. | Indexers, subgraphs, and event listeners parsing transaction receipts. | Validate receipt parsing logic against Linea mainnet data. Chainscore can review your event-handling logic. |
ZKEVM COMPATIBILITY AUDIT
Developer Migration Checklist
A practical checklist for Solidity developers migrating contracts to Linea. Each item identifies a specific behavioral difference from Ethereum mainnet that can cause silent failures, unexpected reverts, or gas estimation errors. Teams should verify each item against their codebase before deployment.
The BLOCKHASH opcode on Linea returns the hash of the L2 block, not the L1 block. The block.number is the L2 block number, which increments faster than Ethereum mainnet. Any contract that relies on block.number for time-based calculations or that assumes a 12-second block time will behave incorrectly.
What to check:
- Search for all
blockhash()calls andblock.numberreferences. - Verify that any off-chain verification of block hashes uses the correct L2 block context.
- Replace
block.number-based timing withblock.timestampwhere possible, and adjust threshold constants for ~2-second block times.
Readiness signal: All time-dependent logic uses block.timestamp or has been recalibrated for Linea's block cadence. No contract relies on L1 block hash availability within the L2 execution environment.
resource-links
ZKEVM COMPATIBILITY REFERENCES
Canonical Resources
Use these resources to validate Linea zkEVM behavior against Ethereum expectations before deployment. Treat documentation, source code, and live-chain observations as complementary inputs, especially for opcode, precompile, gas, and finality-sensitive integrations.
Chains We Build On
Looking to build on a specific blockchain?
We build smart contracts, DeFi applications, wallets, tokenization platforms, and blockchain infrastructure across the major ecosystems teams choose today. That includes Ethereum, Arbitrum, Optimism, Polygon, Avalanche, Solana, Sui, Aptos, Hedera, Stellar, and NEAR, with support for additional EVM and non-EVM networks based on your product requirements.
EVM ecosystems
- Ethereum
- Arbitrum
- Optimism
- Polygon
- Avalanche
- Cronos
Non-EVM ecosystems
- Solana
- Sui
- Aptos
- Hedera
- Stellar
- NEAR
Additional ecosystems
- Polkadot
- Cosmos
- TON
- Cardano
- Algorand
- Tempo
Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.
ZKEVM COMPATIBILITY FAQ
Frequently Asked Questions
Common questions from Solidity developers and protocol architects migrating contracts to Linea. Covers opcode support, precompile behavior, and gas metering differences that can cause silent failures or unexpected reverts.
Linea's zkEVM aims for high compatibility but has known deviations. Teams must verify their codebase against the canonical list of supported opcodes.
Key areas to check:
- SELFDESTRUCT: Behavior may differ from Ethereum's post-Dencun semantics. Verify whether the opcode transfers balance and destroys bytecode as expected, or if it behaves as a no-op/send-only.
- BLOCKHASH: The range of accessible block hashes may be limited compared to the EVM's 256-block window. Contracts relying on historical block hashes for randomness or state proofs should be tested explicitly.
- CREATE2: Address derivation should match Ethereum, but gas metering for contract creation may differ. Verify deployed addresses against expected values in your test suite.
- SLOAD/SSTORE: Gas costs for state access are modeled differently in the zkEVM circuit. Contracts with dense storage layouts may encounter unexpected gas usage.
Action: Do not rely on opcode-level assumptions from Ethereum. Run your full test suite against Linea testnet and compare gas usage and return values. Chainscore Labs can perform a compatibility audit of your codebase before deployment.
Trusted by Industry Leaders
Delivering blockchain solutions for 5+ years.
We have partnered with 50+ leading DeFi protocols, NFT ecosystems, and fintech innovators to build secure, scalable, and capital-efficient blockchain products.
Selected Partners & Clients
“I've been working with Chainscore Labs for last 3+ years, they've consistently delivered with strong ownership across multiple projects. The team is reliable and detail-oriented.”
L
Lee Erswell
CEO, Telos Foundation
how to get started
How to get started?
If you're looking for blockchain integration, ChainScore Labs has 5+ years of experience helping teams build and integrate exchanges, wallets, smart contracts, tokenization solutions, and protocol-connected products, we can help you choose the right path, integrate securely, and get to production faster. Our team consists of experienced blockchain developers and architects who can help you with your blockchain integration needs.
01
Exploration & Strategy
Define your product goals and choose the right blockchain architecture for your use case.
02
Architecture & Design
Design the smart contracts, tokenomics, and security parameters of your system.
03
Development & Integration
Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.
04
Security & Launch
Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.
Explore More Solutions
Discover our
blockchain development services.
We build production-grade blockchain solutions for top-tier projects across DeFi and Web3.
Book a Call
Start a build
Need a blockchain engineering team?
Send the project context and we will respond with next steps, scope questions, and a practical path to delivery.