Introduction

The interoperability and composability between various blockchains have been topics of discussion since the early days when there were fewer than ten L1 solutions in 2017. However, with new rollups being launched almost daily, these issues have escalated significantly. The surge in rollup deployments has indeed boosted throughput and execution capabilities within the Ethereum ecosystem. Yet, this has come at the cost of reduced composability, complicating the problem of fragmentation. Not only is liquidity now spread across the rollups, but the ecosystem itself has become segmented in terms of dapps and community focus.

Multiple teams have put forward various solutions aimed at reducing fragmentation and increasing interoperability with seamless composability within the Ethereum ecosystem. In this article, we will explore the landscape of interoperability on Ethereum, comparing different approaches and highlighting how t1 protocol differentiates itself from existing market solutions. 

However, before diving in, it's important to understand why rollup interoperability poses such a significant challenge and why a universal solution has yet to be discovered.

Ethereum Interoperability is Complicated

As previously discussed, the fragmentation among rollups has become a significant issue. When only Optimism and Arbitrum existed, the problem was less pronounced because developing an interoperability solution across just two or three chains was not that difficult.

One might initially consider using the native bridges of rollups for interoperability, given that Ethereum serves as the base layer where all rollups settle. However, this method is both costly and inefficient. Utilizing the canonical bridge for native bridging is arguably one of the most expensive ways to transfer assets between chains. For instance, if you follow the route Rollup A → Ethereum → Rollup B, the process becomes impractical, especially for optimistic rollups. Here, you would need to wait seven days for your assets to be settled on Ethereum before bridging them elsewhere, not to mention the high bridging transaction fees. This approach simply doesn't scale or fit well with current demands.

That's the main reason why the interoperability ecosystem is developing so rapidly: we don't have native infrastructure that will suit apps that, by design, require cheaper and faster transactions across multiple rollups.

Ethereum has been focused on a rollup-centric roadmap for a long time, and of course, there have been a lot of new designs for rollups proposed, like based rollups, altVM rollups, sovereign rollups, native rollups, and so on. Modifications are being made on all layers of rollup design: sequencing, transaction inclusion, execution, and data availability.

Because of that, rollups are becoming more exclusive than inclusive, leading to the creation of new rollup stacks like the OP Stack, Polygon CDK, and Arbitrum Orbit. This has coined the term "local interoperability," where interoperability is easy within a specific stack but doesn't solve the problem globally.

The variety of rollups — caused by tech limits and political or incentive misalignment — leads to big problems with splitting apart and working together. Each rollup uses different tech, aims for different products, and has its own idea for Ethereum's future, pushing in separate ways.

So, which solutions have been proposed to address these issues, how do they differ, and do they actually fix the problem?

Current Interoperability Landscape

As we've previously discussed, the variety in rollup designs, stacks, and product positioning has resulted in the development of entirely different technologies across various layers of rollup architecture. With over 100 bridges, messaging networks, and intent networks in existence, it's impractical to cover everything in detail (otherwise, this article would span 100 pages). Instead, we aim to outline the main categories of these projects and examine how they fit into the broader landscape of solutions.

Native Bridging (L2 → L1 → L2)

A rollup is an L2 that posts its blocks to another chain for data availability and consensus finality guarantees. Each rollup has a bridge used to transfer assets to and from the rollup, as well as to submit proofs and transaction history. Native bridging has largely failed to gain traction because few people utilize these bridges for asset transfers between blockchains. The primary issue, well-known among users, is that bridging assets from optimistic rollups back to Ethereum incurs withdrawal delays of up to seven days. The situation with zk-rollups is somewhat better than the seven-day withdrawal delays, but most of the time, there are still hours of delay, which isn’t practical either.

To give a clear picture of how native bridging is doing right now, here are the latest numbers showing how many transfers happen each week on major blockchain networks. This includes Arbitrum, Optimism, zkSync, StarkNet, and Base, giving a simple overview of the transactions these native bridges handle over seven days.

There are around 50-100 transactions that occur daily on the native bridges of leading rollups. For instance, when examining the Across Protocol, over 8,000 daily transactions occur solely with Optimism through this third-party bridge. This significant difference underscores that native bridging may not be the best solution for cross-chain interoperability. This insight leads to a key question: what if we modify the ecosystem itself to create a consistent communication standard?

Native Modifications (EIPs & ERCs)

