By Eco research. Updated Apr 2026.
​

ERC-7668 is an Ethereum Improvement Proposal that introduces an abstraction layer for EVM event logs, decoupling the log emission interface from the underlying storage mechanism. Under the current EVM design, every event emitted by a smart contract is stored in a transaction receipt using a fixed structure tied to Bloom filters and receipt tries. ERC-7668 proposes replacing this fixed structure with an interface that allows log storage and indexing to be customized per chain, enabling more efficient log indexing and native cross-chain log verification without changing the Solidity emit syntax that developers already use.
​

EVM event logs are produced by four opcodes (LOG0 through LOG3) that write entries into transaction receipts. Each entry contains the emitting contract's address, up to four 32-byte indexed topics, and an arbitrary-length data payload. Logs are stored in a Merkle Patricia Trie rooted at receipts_root in the block header, alongside a 2,048-bit Bloom filter for fast topic lookups.
​

This design has served Ethereum since the Frontier release in 2015. The LOG opcode implementations in the execution specs show the fixed path: emit a log struct, append to the transaction's log list, fold into the receipt. Indexers like The Graph and Ponder consume logs by querying an Ethereum node's eth_getLogs RPC endpoint, which scans the receipt trie for matching address and topic filters. The Graph network processed more than 700 million log queries in Q4 2025 per its own published indexing metrics, illustrating the scale at which log infrastructure operates.
​

The structural problem is that the log format is rigidly tied to the receipt encoding. A log emitted on Ethereum L1 cannot be natively verified on an L2 without a full receipt proof: a Merkle proof over the receipts trie, plus a proof of the block header. The Bloom filter format makes batch cross-chain log queries expensive. Receipt encoding also adds overhead for dense events like Uniswap V3's Swap logs; nodes serving eth_getLogs must traverse receipt data for every block in the requested range, a throughput bottleneck at high event density.
​

ERC-7668 inserts a configurable log handler between the LOG opcode and the receipt storage path. The handler must implement a standard emit(address, bytes32[], bytes) interface. A default handler preserves existing receipt-trie behavior; alternative handlers can route output to a Merkle tree for cross-chain proofs, a ring buffer for streaming, or a SNARK-friendly zkLog commitment. Existing Solidity contracts require no modification.
​

The ERC-7668 specification draft outlines three concrete changes to the execution environment. First, the LOG opcodes invoke the abstract log interface rather than writing directly to the receipt accumulator. Second, a default log handler preserving the existing receipt-trie behavior ensures backward compatibility for indexers that do not adopt the new interface. Third, alternative log handlers can be registered at the protocol level, allowing rollups or application-specific chains to direct log output to a structure better suited to their indexing or proof requirements.
​

Importantly, the Solidity emit keyword and ABI log encoding remain unchanged. A contract compiled before ERC-7668 will continue to function correctly on any ERC-7668-enabled chain; its LOG opcodes are simply routed through the default backward-compatible handler. This makes ERC-7668 a transparent upgrade for most application developers, with the benefits accruing primarily to indexers and cross-chain verification systems.
​

A Bloom filter is a 2,048-bit probabilistic structure in each Ethereum block header that tests whether a given address or topic appears anywhere in that block's logs without downloading all receipts. At today's event density, high-throughput contracts like Uniswap V3 saturate the block-level filter, forcing eth_getLogs to fall back to full receipt scans for nearly every query involving popular contracts.
​

A Uniswap V3 deployment on Ethereum mainnet generates roughly 50,000 to 100,000 Swap log events per day, per Dune Analytics Uniswap V3 event data as of Q1 2026. At that density, the block-level Bloom filter is saturated and near-useless as a pre-filter: almost every block tests positive for the Uniswap pool contract address, so eth_getLogs must fall back to full receipt traversal. ERC-7668 does not replace the logsBloom in the block header, which would require a base-layer hard fork, but it enables log handlers to maintain supplemental indexes, such as topic-specific Merkle trees, that are more efficient for dense log workloads.
​

The Bloom filter issue is well-documented. Light client libraries like ethers.js and viem expose warnings when getPastLogs queries span more than a few hundred blocks on mainnet because of the scan overhead. Alchemy and Infura cap block range parameters on eth_getLogs calls precisely because unrestricted receipt-trie scans can exhaust node resources. ERC-7668's pluggable storage model is the first protocol-level proposal to address this bottleneck from the emission side rather than the query side.
​

ERC-7668 enables custom log handlers that store events in structures optimized for cross-chain proofs. A binary Merkle tree log handler reduces verification gas by 10 to 20 times compared to the current Patricia Trie path, because verifiers iterate a fixed-size hash array rather than parsing variable-length nibble paths. Cross-chain bridge protocols that verify source-chain events benefit once their source chain deploys a Merkle log handler.
​

Under the current fixed receipt structure, verifying a log onchain on a destination chain requires a Merkle proof over the receipts_root Patricia trie. The receipts trie uses variable-length paths, making proofs larger and more gas-expensive than a simple binary Merkle tree. According to benchmarks from the Succinct Telepathy contracts, Patricia-trie receipt proof verification costs roughly 80,000 to 120,000 gas on a destination L2. A binary Merkle log handler under ERC-7668 could reduce this to 6,000 to 12,000 gas, a 10x reduction, because binary Merkle proofs use keccak256 with fixed-length inputs at each node. For background on how Merkle proofs work at the cryptographic level, see the cryptographic proof explainer.
​

