A Rollup Improvement Proposal (RIP) is a numbered technical document that specifies a change, addition, or new standard for Ethereum Layer 2 rollup networks. RIPs live at github.com/ethereum/RIPs, follow a draft-to-final process modeled on Ethereum's EIP system, and aim to standardize features across rollups so application developers do not need separate implementations for each L2. As of Q1 2026, finalized RIPs include RIP-7212 (the secp256r1 precompile enabling passkey wallets), RIP-7560 (native account abstraction), RIP-7728 (REMOTESTATICCALL), and RIP-7755 (cross-L2 calls).
​

By Eco research. Updated April 2026.
​

A Rollup Improvement Proposal is a governance document for proposing technical changes to Ethereum L2 rollup networks. Each RIP carries a number, a structured specification, and a status that tracks its progress through the review process. RIPs are non-binding: a finalized RIP is a community recommendation, not a mandate. Every L2 operator decides independently whether and when to implement a given RIP in its node software.
​

The RIP repository was established in 2023 as L2 networks proliferated and each made independent engineering decisions about precompiles, opcodes, and protocol features. Optimism, Arbitrum, Base, Scroll, zkSync Era, Linea, and others diverged on execution details that directly affected application portability. An app developer who wanted passkey-based authentication for a smart wallet faced different opcodes, different gas costs, and different precompile addresses across chains. RIPs provide a shared specification so that when multiple rollups implement the same RIP, any app targeting that specification works across all of them without modification.
​

The governance structure reflects how rollups actually work. Unlike Ethereum mainnet validators, who are bound by hard forks at scheduled block heights, rollup operators control their own node releases. Optimism's governing foundation, Arbitrum's DAO, and Matter Labs (zkSync) each ship their own client software. The RIP process gives them a standardized venue to coordinate on specifications before implementation, reducing duplicated engineering work and catching specification errors before multiple chains ship incompatible versions of the same feature.
​

Participation in the process is open. Any developer can submit a draft RIP by opening a pull request in the ethereum/RIPs repository. Editors drawn from the Ethereum Foundation and the Ethereum Magicians community review submissions for completeness and format before merging. Substantive technical review happens in GitHub issue threads and calls that rollup engineering teams join alongside independent contributors.
​

A RIP moves through four stages: Draft, Review, Last Call, and Final. It can also be Withdrawn at any point if the proposal is abandoned or superseded. A draft submitted as a GitHub pull request must satisfy a template covering motivation, specification, rationale, backwards compatibility, and test cases. Editors check completeness but not technical correctness at the merge stage. Technical review happens during the Review phase through GitHub discussions and community calls.
​

The document structure follows the same template as EIP-1, the meta-EIP that defines how improvement proposals are written. This is deliberate: developers already familiar with the EIP process can contribute to RIPs immediately without learning a new system. The preamble must include: the RIP number, title, author GitHub handles, current status, and a list of target networks. The abstract summarizes the change in three to five sentences. The specification uses the EIP convention of "MUST," "SHOULD," and "MAY" from RFC 2119 to distinguish mandatory requirements from optional behaviors.
​

Last Call runs for 14 days after editors determine the specification is stable. Any objections raised during Last Call can revert the proposal to Review status. Once Last Call expires without unresolved objections, the proposal moves to Final. A Final RIP receives no further content edits; errata are handled via a new RIP or a corrigendum notice.
​

Withdrawal is recorded in the repository with a note explaining the reason. Withdrawn proposals include cases where a better approach was found, where the use case was addressed by a different standard, or where the proposal author stopped maintaining it. Withdrawn RIPs remain in the repository as historical reference, because the discussion record can help future authors avoid repeating explored-but-rejected designs.
​

The timeline from Draft to Final varies substantially by proposal complexity and cross-chain coordination requirements. RIP-7212, the secp256r1 precompile, moved from initial proposal in 2023 to deployment on Optimism, Base, zkSync Era, and Polygon zkEVM within roughly 18 months. RIP-7755, which specifies cross-L2 call verification, entered the repository in 2024 and remained under active review in Q1 2026, reflecting the higher coordination complexity of standards that require both source and destination chain implementations to interoperate.
​

EIPs target Ethereum mainnet and its ecosystem: execution layer changes, consensus layer changes, networking, and application standards (the ERC subset). Finalized EIPs that modify the execution or consensus layer take effect at a hard fork block height and are binding on all Ethereum mainnet validators. RIPs target Ethereum L2 rollup networks specifically and are non-binding. An L2 can ignore a finalized RIP without any consequence to its relationship with Ethereum mainnet. The two standards govern different layers of the Ethereum ecosystem through different adoption mechanisms.
​

The table below compares EIPs and RIPs across the dimensions most relevant to developers building on either system.
​

One nuance is worth noting. Some EIPs are application-layer standards (the ERC category, such as ERC-20 and ERC-4337) that are also non-binding and require voluntary adoption by smart contract developers. RIPs are closer to core EIPs in that they target node operators rather than smart contract authors. The article on Ethereum ERC standards covers the ERC distinction in detail.
​