The Ethereum community is currently discussing several significant new developments in interoperability. One of these, ERC-7786, is quite recent. Others gained awareness in August 2024 when Vitalik Buterin outlined the cross-rollup roadmap, highlighting EIP-3770, EIP-7683, and EIP-3668.

ERC-7786 (cross-chain interface)

ERC-7786 proposes a standard interface for cross-chain message sending and receiving flows, enhancing interoperability by providing a common framework for developers. This reduces vendor lock-in while allowing for protocol-specific features through non-standard attributes, with adapters ensuring compatibility for non-native protocols.

How it works: a sender uses a SourceGateway contract to define the destination chain, receiver, payload, and attributes, triggering a MessagePosted event. The message is then validated by a DestinationGateway and delivered via the executeMessage function. Attributes enhance functionality, allowing for gas limits, metadata, and protocol-specific adjustments.

ERC-7786's use cases include seamless token transfers with metadata across blockchains, cross-chain governance where votes or proposals move between chains, and NFT actions where minting or transfers on one chain are reflected on another one. Currently in draft, it's being refined through community discussions on attributes and metadata.

EIP-3770, EIP-7683, EIP-3668 (Vitalik’s plan)

In Vitalik's ambitious plan for rollups, three key Ethereum Improvement Proposals (EIPs) are needed for improving how blockchains work together and operate more efficiently.

1. EIP-3770 standardizes EVM addresses with a chain-prefixed address format, simplifying cross-network interactions.

2. EIP-3668, or CCIP-Read, enables secure off-chain data retrieval, crucial for validating cross-rollup transactions and fetching necessary data. 

3. EIP-7683 provides a standardized format for cross-rollup transaction intents, enhancing transaction initiation and execution across chains. 

These elements collectively define the system's architecture aiming for a more integrated blockchain environment.

Vitalik's Phase 2 update makes the cross-rollup system work better and safer. The Keystore Rollup, which works on Layer 2, helps keep account info the same across different blockchains, making managing smart wallets easier. Proof aggregation means we can check several proofs at once. This setup improves how cross-rollup transactions happen, making them secure and consistent.

Beyond Vitalik's conceptual design for the cross-rollup system, the EVM ecosystem has seen the rise of several projects aiming to deliver comparable capabilities, and of course we are talking about rollup stacks.

Rollup Stacks

As more rollups evolved, both users and developers shifted focus from Ethereum to L2 solutions due to high demand. Building rollups was expensive and time-consuming at first, leading to the creation of various rollup frameworks.

Over the last few years, platforms like OP Stack, Arbitrum Orbit, Polygon AggLayer, Elastic Chain, and others have emerged. Three years ago, constructing a rollup — whether optimistic or zk — was a massive undertaking, often requiring $100 million and a team of 100. Now, thanks to recent advancements, rollup standards and stacks have matured, simplifying the development process and making local interoperability within a stack possible.

OP Stack (Superchain)

As most people know, OP Stack (Superchain) is a modular framework by Optimism for building customizable optimistic rollups. 

The Superchain achieves interoperability through four integrated standards. The Message Passing Protocol enables secure cross-rollup messaging, with transactions initiated on the source chain and executed on the target chain. Building on this, the SuperchainERC20 Standard, an extension of ERC20, ensures standardized asset movement across Superchain's chains, acting as a trust-minimized bridge. The Interoperability Fault Proof system secures these interconnected chains, supporting safe asset management. The Interoperable Chain Set structures chains like OP Mainnet, Mode, and Base as a data-sharing network.

All chains within this cluster share a unified security model and governance, managed through a standard Protocol Upgrade vote as per the Standard Rollup Charter. Currently, Superchain Interop is under development and is not yet prepared for production deployment.

Arbitrum Orbit

Arbitrum Orbit allows for the creation of customizable, dedicated chains, either as Layer 2 or Layer 3 settling to any Ethereum L2. Developers can configure chain components like throughput, privacy, gas token, governance, precompiles, and data availability.

Orbit chains are designed to communicate with each other, forming an interconnected ecosystem rather than isolated blockchain networks. Each Orbit chain operates on self-managed nodes that run an instance of Arbitrum Nitro's node software, which supports both the optimium and rollup protocols. This flexibility allows for configuring the Orbit chain according to specific needs, either with optimium or as a rollup.

The interoperability features of Arbitrum Orbit are not yet available, so Arbitrum Orbit can be seen more as an SDK rather than a rollup stack providing interoperability between the chains on the platform.

