Liquidity Availability, Where Liquidity Meets Innovation

Key Takeaways

• One of the most frequently debated topics in the modular vs. integrated blockchain discussion is liquidity. Modular blockchains often fragment liquidity across various rollups, whereas proponents of integrated chains argue that, since applications operate on a single shard, liquidity is inherently consolidated.
  

• However, even integrated chains that claim to have unified liquidity still face liquidity fragmentation in practice. Even if applications run on the same shard, if liquidity is siloed within a specific app, it becomes inaccessible to others. In that sense, the claim that integrated chains have integrated liquidity can be somewhat overstated.
  

• To address this issue, Injective Research introduced the concept of “liquidity accessibility”, and explored how it can be optimized. While maximizing liquidity accessibility will require significant effort and time, achieving it could usher in a new paradigm for on-chain finance.

Whenever there's a debate about modular vs. integrated blockchains in the industry, one topic that invariably comes up is "whether applications/networks can share liquidity."

In the case of modular blockchains with separate networks, the fragmented liquidity across each rollup creates high costs (having to build new liquidity for each network). On the other hand, integrated blockchains have all liquidity consolidated in a single shard, resulting in relatively lower costs. I emphasized this advantage when writing about Deepbook, Sui's liquidity layer.

However, even integrated chains don't have perfectly integrated liquidity. For example, in the case of Deepbook mentioned above, the concentrated liquidity is only provided to orderbook-based applications. This means the liquidity isn't shared with other DeFi applications like lending or swaps. These limitations were also evident in Serum, introduced by Solana.

In a way, these platforms are only utilizing half the advantages of integrated blockchains. To truly maximize the benefit of using a single shard in integrated blockchains, all applications on that blockchain should achieve liquidity efficiency by leveraging integrated liquidity.

What if there were a network-level solution that allowed liquidity provided to the network to be freely utilized across various applications—not just orderbook-based exchanges, but also lending, insurance, staking, token bridges, swaps, etc.—whenever needed? Interestingly, there is a blockchain preparing such a solution: Injective.

Injective introduces the concept of "Liquidity Availability" to explain this solution. In this article, we'll first examine what liquidity availability is, understand it by comparing it with traditional finance cases, and then look at various liquidity availability optimization mechanisms proposed by Injective. Finally, we'll explore what these optimization efforts mean for both Injective and the broader blockchain ecosystem.

1. What Is Liquidity Availability?

According to a research paper published by Injective Research, Liquidity Availability refers to the ability to meet the liquidity needed to successfully execute any types of transactions at any time under specific constraints. In other words, if these liquidity requirements cannot be met, we can say "liquidity availability is low," and conversely, if they can be sufficiently met, "liquidity availability is high."

Therefore, liquidity availability itself is not an answer to liquidity problems, but rather an indicator that helps gauge how well each network or application is equipped with liquidity. For example, when applying this concept at the application level, liquidity availability only refers to the liquidity isolated within the application. This is because each application typically sources the liquidity needed to execute trades only from its own liquidity pools.

The problem is that most applications do not have sufficient liquidity. While some major DeFi protocols have abundant liquidity of their own, ensuring liquidity availability, the most applications not only have insufficient liquidity themselves, but even that limited liquidity is isolated within individual applications when viewed at the network level. This problem of liquidity not being distributed but remaining in one place has long been considered a chronic challenge in the industry.

And this 'liquidity isolation problem' typically manifests in two forms. Next, we'll look at how each form specifically operates and what problems it causes.

1.1 Two Types of Liquidity Isolation: Network Level and Application Level

The two types of liquidity isolation can be divided into Network-Level Isolation and Intra-Application Constraints. The former refers to isolation where liquidity exists only in specific applications, making it impossible to utilize in other applications within the same network. The latter refers to a state where liquidity is tied to specific pools even within individual applications, preventing liquidity from being used for other purposes within the application itself.

Let's explain each type of isolation further. Most financial applications built on blockchain today receive assets from liquidity providers (LPs) and deposit them into designated pools that process only specific transactions. For example, decentralized exchanges (DEXs) attract liquidity to pools for asset swaps, while lending protocols attract liquidity to lending pools exclusively for loans. However, these two can never directly use the liquidity deposited in each other's pools. In this case, we can say that liquidity is isolated at the network level.

Another problem is the inability to freely utilize liquidity within a single application. Just because a particular pool in a DEX has a lot of liquidity doesn't mean this application has abundant liquidity availability, as this liquidity cannot be arbitrarily moved to other pools. We can say that liquidity is isolated within the application in this case.

