By Eco research. Updated Apr 2026.
​

RIP-7728 is a Rollup Improvement Proposal that adds a precompile called L1SLOAD to EVM-compatible rollups, enabling smart contracts on an L2 to read Ethereum L1 storage slots at execution time without routing data through a bridge or an external oracle. The proposal was published to the ethereum/RIPs GitHub repository in 2024 and targets rollups that inherit Ethereum security through regular state-root commitments.
​

A Rollup Improvement Proposal is a specification format modeled on Ethereum Improvement Proposals but scoped to EVM-compatible rollups. RIPs define optional standards that rollup teams can adopt independently, without waiting for Ethereum mainnet consensus. The ethereum/RIPs repository launched in 2023 to coordinate shared standards across OP Stack, Polygon, and zkSync rollup teams.
​

Unlike EIPs, which go through Ethereum's EIP-1 governance process and require broad consensus across node operators, RIPs can be adopted selectively. A rollup team can implement an RIP in its fork of the EVM without waiting for Ethereum mainnet to ship the same opcode. This faster adoption path is why RIP-7728 is a RIP rather than an EIP: the feature is directly useful on rollups and does not require changes to Ethereum L1 itself. As of Q1 2026, the ethereum/RIPs repository contained more than 20 active proposals, with RIP-7560 (native account abstraction) and RIP-7728 (L1SLOAD) among the most discussed.
​

L1SLOAD is a precompile at address 0x101 that accepts an L1 contract address and storage slot indices, then returns the values stored at those slots on Ethereum mainnet. The rollup sequencer fetches the required L1 state from its local L1 node connection during block building, commits those values alongside the rollup state root, and exposes them inside the EVM stack at the call site.
​

The mechanism has two distinct phases. First, the rollup's block-building infrastructure queries Ethereum L1 for the specified storage slots at the L1 block height the rollup is currently anchored to. This is the same L1 block height already referenced by the rollup's deposit contract to enforce transaction ordering. Second, the retrieved values are committed alongside the rollup's state root, making the L1SLOAD result part of the provable execution trace. For ZK rollups, the ZK circuit must include an inclusion proof of the L1 state, so the prover cannot substitute a different value. For optimistic rollups, the fault-proof system must be extended to allow challengers to dispute an L1SLOAD result using the same Merkle proof tools already used to dispute state transitions.
​

The RIP-7728 specification defines the call signature as a static array of (address, slot) pairs, returning a packed array of 32-byte values in the same order. Gas is charged per slot accessed, with a base cost analogous to the SLOAD opcode on L1 plus a per-slot surcharge to account for cross-layer data retrieval overhead.
​

L1SLOAD charges a base fee of 800 gas per precompile invocation plus 2,000 gas per (address, slot) pair. This is significantly cheaper than a Chainlink oracle callback (60,000 to 120,000 gas on an L2) or an onchain storage proof verification (40,000 to 80,000 gas). Gas figures reflect the current RIP-7728 specification draft and may be adjusted by individual rollup teams.
​

For a contract reading three L1 slots in a single call, total L1SLOAD gas would be 800 + (3 × 2,000) = 6,800 gas units on the rollup. Compare this to oracle-mediated alternatives: a Chainlink oracle callback on an L2 typically costs 60,000 to 120,000 gas units once the request, fulfillment callback, and intermediate SSTORE writes are tallied. An L2 contract using a storage proof verified onchain pays for the Keccak-based Merkle proof verification, which benchmarks at roughly 40,000 to 80,000 gas units depending on proof depth. L1SLOAD at 6,800 gas is meaningfully cheaper for both alternatives when the L2 needs fresh L1 state on every transaction rather than a periodic snapshot.
​

Gas accounting for L1SLOAD is not finalized in the proposal as of Q1 2026. The numbers above reflect the specification draft; individual rollup teams may adjust them at deployment based on their own L1 connection topology and sequencer costs.
​

Storage proofs and L1SLOAD both deliver verified L1 state to an L2 contract through different mechanisms. L1SLOAD is a native precompile requiring no auxiliary contract and no offchain proof generation. Storage proofs are Merkle-Patricia proofs generated offchain then submitted onchain, costing 40,000 to 80,000 gas to verify but working on any rollup regardless of whether L1SLOAD is implemented.
​

The table below compares the two approaches across five dimensions relevant to protocol designers choosing between them.
​

Storage proofs are the right choice when the rollup has not implemented L1SLOAD, or when the application needs to prove L1 state from a historical block rather than the current anchor. Projects like Herodotus have built cross-chain storage proof infrastructure that works today across chains where L1SLOAD has not been deployed. For deeper background on how storage proofs work at the cryptographic level, that article covers Merkle-Patricia tree construction and proof-verification circuits in detail.
​

