By Eco research. Updated April 2026.
​

REMOTESTATICCALL is a proposed EVM opcode or precompile that would allow a smart contract on one chain to read state from a contract on a different chain, without executing a bridging transaction or relying on a trusted oracle. The concept extends the existing STATICCALL opcode, which performs a read-only local call, into the cross-chain dimension: a contract on Arbitrum could call a view function on a contract on Ethereum mainnet and receive the result as part of its own execution. No standard EIP has reached final status as of April 2026, but the design space is actively explored by EVM researchers and cross-chain protocol teams.
​

A static call (STATICCALL) is a read-only EVM message call that prevents the callee from modifying state, emitting events, or calling state-mutating functions. Introduced in Ethereum in EIP-214, STATICCALL is used for all view and pure function calls. It is the foundation of eth_call at the JSON-RPC layer. Because a static call cannot modify state, it costs no ETH to execute off-chain (in an eth_call simulation), though it does consume gas in onchain contexts where it is called from another contract.
​

STATICCALL takes a target address, call data (ABI-encoded function selector and arguments), and a gas limit, and returns the call's return data. The restriction that the callee cannot write state makes STATICCALL safe to use in any context where a developer needs to read contract state or compute a value from onchain data without creating side effects. Solidity's view modifier compiles to STATICCALL when a view function is called externally from another contract.
​

The limitation of STATICCALL is locality: it can only call contracts on the same chain. A DeFi protocol on Arbitrum cannot natively query the TVL of its Ethereum mainnet counterpart, the token supply on Base, or the governance vote totals on Optimism. Cross-chain reads today require external infrastructure, adding trust assumptions that a native opcode would eliminate.
​