Therefore, the concept of Total Value Locked (TVL), which is the most commonly observed metric when examining liquidity deposited in blockchains, can be considered quite ambiguous. This is because TVL does not explain how much liquidity is available at the network level (for example, if one DEX on Chain A holds 90% of Chain A's TVL, and this liquidity cannot be used by other DeFi protocols, can it truly be said to represent Chain A's liquidity?).

In other words, to solve these two problems, we need to increase not only the liquidity availability of a single application (which can also be considered important) but also the liquidity availability at the network level. So what should we do to increase this liquidity availability? I think the easiest way is to look at similar examples in existing industries and benchmark them. This is because there are cases in traditional finance where liquidity availability has been maximized.

2. Lessons Learned From TradFi

Blockchain and decentralized finance enthusiasts tend to dismiss traditional finance due to its centralized nature, but there are clear reasons why traditional finance has ruled the world for so long. Their systems operate more intricately and efficiently than one might think. While traditional finance certainly has its downsides, which is why many Web3 developers are trying to create alternatives, there are many aspects of their legacy that we must observe and learn from. In a way, liquidity availability in traditional finance could be considered one of these aspects. Let's examine what mechanisms traditional finance uses to secure liquidity availability.

2.1 Credit - A means to raise capital when needed

When discussing liquidity in traditional finance, credit is the most important element. Credit is the foundation and infrastructure supporting the modern financial system. Credit provides the ability to borrow funds or assets on the condition of future repayment, immediately satisfying liquidity needs when necessary. For example, credit cards are tools that supply continuous liquidity to consumers and businesses (while our payday is fixed, we can "consume" through credit cards even when we don't have money in our account immediately). Through the credit system, borrowers can bring future consumption forward to the present, and lenders can defer present consumption to the future.

So has such credit been well implemented in Web3? While there has been "some" implementation (through lending protocols), it still hasn't caught up with traditional finance's credit system in terms of capital efficiency.

2.2 Insurance - Financial protection against future uncertainties

Insurance mechanisms strengthen liquidity availability by collecting funds during normal times to provide financial protection against potential future losses. This allows not only individuals but also companies to respond effectively to economic fluctuations and maintain liquidity even in difficult market situations (for example, an uninsured person would have to spend a lump sum when sick, but someone with insurance can cover hospital expenses through insurance when sick because they have consistently paid premiums even when not ill).

2.3 Refinancing -Providing better financial environments depending on circumstances

Those who have taken out loans will be familiar with the concept of refinancing. Refinancing allows borrowers to readjust or replace existing credit agreements, enabling them to take advantage of favorable financial environments and improve their liquidity management capabilities. In particular, refinancing ensures liquidity availability by allowing debt holders to lower interest rates or extend repayment periods.

2.4 Clearing Houses - Enhancing efficiency in financial product transactions

Clearing houses refer to entities that act as intermediaries between buyers and sellers of financial products. They not only settle transactions but also collect margins to ensure that financial product transactions occur efficiently while mitigating risks. A prime example is the U.S. Depository Trust & Clearing Corporation, which processes securities transactions in the United States and provides safe and reliable liquidity.

2.5 Interbank Lending Markets - Optimizing liquidity distribution between banks

Interbank lending literally streamlines liquidity distribution within the banking system. Benchmark rates such as SOFR (Secured Overnight Financing Rate) influence borrowing and lending costs across the financial system, allowing liquidity to be efficiently allocated where needed. The U.S. Federal Funds Rate market is another example of an interbank lending market.

2.6 Escrow - Protecting the assets of transaction parties

Escrow services function by holding assets or funds on behalf of transaction parties until contractual obligations are fulfilled, encouraging the fulfillment of contractual obligations by holding assets until transactions proceed smoothly.

(In fact, many blockchain/crypto-related products currently use escrow-based models, so it can be said that decentralized finance is already borrowing mechanisms from traditional finance.)

2.7 Dealers and Market Makers - Ensuring liquidity for financial products

Dealers and market makers, such as large investment banks, continuously provide bid/ask quotes for specific financial products, ensuring that there is always a counterparty available when someone wants to trade a product (a seller when buying, a buyer when selling).

As we can see, the way traditional financial systems ensure liquidity availability is not driven by a single mechanism, but rather by various mechanisms working together to supply liquidity to the market and optimize infrastructure so that liquidity can be "guaranteed" when needed. Blockchain is no different. For Injective to guarantee liquidity availability at the network level, it doesn't just need one innovative mechanism, but rather various mechanisms working together to distribute liquidity appropriately whenever needed. Of course, it may not be possible to adopt all mechanisms from traditional finance as they are, but there are certainly hints that can be gained from these mechanisms. So what mechanisms is Injective considering to optimize liquidity availability?

3. Optimizing Liquidity Availability in Blockchain

"Appropriately moving liquidity within a network between dApps" may seem simple, but it's actually not that simple. In blockchain, liquidity is attracted from users, and they have 100% authority over their liquidity (since blockchain enables self-custody). Also, the interests between applications need to be considered. For example, what happens when a liquidity provider wants to withdraw liquidity deposited in a dApp, but that capital is being used elsewhere? Or if an application attracts liquidity by providing incentives, but that liquidity is used free of charge by another application that could potentially be a competitor, then no applications would have any incentive to individually attract liquidity. Thus, utilizing liquidity within a network in a timely manner is not as easy as it sounds.

To solve this problem, Injective Research introduces about four mechanisms.

3.1 Providing Economic Incentives and Minimizing Risk

First and foremost, incentives are crucial. Both people providing liquidity and applications must have more incentives to contribute to improving network-level liquidity availability than not to "voluntarily" participate in enhancing network-level liquidity availability. For example, applications that cooperate in increasing network-level liquidity availability can secure more liquidity, which improves user experience, increases transaction volume, attracts more users, and earns more fees, creating a flywheel structure.

At the same time, it's necessary to minimize the risk for liquidity providers. While their liquidity is freely used, a mechanism is needed to ensure that withdrawal requests are processed smoothly whenever they want to recover their funds, preventing bank run situations. For example, creating reserves at the network level to provide liquidity for urgent withdrawals could be one method. Of course, further discussion is needed on how much and how to create and operate these reserves (in my opinion, a good strategy would be to refer to the reserve requirements of commercial banks but make more conservative calculations to block potential bank run situations).

3.2 Just-In-Time (JIT) Action

Just-In-Time action refers to executing transactions in response to changes in chain state when predefined trigger conditions are met. JIT action can be divided into several sub-features as follows:

3.2.1 Trigger Mechanisms

As explained about JIT action, this mechanism starts when a specific trigger occurs. Triggers occur according to changes in chain state, including sudden resource demand surges, changes in user activity, and changes in network state.

3.2.2 Asynchronous Interfaces for Integration

Asynchronous interfaces allow dApps to conditionally interact with JIT mechanisms (this condition can be set variously, for example, if there is unused idle liquidity in DEX A, it can supply A's liquidity to the liquidity availability system, or conversely, it can bring liquidity from the liquidity availability system). Through this, dApps can contribute their liquidity to other places or retrieve it under specific conditions, optimizing network-level liquidity.

3.2.3 Instruction

When a trigger occurs through the trigger mechanism, an instruction sequence is executed. The instructions executed here can also be performed sequentially.

3.2.4 Smart Contract Automation

Since these processes need to be managed and coordinated in real-time, smart contracts must be automated to continuously monitor instruction triggers and automatically adjust resource allocation.

3.2.5 Multi-Resource Allocation

JIT mechanisms can be applied not only to liquidity but also to other resources (such as computing power or storage). Ultimately, if blockchains can integrate liquidity at the network level, they can integrate other elements as well, meaning that improving liquidity availability isn't just about solving liquidity problems, but can be a starting point for enhancing flexibility in various areas.

3.3 Liquidity Proving

Just as important as the Just-In-Time mechanism is liquidity proving. This is because liquidity is needed for immediate execution, and without verification of liquidity, no execution can be performed. To facilitate liquidity proving, 1) dApps must be able to provide the network with verifiable proof that the liquidity they hold is sufficient for Just-In-Time mechanisms to execute, 2) the network must provide sufficient incentives for dApps to voluntarily participate in liquidity sharing, and 3) there must also be a safety net to allow them to provide liquidity with peace of mind.