Polygon AggLayer

Polygon AggLayer is a protocol that enhances blockchain interoperability by unifying state verification and communication across multiple rollups utilizing AggLayer. It aggregates rollup states for a single verification step, reducing redundancy. Serving as a communication bridge, it simplifies message passing between rollups. AggLayer improves interoperability and scalability, allowing numerous rollups to work together while maintaining performance.

AggLayer supports two message delivery methods: optimistic confirmation for quick, latency-reduced communication without immediate proof, and atomic cross-rollup interaction for ensuring simultaneous success or failure of transactions across chains, crucial for scenarios like arbitrage.

AggLayer isn't exactly a stack, instead, it's more of a cross-chain settlement layer that brings together liquidity, users, and data across independent chains, with final results recorded on Ethereum. So other rollup stacks like OP Stack and Arbitrum Nitro can be made interoperable with AggLayer. However, OP Stack and Arbitrum Nitro, as optimistic rollups, need to implement full pessimistic proofs to be fully interoperable with AggLayer for both asset transfers and state sharing. Pessimistic proofs in AggLayer are a zk proof mechanism that ensures secure cross-chain token accounting by assuming potential malicious behavior, verifying that no chain can withdraw more assets than deposited.

A rollup stack that wishes to opt in will also need to set up bridge contracts compatible with the AggLayer's unified bridge for asset transfers, pool all liquidity there, and potentially develop a native local exit tree to track withdrawals and an AggSender equivalent for bridge updates.

Currently, AggLayer's development includes a live unified bridge and pessimistic proofs for secure transactions. Multistack support and fast interoperability are still in development, aiming to enhance compatibility and speed up cross-chain interactions.

Elastic Chain (ZK Stack)

Elastic Chain is a term introduced within the context of zkSync 3.0, referring to a blockchain architecture designed to provide a scalable and interoperable environment. ZK (Stack) chains are L2s with multiple zkEVM instances running in parallel, achieving consensus and finality on Ethereum's L1.

The Elastic Chain achieves interoperability through the Shared Bridge and ZK Gateway. The Shared Bridge connects Ethereum to ZK Chains and holds all the funds within the Elastic Network. The ZK Gateway is where different ZK chains can communicate with each other effectively. By acting as a shared meeting point, the gateway facilitates fast and cost-efficient messaging between participating chains while maintaining robust security measures. Interoperability in the Elastic Network is structured across four levels:

• Level 1: InteropMessage is the base, allowing simple message passing between L2s, using metadata for identification and a Merkle proof for verification via the Gateway.

• Level 2: InteropCall advances to cross-chain function calls with replay protection and mapped sender addresses for security.

• Level 3: Interop Call Bundle groups calls into atomic transactions, ensuring all or none succeed, with options for retrying or cancelling failed bundles.

• Level 4: Interop Transactions manages bundle execution, handling both operational and payment aspects, simplifying complex cross-chain workflows.

The native interoperability feature of the Elastic Chain is currently in its demo version, focusing exclusively on cross-chain swaps. While some teams are attempting to achieve local interoperability among the rollups, there are others who approach the interoperability problem differently, focusing on messaging in general and communication not only within rollups but also with L1s in general.

Messaging Networks

Some teams are exploring interoperability by developing a universal solution that transfers information across various blockchains, including both Layer 1s and Layer 2s. This approach harnesses strong network effects with O(1) marginal complexity, where a single integration provides access to the entire ecosystem attached through a messaging bridge. However, these designs may sometimes sacrifice security and decentralization for scalability.

Currently, two of the most popular solutions with significant traction are LayerZero and Hyperlane, which enable the seamless transfer of messages and assets across different blockchain networks.

LayerZero

LayerZero functions as a messaging protocol rather than a blockchain itself. It facilitates interactions between various blockchains by employing smart contracts on each network, alongside Decentralized Verifier Networks (DVNs) and Executors. Here is what the architecture looks like:

DVNs verify messages, replacing the single oracle, while permissionless Executors handle message execution separately, improving throughput. Each application can customize its security stack, choosing from DVNs, Executors, and other parameters. The V2 version supports universal semantics across chains and is backward compatible with V1.

Hyperlane

Hyperlane is an open-source platform designed to link blockchains together, enabling developers to integrate any blockchain and develop applications that can communicate across various chains and virtual machines.

