Compose Shared Publisher

A Horizontal Scaling Architecture for Synchronous Cross-Rollup Composability

Special thanks to Jason Vranek for reviewing
A diagram showing the Compose Shared Publisher.
A diagram showing the Compose Shared Publisher.
A diagram showing the Compose Shared Publisher.
The Shared Publisher architecture presents a novel approach to cross-rollup synchronous composability through the separation of sequencing and publishing responsibilities. This paper introduces the technical foundations of the Publisher, demonstrating how sequencer coordination via Two-Phase Commit enables atomic and synchronous cross-rollup execution while preserving rollup sovereignty. No EVM changes are required. The proposed architecture can help dApps achieve horizontal scaling, while maintaining Ethereum alignment through based publishing mechanisms.
  1. Introduction

On one hand, the proliferation of rollups creates multi-execution environments across isolated state machines, while on the other hand, applications seek seamless integrations across these environments, as though they are on a single chain. The fundamental challenge lies in enabling synchronous composability—atomic execution across multiple rollups that occur over the timespan of a single block—while preserving the sovereignty and scalability benefits that motivate rollup adoption.

The Shared Publisher (SP) architecture introduces a coordination mechanism that separates local sequencing from cross-rollup publishing. This separation enables each rollup to maintain control over its transaction ordering and execution while participating in a coordinated publishing protocol that ensures atomic cross-rollup execution.

The core innovation of SP lies in its distributed algorithm based on CIRC [1], where multiple independent sequencers coordinate through a permissionless publisher to achieve synchronous composability without sacrificing individual rollup performance or autonomy.

  1. Architectural Foundation

2.1 Core Design Principles

The SP architecture builds on three fundamental principles:

Sovereignty Preservation: Each rollup maintains complete control over its sequencing mechanism, fee markets, and execution environment while participating in cross-rollup coordination.

Horizontal Scaling: Rather than consolidating and limiting execution to a single coordinator (as in shared sequencing solutions), SP achieves the desired parallel processing across rollups with coordinated publishing.

Ethereum Alignment: The publisher election mechanism leverages Ethereum's validator set, following a based approach and inheriting Ethereum's security and decentralization properties.

2.2 Component Architecture

Independent Sequencers: Each participating rollup operates its own sequencer responsible for:

  • Building L2 blocks from rollup-specific mempools

  • Participating in a synchronous composability protocol for cross-rollup transactions

  • Delivering its blocks to the current shared publisher

Shared Publisher Network: A permissionless network in which the current shared publisher:

  • Leads the synchronous composability protocol for cross-rollup transactions

  • Aggregates L2 blocks into optimized superblocks

  • Publishes aggregated data to Ethereum L1

Registry and Shared Bridge Infrastructure: L1 and L2 contracts that manage:

  • Rollup registration and configuration

  • Publisher set management and slashing

  • Unified bridging for cross-rollup assets

  • Settlement and proof verification

  1. Message-Passing Composability

On a single EVM chain, composability was achieved by simply calling another contract's function. For example:

Snippet 1: Traditional Composability

function swapWithCondition(uint256 amount, uint256 threshold) {
    uint256 receivedDAI = uniswap.swap(ETH, DAI, amount);
    require(receivedDAI >= threshold, "Insufficient DAI");
}

On a rollup network, SP achieves inter-chain composability through a standardized message-passing protocol that uses a Mailbox abstraction.

Snippet 2: Cross-Rollup Message-Passing Composability

function swapWithCondition(uint256 amount, uint256 threshold) {

    // Equivalent to function call
    Mailbox.write(chainU,
                  uniswapAddr,
                  "SWAP",
                  abi.encode(msg.sender, ETH, DAI, amount));

    // Equivalent to function response
    bytes m = Mailbox.read(chainU,
                           uniswapAddr,
                           "SWAP ACK");
    (receivedDAI) = abi.decode(m, (uint256));

    require(receivedDAI >= threshold, "Insufficient DAI");
}

  • In Mailbox.write, a destination chain, a contract address, and a message label are specified along with call arguments. This is equivalent to the uniswap.swap(ETH, DAI, amount) call in Snippet 1.

  • The result from the call is caught through a Mailbox.read, which again identifies the other chain and contract along with an expected message label response.

While the dApp is abstracted from how the actual integration with other chains will work, the sequencer will be responsible for managing such a Mailbox through the synchronous composability protocol.

Note that, for the example above, there must be another function of the contract uniswapAddr in chain chainU that reads a SWAP message, performs logic, and responds with a SWAP ACK message.

Snippet 3: Message Handler Implementation

