RIP-7755 is a draft Rollup Improvement Proposal that defines a standard for smart accounts on one Ethereum L2 to make verified function calls on a different L2 without routing through a bridge. It pairs a fulfiller (solver) network with storage proofs to let any party execute a cross-chain call and then cryptographically prove that execution occurred. The specification is maintained in the ethereum/RIPs repository alongside RIP-7728, which covers lower-level static read calls.
​

RIP-7755 is an onchain standard for cross-L2 smart contract calls. A smart account on a source L2 posts a signed request with a target contract, calldata, and a reward. A permissionless fulfiller executes the call on the destination L2 and claims the reward by submitting a storage proof that cryptographically confirms execution occurred.
​

The proposal lives in the RIP-7755 specification on GitHub as a draft that is actively discussed by Ethereum application developers and L2 teams. Its design deliberately avoids requiring a bridge, a canonical message relay, or any trusted third party. The two parties involved are the user who posts the request and the fulfiller who executes it. A smart contract on the source chain holds the reward in escrow and releases it only when the fulfiller supplies an EIP-1186 storage proof confirming the call landed on the destination L2.
​

RIP-7755 is categorized as an application-layer standard, not a protocol change, which means no fork or L2 upgrade is needed to implement it. Any L2 with EVM compatibility can participate as a source chain or destination chain. The companion proposal RIP-7728 handles REMOTESTATICCALL at a lower level; RIP-7755 is the higher-level intent layer that adds execution, reward, and proof settlement on top of that primitive.
​

Today there is no shared standard for a smart account on one L2 to call a contract on another L2. Developers route cross-chain actions through lock-and-mint bridges, native L2 message systems, or off-chain relayer networks, each of which introduces trust assumptions, liquidity constraints, or vendor lock-in. None of these were designed for the composable, account-abstraction-native call pattern that ERC-4337 smart accounts require.
​

Lock-and-mint bridges require users to trust either a multisig validator set or a single oracle network. The cross-chain messaging protocols that back these bridges (LayerZero, Wormhole, Across, and others) each have their own security model, finality window, and fee structure. A developer building cross-L2 DeFi composability must integrate against each bridge individually.
​

Native L2 messengers (for example, the Optimism standard bridge or Arbitrum's retryable tickets) are limited to pairs of chains: the L2 and Ethereum L1. There is no native Optimism-to-Base message relay. Users who need L2-to-L2 calls today must go L2-to-L1-to-L2, which doubles latency and fees and requires the user to post transactions on L1.
​

Smart accounts built on ERC-4337 compound the problem. A UserOperation bundles the user's intent into a single signed object, but that object is currently confined to one chain. There is no standard way for a UserOperation originating on Base to trigger a contract call on Arbitrum. RIP-7755 is designed specifically to fill that gap.
​

RIP-7755 moves a cross-chain call through four discrete onchain steps: request posting, fulfiller execution, destination-state commitment, and storage-proof settlement. Each step touches a different contract on a different chain, and the only trust required is that the destination L2's state root is eventually accessible to the source chain, which is guaranteed by each chain's own proof system.
​

The four steps in detail:

The fulfiller's economic incentive is the fee spread: they pay gas on the destination chain and earn a reward on the source chain. Because the settlement is trustless, anyone can fulfill the request. Competitive fulfillers drive reward fees down to near gas cost, similar to the solver market in ERC-4337 bundlers or cross-chain intent systems like Across.
​

The RIP-7755 GitHub specification defines the exact ABI for the Inbox contract, the storage slot derivation formula, and the proof verification interface. Teams building fulfillers can implement against this ABI without any vendor-specific SDK.
​

Storage proofs in RIP-7755 let the source chain independently verify that a specific function call landed on the destination chain, with no oracle or relayer in the trust path. The fulfiller generates a Merkle-Patricia-trie proof (specified in EIP-1186) for a deterministic storage slot on the destination L2, then submits that proof to the source chain's Inbox contract, which checks it against the destination's published state root.
​

EIP-1186 defines the eth_getProof JSON-RPC method, which returns three items: an account proof, a set of storage proofs, and the associated values at those storage slots. A fulfiller calls eth_getProof on the destination L2's RPC endpoint after execution, targeting the contract address and the specific storage slot where the storage proof was written when the call landed.
​

The source chain's Inbox contract can verify the proof because every L2 that settles to Ethereum eventually publishes a state root back to L1. Optimistic rollups publish state roots after a 7-day fraud-proof window (for example, Optimism and Base using the OP Stack). ZK rollups publish state roots much faster, typically within minutes, backed by a validity proof. The Inbox contract reads the state root from the destination chain's L1 settlement contract and uses it as the anchor for EIP-1186 proof verification.
​

This design means that RIP-7755 storage proof latency is not set by RIP-7755 itself but by each destination chain's proof finality. On a ZK rollup, proof settlement can complete in under 30 minutes. On an optimistic rollup using the 7-day window, the fulfiller must either wait for full finality or accept the economic risk of optimistically claiming the reward before the fraud window closes (a risk model the specification leaves to the fulfiller's discretion).
​

