### Layer 2 Interoperability through Shared Validity Sequencing

I have ETH on Base but I want to play a game on Mode which is currently impossible without a serires of complex bridge actions. Interoperability removes these barriers, unlocking the full potential of the Layer 2 ecosystem. A user should not care what chain their game or financial asset is on to use Ethereum.

#### Why L2 Interoperability Matters:

For users, interoperability means a smoother, more intuitive experience where it no longer matters which chain their assets reside on; they can be used seamlessly across different rollups. This greatly reduces fees by eliminating the need for complex bridges, resulting in cheaper transactions. With faster cross-rollup communication, users also experience less waiting time and reduced slippage, thanks to unified liquidity pools that provide better pricing. The process of bridging assets is either eliminated or becomes so seamless that it feels like a single, integrated transaction, enhancing overall usability.

For developers, L2 interoperability simplifies the process of building cross-chain applications by removing the need to develop complex bridge logic, allowing them to focus more on product development. This makes it easier to reach a broader audience since applications can be accessed by users across all participating rollups. Developers can also leverage the strengths of each rollup, such as lower fees or unique dApps, and collaborate across chains, opening up opportunities for creative projects like integrating an onchain game with a DeFi product.

On a broader level, the ecosystem benefits greatly from interoperability as it encourages network growth through shared infrastructure and a more interconnected user base. This interconnectedness accelerates innovation, as collaboration between developers on different chains leads to the creation of more advanced use cases. Additionally, interoperability increases the utility of tokens, as they can operate across multiple chains, reaching more liquidity and user engagement points.

---

### Shared Validity Sequencing: Simplifying Cross-Rollup Token Transfers

Shared Validity Sequencing (SVS) offers a novel solution to these challenges by creating a unified system of transaction ordering and verification across multiple rollups. It allows rollups to share a globally valid transaction history, eliminating the need for third-party services and enabling token transfers that are fast, secure, and efficient.

### Current Challenges in Cross-Rollup Token Transfers

When users move tokens between Layer 2 rollups, they typically interact with a **bridge**, which locks tokens on the source rollup and unlocks or mints corresponding tokens on the destination rollup. Here’s a simplified version of the bridging process:

1. **Locking Tokens**: The user locks or burns tokens on Rollup A, signaling that they want to move the assets to Rollup B.
2. **Message to the Bridge**: The user sends a transaction to a bridge smart contract, which acts as an intermediary, verifying the locked tokens on Rollup A.
3. **Waiting for Confirmation**: Rollup B needs to verify the finality of the transaction on Rollup A, often waiting for multiple confirmations to prevent any potential rollback or reorganization of the source chain.
4. **Minting Tokens**: After verification, the bridge mints or unlocks equivalent tokens on Rollup B.

This process is not only time-consuming but also relies on third-party relayers or validators. These external entities introduce additional costs and potential vulnerabilities. Bridges have been a frequent target for hacks, underscoring the security risks involved in cross-chain transfers.

### How SVS Simplifies Cross-Rollup Token Transfers

Under SVS, Rollup A and Rollup B both reference the same **shared global transaction sequence** and rely on a **shared validity layer** to ensure consistency across rollups. This system provides cross-rollup compatibility, allowing tokens to be transferred seamlessly without any external validators or validators involved

Here’s how token transfers work with SVS:

1. **Transaction on Rollup A**: The user initiates a transfer by locking or burning their tokens on Rollup A. This transaction is not only processed by Rollup A but also included in the shared transaction sequence that both Rollup A and Rollup B can see.

2. **Shared Transaction History**: Since both rollups reference the same shared sequence, Rollup B immediately knows about the transaction on Rollup A. There is no need for an external bridge or relayer to communicate the intent of the transfer.

3. **Token Release on Rollup B**: After confirming that tokens were locked on Rollup A through the shared sequence, Rollup B mints or releases the equivalent amount of tokens. The entire process is governed by the cryptographic proofs embedded in the shared validity layer, which ensures that Rollup B can trust the transaction without additional verification steps.

---

### Local and Global Transaction Sequences in SVS
In the Shared Validity Sequencing (SVS) framework, each rollup maintains both a local and global transaction sequence, which work together to ensure efficient processing of transactions within individual rollups and across the broader Superchain ecosystem.

**Local Transaction Sequence**: This is the transaction history specific to each rollup, handling operations that are confined to that particular chain. For example, simple token transfers, swaps, or gaming interactions that occur on one chain, are managed within the local transaction sequence. This allows each rollup to process transactions independently, maximizing efficiency and speed.

**Global Transaction Sequence**: The global sequence, on the other hand, tracks transactions that involve cross-rollup interactions. When you transfer ETH from Base to Mode or when an in-game action requires assets from another rollup, this transaction is included in the global sequence. Both chains reference this shared global transaction history, ensuring consistent state across all participating rollups.

**How This Works Together:**
When a user initiates a transaction on one chain that doesn’t involve another rollup, it stays within the local sequence—this makes it quick and efficient.

If the transaction needs to be recognized by another rollup (e.g., transferring ETH to a differnt L2 for gameplay), it’s recorded in the global transaction sequence, which both rollups can see and trust.
This dual-sequencing model enables rollups to operate independently for most tasks while maintaining seamless interoperability for cross-rollup actions. The result is an ecosystem that’s both scalable and interconnected, allowing for efficient processing of localized transactions without sacrificing the ability to interact across the entire Layer 2 network.

---

### Real User Experience: Using ETH on Base to Play a Game on Mode with SVS