function swapper(uint256 srcChain, address srcContract, uint256 amount, uint256 threshold) {

    // Handler for being called
    bytes m = Mailbox.read(srcChain,
                           srcContract,
                           "SWAP");

    (userAddr, token1, token2, amount) = abi.decode(m, (address, address, address, uint256));

    // Performs some logic
    uint256 tradedAmount = uniswap.swap(token1, token2, amount)// ...

    // Response
    Mailbox.write(srcChain,
                  srcContract,
                  "SWAP ACK",
                  abi.encode(tradedAmount));
}

In this context, the cross-rollups transaction bundle would be the set of transactions {srcChain.swapWithCondition(...), chainU.swapper(...)}. An execution of this bundle satisfying atomicity means that either both transactions are included and finalized, or neither. Achieving synchronous composability means that both transactions will be included in the same L1 block which, in turn, guarantees atomicity.

  1. SP Synchronous Composability Protocol

4.1 The CIRC Building Block

The SP protocol is based on CIRC (Coordinated Inter-Rollup Communication) by Espresso Labs [1], which is a shared sequencer solution to synchronous composability.

In CIRC, the shared sequencer starts by simulating all transactions with calls to the Mailbox contract:

  • Once a Mailbox.write is called by a transaction, it writes message m to the destination chain d, the shared sequencer adds m to the Mailbox of chain d. This is accomplished by adding a transaction (e.g. Mailbox.addMessage) placed before the bundle's transaction.

  • In the previous section’s example, the shared sequencer would add a prior transaction to chainU that populates the Mailbox with a message from chain srcChain with label SWAP, and the same would be for chainSrc with a SWAP ACK message label from chain chainU.

After all messages are included into their respective mailboxes, the bundle can be executed and included in each block, if successful. To ensure inclusion in the same L1 block, the L2 blocks are aggregated into a superblock and published as a single L1 transaction.

Notice that, under the hood, the Mailbox is not actually sending any messages, as we would expect from Solidity code. Indeed, it just stores messages, with the shared sequencer being responsible for correctly managing them.

Snippet 4: Mailbox Pseudocode

Mailbox Contract:
    inbox: map[(srcChain, dstChain, sender, receiver, label)] -> data (arguments)
    outbox: map[(srcChain, dstChain, sender, receiver, label)] -> data (arguments)

    clear():
        inbox ← ∅
        outbox ← ∅

    addMessage(srcChain, dstChain, sender, receiver, label, data):
        inbox[(srcChain, dstChain, sender, receiver, label)] = data

    read(srcChain, dstChain, sender, receiver, label):
        if (srcChain, dstChain, sender, receiver, label) not in inbox:
            revert
        return inbox[(srcChain, dstChain, sender, receiver, label)]

    write(srcChain, dstChain, sender, receiver, label, data):
        outbox[(srcChain, dstChain, sender, receiver, label)] = data

clear is added as a transaction at the beginning of the block.

  • read and write are called by other dApps’ functions. While write just adds to the outbox and will be tracked by the sequencer, read may revert if a message doesn't exist in the mailbox.

  • addMessage is added by the sequencer as a result of a write in some other chain intended for this chain.


Moreover, notice that, because of dependency, some messages may only be generated after a re-simulation. For example, as in the previous section, the swapper function can only reach Mailbox.write after it receives the ACK message produced in the first simulation.

4.2 The SP Protocol

The SP protocol decentralizes CIRC. Instead of a shared sequencer entity, each rollup has its own sequencer, while a shared publisher, a permissionless party, is responsible for cross-chain transaction coordination. This achieves synchronous composability with horizontal scaling, while preserving rollups' sovereignty over sequencing rights.

The protocol works in a similar manner:

  1. Each sequencer simulates its local transaction from the cross-chain transaction bundle, keeping track of Mailbox calls.

    • As a result of the simulation, Mailbox messages are generated, and the sequencer sends them to the destination chain’s sequencer.

    • Upon receiving a Mailbox message from another sequencer, that sequencer adds it as a Mailbox.addMessage transaction, populating the Mailbox as it would do in CIRC.

    • It could be a sequencer has to simulate several times, until it receives all messages.

  2. After all messages are exchanged, sequencers can fully execute their transactions and conclude if they are valid or not.

  3. To determine if the bundle is successful, the shared publisher would check if all transactions were indeed successful. The same must be accomplished in a decentralized way.

    • A lightweight agreement algorithm, Two-Phase Commit (2PC) [2], is executed and coordinated by the shared publisher.

    • In 2PC, each sequencer sends a vote (0 or 1) indicating whether its transaction is successful or not.

    • The shared publisher waits for all votes from all sequencers within a timeout period.

      • If all votes are received with 1, it sends a Decided(1) message indicating that the bundle should be included.

      • Else, if at least one vote has 0 or the timer expires, it sends Decided(0).

Figure 1: SP Protocol with CIRC and 2-phase commit
Figure 1: SP Protocol with CIRC and 2-phase commit
Figure 1: SP Protocol with CIRC and 2-phase commit

Figure 1: SP Protocol with CIRC and 2-phase commit