L1SLOAD enables L2 contracts to read live Ethereum L1 state inside their execution logic without bridges, oracles, or offchain infrastructure. Three application categories benefit most directly: governance mirroring, token balance gating, and cross-layer state synchronization for restaking protocols and fee-market-aware contracts.
​

Many governance tokens, including Uniswap's UNI and Compound's COMP, are held primarily on Ethereum L1. Governance contracts on those L1 deployments calculate voting power from L1 balances. An L2 protocol that wants to let token holders vote directly from the L2 currently needs a snapshot oracle or a token bridge to bring balance data onchain. With L1SLOAD, the L2 governance contract can read UNI or COMP balances from Ethereum storage slots in real time, eliminating oracle freshness risk and bridge trust assumptions. The Snapshot protocol's cross-chain voting research identified stale balance data as the primary attack vector for off-chain votes; L1SLOAD closes that vector for onchain L2 votes.
​

Access-control contracts on L2s sometimes gate features behind an L1 NFT or token balance. Before L1SLOAD, the common approach is to deploy a separate "mirror" ERC-20 contract updated by a bridge event each time the L1 balance changes. This creates a lag between the L1 balance change and the L2 gate update, and it requires the user to trigger bridge transactions. With L1SLOAD, the L2 contract reads the L1 ERC-20 balanceOf slot directly at the time of the user's request, with no mirror contract and no latency beyond block finality.
​

Rollup sequencers already monitor L1 for deposit events and forced-transaction queues. L1SLOAD extends that L1-awareness into the execution layer itself. EigenLayer's restaking contracts live on Ethereum L1; an L2 AVS (Actively Validated Service) contract that wants to verify a restaker's stake currently needs an oracle or a bridge message. With L1SLOAD, the AVS contract reads the restaking contract's storage directly at execution time. For a broader overview of how rollup architectures handle cross-layer messaging, see the rollup explainer.
​

As of Q1 2026, no production EVM rollup has shipped L1SLOAD on mainnet. Scroll has listed RIP-7728 as a candidate for a future network upgrade, and the Polygon zkEVM team participated in initial drafting discussions. The OP Stack ecosystem, powering Optimism, Base, Unichain, and Ink, had discussed the proposal but had not reached a formal upgrade proposal as of April 2026.
​

The adoption timeline is constrained by ZK proof system complexity. For ZK rollups, adding L1SLOAD requires extending the proving circuit to include an L1 state inclusion proof, which touches the most performance-sensitive part of the stack. Optimistic rollup implementations are simpler in principle but still require extending the fault-dispute game to cover L1SLOAD results. The Ethereum Foundation's Protocol Support team has been coordinating cross-rollup RIP adoption through AllCoreDevs-L2 calls.
​

Developers targeting L1SLOAD before it is live on their preferred chain can simulate the interface using a wrapper contract that calls a storage proof verifier, then switch the call target to the precompile address once the chain ships the upgrade. This migration path requires no application-level logic change beyond updating the target address.
​

L1SLOAD inherits its security guarantees from the rollup's existing L1 anchor relationship. Because the rollup already proves its state transitions against a known L1 block height, the L1 state values read by L1SLOAD are subject to the same proof machinery. An attacker who wants to supply a false L1 storage value via L1SLOAD would need to corrupt the rollup's entire state root, which is the same attack barrier that protects every other aspect of the rollup's execution.
​

For ZK rollups, the ZK prover generates a proof that includes the L1 state inclusion alongside the rollup's own state transitions. The verifier contract on L1 checks both together. If the L1 storage slot value was wrong, the inclusion proof would fail, and the entire block proof would be rejected. This is categorically stronger than an oracle model, where a quorum of offchain data providers can theoretically collude to supply a false value without the application contract having any way to detect it.
​

For optimistic rollups, the fault-proof game is extended to cover L1SLOAD assertions. If a sequencer posts a block in which an L1SLOAD call returned an incorrect value, any challenger can submit the correct L1 Merkle proof within the dispute window (typically 7 days on Optimism and Arbitrum) and invalidate the block. The dispute mechanism is identical to how optimistic rollups already handle disputes about general EVM state transitions. The Optimism fault-proof documentation describes the dispute game architecture that would need to be extended for L1SLOAD support.
​

One architectural nuance: if a rollup's L1 node connection is lagging (receiving L1 blocks with a delay), the L1SLOAD values will reflect the lagging L1 state rather than the absolute latest. For most applications this is acceptable, because governance tokens and restaking balances change slowly relative to block times. For applications requiring sub-block L1 freshness, an oracle with a faster update cycle may still be the appropriate choice even after L1SLOAD is available.
​

