# The ABC Stack ABC Stack is a high-performance **Rollup L1 framework** using Celestia’s Sovereign Rollup that achieves throughput of [1 Gigagas per second](https://www.gigagas.life/). The ABC Stack framework fully embraces the [**sovereign rollup**](/sovereign-rollup-l1s-vs-settled-l2s) **paradigm**. Rollup L1s **completely decouple bridge functionality from the execution layer** and leverage Celestia for consensus and data availability. This approach eliminates the overhead and architectural constraints of Layer 2 solutions. Unlike L2s that must maintain an enshrined bridge to a settlement layer on Ethereum, ABC Stack functions as a settlement layer in its own right, and achieves its exceptional throughput by focusing solely on efficient execution, with the freedom to implement modular bridging solutions based on specific application needs. ### Understanding the "L" Terminology in Rollups The "L" in L1 or L2 refers to the settlement style of a rollup: * **L2 Rollups** enshrine a bridge to a remote chain's settlement smart contract (typically Ethereum). This means the rollup's canonical chain and transaction validity are determined by the settlement layer through this bridge. L2 rollups are "settled rollups" because a smart contract on another chain serves as the root of trust. * **Rollup L1s** (like ABC Stack) handle settlement directly on the rollup's node network itself, similar to a non-rollup L1 blockchain. The rollup nodes collectively determine the canonical chain and transaction validity without deferring to an external settlement layer. These are "sovereign rollups" because they maintain full control over their settlement process. ## **Why Rollup L1s?** ***“Where we're going, you won't need Settlement Layers”*** Although L2s are designed to rely on a trust-minimized bridge with Ethereum, over time, the market has sought out options that provide superior scalability, lower cost, and a way of bootstrapping liquidity on new blockchain ecosystems custom-built for each application. The reality is that despite the immense overhead of maintaining an enshrined bridge, these bridges offer no safeguards for assets natively issued on the L2 or that do not settle on Ethereum. In fact, a growing proportion of assets on major L2s are either: 1. Bridged through third-party bridges like Hyperlane, LayerZero or Wormhole 2. Natively issued on the L2 itself This reality reflects the market preference for high-performance blockchains optimized for user experience and the unique needs of each application. ABC Stack acknowledges this preference by removing the architectural constraint of an enshrined bridge, which allows for pure optimization of the execution layer. It's worth noting that traditional L2s serve an important purpose when users specifically need the trust-minimized bridge they enshrine and want to leverage Ethereum's security model for settlement layer assets. However, market trends indicate this represents only a fraction of users, with many applications and their communities not requiring or prioritizing this specific architecture. **ABC Stack is the logical conclusion of the modular thesis—complete separation of concerns between different blockchain functions.** By focusing exclusively on high-performance execution, leveraging Celestia for data availability, and enabling cross-chain interop through truly modular bridging, developers can build highly secure applications that can truly scale to web2-like performance requirements, including fully on-chain games, high-throughput DeFi, and other compute-intensive applications that were previously impractical on blockchain infrastructure. # Monolithic vs Modular Blockchains ## **Core Concepts** Any blockchain must perform four essential functions: 1. **Execution**: Processing transactions and updating state 2. **Settlement**: Verifying proofs and resolving disputes between chains 3. **Consensus**: Agreeing on transaction ordering 4. **Data Availability**: Ensuring transaction data is published and accessible Traditional monolithic blockchains handle all these functions in a single system. This design creates inherent limitations since optimizing for one function often requires trade-offs in others. The [modular approach](https://celestia.org/learn/intermediates/modular-and-monolithic-blockchains/) pioneered by Celestia separates these four functions into specialized layers that can be optimized independently. ## Celestia's Modular Framework
Celestia provides a base layer of consensus and data availability to allow settlement and execution to operate in their own layers. This arrangement offers two critical advantages: * First, each layer can be optimized specifically for its function rather than trying to balance competing requirements. This leads to significant throughput improvements. * Second, the same settlement and data availability layers can support multiple execution layers (rollups) simultaneously, which creates an ecosystem of specialized chains rather than requiring each application to compete for resources on a single chain. # "Sovereign" Rollup L1s vs "Settled" L2s ABC Stack is the framework for building sovereign rollups on Celestia that achieves gigagas-level throughput. ABC embraces true modularity by cleanly separating core blockchain functions and removing unnecessary coupling between components. ## **L2 Rollups (Settled Rollups)**
L2 rollups are defined by their relationship with a settlement layer (typically Ethereum). They require an enshrined bridge - a mandatory smart contract bridge to the settlement layer that's built directly into the rollup's protocol. State commitments and proofs get posted to the settlement layer, which creates a dependency where the rollup relies on this layer for validation and security guarantees. Additionally, because these rollups must coordinate protocol changes with the settlement layer, they cannot evolve independently or implement changes that might conflict with the base layer's rules or capabilities. This architecture creates several limitations. The enshrined bridge introduces significant computational overhead. For optimistic rollups, the 7-day fraud proof challenge period has led many users to rely on third-party liquidity providers to bridge assets more quickly. Additionally, the requirement to maintain synchronization with the settlement layer adds substantial complexity to the rollup client, which must constantly monitor for reorgs and manage state transitions between chains. ## **Rollup L1s (Sovereign Rollups)** Rollup L1s are both modular and sovereign; they define themselves by their independence.
Unlike L2s that rely on an enshrined smart contract on another blockchain, Rollup L1s maintain sovereignty through self-defined state validation, where the correct chain state is determined by the rollup's own network of nodes. This independence extends to settlement as well - Rollup L1s have no mandatory bridging to another chain, allowing them to operate without any bridge at all if desired. When bridges are needed, they benefit from modular bridging, with the freedom to choose any bridging solution that best serves their specific needs. Perhaps most importantly, Rollup L1s maintain protocol sovereignty, which allows them to evolve through independent governance and social consensus just like traditional L1s, giving communities the power to determine their own upgrade paths and future direction without requiring permission from an underlying settlement layer. ## **Key Differences** In terms of verification, L2s requires running both the rollup node and the settlement node to determine settlement finality. In contrast, for Rollup L1s, the rollup node itself serves as the settlement node, and only needs to be run in conjunction with a DA node (e.g., a Celestia light node).
Regarding finality, L2 Rollups have a dependency on two separate layers, requiring both the settlement layer and the data availability layer to finalize before transactions can be considered complete. This dual dependency can introduce delays and complications. Rollup L1s, however, only require the data availability layer to finalize, which creates a more direct path to transaction finality. For asset issuance, L2 Rollups were originally designed with the assumption that assets would primarily originate on the settlement layer and then move to the L2 for operations. This design creates a dependency on the settlement layer for asset origination. Rollup L1s break free from this constraint, offering the ability to natively issue assets without any inbuilt reference to another chain, providing greater autonomy for applications and ecosystems. Perhaps the most significant difference lies in bridging capabilities. L2 Rollups must always maintain their enshrined bridge to the settlement layer, even if it's rarely or never used. By contrast, Rollup L1s provide maximum flexibility – they can operate with no bridges at all (for self-contained ecosystems), or they can implement any bridging solution that best meets their specific requirements. This modular approach to bridging allows Rollup L1s to optimize for their particular use cases without forcing unnecessary components into their architecture. ## **Moving From Settled L2s to Rollup L1s** Rollup L1s represent the next evolution of rollups based on our observations of how developers and users actually interact with blockchain systems. While rollups were initially designed with the assumption that maximum security required anchoring all state transitions to Ethereum and that users would first mint tokens on Ethereum and bridge to L2, experience has shown that this design does not align with an increasing number of blockchain use cases. ## **The Role of Celestia in ABC Stack** Celestia is the first modular consensus and data availability network. It provides the [foundation that powers sovereign rollups](https://blog.celestia.org/sovereign-rollup-chains/) by deeply focusing on two of the core blockchain functions: 1. **Consensus**: Providing secure transaction ordering through proof-of-stake 2. **Data Availability**: Ensuring data is published and available through data availability sampling (DAS) By specializing in these functions, Celestia can maintain security while scaling to handle massive amounts of data, which is why Celestia’s modular network serves as an ideal base for ABC Stack’s high-throughput execution layers to build on top. # ABC Stack Architecture ## **Overview** ABC Stack embraces the Sovereign Rollup model pioneered by Celestia, where rollups operate as independent chains rather than being tightly coupled to a settlement layer like Ethereum. By removing the architectural constraints of monolithic and “settled” L2 rollups and performing additional optimizations, ABC Stack achieves gigagas levels of throughput (over 1000 megagas per second). This architectural choice aligns the design of blockchains with the functionality users expect from traditional applications. ABC Stack makes deploying a Rollup L1 as straightforward as deploying a smart contract. Rather than being constrained by monolithic blockchains, enshrined bridges and settlement layers, developers can focus purely on their application logic and choose exactly the features they need. ### How ABC Achieves Gigagas Throughput The ABC stack achieves unprecedented throughput through the following design choices: * Optimized Execution: The execution layer can be fully optimized for performance without settlement layer synchronisation constraints * Efficient Data Handling: Direct integration with Celestia's data availability layer enables efficient data processing * Minimal State Synchronization: No need to constantly synchronize state with a settlement layer # Key Features As a sovereign Rollup L1 framework built on Celestia, ABC delivers exceptional performance, flexibility, and sovereignty. ### Performance & Scalability #### Gigagas Throughput * **1 Gigagas Per Second Processing**: ABC Stack achieves throughput of 1 Gigagas per second — vastly more processing capacity than conventional L2s — by removing the computational overhead of settlement layer bridges and optimizing the execution layer specifically for Celestia's DA. * **Low Block Times**: Enjoy rapid transaction confirmations (up to 100ms) with minimal latency through optimized block production pipelines and by eliminating the dependency on Ethereum's block time constraints * **Real-Time State (WIP)**: Experience near-instantaneous (10ms) state updates by implementing partial block architecture where state updates can be broadcasted before complete blocks are finalized. #### Advanced Block Building * **Custom Block Building**: Developers can define custom rules for transaction inclusion and ordering through modifiable block building logic. * **Rollup Boost Integration**: Connect to external specialized block builders who can optimize block construction for specific needs like MEV protection. * **Lazy Block Building**: Conserve resources by generating blocks only when needed rather than at fixed intervals. * **Dynamic Block Gas Limits**: Automatically adjust block capacity based on network demand through configurable parameters that can change during runtime. * **Custom/Dynamic EIP-1559 Configurations**: Customize base fee algorithms and fee market mechanics to optimize for your specific economy. ### Sovereignty & Architecture #### True Blockchain Sovereignty * **No Settlement Costs**: Eliminate unnecessary fees and complexity by removing the enshrined Ethereum bridge * **Sovereign Design**: Operates as its own settlement layer with complete authority over chain rules, upgrades, and parameters. * **Independent State Validation**: Verifies transactions through its own network of nodes that run full state validation without relying on external chains. * **Protocol Sovereignty**: Enables governance decisions to be made by the chain's own community without requiring approval from any parent chain. #### Modular Architecture * **Celestia Integration**: Leverage Celestia for data availability and consensus * **Modular Bridging**: Implements bridges as separate modules that can be added, removed, or upgraded independently from the core protocol. * **No Reorgs**: Benefit from Celestia's single-slot-finality for transaction certainty * **ZK Ready**: Designed with future compatibility for zero-knowledge proof integration through a modular architecture that can incorporate ZK verification. * **Sequencer HA Setup (WIP)**: High availability sequencer configuration for maximum uptime ### User Experience #### Account Abstraction & Onboarding * **Sequencer Sponsored Transactions**: Implement EIP-7702 to allow users to delegate their EOAs to smart contracts with sequencer-sponsored costs * **Passwordless Onboarding**: Integrates with WebAuthn standard to let users authenticate using biometrics or hardware keys rather than managing private keys. * **Gasless Transactions**: Optionally enable zero gas price operations that can be dynamically configured * **Private Mempool**: Enable a protected transaction pool visible only to block producers, preventing frontrunning by keeping pending transactions confidential. #### Advanced Account Features * **Call Batching**: Send multiple calls in a single transaction to reduce gas costs and improving UX * **Gas Sponsorship**: Allow any entity to pay for fees in any ERC20 or ETH through relayer infrastructure that detects user-signed messages and submits them as transactions with gas paid by designated sponsors. * **Access Control**: Whitelist receivers, function selectors, and arguments * **Session Keys**: Creates temporary limited-privilege keys through smart contracts that can authorize specific actions without full account access. * **Multi-factor Authentication**: Combines multiple signature verification requirements in smart contracts to ensure multiple authentication factors are validated. * **No Vendor Lock-in**: Built on top of standards that have powered Ethereum for years to ensure portability across different implementations. ### Technical Capabilities #### Cryptographic Precompiles * **EIP-7212**: Provides native support for secp256r1 curve through an efficient low-level implementation at the EVM level. * **EIP-2537**: Implements BLS12-381 curve operations as EVM precompiles for efficient zero-knowledge proof verification and threshold signatures. * **Prague Hardfork**: Activates the latest Ethereum technical improvements ahead of mainnet by implementing the Prague EIPs directly in the execution client. #### Smart Contract Infrastructure * **Preinstalled Contracts**: Deploy with essential contracts available from genesis, including: * **Safe Ecosystem**: `Safe`, `SafeL2`, `MultiSend` and `MultiSendCallOnly` at standardized addresses * **Deployment Utilities**: Safe Singleton Factory, `create2Deployer`, `CreateX`, and Arachnid's Deterministic Deployment Proxy * **ERC-4337 Support**: EntryPoint v0.6.0 and v0.7.0 with required `SenderCreator` dependencies * **Developer Tooling**: `Multicall3` for batched calls * **DeFi Infrastructure**: `Permit2` for token approvals * **Utility Contracts**: Includes `multicaller`, `create3`, and other foundational infrastructure #### Interoperability * **Gelato Hyperlane Cluster**: Integrates dedicated messaging infrastructure that connects your chain to 100+ blockchains through secured messaging pathways. * **Native or Bridged Token Options**: Provides flexibility to either mint tokens directly on your chain or use token bridge infrastructure to import existing assets. * **Chain Abstraction (WIP)**: Invisible cross-chain transactions powered by ERC-7683 intent standard to eliminate cross-chain complexity from users by having intermediaries handle the execution details. ### Privacy & Security * **Private Transactions**: Support for confidential transactions and [transaction privacy](https://vitalik.eth.limo/general/2023/01/20/stealth.html) to encrypt transaction amounts while still allowing verification of balance correctness through ZK. * **Recovery Options**: Multi-path account recovery via social, email, OAuth, or other identity providers * **Privacy-Preserving Identity**: Options for ZK Passport or similar verification where users can prove attributes without revealing sensitive data *** ABC Stack represents the future of sovereign blockchain architecture. Build highly secure, scalable applications without the constraints imposed by traditional L2 designs. # Data Availability and Consensus ABC Stack chains achieve [gigagas throughput](http://gigagas.life/) by leveraging Celestia for consensus and data availability. Rather than posting state updates to Ethereum like L2 rollups, ABC Stack chains post their raw transaction data directly to Celestia. This data is organized into [namespaces](https://docs.celestia.org/learn/how-celestia-works/data-availability-layer#namespaced-merkle-trees-nmts), allowing efficient retrieval and verification through Celestia's data availability sampling (DAS). The chain's consensus is secured by Celestia's proof-of-stake validator set, which orders transactions and ensures their data is available.