Throughout a slot, sequencers will build blocks with local transactions as well as cross-chain bundles, as explained in the above protocol. After the block is built, it is sent to the shared publisher, who will aggregate all blocks into a superblock and publish it to L1 as a single transaction.

  1. Settlement

5.1 Mechanism

The SP will settle all the rollups participating in cross-chain transactions simultaneously. It does so by publishing aggregated blobs and validity proofs. The proofs are used for ensuring the correctness of both individual rollup blocks as well as cross-chain interactions.

In addition to validity proofs, the SP will perform a Mailbox validation check: for each write to the CIRC's Outbox on one chain, there is a corresponding read on the Inbox of the destination chain. For the settlement to be successful, the SP will post a proof of Mailbox validation, ideally aggregated together with the rollups' validity proofs.

5.2 Benefits of SP

Even without any cross-chain transactions, the SP can help rollups to collectively amortize the gas cost of L1 settlements by utilizing:

  • Blob Space Optimization: By optimizing blob usage across several L2 blocks.

  • Proof Aggregation: By aggregating ZK proofs into a single proof for all blocks.

Thus, rollups may choose to use the SP for its given benefits even if they don't participate in cross-chain activity.

  1. Mitigating the Rollback Problem

It is possible that a rollup may commit to a certain block but not settle it. This can block other rollups from settling their blocks with cross-chain transactions. In order to mitigate this problem, rollups will be able to choose which other chains they interoperate with based on clear criteria.

  1. Trustworthiness based on decentralization stage.

  2. Use settlement commitment mechanisms:

    1. TEEs performing real-time proving for a block [3].

    2. Slashable bonds.

  1. UX

Current prevalent UX is centered around simple EOA transactions that do not support atomic transactions on a single chain. Luckily, account abstraction introduced by ERC-4337 allows the creation of UserOperations that can execute batches atomically. Complimented by EIP-7702, one can transform thetheir EOA wallet to a smart wallet, controlled by a smart contract, that enables account abstraction. By sending UserOperations to each chain participating in the Synchronous Composability Protocol, users can receive VM-enforced atomicity guarantees per chain, and SP protocol-enforced atomicity guarantees inter-chain.

Figure 2: UserOperations on 2 chain
Figure 2: UserOperations on 2 chain
Figure 2: UserOperations on 2 chain

Figure 2: UserOperations on 2 chain

Figure-2 illustrates the creation of a single atomic inter-chain operation through the submission of two distinct UserOperations. Without a UserOperation, the VM of chain A cannot guarantee the atomic execution of transactions tx1, tx2, and tx5 as a batch within the same block. Similarly, this applies to tx3 and tx5 on chain B. Furthermore, the SP protocol ensures the atomicity of tx2 <-> tx3 and tx4 <-> tx5. Collectively, these mechanisms ensure the atomicity of the entire inter-chain operation.

  1. Permissionless Based Publisher Election

The SP protocol leverages Ethereum's validator set by following a based approach for the publisher election.

state variables
    current_publisher
    publisher_set // opted-in L1 validators

procedure Initialize(initial_publisher, initial_set)
    publisher_set ← initial_set
    current_publisher ← initial_publisher

upon new Ethereum slot with L1 proposer V:
    if V in publisher_set then
        current_publisher ← V
    // Else current_publisher remains unchanged

procedure optIn(V, slashingBond)
  1. Summary

The Shared Publisher architecture represents a paradigm shift in cross-rollup composability, introducing the first horizontally scalable solution for atomic cross-rollup execution. By separating sequencing from publishing concerns and implementing lightweight coordination through distributed 2PC, SP achieves superior throughput scaling while preserving rollup sovereignty and maintaining synchronous composability guarantees.

Furthermore, the shared publisher role can achieve Ethereum economic alignment by adopting a permissionless and based approach that inherits Ethereum’s security and decentralization properties. In doing so, SP reinforces the rollup-centric scaling thesis at the heart of Ethereum’s roadmap. As the rollup ecosystem continues to expand, the Shared Publisher offers the unifying infrastructure needed to enable a truly composable, cross-rollup execution environment—without compromising the independence or performance of individual rollups.

  1. References

[1] Espresso Systems. CIRC: Coordinated Inter-Rollup Communication. Accessed 2025. https://espresso.discourse.group/t/circ-coordinated-inter-rollup-communication/43

[2] Gray, Jim; Reuter, Andreas. Transaction Processing: Concepts and Techniques. Morgan Kaufmann, 1992. (Two-Phase Commit overview). Also see: https://en.wikipedia.org/wiki/Two-phase_commit_protocol

[3] Annika Wilde; Tim Niklas Gruel; Claudio Soriente; Ghassan Karame. "The Forking Way: When TEEs Meet Consensus." arXiv, Dec 2024. https://arxiv.org/html/2412.00706v1