RIP-7560 is a companion Rollup Improvement Proposal that specifies native account abstraction for EVM rollups, allowing any contract to be used as the "from" address in a transaction without requiring an offchain bundler. L1SLOAD and RIP-7560 are independent proposals that can be adopted separately, but they compose naturally: a smart account built under RIP-7560 can use L1SLOAD to read its L1 keystore contract or verify a user's L1 stake before executing a sponsored transaction.
​

The combination is particularly relevant for restaking applications. An EigenLayer operator running an AVS on an L2 could deploy a smart account under RIP-7560 that uses L1SLOAD to verify the operator's restaked ETH balance on L1 in the same transaction that executes the AVS task. This eliminates two separate cross-chain operations that would otherwise be required: one to read the L1 balance and one to submit the task result. The EigenLayer protocol's AVS architecture documentation describes the on-L2 task-execution flow that L1SLOAD could simplify.
​

Developers planning deployments that use both RIPs should note that each has an independent adoption timeline. Chains that implement RIP-7560 without RIP-7728 would still need a separate oracle or storage proof step to read L1 balances. Chains that implement RIP-7728 without RIP-7560 would benefit from cheap L1 state reads but still use the standard ERC-4337 bundler model for smart-account transactions. Full composability between the two proposals requires both to be active on the target chain.
​

L1SLOAD addresses a specific, well-scoped problem: reading current L1 state cheaply from an L2. Several use cases remain outside its scope, and protocol designers should understand these limits before relying on L1SLOAD exclusively.
​

Historical queries are the primary gap. L1SLOAD reads only the L1 block the rollup is currently anchored to. An application that needs to prove a user held a token at a specific past block height, for example to verify governance eligibility at a prior snapshot, still needs a storage proof over the historical L1 state root. The storage proof explainer covers this use case in detail. Herodotus and similar infrastructure projects continue to be relevant for historical proof workloads even as L1SLOAD handles current-state queries more efficiently.
​

Cross-L2 reads are also outside scope. L1SLOAD reads Ethereum L1 state, not the state of other L2s. An application on Arbitrum that wants to read a storage slot from a contract on Optimism cannot use L1SLOAD for this; it would need a cross-chain messaging or storage proof system that covers L2-to-L2 paths. Projects like Polymer and Optimism's Interop specification address L2-to-L2 state reads through different mechanisms.
​

The gas cost model is also still evolving. The 2,000 gas per slot figure in the current draft is a starting point; actual costs will depend on the rollup team's implementation choices and whether the L1 state is cached at the sequencer level. Teams building products that depend on L1SLOAD economics should treat the current draft figures as directional rather than final until the proposal reaches deployment on a production chain.
​

No. L1SLOAD retrieves L1 storage slot values as part of the rollup's block-building process, using the same L1 node connection the sequencer already maintains. No cross-chain message is sent and no separate bridge transaction is required. The result is committed to the rollup's state root and is provable or disputable under the rollup's existing security model.
​

An oracle relies on an offchain network of data providers to fetch and sign L1 data, then submits that data in a separate transaction. L1SLOAD is a native precompile call that reads directly from the rollup's local L1 state view at block-building time. This eliminates oracle trust assumptions, submission latency, and the 60,000 to 120,000 gas overhead of an oracle callback on a typical L2.
​

For ZK rollups, an incorrect L1SLOAD result would fail the in-circuit inclusion proof and the block would be rejected by the proof system. For optimistic rollups, a fault-dispute challenger can submit a Merkle proof against the relevant L1 state root to invalidate the disputed transaction. The security guarantee is identical to any other aspect of the rollup's state transition function.
​

The RIP-7728 specification targets the L1 block that the rollup is currently anchored to, typically the most recent finalized L1 block. Reading historical L1 state requires a storage proof approach rather than L1SLOAD, because the rollup only maintains a live pointer to one L1 block height at a time. Historical queries are better served by storage proof systems like Herodotus.
​

No. RIP and EIP numbering spaces are independent. RIP-7728 is a Rollup Improvement Proposal scoped to EVM-compatible L2 execution environments; an EIP with the same number would be a separate Ethereum mainnet proposal. RIPs are maintained at github.com/ethereum/RIPs; EIPs are maintained at github.com/ethereum/EIPs.
​

Sources and methodology. RIP-7728 specification reviewed from the ethereum/RIPs GitHub repository, April 2026. Gas cost figures reflect the current specification draft and are subject to change before mainnet deployment. Chain roadmap status sourced from public governance forum posts as of Q1 2026.
​

Eco Routes operates across 15 supported chains. As rollups adopt RIP-7728, contracts using L1SLOAD can verify L1-side stablecoin balances and protocol states at execution time, reducing reliance on bridge-mediated data feeds for applications built on top of Eco Routes.
​