REMOTESTATICCALL extends the STATICCALL semantics to a remote chain by specifying a chain ID as an additional parameter. In the most common design proposal, the opcode takes four inputs: chain ID, target contract address, call data, and a block tag (specifying which block's state to read against). The EVM then either halts execution and waits for a proof from the target chain's state (a synchronous design, which stalls the block builder), or batches the remote reads for asynchronous resolution in a future block (an asynchronous design that introduces latency but does not block execution).
​

The synchronous design resembles the existing CALL opcode's behavior: execution pauses, the remote state is fetched, and execution resumes with the result. This is simple for developers but requires either a very short block time on both chains (sub-second, as on some L2s) or an out-of-band proof relay system that the block builder can query synchronously. The asynchronous design is more complex at the application level but more realistic for chains with 12-second mainnet block times: the contract emits a "remote read request" in one transaction, and a future transaction delivers the result into a callback function, similar to Chainlink's request-response model for VRF and price feeds.
​

Proof of correctness for the remote state requires one of two mechanisms: a trust-minimized light client (the calling chain runs a light client for the target chain, verifying block headers and Merkle proofs), or a storage proof submitted by a third-party relayer and verified by a precompile. The storage proof approach is how the use case is handled today without a native opcode, using protocols like Axiom, Herodotus, and Lagrange. A native REMOTESTATICCALL precompile would internalize the proof verification step into the EVM itself, removing the need for application developers to integrate an external proving SDK.
​

Storage proofs allow a contract on Chain B to verify a specific value from Chain A's state without trusting any intermediary, by submitting a cryptographic proof that the value was included in Chain A's state trie at a specific block. The Ethereum state trie is a Merkle Patricia Trie (MPT); every account and storage slot is reachable by a Merkle proof from the block's state root. A storage proof for a specific slot contains the path from the state root down to the leaf, and any contract that has access to Chain A's state root can verify it.
​

The challenge is getting Chain A's state root onto Chain B in a trust-minimized way. Several approaches exist:

The storage proofs explainer covers the Merkle Patricia Trie structure and proof verification mechanics in detail. REMOTESTATICCALL is the long-term proposal to make this capability native to the EVM rather than requiring application-level integration with a proving protocol.
​

An EVM precompile is a built-in contract at a reserved address that executes outside the EVM interpreter, typically implemented in the execution client's host language for efficiency. Existing precompiles handle operations like elliptic curve arithmetic (ecrecover at address 0x01, bn128 pairing at address 0x08) and SHA-256 hashing (at address 0x02) that would be too gas-expensive to implement in EVM bytecode. A REMOTESTATICCALL precompile would follow the same pattern: a contract calls the precompile address with the target chain ID, contract address, and call data, and the precompile returns the result after verifying the proof.
​

The advantage of the precompile approach over a new opcode is forward compatibility: precompiles can be added to existing EVM versions without modifying the opcode table or breaking existing tooling. EIP-7212, which added secp256r1 curve support as precompile 0x100, used this pattern and was activated on Ethereum in the Pectra upgrade (scheduled for 2025). A REMOTESTATICCALL precompile could similarly be proposed as an EIP specifying a reserved address, the expected call ABI, and the proof verification algorithm.
​

Several design questions remain unresolved in public discussions. First, which proof system should the precompile accept? Requiring Merkle proofs limits the precompile to chains with accessible state tries (all EVM chains) but may be too slow for some use cases. Accepting ZK proofs is faster to verify but requires committing to a specific proving system. Second, who pays for the proof generation? Off-chain relayers who generate proofs must be compensated, which reintroduces an external dependency. Third, how does the precompile handle finality? A storage proof for a block that is later reorganized out of the canonical chain would return a value that no longer exists in the canonical state.
​

Cross-chain governance, oracle-free data reads, and cross-chain identity verification are the three highest-value use cases identified in public design discussions.
​

Cross-chain governance is particularly well-suited to REMOTESTATICCALL because it is a read-heavy operation (count votes on multiple chains) that does not require moving funds. Uniswap's 2023 expansion to multiple L2s created immediate demand for a mechanism to count UNI votes across Ethereum mainnet, Arbitrum, and Optimism before finalizing governance proposals. The current approach bridges votes using LayerZero's cross-chain messaging, which adds a trust assumption on the LayerZero message validation layer. A REMOTESTATICCALL that reads L2 vote balances with storage proof verification would eliminate that trust assumption.
​

Oracle-free price reads would allow DeFi protocols to use onchain AMM prices from other chains as inputs, rather than relying on oracle networks like Chainlink. Uniswap v3's time-weighted average price (TWAP) oracle is manipulation-resistant over longer windows because manipulating it requires holding an unfavorable position for the entire averaging window. Reading a Uniswap v3 TWAP from Ethereum mainnet into a contract on Arbitrum via REMOTESTATICCALL would give the Arbitrum contract access to Ethereum's deeper liquidity for pricing without any oracle intermediary.
​

Cross-chain identity use cases include reading an Ethereum mainnet ENS name into an L2 contract, verifying an onchain credit score from one chain within a lending protocol on another, or checking whether an address holds a specific NFT (like a governance badge or soulbound token) on the canonical chain without bridging the NFT. The cross-chain communication overview covers the broader interoperability landscape that REMOTESTATICCALL fits within.
​

REMOTESTATICCALL, if standardized, would eliminate the need for a trusted data delivery layer in the specific use case of cross-chain state reads. It does not replace bridging for asset transfers (which require lock/mint or burn/mint mechanics that inherently involve state changes on two chains) or cross-chain message passing (which requires a two-way protocol to execute code on the destination chain). The distinction is important: REMOTESTATICCALL is a read primitive, not a write primitive.
​

In the current cross-chain infrastructure stack, read operations and write operations are often bundled together in bridge protocols that support both. Wormhole, LayerZero, and Hyperlane all offer cross-chain messaging that can carry both data queries and execution instructions in the same message. A native read opcode would let protocols decouple these two concerns: use REMOTESTATICCALL for state reads (trust-minimized, no bridge fee, synchronous execution) and use a messaging bridge only for cross-chain execution instructions that require the destination chain to act.
​

Eco's cross-chain routing and settlement infrastructure currently uses Hyperlane for verified message passing across supported chains. A future where REMOTESTATICCALL is standardized would allow Eco's onchain contracts to verify cross-chain state (such as whether a settlement has been confirmed on the destination chain) without a separate message, reducing the round trips required for some settlement patterns. For the current architecture, storage proofs provide a trust-minimized alternative for state verification use cases that cannot wait for a native EVM opcode.
​

No REMOTESTATICCALL EIP has reached final status as of April 2026. The concept appears in Ethereum research discussions and in proposals from cross-chain protocol teams, but the consensus design questions (synchronous vs. asynchronous execution, proof system, finality handling) have not been resolved. The Ethereum Magicians forum and ethresear.ch host ongoing discussions about cross-chain execution primitives, and several research teams including those working on the Ethereum interoperability roadmap have identified native cross-chain reads as a long-term goal.
​

The closest implemented analogs are application-layer storage proof protocols. Herodotus provides storage proof verification infrastructure on Starknet and Ethereum. Axiom (acquired and integrated into Brevis in 2024) built ZK proof-based historical state queries on Ethereum. Lagrange offers verifiable computation over cross-chain state using ZK coprocessors. These projects demonstrate the demand and technical feasibility of the underlying capability, even without a native EVM opcode.
​

The Ethereum Foundation's roadmap discussion around the "Surge" phase (focused on L2 scalability) and "Splurge" phase (EVM improvements) includes primitives to improve L1-L2 and L2-L2 communication. Native cross-chain state reads fit naturally into the Splurge phase, where EVM improvements are discussed, but there is no confirmed EIP number or hardfork assignment for REMOTESTATICCALL as of April 2026.
​

No. A cross-chain message (sent via LayerZero, Hyperlane, or Wormhole) executes code on the destination chain, which requires both chains to act. REMOTESTATICCALL only reads state from the remote chain without executing code there. It is a read-only operation, similar to the existing STATICCALL opcode but extended to a different chain's state.
​

No standard EIP or mainnet implementation exists as of April 2026. Application-layer storage proof protocols like Herodotus achieve the same result using verifiable state proofs submitted by off-chain relayers, but these require integrating an external SDK and do not expose a native EVM opcode or precompile interface. See the storage proofs article for the current state of the art.
​

Bridges designed for asset transfers add latency, cost, and trust assumptions beyond what a state read requires. REMOTESTATICCALL would provide a read with the same security model as the underlying chain's consensus, not the security of the bridge's validator set or relayer network. For use cases like cross-chain governance where correctness matters more than execution speed, trust minimization is the primary goal.
​

A storage proof is the cryptographic mechanism that proves a specific value was in a chain's state trie at a given block. REMOTESTATICCALL is the proposed opcode interface that would use a storage proof (or equivalent) under the hood, abstracting the proof generation and verification away from the application developer. Storage proofs exist today as an application-layer tool; REMOTESTATICCALL does not yet exist as an EVM primitive.
​

Sources and methodology. EVM opcode and precompile documentation verified against the EVM codes reference and the Ethereum Yellow Paper. Storage proof protocol capabilities verified against Herodotus documentation. EIP process status verified against eips.ethereum.org. Ethereum upgrade roadmap referenced from ethereum.org/roadmap. No confirmed EIP number for REMOTESTATICCALL as of April 2026; this article describes the design space and existing analogs.
​