Hyperlane refers to blockchain interoperability as “interchain messaging." This process involves sending messages from one blockchain to another, facilitated by three key components: a messaging layer, a transport layer, and a security layer. 

• The messaging layer uses Mailboxes to manage the transmission of messages between chains.

• The transport layer is handled by a Relayer, which picks up messages from the originating blockchain, known as the origin chain, and transports them to the intended recipient blockchain, or destination chain.

• The security layer employs Interchain Security Modules (ISMs). These modules aim to provide a certain amount of security that each message received is authentic, verifying it indeed came from the claimed origin chain.

Both LayerZero and Hyperlane function as messenger networks rather than standard blockchains. They employ oracles and relayers for messaging, aspiring to provide valid message delivery without relying on further intermediary entities. However, there are concerns which we will address later in a separate section.

Having discussed traditional blockchain-centric and more recent messaging-centric interoperability angles, we will now delve into exploring interoperability and composability at the sequencer level where transactions are ordered.

Sequencing Models

Typically, a sequencer in a rollup system is a centralized entity responsible for both ordering and executing transactions, managing the sequence across the entire rollup’s ecosystem. However, there are other approaches moving away from this model. 

One such approach involves using a single  sequencer shared by several rollup ecosystems rather than having one dedicated to each ecosystem. This method allows for transactions from multiple rollups to be bundled together gaining atomic composability where transactions either all succeed or fail as a unit. 

A subset of the above-mentioned approach is to designate Ethereum itself as the sequencer for various rollups, known as “based” sequencing. This enhances composability and interoperability by allowing opted-in L2s to also interact with the L1 in a synchronous way, and it improves censorship resistance. 

Let's dive into these two models which leverage sequencing layers to address interoperability challenges.

Shared Sequencing

Shared sequencing refers to the concept where a rollup doesn’t have its own sequencer(s), but rather opts into a shared sequencer which orders transactions from multiple rollups at once, organizing them into shared bundles sent for inclusion to L1. A shared sequencer is rollup-agnostic. This means that it can support multiple types of rollups, including both optimistic and zk-rollups. However, all such rollups must opt in, both politically (including MEV) and by adjusting their technology, to take advantage of the features that shared sequencing unlocks.

Rollups would no longer need to aim to implement and enshrine into their own node software separate sequencing light-clients and reorg handling for each other rollup they wish to interact with. Instead, each rollup could implement ways of directly reading from other rollups via the shared sequencer, which provides a global ordering for all transactions. This reduction in complexity not only streamlines operations but also enhances security by minimizing the attack surface and reducing the chances for errors. This approach becomes increasingly beneficial as more rollups connect to the shared sequencer over time—which seems to be a big political ask, though. Moreover, it does not remove the necessity for each rollup to maintain execution light-clients to support bridging operations with other rollups and to enable composability in general, unless they’d be willing to wait for the slow L1 for post-execution states of required rollups.

Based Sequencing

Based sequencing utilizes the existing validator set of the L1 blockchain to order participating rollups’ transactions, circumventing the need for any dedicated sequencer(s) to manage this task. A rollup is considered "based" if it employs based sequencing for transaction ordering. 

The main advantage of based rollups is censorship resistance and enhanced interoperability, which can be described as synchronous composability with L1. This means transactions across different L2s can be sequenced simultaneously with those on Ethereum. 

In simpler terms, smart contracts on based rollups could interact with any other contract on the Layer 1 all within the same block, creating the illusion that they are operating on a single, unified chain.

A drawback of this approach, in addition to the political issues stemming from shared sequencing in general, is the necessity of overloading L1 proposers with the additional burden of block-building for many rollups at low latency. This is only feasible by introducing a further indirection layer known as gateways, which aims to constrain the L1 node-running requirements at the expense of creating a potential centralizing force in the gateways themselves.

Moreover, given L1's block time of 12 seconds, for based rollups to avoid sacrificing the low-latency (~1-second) transaction confirmation user experience we're accustomed to in other rollups, they would also depend on preconfirmation research being productized, rolled out, and reaching critical mass. This would also become an additional layer of complexity and a potential centralizing force.

Fundamental Problems with Interoperability

As with all solutions, trade-offs are inherent, particularly when addressing the fragmentation of rollups. Each approach has its own set of advantages and disadvantages, requiring users and teams to make strategic decisions about what they are willing to compromise to meet their specific goals.