Importantly, the proof-verification logic on the source chain is modular. Each destination chain requires a small adapter contract that knows how to locate that chain's state root on L1. The RIP-7755 draft discusses a registry of these adapters so that new L2s can be added without changing the core Inbox ABI. Details are in the open specification on GitHub.
​

RIP-7755 differs from bridge-based cross-chain calls primarily in its trust model: it requires no trusted validator set, no liquidity pool, and no dedicated relayer network. The table below compares RIP-7755 against two common alternatives: a lock-and-mint bridge (such as a canonical bridge or an external bridge using an oracle model) and a native L2 messenger (such as Optimism's L2CrossDomainMessenger).
​

The table covers five dimensions that matter for developers and protocols choosing a cross-chain call mechanism.
​

A key practical difference is that RIP-7755 does not require any protocol-level deployment on the destination chain beyond the target contract that receives the call. The destination chain is unaware of RIP-7755 as a standard; it simply receives a normal function call from the fulfiller's address. The proof-and-reward mechanics all settle back on the source chain.
​

The Ethereum documentation on rollup scaling provides background on the state root and fraud-proof mechanisms that RIP-7755 builds on.
​

RIP-7755 is explicitly designed as a complement to ERC-4337 smart accounts. An ERC-4337 UserOperation is a signed data structure that bundles a user's call intent, gas parameters, and a signature. Under the current ERC-4337 spec, a UserOperation is scoped to a single chain: the bundler submits it to the EntryPoint contract on that chain, and execution happens there. RIP-7755 extends that model by letting the UserOperation's calldata include a cross-L2 call that lands on a different chain through the fulfiller network.
​

In practice, the integration works like this: a user's cross-chain UserOperation on the source L2 includes a call to the RIP-7755 Inbox contract as one of its operations. The ERC-4337 bundler picks up the UserOperation, executes the call to the Inbox on the source chain, and the reward is locked. The fulfiller (which can be the same bundler, a different bundler, or a dedicated solver) then completes execution on the destination chain and claims the reward via storage proof.
​

This architecture means that a user with a single smart account can execute a sequence like: swap USDC on Base, bridge the proceeds to Arbitrum, and supply them into Aave, all within one signed UserOperation. Each step in that chain can be wired through RIP-7755 calls for the cross-chain legs. No individual step requires trusting a bridge operator.
​

The ERC-4337 specification, maintained at EIP-4337 on ethereum.org, defines the UserOperation fields and the EntryPoint interface. RIP-7755 reuses the same calldata format so that existing 4337 smart account contracts do not need modifications to issue cross-L2 calls; they simply need a version of the Inbox contract available on their source chain.
​

Cross-L2 session keys are a related use case. A session key in ERC-4337 is a limited-scope key that a user pre-authorizes for a specific period and call set. With RIP-7755, session keys can be scoped to cross-L2 operations: a user can grant a DeFi protocol the ability to execute calls on Arbitrum from their Base smart account for 24 hours without granting broader signing authority. This pattern enables gasless cross-L2 automations for use cases like limit orders, yield rebalancing, and cross-chain governance.
​

RIP-7755 targets three classes of applications that currently lack a trustless, standard-based mechanism for cross-L2 smart contract calls: DeFi composability across L2s, cross-chain governance execution, and unified liquidity management. Each class benefits from the proposal's combination of arbitrary calldata support, fulfiller permissionlessness, and cryptographic proof settlement.
​

A protocol that deploys lending or liquidity contracts across multiple L2s today must either deploy bridged versions of each contract (adding liquidity fragmentation) or require users to manually bridge assets and call contracts in separate transactions. RIP-7755 lets a protocol expose a single entry point on the user's preferred L2, route the call to whichever chain holds the relevant contract, and settle back to the source chain in one user-visible step. Protocols like Aave and Uniswap v4 that operate on five or more EVM chains are natural candidates for this pattern once the fulfiller infrastructure matures.
​

DAOs that hold assets or contracts on multiple L2s face a governance-execution problem: a vote that passes on the DAO's primary chain must somehow trigger contract changes on every other chain the DAO operates on. Current solutions use multisig committees or trusted bridges, both of which introduce centralization. RIP-7755 lets governance contracts issue cross-L2 calls directly from the DAO's source chain once a proposal passes, with execution verified by storage proof rather than by a committee's signature. The Ethereum governance documentation provides context on onchain governance patterns.
​

Liquidity fragmentation across L2s is a persistent problem in cross-chain interoperability. Each L2 holds its own pools, and rebalancing between them currently requires bridge transactions with liquidity requirements on both sides. RIP-7755 enables protocols to call liquidity management contracts on remote L2s without moving tokens through a bridge. A rebalancer can post an Inbox request on Base, have a fulfiller call the adjustment function on Arbitrum, and verify execution via storage proof, all without locking capital in a bridge pool.
​

ERC-4337 session keys extended to cross-L2 contexts via RIP-7755 enable automated strategies that span chains: a yield optimizer can rebalance a position between Optimism and Base on a schedule, a limit order system can fill on whichever chain offers the best price, and a cross-chain dollar-cost averaging bot can execute purchases on multiple chains from a single signed session authorization. These automations become possible without any of them requiring users to pre-fund gas on every destination chain, since the fulfiller fronts gas and is reimbursed on the source chain.
​

RIP-7755 is a draft specification as of April 2026 and is not yet deployed on any mainnet. It is under active development in the ethereum/RIPs repository. Teams building cross-L2 infrastructure are following the draft closely, but no production deployment has been announced.
​

A bridge requires a trusted validator set or liquidity pool and is typically designed for token transfers. RIP-7755 handles arbitrary smart contract calls, not token movements, and settles via storage proofs anchored to each chain's own state root. No bridge operator or pool is in the trust path. See the cross-chain messaging article for background on how bridges compare.
​

A fulfiller is any address that monitors the source chain for open RIP-7755 requests, executes the specified call on the destination chain, and then submits a storage proof to the source chain to claim the escrowed reward. Fulfillers are permissionless: anyone can act as one. Competitive fulfiller networks drive reward fees toward gas cost, similar to the ERC-4337 bundler market.
​

Yes. RIP-7755 is compatible with both rollup types. The proof finality window determines settlement latency: ZK rollups settle state roots in minutes, while optimistic rollups require up to 7 days for the fraud-proof window. The fulfiller bears the latency risk and can choose to accept optimistic risk or wait for full finality. See What Is a Rollup for details on how each proof type works.
​

RIP-7728 defines REMOTESTATICCALL, a lower-level primitive for reading state from a remote chain without execution. RIP-7755 is the higher-level intent layer: it adds write calls, fulfiller incentives, and proof-based reward settlement on top of the read primitive RIP-7728 provides. Both proposals are maintained in the ethereum/RIPs repository.
​

Sources and methodology. Specification details sourced from the RIP-7755 draft on GitHub and the EIP-1186 specification on ethereum.org. Rollup finality windows referenced from public Ethereum Foundation documentation. Draft status confirmed April 2026.
​