To demonstrate how **Shared Validity Sequencing (SVS)** enhances user experience, let's walk through a scenario where you hold **ETH on Chain A (Base)** and want to use it to **play a game on Chain B (Mode)**. This process highlights how SVS makes cross-rollup interactions seamless, secure, and efficient compared to traditional bridging methods.

#### Scenario:
You hold **ETH on Chain A (Base)** and want to use that ETH to interact with a game on **Chain B (Mode)**. Normally, transferring ETH between these rollups would involve using a bridge, introducing delays, complexity, and additional costs. With SVS, however, the process is streamlined. Here’s how it works:

#### Step 1: Initiating the Transaction on Chain A (Base)
You have ETH on Chain A (Base) and decide to use it for in-game purchases or to participate in gameplay on Chain B (Mode). To enable this, you need to transfer your ETH from Chain A to Chain B.

Under the **Shared Validity Sequencing (SVS)** framework, instead of relying on a traditional bridge, you initiate a **burn or lock transaction** on Chain A (Base). This action signals that the ETH is no longer available for use on Chain A and will be transferred to Chain B (Mode).

**Transaction Details**:
- **Locking or burning ETH on Chain A**: This transaction locks your ETH on Chain A (Base) and is included in the shared global transaction sequence, visible to both rollups.

#### Step 2: Shared Transaction History and Verification
Once the ETH is burned on Chain A (Base), this event is immediately recognized by both Chain A and Chain B (Mode) through the **shared global transaction sequence**.

- **No relayer or bridge** is needed to communicate this transfer. Chain B can directly reference the shared transaction history to confirm the lock on Chain A.

Since **Chain B (Mode)** trusts the shared validity layer, it knows the ETH on Chain A has been locked or burned and is now available for release on Chain B.

**Key Points**:
- **Shared Global Sequence**: Both chains access the same transaction history.
- **Instant Recognition**: Chain B recognizes the transfer as soon as it’s confirmed on Chain A.

#### Step 3: Releasing ETH on Chain B (Mode)
ETH becomes available on Chain B (Mode). Once Chain B confirms through the shared sequence that the ETH was locked on Chain A (Base), it "mints" or releases the equivalent amount of ETH on Chain B.

Now, your ETH is available on Chain B without requiring any external validators or bridges. You can use this ETH to interact with the game on Mode, such as buying in-game items, paying for gameplay, or participating in the game’s ecosystem.

#### Step 4: Playing the Game on Chain B (Mode)
With your ETH now on Chain B (Mode), you’re ready to engage with the game. The ETH you transferred can be used to purchase items, pay for game actions, or interact with other in-game assets, all in a straightforward manner.

- You make in-game transactions using the ETH available on Chain B, just as if you were originally holding ETH on that chain. The experience is smooth, as there’s no need for any additional steps or bridging mechanisms.

#### Step 5: Finalization and Cross-Rollup State Consistency
Both chains remain synchronized: Since both Chain A (Base) and Chain B (Mode) reference the **shared global transaction sequence**, they stay updated on the transfer of ETH. There’s no need for further reconciliation, and your gaming experience on Chain B is uninterrupted.

**Outcome**: You successfully used ETH from Base to participate in a game on Mode in a secure, efficient, and cost-effective way, without the complexities and delays of traditional bridges.

---

### Why This Experience is Superior with SVS
- **No Delays**: You don't have to wait for multiple confirmations or rely on third-party relayers to transfer your ETH.
- **Lower Fees**: Without external bridges, you avoid the additional fees typically associated with cross-chain transfers.
- **Seamless Gameplay**: The process feels like you’re interacting with a single network, allowing you to focus on playing the game without worrying about complex bridging mechanics.

SVS transforms what would be a multi-step, costly, and time-consuming process into an **instant, secure, and user-friendly experience**, making it easier to interact on Ethereum with the scaling and affordances offered by Layer 2s.

---

### Traditional vs. SVS Process

#### Traditional Bridging Process:
1. You’d have to use a bridge to lock ETH on Chain A.
2. A bridge would verify the transaction, requiring third-party relayers.
3. You’d wait for the bridge to mint ETH on Chain B.
4. This process would take longer due to multiple layers of verification and incur higher transaction fees.

#### SVS Process:
1. You lock ETH on Chain A, which is immediately recognized by Chain B via the shared transaction sequence.
2. Chain B releases ETH without any bridge, relayer, or third-party protocol.
3. The process is fast, secure, and cheaper, as it reduces reliance on external validators and eliminates redundant verification.

### Security and Efficiency with SVS

- **No need for bridges**: SVS removes the requirement for bridging mechanisms, which are traditionally slow and prone to security vulnerabilities.
- **Consistency**: Both rollups remain synchronized through the shared validity layer and global transaction history, reducing the risk of inconsistencies between rollups.
- **Faster finality**: Since both chains are using the same global transaction sequence, the transaction can be verified and processed much faster than traditional cross-rollup token transfers.

In summary, with **Shared Validity Sequencing**, transferring ETH, tokens and other assets between rollups to interact across chains becomes seamless and efficient. The elimination of bridges and reliance on shared sequencing results in a faster, more secure, and cheaper process.

**Shared Validty Sequncing** was designed by [Umbra](https://www.umbraresearch.xyz/writings/shared-validity-sequencing) and is the [current approach being explored](https://specs.optimism.io/interop/overview.html) by Optimism. There is no release date for this but there is a lot of effort on it and I'm hopefully we will all be transaction seamlessly across chains in the next 12 months.

### Thanks
Thanks to phil, naomi and max for edit. To the Farcaster community for early feedback and to Sandman from Delphi Research for this research report on the various approaches to Layer 2

https://www.notion.so/Superchain-and-the-Monolithic-Experience-cc499f712c8648cd852b0b5393db2b51