The process similarity is intentional. By following the same template, the same RFC 2119 language conventions, and the same GitHub-based review structure, RIPs lower the barrier for Ethereum developers to participate in L2 governance without learning a new workflow. Authors who have written EIPs can adapt the same habits to RIPs.
​

Four RIPs attracted the widest adoption or discussion as of Q1 2026: RIP-7212 (secp256r1 precompile), RIP-7560 (native account abstraction), RIP-7728 (REMOTESTATICCALL), and RIP-7755 (cross-L2 calls). Each targets a different layer of L2 execution infrastructure, from cryptographic primitives to cross-chain communication.
​

RIP-7212 specifies a precompiled contract at address 0x100 that verifies signatures over the secp256r1 elliptic curve. secp256r1 is the curve used by Apple's Secure Enclave, Android's hardware-backed keystore, and FIDO2 passkeys. Without the precompile, verifying a passkey signature onchain requires Solidity-level elliptic curve math costing roughly 200,000 to 300,000 gas per verification. With the precompile, verification costs drop to approximately 3,450 gas, a reduction of more than 98 percent. This price difference determines whether biometric-secured smart wallets are economically practical.
​

RIP-7212 was deployed on Optimism, Base, zkSync Era, Polygon zkEVM, and Linea by mid-2024, making it the most widely adopted RIP to date. The full specification and its implications for passkey wallet design are covered in the RIP-7212 explainer.
​

RIP-7560 proposes native account abstraction at the L2 protocol level, eliminating the need for the ERC-4337 smart contract workaround. Under RIP-7560, smart accounts are first-class transaction senders recognized by the L2 node itself. Validation logic runs inside the node's transaction pool, not in the EntryPoint contract. The bundler as a required intermediary disappears; the node handles UserOperation inclusion directly.
​

RIP-7560 was authored by Yoav Weiss, Dror Tirosh, Vitalik Buterin, and Alex Forshtat, several of whom also co-authored ERC-4337. The RIP directly addresses ERC-4337's structural overhead: because the EntryPoint contract is an onchain singleton, every smart account operation carries EntryPoint execution overhead. Moving validation into the node could reduce smart account transaction costs by 20 to 40 percent compared to current ERC-4337 deployment gas. As of Q1 2026, RIP-7560 had not reached mainnet deployment on any production rollup, though zkSync and Optimism had published implementation discussions in their engineering forums.
​

RIP-7728 proposes a new EVM opcode, REMOTESTATICCALL, that lets a smart contract on one L2 read state from a smart contract on another L2 in a verifiable way. The call is static, meaning it reads but does not modify state. Verification relies on the source chain's state root being available on the destination chain, which requires either an L1-anchored state proof or a shared-state mechanism between the two rollups.
​

The practical benefit is significant for cross-chain DeFi infrastructure. Today, reading an oracle price from chain A in a contract on chain B requires an off-chain relayer to fetch the price, sign it, and submit it as a transaction on chain B. REMOTESTATICCALL replaces the off-chain relayer with a protocol-level read, which cannot be censored at the relayer layer. RIP-7728 was in the review stage with no mainnet deployments as of Q1 2026. Its implementation depends on rollup teams committing to the shared-state infrastructure it presupposes.
​

RIP-7755 specifies a standard envelope format for cross-L2 message calls. It defines a canonical call record with fields for source chain, destination chain, target contract, call data, value, and validity window. Any bridge or relayer implementing the RIP-7755 format can process calls from any sending contract that conforms to the envelope structure, without requiring the sender to know which bridge will carry the message.
​

The standard is designed to be composable with existing bridge protocols. Across, Hyperlane, and Wormhole each use proprietary message formats today. RIP-7755 does not require them to change, but it could serve as an interoperability shim: applications write to the RIP-7755 interface and the bridge protocol adapts on the back end. How cross-L2 messaging fits into the broader interoperability landscape is covered in the article on blockchain interoperability.
​

Shared standards reduce the per-application cost of supporting multiple L2 networks. When five rollups implement the same RIP, an app developer writes one implementation and tests it once. Without shared standards, the developer must write and test five implementations, each targeting a different chain's specific configuration. For precompiles, which are consensus-level features requiring node-software changes, this is not just an application cost but a recurring maintenance burden each time any of the five chains ships a node upgrade.
​

The coordination benefit is most visible with precompiles. A precompile is a built-in contract at a fixed address that the L2 node executes in native code rather than through EVM bytecode interpretation. Because precompile behavior is determined by the node implementation and the precompile address is fixed by specification, two rollups that implement the same RIP spec will have identical behavior at that address. Any smart contract targeting address 0x100 for secp256r1 verification will behave identically on Optimism and Base because both implemented RIP-7212 from the same specification. See the article on precompiles for the full mechanics.
​

Standards also create a shared testing surface. When RIP-7212 was proposed, the specification included test vectors for secp256r1 verification: a list of public keys, messages, and signatures with known correct outputs. Each L2 team could run those test vectors against their implementation and confirm compatibility before deploying. Without a shared standard, verifying cross-chain compatibility requires bespoke test harnesses that each application team must build and maintain independently. For an active RIP like RIP-7212, the test vectors are a permanent part of the specification and remain available to any future L2 that wants to implement the precompile.
​