EIPs and ERCs provide valuable frameworks for establishing standardized cross-chain token and communication protocols for rollups. However, Ethereum does not frequently implement enhancements from these proposals, leading to delays and a slow pace of progress.

Local interoperability within a rollup stack can be likened to a well-organized road system within a single city in the Ethereum country, effectively managing interactions within its own ecosystem. Yet, many stacks have not fully deployed their interoperability models. There's also debate over this approach since, while it does resolve interoperability within the stack, it doesn't address the broader issue of global fragmentation among different blockchain ecosystems—roads between the different cities.

Messaging networks are notably security-budget-bounded, and also resource-intensive. Developers need to craft new smart contracts for each destination chain to interpret state proofs from the source chain, and the validation process consumes significant gas. More importantly, light clients, which verify only headers, pose security risks by potentially allowing double-spending (equivocation). Meanwhile, relayers, essential for data transfer, introduce centralization vulnerabilities, opening up possibilities for data censorship.

Different sequencing models inherently involve trade-offs. For instance, Taiko's based rollup sometimes incurs L1 sequencing costs that exceed its fee revenue, rendering the model economically unsustainable before the implementation of preconfs. Moreover, many teams are hesitant to adopt a shared sequencer model due to the desire to retain control over their Maximum Extractable Value (MEV) rather than sharing it. Even the necessity of decentralizing a rollup’s sequencer in the first place is not a political given. It remains uncertain whether the economic advantages of participating in a shared sequencer system will outweigh the benefits of maintaining control over transaction ordering, or even just sticking to a centralized sequencer, especially with research and engineering progress on forced transactions, exit windows and further measures rendering sequencer decentralization less of a priority.

Each design comes with its own set of compromises, but the most critical considerations are speed and security. Achieving real-time proving and instant settlement is vital for speed, while enhancing security through advanced cryptographic methods and economic incentives can lead to greater decentralization and resistance to censorship, helping security.

Introduction of t1

At 𝚝𝟷, we aim to resolve a challenge: achieving maximum security without sacrificing fast interoperability, thus also addressing the fragmentation caused by numerous rollups. Our solution is designed to be highly secure, leveraging Trusted Execution Environments (TEEs) alongside EigenLayer's economic security measures and a bespoke zero-knowledge proof mechanism. The latter two become crucial to guard against potential TEE vulnerabilities through comprehensive defense strategies as 𝚝𝟷 evolves into a fully permissionless network.

𝚝𝟷 utilizes Autonomous Verifiable  Services (AVS) to harness crypto-economic security from restaked tokens, effectively creating a programmatic insurance reserve equal to one-third of the staked amount, complementing the security provided by TEEs. Bespoke ZKP is then employed in order to expand 𝚝𝟷’s security beyond its AVS security budget.

By integrating AVS-secured and ZKP-reinforced TEEs, 𝚝𝟷 introduces Real-Time Proving (RTP), which verifies the integrity of 𝚝𝟷's operations to Ethereum within less than 12 seconds. RTP not only facilitates instant settlement on Ethereum but also, when paired with TEE-enabled L2 clients, promotes seamless composability across various rollups.

𝚝𝟷 is an EVM-based rollup designed for cross-chain interoperability, using real-time proofs with TEEs, AVS for economic security, and bespoke zk proofs for cryptographic security. Sequencers order partially-encrypted mempool transactions into bundles accompanied by a Sequencing Consensus proof, to be executed by TEE-enabled Executors, handling state changes and producing blocks accompanied by an Execution Consensus proof. Blocks are produced every second and submitted every twelve seconds to the canonical bridge contract on Ethereum L1  requiring proof about both consensus types for state updates. Such state updates enable in particular withdrawals from t1. 

Consensus is secured by EigenLayer's AVS via restaked tokens as well as by a bespoke ZKP mechanism via cryptography aiming to provide security exceeding the AVS insurance ceiling. As 𝚝𝟷 aims to be fully permissionless in the long-term, these defenses against TEE vulnerabilities are essential.

TEEs

TEEs are secure hardware areas that isolate and protect computations and data, ensuring privacy and integrity through "Remote Attestation." This process verifies that the TEE runs specific, unmodified software. TEEs are crucial for 𝚝𝟷's real-time proving and cross-chain composability, allowing for a minimal 12-second asynchrony with Ethereum. They also enable an encrypted mempool, preventing adversarial transaction reordering like sandwich attacks, enhancing UX and fairness in transaction processing.

