Ethereum rollup synchronous composability has moved from theory closer to engineering reality. A detailed proposal published February 2 on ethresear.ch by researcher Jorge Baylina outlines a path where rollups compose like a single chain without bridges, without waiting, without async message passing.

The Ethereum Economic Zone account on X flagged the proposal, noting the work points toward a setup where rollups remain economically and socially tied to Ethereum while composing freely across chain boundaries.

What Real-Time Proving Actually Changes

Today’s cross-chain interactions work like this: a contract on chain A sends a message, waits for relay to chain B, then handles the result separately. That delay breaks the composability model that powers DeFi. Protocols cannot atomically connect across rollup boundaries.

Baylina’s proposal cuts that gap. His model requires that a data availability payload and a validity proof get submitted together as one atomic unit. The block proposer handles both execution and proving. If the proof is missing or wrong, the block does not exist. No separate proof markets. No challenge periods.

This is possible because of real-time proving. As of the proposal’s publication, proving a full Ethereum block takes roughly 12 GPUs at about 7 seconds average. That number is still dropping. The model also works without any L1 fork, running entirely through smart contracts on the existing Ethereum network.

The Proxy Contract Model

The mechanism that makes cross-chain calls work is a proxy smart contract. A proxy is deployed on one chain but represents a contract living on a different chain.

When an L1 contract wants to call a contract on a rollup, it calls the proxy version of that contract on L1 instead. The proxy handles the cross-chain call, applies the corresponding state changes on the rollup, and returns the result inside the same transaction. From the caller’s view, nothing looks different from a local call.

For L2-to-L2 composability, the model is even cleaner. Data availability for all affected rollups bundles into one blob. The block builder constructs combined execution touching multiple rollup states, proves them together, posts as one atomic submission. Either all state transitions happen or none do.

Execution Tables and Revert Handling

The harder case is L1-and-L2 interaction. Baylina’s model handles this through what he calls an execution table, a sequence stored temporarily in L1 state that captures the full trace of cross-chain interactions.

Each entry in the table records an action (a CALL or RESULT), which rollup state roots are changing and how, and what comes next in the call chain. A single validity proof covers the correctness of every step in the table. The proof gets verified once at submission.

When a revert happens on L2, a REVERT action goes to L1. L1 unwinds the nested L1 calls in that execution path and updates rollup state roots. Then a REVERT_CONTINUE action goes back to L2 so execution can resume. Reverts work the same way they currently work on a single chain.

“Synchronous composability means that within a single transaction, a smart contract on one chain can call a smart contract on a different chain and receive the result back in the same execution context, just as if both contracts lived on the same chain,” Baylina wrote in the ethresear.ch post.

No Fork, Broad Rollup Support

Baylina’s design does not require rollups to be EVM-native. Any rollup that can accept and generate CALLs to other rollups can participate. Each rollup defines its own state transition via a zkVerification key.

The only constraint the system places is Ether accountability. The system tracks how much Ether each rollup holds and will not allow a rollup to make a call with a value higher than its total Ether balance. Rollups using their own native tokens face one additional restriction: they cannot accept or make calls with non-zero Ether value to or from external rollups.

Incentive alignment and proxy deployment coordination can use existing Ethereum standards, EIP-7702 and EIP-4337, according to the proposal. No new protocol changes needed for that either.

As @etheconomiczone noted on X, real-time proving is what makes this viable. The proposal is orthogonal to preconfirmations and would actually benefit from faster L1 finality once preconfirmations are available. A reference implementation is already published at github.com/jbaylina/sync-rollups.