Saga Liquidity Integration Layer

Part I

Introduction

As the number of chains, L2s, rollups and other base infrastructure dramatically increased over the last cycle, liquidity fragmentation became an immovable problem in the blockchain ecosystem. New technologies such as chain abstraction, intents, and aggregator solutions have emerged to help address the challenges around liquidity fragmentation. However, most of these solutions require infrastructure that is manually jerry-rigged, resulting in a sub-optimal developer and user experience.

Saga is a Layer 1 protocol that allows developers to automatically spin up chainlets that provide applications with infinite horizontal scalability. Does Saga’s “infinite horizontal scalability” also therefore result in infinite liquidity fragmentation?

In this paper, we introduce Saga’s Liquidity Integration Layer (LIL) that solves the liquidity fragmentation problem.

Why does Liquidity Naturally Fragment in the Current Meta?

Liquidity fragmentation is fundamentally caused by the lack of composability between applications in two different chains. In a shared L1, every application is fully composable: when a new application is deployed, it automatically acquires access to every other application that has already been deployed on that L1. For this reason, liquidity fragmentation is not an issue on a single L1.

In a horizontally scaled multi-chain world, things get much more complicated. At the very minimum, the developer needs to manually set up bridges to every chain they want to interact with. Even when the bridges are all set up, cross-chain interactions have usability issues. This is because three distinct stakeholders are involved for every cross-chain interaction: the source chain, bridge operators, and the destination chain. Generally speaking, each of these stakeholders is a disparate collection of projects and operate under different technical and economic models that complicate deployments.

If an application on Chain A wants to access liquidity on Chain B, the developer needs to fight against technology limitations as well as payment flows with the bridge operator (bridge fees) and Chain A validators (transaction fees) and Chain B validators (transaction fees). The developer also needs to manage 3 different UX flows related to the three stakeholders. An experience where the users transition between DEX UI, bridge UI, and application UI is not a viable solution.

However, liquidity that is pooled natively in Chain A is fully composable with all applications on Chain A. It is simply easier for Chain A to pool liquidity in Chain A instead of tapping into liquidity in Chain B. Ergo, liquidity fragments.

How do you solve the liquidity fragmentation problem? Restoring composability across multiple chains is the key to solving liquidity fragmentation. When liquidity in Chain B is just as easy to access as liquidity in Chain A, then liquidity fragmentation is no longer an issue.

Liquidity Fragmentation in Saga

In Saga, a developer can request a chainlet through a simple transaction. Validators monitor the Saga mainnet for this chainlet request transaction and provision a new chainlet automatically without any manual intervention. With an automated system like Saga, horizontally scaling your application is as simple as requesting a second chainlet.

Because every application is potentially on different chainlets (and potentially across multiple chainlets), liquidity is at risk of fragmenting. However, due to Saga’s unique integrated architecture, we are uniquely positioned to solve liquidity fragmentation.

Introducing the Saga Liquidity Integration Layer

Saga’s Liquidity Integration Layer introduces automatic composability into the Saga ecosystem. When a developer launches a fresh new chainlet, it will automatically be connected to the LIL. Through the LIL, this fresh chainlet will have immediate access to tokens, services, and applications on other chainlets as well as other ecosystems outside of Saga.

The LIL is a combination of four innovative products:

• Automatic bridges from the LIL to every chainlet
• A router that determines a canonical hub for all liquidity to route through
• Packet-forwarding middleware that automates routing
• Hooks to enable cross-chain smart contract calls

By combining these four products, the Liquidity Integration Layer enables developers to:

• Bring in USDC, SAGA or ETH into the developer’s chainlet
• Mint a token on a chainlet and, using a simple command, bridge the token to a DEX, swap to another token, and bridge the swapped token back into the developer’s chainlet
• Mint an NFT on a chainlet and, using a single API, move the NFT to an NFT marketplace and list the NFT for sale

Even though developers deploy on their own chainlet, the LIL grants automatic access to applications on every other chain and ecosystem. Through the LIL, developers can finally choose both composability AND scalability.

The Liquidity Integration Layer is designed such that:

• All infrastructure is automatically provisioned and immediately available
• Routing messages from chainlets through the Liquidity Integration Layer and back is automatically managed
• The developer can interact with a unified and simple API / UX to access the Liquidity Integration Layer
• Cross-chain execution enables composable applications across the Saga ecosystem

Let’s dive deeper into the various innovations that enable the Saga Liquidity Integration Layer.

Saga Liquidity Integration Layer Innovations

First Innovation: Automatic bridge deployment

Easy access to liquidity depends on an automatic setup of bridging infrastructure. Prior to Saga’s Liquidity Integration Layer, developers had two choices: roll and operate their own bridge or convince a bridge partner to support their chain. Neither option is particularly appetizing as operating a bridge is highly complicated and risky while convincing bridge operators to support a new chainlet may take many months. Is there a way to automate the bridging process?

As mentioned previously, automating bridging is normally a difficult task because there are three distinct stakeholders involved: the source chain, bridge operators, and the destination chain. Generally speaking, each of these stakeholders is a disparate collection of projects and operate under different technical and economic models that complicate deployments.

However, in Saga, the picture is significantly simpler. The source and destination chains are operated by the same set of validators. By embedding the bridge relayer logic directly into the validator binary, the validators can also operate the bridges. Once embedded, the validators’ services can natively include operating the bridges within the Saga ecosystem. Saga is one of the first blockchains ever to have protocol-native bridge infrastructure.