ZK rollup teams benefit from a third handler variant: zkLog commitments using Poseidon or Pedersen hash trees. Verifying a log inclusion proof against a Poseidon-based commitment costs roughly 200 to 500 gas in a ZK circuit, compared to thousands for a Keccak-based Patricia-trie path. This makes zkLog handlers attractive for ZK rollups whose proof systems already use SNARK-friendly hash functions. Projects like Herodotus have built cross-chain receipt proof infrastructure that would benefit directly from a more prover-friendly log commitment scheme.
​

For Solidity and Vyper developers, ERC-7668 is a no-op: the emit keyword and event ABI are unchanged, and existing contracts function without modification on any ERC-7668-enabled chain. Impact concentrates in three groups: indexer operators gain more efficient log fetch paths, chain developers can select custom log storage at launch, and cross-chain protocol developers get cheaper proof verification once source chains deploy Merkle log handlers.
​

Indexer operators running The Graph nodes, Ponder, or Envio must update their log-fetching logic if they want to take advantage of custom handler indexes rather than relying solely on eth_getLogs. Chain developers building rollups or app-specific chains can register a custom log handler at chain initialization, selecting the storage format that best matches their indexing and proof requirements. Cross-chain protocol developers building bridges, intent settlement systems, or cross-chain oracle networks gain access to cheaper log proofs once the source chain's handler is optimized for proof generation.
​

Toolchain support is still early. As of Q1 2026, the ERC-7668 specification had not reached Final status in the EIP process. Ethereum execution-layer client teams (Geth, Nethermind, Besu, Erigon) had not published implementation timelines. Rollup teams with faster upgrade cycles, such as those built on the OP Stack, are more likely to be early adopters if the specification stabilizes in 2026.
​

Indexers are the primary near-term beneficiaries of ERC-7668. The current eth_getLogs bottleneck scales with block range and event density; querying Swap events across 10,000 Ethereum blocks takes 5 to 30 seconds on a public node. A custom log handler maintaining a topic-indexed Merkle tree can serve the same query in milliseconds, because its storage organizes events by topic rather than by block position.
​

The Graph's subgraph model already decouples event consumption from raw receipt scanning: subgraph processors stream events in real time and write derived state to a Postgres-backed store. ERC-7668 would let indexer nodes consume log data from a more efficient onchain commitment, reducing node-side computational load for dense event streams. Ponder published benchmarks in early 2026 showing that receipt-scan throughput limits index catchup speed for contracts with more than 1,000 events per block, which is precisely the workload ERC-7668 targets.
​

For cross-chain indexers aggregating events from multiple chains, ERC-7668's pluggable storage model enables a standardized log commitment interface across rollups. Rather than maintaining chain-specific adapters for each chain's receipt encoding quirks, a multi-chain indexer could query a single abstract log interface on any ERC-7668-enabled chain. This is especially relevant for cross-chain DeFi applications that aggregate Swap or Transfer events from Arbitrum, Base, and Optimism to construct a unified view of protocol activity.
​

No. The ERC-7668 specification requires a default log handler that preserves the existing receipt-trie format. Existing contracts using emit and LOG opcodes continue to function without modification. Indexers relying on eth_getLogs continue to work against the default handler on any ERC-7668-enabled chain. The abstraction is in the execution environment, not in the contract language or ABI.
​

ERC-7668 does not replace bridges; it reduces the gas cost of log-based proof verification, which is one component of bridge security models. Bridges that settle by verifying event receipts from a source chain would benefit from cheaper verification once source chains adopt a Merkle log handler. The trust model is unchanged. See the cryptographic proof article for how Merkle proofs underpin bridge security.
​

App-specific rollups and new chain deployments are the most likely early adopters, because they can select their log handler at chain initialization without a disruptive hard fork. General-purpose L2s built on the OP Stack or Polygon CDK could adopt ERC-7668 as a network upgrade if the specification finalizes in 2026. Ethereum mainnet adoption would require broad consensus across all client teams and is unlikely before the specification reaches Final status.
​

No. ERC-7668 adds a log storage abstraction layer; it does not modify the block header format. The logsBloom field is defined at the consensus layer and would require a separate hard fork to remove. ERC-7668 enables supplemental indexing structures on top of the existing Bloom-filter-based system, not a replacement of it.
​

A zkLog commitment handler accumulates log entries into a SNARK-friendly Poseidon or Pedersen hash tree. Verifying a log inclusion proof against a Poseidon tree costs roughly 200 to 500 gas inside a ZK circuit, versus thousands for a Keccak-based Patricia-trie path. This makes zkLog handlers valuable for ZK rollups whose proof systems already use SNARK-friendly hash functions, since the log verification circuit adds minimal prover overhead.
​

Sources and methodology. ERC-7668 specification reviewed from eips.ethereum.org, April 2026. LOG opcode behavior verified against the Ethereum execution-specs repository. Gas benchmarks for Patricia-trie proof verification sourced from the Succinct Telepathy contracts repository. Uniswap V3 event volume from Dune Analytics as of Q1 2026. Specification status and client implementation timelines as of Q1 2026.
​

Eco Routes handles stablecoin transfers across 15 chains. As cross-chain event verification becomes cheaper through ERC-7668 Merkle log handlers, the intent-settlement and bridge verification steps that underpin cross-chain routing will operate at lower gas cost, directly benefiting protocols that rely on log-based finality signals from source chains.
​