3.4 Solver and Routing Layer

If the Just-In-Time mechanism can supply liquidity in real-time, and liquidity proving guarantees that liquidity, the remaining challenge is to decide where and how to allocate that liquidity and designate its path. For this, a Solver and Routing layer is needed. This layer serves as the 'decision-making engine' within the liquidity availability framework, optimally allocating liquidity according to real-time network conditions and routing it to various applications or chains.

The solver continuously explores the most efficient liquidity paths, optimizing by comprehensively considering various factors such as transaction costs, liquidity movement speed, capital efficiency, and network status. Additionally, it identifies various constraints across the network to ensure liquidity is efficiently distributed while not compromising safety. This entire process operates dynamically according to real-time situational changes, redistributing liquidity as soon as network demand occurs to maintain overall balance.

To summarize, the solver and routing layer is the key link between the Just-In-Time system and users (dApps), identifying when and where liquidity is needed and enabling the Just-In-Time system to trigger (refer to the figure above). This structure differs from cross-chain liquidity routing solutions attempted on existing blockchains. While current routing solutions aggregate application-specific liquidity (an app’s own liquidity) distributed across multiple networks, the solver & routing layer introduced by Injective differentiates itself by eliminating the concept of 'liquidity separated by application' altogether, and supplying liquidity that is distributed among applications to where it's needed when it's needed.

