1. Introduction: The Multi-Chain Liquidity Problem
The public blockchain ecosystem is no longer single-chain; it is inherently multi-chain, with L1s, L2s, rollups, and appchains coexisting.
Instead of operating assets within a single network, users move their assets across multiple chains to allocate, transfer, and swap them. In the process, both liquidity and user experience are fragmented at the chain level, and service providers find themselves facing the challenge of integrating infrastructure separately for each chain.
1.1 Fragmented Chains/Liquidity and User Experience
Today’s Web3 liquidity is spread across chains, centered around chain-specific DEXes, bridges, and token standards as L1s, L2s, rollups, and appchains proliferate. Even for “the same asset,” the wrapping format and circulation path differ by chain, and users must constantly deal with the inconvenience of having to check which chain they hold it on and in what form.
When we go down to the actual usage flows, the problem becomes clearer. During onboarding, users often have to chain together bridge usage, CEX transfers, DEX swaps, and gas token acquisition. Different UI and security models apply at each step, increasing operational complexity end-to-end. From a service provider’s point of view, to handle users coming in from any chain, they must repeatedly design onboarding, payment, and withdrawal flows for each chain.
1.2 Limitations of Bridge/CEX-Centric Multi-Chain UX
As a response to liquidity fragmentation in multi-chain environments, the use of bridges and CEXes has become the dominant approach. Bridges provide the ability to recreate tokens across chains, but their implementations and security models vary widely. And users must not only choose a bridge and assess the associated risks themselves, but also repeatedly go through separate swap and gas-funding steps even after switching chains.
CEX-based routing may look simple in the short term, but it creates heavy dependence on account/KYC/withdrawal policies and is vulnerable to regulatory and policy changes.
More importantly, both approaches focus on moving tokens, but do not tie onboarding, payment, and additional contract calls into a single coherent flow.
Ultimately, the problem converges not on “how to move tokens,” but on “how to unify multi-chain execution flows into a single experience.” Squid is a cross-chain liquidity router designed to address exactly that challenge.
2. Cross-Chain Stack: Infra vs Application
In a multi-chain environment, the interoperability stack can broadly be divided into two layers:
An infrastructure layer that enables cross-chain messaging and token movement
An application layer that composes real scenarios on top of that foundation (swaps, gas handling, app entry, etc.)
To understand Squid, it helps to first separate what the infrastructure layer guarantees from what the application layer designs.
2.1 Infra Layer: Messaging and Bridging (Axelar, Wormhole, LayerZero)
The infrastructure layer is responsible for “cross-chain delivery.” In other words, it provides common patterns that allow messages (call data) and tokens (value) to move across chains. Protocols such as Axelar, Wormhole, and LayerZero build the foundation for interoperability at this level.
Two points matter here:
The infrastructure layer provides standardized primitives for cross-chain messaging and token movement.
On top of those primitives, a separate application decides what to swap, which route to take, how to handle gas, and which contracts to call.
In short, infrastructure is closer to building roads between chains. On top of those roads, you still need an application layer that composes swaps, gas funding, and contract calls into a user-facing flow.
2.2 Infrastructure Layer vs Application Layer
If infrastructure makes “delivery” possible, Squid is the routing layer that designs the “execution” flow on top of it.
A roads-and-transport analogy makes the distinction intuitive:
Infra (e.g., Axelar/Wormhole/LayerZero) = road network
It corresponds to the highways and roads that connect different cities (chains).
It determines where roads are open and in which directions vehicles can move.
Squid = transport service (navigation/toll system)
It designs which route users take when traveling from city A to city B, and where they transfer or stop along the way.
It composes liquidity pools, DEXes, gas tokens, and additional contract calls into a concrete travel experience.
While the infrastructure layer focuses on defining cross-chain deliverability, the application-layer router Squid—built on Axelar’s GMP—takes on the role of composing and executing the actual end-to-end execution flow.
3. Squid: A Multi-Chain Liquidity and Payments Router
Once chains can be connected, Squid completes the flow with payment and execution.
The key challenge is how to design a single consistent entry point for users and services in an environment where chains and assets are all heterogeneous.
3.1 Cross-Chain UX and Liquidity Problems Targeted by Squid
In a multi-chain environment, users face challenges that go beyond the complexity of simply managing multiple chains.
When attempting to move from holding assets on one chain to using DeFi, NFT marketplaces, or games on another, the steps required for asset transfer and execution become fragmented across multiple stages.
Swap tokens on the source chain into a stablecoin or other bridge-friendly asset
Bridge that asset to the destination chain
Swap again into the desired token on the destination chain
If necessary, acquire gas tokens and finally call the target application contract
Each step requires a separate interface, a separate signature, and a separate fee, with many opportunities for mistakes and risk along the way. As chain/token combinations become slightly more complex, users tend to prefer detouring via a CEX.
From the perspective of service providers and developers, the trade-off is also clear. If you concentrate liquidity on a single chain, onboarding remains simple, but you effectively give up multi-chain users. Conversely, if you directly integrate multiple bridges and DEXes to implement a cross-chain UX, you face growing burdens such as:
Managing edge cases for each combination of chain, token, and bridge
Increased operational complexity around gas funding, failure rollback, and fee structures
In the end, there is a gap between the two requirements: services want a single entry point no matter which chain users come from, while users want an entry experience about as simple as a CEX. Squid is a cross-chain liquidity and payments router application designed to narrow this gap.
3.2 Squid’s Role: Cross-Chain Liquidity and Payments Routing
Squid is a cross-chain liquidity & payments router application that unifies DEX liquidity across multiple chains into a single router.
From a user’s point of view, they can submit a single request like “token A on chain X → token B on chain Y + (optionally) a specific contract call,” and Squid composes the underlying bridge path, swap route, and contract-call sequence.
Summarizing Squid’s role in solving the cross-chain UX and liquidity problem:
Liquidity routing
Squid connects liquidity that is scattered across chains and DEXes, and finds & executes an optimal route (in terms of cost and path) for converting token X into token Y on another chain. Bridges and swaps are handled as a single flow.
Payments/onboarding routing + additional contract calls
Beyond simple swaps, Squid is designed to call a specific contract on the destination chain in one go. For example, buying an NFT on chain B with assets from chain A, or entering a DeFi position on chain C with tokens from chain A can be handled within a single transaction flow.
From the perspective of service providers, Squid offers a way to delegate the design of multi-chain liquidity and payment infrastructure to a single router rather than building it all in-house.
Developers can define only the chain, token, and contract they want users to ultimately reach through the Squid SDK/API, and the combination of Axelar + Squid takes care of the intermediate steps: bridging, swapping, gas handling, and message passing.
As a result, Squid delivers a CEX-like user experience while operating on a decentralized cross-chain stack.
4. Squid Technical Architecture: Design and Transaction Flow
From a technical perspective, Squid can be analyzed along three axes:
How it connects DEXes and liquidity across chains to find routes
How it uses Axelar GMP to execute cross-chain swaps and contract calls
How developers can integrate Squid into real services in practice
4.1 Liquidity Routing: Connecting Chains and DEXes
Squid’s basic unit is a swap path between token A and token B. Here, A and B may live on the same chain or on different chains. Squid aggregates DEXes and liquidity pools across chains to construct executable swap routes for each requested combination of source/destination asset and chain.
Conceptually, the structure is as follows:
The Squid router composes source asset → intermediate bridge asset → destination asset flows by combining DEXes and pools integrated on each chain.
Swaps within the same chain are handled by that chain’s DEXes, and only the segments that require chain-to-chain movement are handled via Axelar.
Service developers do not need to manage liquidity or design bridge/swap combinations for each chain and DEX. They only define the assets and chains the user holds and what the service wants to receive. Squid’s routing logic handles the path finding and execution in between.
4.2 Cross-Chain Swap and Call Flow Based on Axelar GMP
Squid’s cross-chain swap and contract-call flow is built on Axelar’s General Message Passing (GMP). Conceptually, it works as follows:
Calling the Squid contract on the source chain
The user calls the SquidRouter contract on the source chain, requesting conversion from their current token into a specific token on the destination chain (optionally with a contract call on that destination). If needed, a swap is performed on the source chain first to convert the asset into a bridge-friendly form.
Message passing and chain-to-chain movement via Axelar
The SquidRouter contract constructs a message, via the Axelar Gateway, that includes which contract to call on the destination chain and with which parameters. The Axelar validator set reaches consensus on the event on the source chain and relays the message to the destination chain.
Swaps and contract execution on the destination chain
On the destination chain, the SquidRouter contract receives the message via the Axelar Gateway, performs any required swaps via DEXes, and finally calls the specified contract (e.g. a DeFi protocol, NFT marketplace, or game contract). From the user’s point of view, they have only sent a single transaction on the source chain, yet end up with both token conversion and contract execution completed on the destination chain.
This structure allows users to avoid manually performing bridge → swap → gas acquisition → contract call as separate steps. Axelar handles cross-chain messaging and state propagation, while Squid composes asset conversion and contract-call sequences on top.
4.3 Developer Experience: SDK, API, and Widget Integration Patterns
From a service developer’s perspective, Squid is less a pure backend infrastructure component for cross-chain functionality and more an application-level tool that can be easily integrated into both the frontend and backend.
Squid supports two integration paths to provide a flexible developer experience.
Cross-chain widget integration
A low-friction option where services embed Squid’s provided UI widgets directly into their views. Users choose source/destination chains and tokens through the widget, and the service only needs to consume the outcome and connect it to their final contract.
API/SDK integration
When more fine-grained control is needed, developers can use the JS SDK or REST API to construct routing requests directly and handle transaction creation, signing, and status tracking within their application logic.
This integration approach allows service providers to avoid designing multi-chain onboarding, payment, and funding flows from scratch. Instead, they can quickly set up cross-chain UX through Squid and spend more time on the business logic itself.
Additionally, Squid offers execution options such as CORAL / CORAL V2, pointing toward more extensible routing and execution flows beyond basic swaps.
5. Integrator and Ecosystem View: Squid as Multi-Chain Stablecoin/RWA Rails
For teams operating services in a multi-chain environment, the real concern is less about “which bridge to choose” and more about how to converge users and liquidity dispersed across chains into a single onboarding and payment flow.
Squid absorbs these fragmented entry points into a single liquidity and payments routing layer, providing an experience close to a single entry point for both services and users.
5.1 Common Benefits for Live Services (DeFi, Games, Infrastructure)
Projects considering multi-chain expansion typically face two options:
Focus on a single chain to keep onboarding simple, while essentially giving up a large portion of users/liquidity on other chains
Support multiple chains, but accept complex onboarding flows by designing bridge/DEX/gas onboarding separately for each chain
The latter expands the user pool and usage surface, but onboarding paths become complex and conversion rates are likely to drop. In particular, managing different bridges and swap routes for each chain becomes an ongoing operational burden.
Squid simplifies this by acting as a multi-chain entry point via a single router. Services only need to define two things:
Which chains/tokens users may enter with (set of source chains/tokens)
Which chain/token the service ultimately wants to receive (set of destination chains/tokens)
The combination of bridges and DEXes in between, gas token acquisition, and the sequence of any additional contract calls are handled by Squid’s routing logic. As a result, services no longer need to design separate onboarding flows for each chain, but can build a single entry screen that accepts users from multiple chains.
From a UX standpoint, this makes chainless onboarding more achievable. Users do not need to worry about which chain they are currently on or which bridge they should use; they can keep a simple mental model of “I use the assets in my wallet to enter this service.” DeFi, gaming, and infrastructure projects can design multi-chain services where users start with the same UX regardless of entry chain, reducing drop-off during onboarding while expanding the range of supported chains.
5.2 Impact for Stablecoin and RWA/STO Projects
Stablecoin and RWA/STO projects need to manage issuance, redemption, and settlement on a hub chain that fits regulatory, accounting, and risk-management requirements, while distributing and redeeming tokens on multiple sub-chains where real-world investment, payments, and trading demand exist.
Traditional approaches are typically some combination of:
Listing on major CEXes and securing trading pairs
Building custom bridges for each chain
Designing distinct on/off-ramp and settlement logic for each chain
This can look flexible initially, but as the number of chains and bridges grows, the cost and complexity of maintaining separate settlement, risk, and monitoring frameworks for each configuration rise quickly.
Squid reframes this problem as a common multi-chain distribution rail. You can design a structure where the hub chain remains the control point for cross-chain circulation state and supply flow, while inflows and redemptions on surrounding chains—where investment and payment traffic actually happens—are handled through Squid routing.
Issuers and financial institutions can manage issuance, redemption, circulating supply, and risk from the hub chain while simultaneously achieving:
A consistent user experience where the same asset can be used on any chain
Reduced dependence on CEXes and custom bridges, and lower operational overhead for multi-chain operations
Here, Squid is not the issuer of tokens, but the router that designs and executes how already-issued assets are used and redeemed across chains. Maintaining the structure of hub-chain-centric accounting and regulatory compliance with sub-chains investment/payment usage in a consistent pattern is also beneficial for regulatory and audit responses.
6. Conclusion: Squid’s Strategic Position as Multi-Chain Stablecoin/RWA Rails
Discussions around stablecoins and RWAs have largely focused on which chains and bridges are safer and faster. However, safety and speed alone are not sufficient. From a UX perspective, the additional question in a multi-chain environment is:
“Can we handle multiple chains and assets within a single, consistent onboarding, payment, and settlement flow?”
Interoperability networks provides an infrastructure-level answer as an interoperability network, while Squid acts as the application that unifies liquidity routing and payment flows on top of it.
Instead of interpreting different rules and UX patterns for every bridge and chain, projects can implement multi-chain onboarding, distribution, and redemption as common patterns on the combined stack of infrastructure + Squid router.
Today, Squid offers widget and API/SDK integrations for 100+ chains, including EVM, BTC, Solana, XRPL, Hedera, and Cosmos. It has safely processed over 3 million cross-chain transactions with cumulative volume exceeding $5 billion. Integrations with major wallets, DEXes, swap services, and infrastructure protocols such as MetaMask, PancakeSwap, Trust Wallet, dYdX, and Circle are already in place.
By leveraging this already-proven common rail, projects can concentrate regulatory, accounting, and risk frameworks on a chosen hub chain while implementing distribution and payment expansion to surrounding chains through relatively lightweight integrations.
Therefore, Squid is not just a simple cross-chain swap tool, but an application that can play the following roles in a multi-chain stablecoin and RWA environment:
From the service perspective: a multi-chain entry rail where users can onboard in a single flow from any chain
From the issuer and financial-institution perspective: a distribution and redemption rail that manages multi-chain circulation from the hub chain’s point of view
Building on these roles, Squid is moving at the forefront as multi-chain stablecoins and RWAs transition from “infrastructure” to real-world usage. It delivers an end-to-end UX that completes swaps, bridging, gas handling, and contract calls in a single request, while offering services a practical way to “delegate” multi-chain operational complexity to the router.
As multi-chain stablecoins and RWAs move to the center of the industry agenda, Squid is recognized as a leading player in cross-chain liquidity routing.
Key References
Squid Is Cross-Chain Liquidity for Everyone - Axelar Blog
Squid: Single Click Cross-Chain Swaps and Messaging
Other References
The State of Cross-Chain Messaging: Squid Router x Axelar Core
Squid Router and the Future of Interchain Liquidity
Introducing Cross-Chain Swaps with Axelar on our DEX Aggregator (Use-Case)
Disclaimer
The contents of this report are for informational purposes only and do not constitute a recommendation or basis for legal, business, investment, or tax advice under any circumstances. References to specific assets or securities are for informational purposes only and do not represent an offer, solicitation, or recommendation to invest. The final responsibility for any investment decisions lies solely with the investor, and this report should not be used as a guideline for accounting or legal judgment.
As a matter of principle, the author does not trade related assets using material non-public information obtained during the research or drafting process. The author and Catalyze may have financial interests in the assets or tokens discussed herein and may serve as a strategic partner to certain networks.
The opinions and analyses expressed in this report reflect the author's personal views and do not necessarily represent the official position of Catalyze or its affiliates. All information is current as of the date of publication and is subject to change without prior notice.