Sovereign rollups (Rollup L1s) achieve their efficiency and flexibility due to the DA layer handling consensus as well as DA.

Such massive throughput is enabled through the use of advanced data structures and encoding schemes that enable the network to scale with the number of participating nodes. A key aspect of this efficiency is its native namespace support, which allows different applications to organize their data efficiently within the same blockchain. Through namespacing, ABC chains can isolate their transaction data, which enables efficient retrieval and verification while maintaining separation from other applications using the same DA layer.

Source: docs.celestia.org

Celestia ensures secure transaction ordering through its proof-of-stake validator set, which ensures that all transactions are processed in a consistent, tamper-resistant sequence. Light nodes verify data availability by randomly sampling small portions of block data rather than downloading entire blocks. This sampling achieves high confidence in data availability while keeping resource requirements minimal. For ABC Stack chains, this means: * Each Rollup L1 can process massive amounts of transaction data * Light clients can efficiently verify the chain's state * Security scales horizontally with the number of participating light nodes The system maintains security through probabilistic sampling that verifies against an agreed-upon level of confidence in data availability, and is capable of network-wide data reconstruction from sampled shares. # EVM Execution Environment ABC Stack provides a fully EVM-compatible execution environment that processes transactions and maintains state. Following best practices in software architecture, ABC Stack separates concerns to prioritize execution and interoperability. Unlike Layer 2 rollups that must coordinate with a settlement layer, ABC's execution environment processes transactions and maintains state without external dependencies. This independence is key to achieving gigagas-level throughput. For developers, this means being able to build high-performance applications that can fully leverage EVM compatibility while maintaining the flexibility to integrate with other chains through their choice of bridging technology. ABC's execution layer maintains its own canonical state, similar to a Layer 1 blockchain. Full nodes in the network independently validate all state transitions according to the rollup's rules, without needing to generate fraud proofs or validity proofs for an external chain. This removes a major source of computational overhead that constrains settled rollups. # State Management As a sovereign rollup, ABC Stack's state management differs fundamentally from traditional L2s. While L2s must commit state roots to Ethereum for settlement purposes, ABC Stack chains maintain and validate their state independently, posting only transaction data to Celestia. The key aspects of this state management approach are: 1. **Independent State Validation**: Full nodes validate and maintain the complete state of the chain without requiring external settlement verification. Sovereign rollups handle their own state transitions. 2. **Data Availability**: Rather than settling state on Ethereum, ABC Stack relies on Celestia's data availability layer to ensure transaction data remains permanently accessible. This provides the foundational security guarantee for state validation, as Celestia ensures all nodes can access the data needed to verify and reconstruct the chain's state. 3. **Optional Modular Bridge Architecture**: State can be verified by external bridges if needed, but this is decoupled from core state management. Developers can pick whatever bridge they want without constraining the chain's state management. # Security Model Security in ABC Stack is based on two primary mechanisms: 1. **Data Availability**: Celestia's data availability sampling ensures that all transaction data is provably available to the network. 2. **State Validation**: Full nodes independently validate all state transitions according to the chain's rules. This model provides strong security guarantees while enabling high performance and sovereignty. Unlike traditional L2s that rely on fraud proofs and challenge periods, ABC Stack's security is immediate and doesn't require trust in external validators or settlement layers. # Use Cases The performance characteristics of ABC Stack enable several new categories of applications that were previously impractical on monolithic or “settled” EVM chains: * **High-Frequency Trading**: The ability to process millions of gas per second enables HFT-style applications with sub-second finality. * **Large-Scale Games**: Games requiring frequent state updates can now run entirely on-chain, with support for thousands of concurrent players. * **Data-Intensive Applications**: Applications that need to process and store large amounts of data can do so efficiently and economically. * **Sovereign applications** that want full control over their environment * Applications that want **flexibility in bridging solutions** # Modular Bridging A key innovation of ABC Stack comes from its deliberate decoupling of bridging from the core rollup functionality. ABC Rollup L1s are not tied to an enshrined bridge, and can implement custom bridging logic tailored to specific assets or use cases or operate without any bridges at all if they choose. ### **ABC rollups don't require a bridge to operate.**
This means you can create an application-specific blockchain that only uses assets native to the rollup itself. This includes defining your own native gas token for the rollup, rather than being required to use ETH bridged from Ethereum for transaction fees. For example, a gaming rollup can create its in-game currency to serve as both the primary token and the gas token, so that users can pay transaction fees with the same asset they use within the game. This simplifies the user experience by eliminating the need for users to hold multiple currencies just to interact with the rollup. It also removes dependency on external blockchains for basic operations, eliminates bridge-related security risks, and maximizes performance since the rollup doesn't need to maintain or process bridge-related operations. Developers can tailor the economic model of their gas token specifically for their application's needs rather than inheriting the properties and price volatility of an external blockchain's token. ### ABC allows you to bring your own bridge.
ABC's modular architecture allows you to select bridging solutions that match your exact requirements. Use any combination of bridging solutions based on your specific needs. Different bridges offer various trade-offs in terms of security, speed, asset support, and economic models. For instance, if your application demands security for high-value transactions, you can choose a bridge with stronger security guarantees. If your application needs fast finality for user experience, you can select a bridge optimized for speed. ### **Implement different bridges for different asset types or use cases within the same Rollup L1**.
Different user segments have different risk tolerances or speed requirements - professional traders prefer faster bridges with higher throughput, while institutions require bridges with specific security models or compliance features. For example, an ABC Stack rollup can use Hyperlane for general token transfers between chains and a specialized LayerZero (or custom Hyperlane) bridge for NFTs or other assets that ensures collection properties, royalties, and relationships between tokens are preserved when crossing from one ecosystem to the other. ### **Easily upgrade or change bridges without modifying the core rollup implementation.**
Bridge technology and standards evolve quickly. ABC's separation of bridging from the core rollup functionality means you can adopt new bridging solutions or upgrade existing ones without needing to modify or redeploy the underlying rollup. If a more efficient or secure bridging protocol emerges, simply integrate it with minimal disruption to your users. This also prevents lock-in if a bridge provider changes their fee structure, security model, or supported chains. Whether you want to use established solutions like Hyperlane, Decent, Socket, or LayerZero or build a completely custom bridge for specialized needs, ABC supports your choice. For applications with unique requirements, this means you can develop purpose-built bridging solutions that handle specific token types, implement custom security models, or connect to blockchains that aren't supported by mainstream bridges. # Gelato Hyperlane Cluster To simplify bridging setup, ABC Stack offers the Gelato Hyperlane Cluster as a pre-made bridging solution that's readily available and can be deployed with a single click. ### **What is the Gelato Hyperlane Cluster?** The Gelato Hyperlane Cluster is a collection of Gelato-operated Hyperlane Validators on multiple blockchains that validate cross-chain messages through [Interchain Security Modules](https://docs.hyperlane.xyz/docs/protocol/ISM/modular-security) (ISMs). This cluster: * Provides a ready-to-use bridging infrastructure for ABC rollups * Connects to existing Hyperlane mailboxes on chains like Base, Ethereum, Solana, and others * Is operated and maintained by Gelato, with integration from other trusted validators * Can be deployed with a single click through Gelato's RaaS platform # Hyperlane Components The Gelato Hyperlane Cluster leverages several key components of the Hyperlane protocol.
### **Hyperlane Mailbox** The Mailbox smart contracts form the foundation of Hyperlane's messaging infrastructure: * They expose an on-chain API for sending and receiving interchain messages * Messages are dispatched from the origin chain and delivered to the destination chain * The Mailbox maintains a merkle tree of all dispatched messages ### **Hyperlane Validators** Validators are responsible for attesting to the validity of cross-chain messages. They monitor the Mailbox on the origin chain, sign merkle roots that reflect the current state of the Mailbox, and provide cryptographic proofs that messages were actually sent The Gelato Hyperlane Cluster includes validators operated by Gelato, working alongside validators from Hyperlane, Decent, and other trusted partners. ### **Hyperlane Relayers** Relayers ensure messages are delivered from the origin chain to the destination. They monitor for dispatched messages on the origin chain, submit messages and validator signatures to the destination chain, and handle gas payments and transaction execution. Gelato operates dedicated relayers to ensure reliable message delivery for ABC rollups. ### **Interchain Security Modules (ISMs)** ISMs are smart contracts responsible for verifying that messages delivered to the destination chain were actually sent on the origin chain. They check validator signatures against a known set of trusted validators, can implement various security models (multisig, threshold, etc.), and allow for customizable security settings. ### **Hyperlane Warp Routes** Warp Routes provide the token bridging functionality. These allow for permissionless transfer of assets across chains and support native tokens, ERC20 tokens, and synthetic assets. Warp Routes can implement different bridging models based on token type. # Warp Route Types Hyperlane Warp Routes support several bridging models to accommodate different token types: ### **Native Token Warp Routes** For bridging of native gas tokens (e.g., ETH) between chains, these routes lock the tokens on the source chain, mint wrapped representations on the destination chain, and support direct transfers without requiring users to perform manual wrapping operations. This enables gas tokens to easily move across connected networks while maintaining their redeemability. ### **Collateral-Backed ERC20 Warp Routes** For existing ERC20 tokens, tokens are held as collateral in a contract on the source chain and synthetic representations are minted on the destination chain, using SafeERC20 standards to ensure tokens from established networks can be used across multiple chains while remaining fully backed by the original assets. ### **Synthetic ERC20 Warp Routes** When creating new representations of tokens, ERC20 Warp Routes create cross-chain representations of tokens that maintain consistent total supply across the network. When a token moves between chains, it's burned on the source chain and minted on the destination chain. These routes support custom token attributes (name, symbol, decimals) and are particularly useful for tokens native to the rollup that need presence on multiple chains. ![Source: docs.hyperlane.xyz](https://3510595974-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F02awWpWUSHgDHYXgy2bP%2Fuploads%2F0oHIYcibC06pZEl8JccJ%2F0.png?alt=media) # Bridging Process with Hyperlane Warp Routes When a user initiates a token transfer across chains, the process follows these steps: 1. **Message Sending**: The user calls `transferRemote` on the Warp Route contract, specifying the destination chain and recipient 2. **Token Handling**: Depending on the Warp Route type: * Native tokens are locked in the contract * ERC20 tokens are transferred to the contract * Synthetic tokens are burned 3. **Message Dispatch**: The Warp Route sends a message through the Hyperlane Mailbox with token details 4. **Validator Attestation**: Validators in the Gelato Hyperlane Cluster sign the message 5. **Message Relay**: The Gelato Hyperlane Relayer delivers the message to the destination chain 6. **Security Verification**: The ISM on the destination chain verifies validator signatures 7. **Token Release**: The destination Warp Route contract mints or releases tokens to the recipient # Getting Started with Modular Bridging To implement bridging for your ABC rollup, you have two primary options: ### **Use the Gelato Hyperlane Cluster (1-Click Deployment)** The simplest way to add bridging to your ABC rollup is through Gelato's 1-Click Modular Bridging. 1. Select your ABC rollup in the Gelato dashboard 2. Choose the destination chains you want to connect to 3. Select the tokens you want to bridge 4. Deploy with a single click This automatically sets up the Hyperlane infrastructure, deploying the necessary contracts and connecting your rollup to the Gelato Hyperlane Cluster. ### **Bring Your Own Bridge** If you prefer to use a different bridging solution: 1. Deploy your ABC rollup without bridging 2. Implement your chosen bridge 3. Configure the bridge according to your security and operational requirements By decoupling bridging from the core rollup functionality, ABC enables developers to build high-performance rollups that can flexibly connect to the broader blockchain ecosystem without compromising on throughput. Whether you choose the pre-configured Gelato Hyperlane Cluster or implement your own bridging solution, you can build the exact cross-chain experience your application requires.