3.5 Expected Effects

If these mechanisms are well utilized and the network matures, dApps will no longer need to pay numerous costs to gather their own liquidity(Currently, numerous DeFi protocols are creating meaningless 'governance' tokens or points that imply such tokens to gather liquidity, distributing them as rewards, or Layer 1 networks are their distributing governance tokens to dApps to gather temporary liquidity. This is not beneficial in the long term for either the dApps or the Layer 1 networks). Moreover, liquidity providers can aim to maximize returns on their deposited liquidity while keeping their assets safe (since the liquidity they provide doesn't become idle liquidity but is used for actual financial activities, they can receive fees for this, allowing liquidity providers to aim for profit maximization).

Ultimately, users benefit the most when liquidity availability is optimized at the network level. Users can trade assets quickly and safely at the most optimal prices regardless of when, where, or what they are trading, and can conduct various financial transactions without having to search for which application has more liquidity. Therefore, Injective's movement to maximize liquidity availability is not an initiative for any one party, but aims to reduce the inefficiency of liquidity that has existed until now for all participants in the network and to achieve maximum efficiency at minimal cost.

4. Author’s Opinion

4.1 No More TVL

As a researcher in the blockchain industry, I have judged the success of networks based on various indicators, including TVL. However, even while knowing how inaccurate indicators like TVL are, I have continued to mention and utilize them because there hasn't been an indicator that intuitively shows liquidity at the network level as much as TVL. In the midst of this, Liquidity Availability introduced by Injective is very encouraging in that it not only proposes a new indicator but is also conducting research on how to improve liquidity availability at the entire network level.

In particular, some have criticized that many blockchain projects tend to competitively inflate or distort TVL figures. For example, it was common to see the same funds counted multiple times across various protocols, or artificially inflated TVL through lending-deposit structures. Because of this, despite TVL being the most used indicator in the decentralized finance (DeFi) ecosystem, questions have continued to be raised about 'whether this indicator properly reflects actual liquidity.' In this context, liquidity availability focuses not on the simple amount of locked-up funds, but on how much liquidity is actually available for any types of transactions, and how quickly and stably that liquidity can be utilized in any situation.

The concept of liquidity availability proposed by Injective is also an attempt to grasp the qualitative level of liquidity possessed by the entire network. For example, rather than having all funds concentrated in a single application, if liquidity resides at the network level—enabling users to receive the necessary liquidity at the right time and place no matter which application they use—then measuring that capability would reveal which blockchains truly offer more stable liquidity and greater practical potential. “Liquidity availability” is particularly noteworthy in this regard, as it evaluates the network’s actual liquidity capacity by considering factors such as fund distribution, accessibility, and real-time convertibility at the network level.

4.2 Liquidity Availability Forms Symbiotic Relationships Instead of Competition Between dApps

The perspective of viewing liquidity availability as a common task for the entire network rather than for individual applications throws very important implications for the future direction of DeFi. This is a turning point that moves beyond focusing solely on the 'TVL competition' and marketing effects shown by specific protocols, taking one step further toward pursuing ecosystem symbiosis and joint prosperity.

By addressing liquidity issues from this macroscopic perspective, project-to-project fund movements and interoperability can be built more flexibly and stably. This creates a structure that maximizes mutual cooperation and synergy rather than 'competition to take limited funds first.' As a result, a virtuous cycle becomes possible where protocols share and expand funds with each other, and in crisis situations, quickly redistribute funds to simultaneously enhance the competitiveness and stability of the entire ecosystem.

Ultimately, by establishing liquidity availability at the network level, the following three core effects can be expected:

• Continuous Growth and Technological Development

When liquidity bottlenecks disappear, projects have greatly expanded capacity to attempt new financial products or services. This triggers more innovation and accelerates protocol compatibility and collaboration, allowing the entire DeFi ecosystem to meet opportunities for growth.

• Building a More Fair and Dynamic Financial Ecosystem

A foundation is laid where anyone can easily utilize funds, and even small-scale projects can grow without worrying about easily collapsing due to market shocks. In an environment where flexible flow of funds is guaranteed, the entire ecosystem becomes more vibrant as various experiments and new projects continuously emerge.

• Streamlining Risk Management

When distributed fund operation and real-time liquidation become possible, the phenomenon of funds concentrating only on specific projects or assets is alleviated. This reduces crisis transfer in unexpected situations and increases stability across the network.

In the end, if the entire network begins to pursue cooperation and mutual complementarity centered on the concept of liquidity availability, the horizon of long-term and sustainable financial innovation can open beyond the point where the era of existing TVL competition had stopped. This carries meaning beyond simple indicator improvement and can ultimately become a core driving force that brings out the true potential of on-chain finance.

4.3 Liquidity Availability Completes the Composability of Integrated Blockchains

One of the biggest advantages of integrated blockchains is that 'atomic composability' is possible between smart contracts. That is, even when calling multiple protocols within a single transaction, the whole can be executed or canceled collectively, making logical interactions between protocols smooth. However, this atomic composability has often been limited to the logic dimension. This means that scenarios where actual funds, i.e., liquidity, 'move simultaneously' and are 'shared' smoothly across multiple protocols have been limited.

But introducing the concept of liquidity availability to integrated blockchains opens a path to advance this issue one step further. When all applications under a single shard structure can atomically move and utilize liquidity with each other, liquidity is essentially tied into 'one huge pool' that can be immediately reused throughout the DeFi ecosystem. This is innovative in that all applications can enjoy optimized fund efficiency and transaction convenience in a state where the liquidity itself between protocols is fully connected, not just at the level of calling multiple DeFi protocols at once.

For example, imagine a scenario where liquidity temporarily used in an orderbook-based application can be immediately received and utilized by lending or swap protocols, and the entire process is processed atomically within a single transaction. This is a way to maximize the advantages of integrated blockchains—the fact that the entire system is closely connected through a single shard—and as a result, true composability can be realized by all applications atomically sharing integrated liquidity.

In the end, making funds move atomically through liquidity availability allows the potential of composability touted by integrated blockchains to be utilized 100%. This is also an advantage that is difficult to implement in a modular chain environment where rollups are separated, and ultimately leads the entire chain ecosystem to operate with lower costs and higher liquidity efficiency. In other words, by atomically sharing liquidity, integrated chains complete a 'unified financial infrastructure' in the true sense.

4.4 But Given Challenges

Of course, the ideas presented here are just starting points. The concepts and strategies currently presented need to be refined through additional research and experimentation, and numerous elements that arise when applying them to actual protocols and market environments need to be closely identified. This requires comprehensive understanding of participant behavior patterns and incentive structures as well as analysis of internal network data.

As I mentioned above, insights from traditional financial systems are extremely useful reference points. There is clearly room to reinterpret traditional risk management techniques such as central bank models or Basel regulations and apply them to on-chain finance. However, at the same time, there is also the challenge of overcoming the limitations of centralization and closed nature inherent in traditional finance. In other words, rather than directly adopting concepts used in existing systems, we need to open a new paradigm by developing and applying "blockchain-specific mechanisms" mentioned above.

Thus, the perspective of 'risk management and liquidity design for a new financial ecosystem' is by no means a simple task. The constant emergence of new protocols and market participants, as well as the rapid pace of development across blockchain technology, are factors that increase uncertainty while also providing a field of explosive opportunity. Therefore, if efforts to systematically research, verify, and apply to the actual market the ideas related to 'liquidity availability' presented now accumulate, they will become a valuable driving force that dramatically elevates the entire on-chain economy.

In the end, the future challenge is to concretize this potential. How exactly will economic incentives be designed at the network level to make dApps distribute each other's liquidity to the network? What technical and economic risks exist in the process of making liquidity available, and how will the network mitigate these risks? How will dApps verify the liquidity they hold? How will solvers optimize liquidity paths? And so on. Many challenges remain. But I think the first step in solving a problem is recognizing the problem and throwing various ideas to solve it. In that sense, I believe the liquidity availability written by Injective Research this time is a problem that numerous smart contract platforms should consider in the future.