Saga’s protocol-native bridge solution automates the provisioning of Inter-Blockchain Communication (IBC) bridges within the Saga ecosystem. The developer does not need to do anything extra besides launch their chainlet.

Another major benefit of a protocol-native bridge is that because the source and destination chains are all operated by the same validators, bridges in the Saga Liquidity Integration Layer can be all free and gasless to the developer. These benefits translate to a usable UI and UX for both the developers and end users of Saga.

Second Innovation: Automatic liquidity routes

While free and automatic bridges within the Saga ecosystem are amazing, canonical routes are helpful in establishing the topology of the network. Directly connecting every chainlet with every other chainlet is technically possible with Saga’s automatic bridge deployments. However, the topology can quickly become too complex due to token fungibility issues.

In addition to connections across all chainlets, developers need bridges to ecosystems outside of Saga such as Ethereum, Solana, etc. Ideally, each chainlet does not need to manually stand up bridges to various ecosystems. Saga’s Liquidity Integration Layer automates this process by creating a router (LIL Chainlet).

The LIL Chainlet is simply just another chainlet all bridges route through. Using the protocol-native bridge solution, every chainlet is automatically connected to the LIL Chainlet. By proxy, all chainlets will have automatic access to any ecosystems bridged from the LIL Chainlet. This topology is starting to feel as composable as an L1!

Third Innovation: Automatic packet forwarding

With the LIL Chainlet, canonical routes are set up through the Saga ecosystem. However, there’s a new issue introduced by the topology: every bridge transaction now requires at least two hops. For example, a simple Chainlet A to Chainlet B communication requires one bridge transaction from Chainlet A to LIL Chainlet and another transaction from the LIL Chainlet to Chainlet B. Traditionally, the user experience for these kinds of multi-hop bridges is not smooth. The developer or user must wait for confirmation of completion of the first hop before manually initiating a second bridge transaction. Not only is this a mechanical nuisance, it also forces the users to know the bridge infrastructure topology. We can solve this user experience problem using packet forwarding.

IBC packet forwarding allows multi-hop bridge transactions utilizing the memo field (similar to calldata on Ethereum) of a transaction. The Liquidity Integration Layer can automatically daisy chain as many forward requests as needed to route through the relayer topology. With the LIL Chainlet, the routes are relatively simple across the Saga ecosystem. All routes always begin with a path down to the LIL Chainlet. Generally, LIL Chainlet has no inherent functionality besides routing, so all routes eventually end with a path to another chain (whether it is a chainlet or outside ecosystem).

Saga’s Liquidity Integration Layer automates the routing within the Saga ecosystem and facilitates usable UI and UX for both the developers and end users of Saga.

Fourth Innovation: Automatic cross-chain execution

The final part of a fully composable system is the ability to access applications across any chain from any chainlet. Once the message passes through the LIL into the destination chain, developers want the ability to automatically execute a transaction on the destination chain. The Saga Liquidity Integration Layer accomplishes this using ADR-8 actor callbacks.

Actor callbacks are conceptually similar to packet forwarding, where a specific transaction is executed on the destination chain after a set of transactions (for example a series of bridge transactions) is complete. By utilizing IBC hooks, we can embed any EVM transaction with the route transaction to be executed once the packet arrives in the destination chainlet.

If Chainlet B has a DEX smart contract (like Uniswap) deployed, any arbitrary chainlet can utilize the Saga Liquidity Integration Layer to automatically route an asset to Chainlet B, swap for another token then move the swapped token back to the originating chainlet. In fact, with cross-chain execution, the Saga Liquidity Integration Layer introduces application composability to all chainlets. Any smart contract deployed on any chainlet on Saga is automatically and instantly accessible to all developers.

Conclusion

By combining the four innovations, Saga’s LIL is able to automatically solve composability and liquidity fragmentation. The magic of the Liquidity Integration Layer is the automated access — the developer does not need to do anything manual or extra beyond spinning up a chainlet. A chainlet simply comes equipped with all the features of the LIL.

Saga is not the first and only decentralized blockchain protocol to champion horizontal scalability. Appchains (Cosmos, Avax Subnet, Polkadot) and rollups (Ethereum L2s, RaaS, Polygon CDK) are all horizontal designs that are available for developers. However, most of these scaling solutions introduce insurmountable complexities for the developer, chief of which is liquidity fragmentation. Horizontal scalability that introduces insurmountable difficulties and complexity for the developer is merely promising theoretical scalability. Practically, a blockchain protocol is only as scalable as how easy it is to use. A truly scalable infrastructure needs to be horizontally scalable but also be a product that people will actually use.

What differentiates Saga is the integrated approach to horizontal scalability. In our Unblock Manifesto, we outlined Saga’s platform-based approach to disrupting the web3 space by focusing on developer needs and ease of use. Saga’s mission is to integrate the complete product experience and offer practical scalability to developers.

With Saga, developers can finally choose both composability AND scalability. Whether it is gaming, entertainment, DeFi, social or other use cases, Saga is the best infrastructure for developers. By combining practical and usable solutions with horizontal scalability, Saga unlocks the “infinite” in infinite horizontal scalability.

For further information, follow us on Twitter, join our Discord and Telegram and subscribe to our Medium.