Sequencers

In 𝚝𝟷, Sequencers sequence and broadcast partially-encrypted transactions, forming a consensus on a blind block order (“bundles”), which is then passed to Executors for execution. Most of the rollups nowadays utilize single-sequencer designs compromising security for speed; also, usually both sequencing and execution are performed by a single entity, leading to little censorship resistance. We want to separate sequencing (broadly accessible) and execution (higher hardware requirements, esp. a TEE) to allow for fast, decentralized consensus, offering strong resistance to censorship and bribery, while minimizing MEV from transaction ordering.

𝚝𝟷’s long-term design employs Espresso Systems' HotShot Consensus, a BFT protocol adapted for PoS, enhancing decentralization. Sequencers, part of 𝚝𝟷's AVS, use restaked stake with slashing conditions to maintain security and integrity in transaction sequencing.

Executors

TEE-enabled Executors oversee the current state of 𝚝𝟷 by running transactions from Sequencer-ordered blind bundles and establishing consensus on the new state. They utilize t1VM, a TEE-optimized and interop-enriched version of Reth, which ensures full backwards compatibility with Ethereum while adding cross-chain-composability-specific capabilities. An Ethereum full node is maintained within the Executor for streamlined interaction with the canonical bridge, while follower nodes (clients) for other rollups  run by the Executor allow for real-time state monitoring and interactions with them, without delays usually required for fraud or zero-knowledge proofs. t1VM includes unique capabilities powered by Reth’s ExEx, enabling Executors to interact with both Ethereum and other (partner) rollups from within 𝚝𝟷's Solidity smart contracts.

Executors operate under a leader-based, instant-finality PoS Byzantine Fault Tolerant consensus system, representing the second category of 𝚝𝟷's AVS, and they are liable to slashing to enforce system integrity.

Impact on Interoperability

Everyone imagines Ethereum's future differently, but one thing many agree on is that there will be more rollups. This growth is driven by lower costs for building infrastructure, more demand for space on the blockchain, and greater crypto use. Right now, several platforms make it easier, cheaper, and quicker to set up rollups, allowing focus on creating useful products rather than just tech. All these rollups eventually link back to Ethereum, making it the central place for money, attention, and new ideas.

As more rollups develop but permissionless interop lags behind, there's a higher chance of security threats from hackers or censorship from centralized, quick-fix-based systems, which could affect how safe and easy it is to use apps in the Ethereum ecosystem. We're using TEEs and extra security measures in the form of AVS and ZKP to tackle these issues, making sure that key Ethereum values are maintained even in a world full of rollups where speed is the priority.

More rollups mean more money flowing through them, but not all will have lots of liquidity or fast transaction times, making them vulnerable to profit-making strategies like sandwich attacks or trading between centralized and decentralized exchanges. Using secured TEEs and partner rollup follower nodes, 𝚝𝟷 helps decentralized exchanges build smart agentic systems that manage small investors' money across different blockchains, offering better returns while keeping the user experience smooth.

No one knows exactly what Ethereum's future will look like—whether it'll be all about rollups, app-chains, or decentralized systems for ordering transactions. But one thing is clear: with lots of rollups and lots of money moving through them, ensuring access to this money, keeping transactions quick, and maintaining security are vital for a healthy ecosystem.

Conclusion

In this article, we've taken a deep dive into the landscape of blockchain interoperability, examining various systems such as rollup stacks, different sequencing approaches, messaging networks, and other related technologies. Each of these systems presents its own set of advantages and drawbacks, but they all aim to converge on a critical requirement: the simultaneous provision of security and speed. 

t1, being a rollup solution itself, is uniquely positioned to tackle these interoperability challenges. Our approach is not just about enhancing one aspect but about harmonizing both security and speed to meet the diverse needs of the Ethereum ecosystem. We recognize that as the blockchain space evolves, the proliferation of rollups is inevitable. Thus, our mission is to foster an environment where more rollups can be developed and integrated, creating a seamless, efficient, but also secure network.

By doing so, t1 strives to not only simplify the complexities for developers but also to enhance the user experience, ensuring that transactions are not only fast but also secure. We look forward to witnessing and contributing to a future where interoperability is not a barrier but a bridge, connecting various blockchain solutions to provide the best possible experience for everyone involved.