The network effects of standardization accelerate ecosystem tooling. Once three or more rollups ship RIP-7212, wallet libraries like wagmi, viem, and ethers.js add secp256r1 signature handling as a standard feature, because the surface area is predictable across supported chains. Without RIP-7212 as a common specification, those libraries face a per-chain configuration problem that discourages ecosystem-wide tooling updates.
​

RIPs are written for Ethereum rollups but can be adopted as technical specifications by other EVM-compatible networks. Polygon's CDK chains and other ZK-EVM networks have implemented RIP-7212 despite not being canonical Ethereum rollups. A non-Ethereum chain can adopt a RIP specification by matching the technical requirements without participating in the GitHub governance process. The specification itself is open, and there is no license or governance barrier to adoption by non-Ethereum-ecosystem chains.
​

The formal governance process in the RIPs repository is scoped to Ethereum-aligned rollups. Editors are drawn from the Ethereum Foundation's protocol team and the Ethereum Magicians community, and the process assumes EVM compatibility and Ethereum-style consensus. Side chains, alternative Layer 1 networks, and non-EVM environments would typically adapt RIP specifications to their execution model rather than adopting them verbatim.
​

The distinction between rollups and side chains matters here because some RIPs encode rollup-specific security assumptions. RIP-7728 (REMOTESTATICCALL), for example, depends on the source chain's state root being provably available on the destination chain. This guarantee holds between two Ethereum rollups that both post proofs to Ethereum mainnet, because Ethereum's state serves as a shared root of trust. It does not hold between a rollup and an independent side chain with its own consensus. For the full distinction between rollup security and side chain security, see the article on rollups.
​

RIPs define the execution primitives that make cross-chain stablecoin payments practical at scale. RIP-7212 enables biometric-secured smart wallets with near-zero additional gas cost, lowering the friction of account setup for payment-intent users. RIP-7560 would reduce smart account transaction overhead by routing validation through the node rather than the EntryPoint contract, which benefits high-frequency payment flows where bundler overhead is a material cost. RIP-7755 would standardize cross-L2 call verification, reducing trust assumptions in multi-chain payment routing by providing a canonical message format that any bridge can implement.
​

Payment infrastructure that operates across multiple L2 networks benefits directly when rollups converge on shared standards. If five rollups implement RIP-7212, a payment app built for those networks can offer Face ID or fingerprint authentication uniformly, rather than providing fallback key management on chains that lack the precompile. The cumulative effect is a payment experience that is consistent regardless of which chain processes the settlement.
​

Eco's cross-chain payment routing operates across 15 supported networks, including Base, Arbitrum, Optimism, Polygon, and other major L2s where RIP-7212 has been deployed. As more rollups implement finalized RIPs and the next generation of RIPs like RIP-7560 and RIP-7755 moves toward production, the infrastructure layer for cross-chain stablecoin payments gains execution primitives that reduce per-chain engineering overhead and improve consistency at the account level.
​

No. RIPs are non-binding governance recommendations. Each L2 operator independently decides whether to implement a finalized RIP. Optimism's governing foundation, Arbitrum's DAO, and Matter Labs (zkSync) each make independent adoption decisions on their own timelines. There is no Ethereum authority that mandates RIP adoption on any L2 network.
​

ERC standards (the ERC subset of EIPs) specify smart contract interfaces, such as ERC-20 or ERC-4337, that any developer can implement in a deployed contract without L2 node changes. RIPs typically specify execution-layer changes, such as new precompiles or opcodes, that require L2 node operators to ship updated node software. See the article on ERC standards for the full distinction.
​

As of Q1 2026, RIP-7212 has been deployed on Optimism, Base, zkSync Era, Polygon zkEVM, Linea, and Scroll. RIP-7560 was under active review across rollup teams but had not reached mainnet deployment. RIP-7755 and RIP-7728 remained in the review stage. Any new L2 deployments are tracked in the RIPs repository and on chain-specific developer documentation pages.
​

Any developer can author a RIP by submitting a pull request to the ethereum/RIPs GitHub repository following the template structure in the contributing guidelines. Editors review for format compliance, then the proposal enters community discussion. RIP authors have included Ethereum Foundation researchers, rollup engineering teams, and independent contributors working on account abstraction and cross-chain infrastructure.
​

No. L2 networks can deploy a finalized RIP at any time by shipping an updated node client, independent of Ethereum mainnet hard forks. RIP-7212 was deployed on multiple rollups in 2024 with no mainnet upgrade required. RIPs that require shared state infrastructure between rollups (like RIP-7728) need coordination between L2 teams, but still do not require any Ethereum L1 changes.
​

Sources and methodology. RIP specifications verified against the ethereum/RIPs GitHub repository as of April 2026. EIP-1 process details verified against eips.ethereum.org. L2 deployment statuses sourced from official Optimism, Base, zkSync, Polygon, and Linea developer documentation. Gas cost estimates for RIP-7212 sourced from the RIP specification's reference implementation benchmarks. All protocol statuses as of Q1 2026.
​