Our Vision for Composable Finance

Mission Statement

The decentralized finance (DeFi) ecosystem has sought sharded blockchains for increased scalability. As examples, ETH 2.0, Polkadot, and NEAR will be sharded. The result, however, is that even though the vision of ETH 2.0 is already upon us, instead of just blockchains being sharded, applications are being sharded as well. As an example, SushiSwap is deployed on Ethereum Virtual Machine (EVM) chains, Layer 2s (L2s) like rollups, Parachains, etc., and the expansion of these applications to other ecosystems is very likely. Thus, while moving money intra-ecosystem is becoming more intuitive, with several applications segregated within a specific ecosystem, managing assets inter-ecosystem is not.

Thus, Composable is focused on a cross-chain, cross-layer liquidity layer for sharded applications. Composable takes this notion a step further by also realizing that between each ecosystem, there is a sharding of functionality itself; for instance, every ecosystem has its own lending protocol. Composable’s vision is thus to abstract away inter-ecosystem decision making and maximize users’ and developers’ outcomes based on their unique goals.

To accomplish this function, we are creating an inter-ecosystem communication protocol, utilizing a parachain as a finality layer, that will connect L2s, L2s to the Polkadot/Kusama ecosystem, and the Cosmos Ecosystem through the Inter-Blockchain Communication protocol (IBC) to the Polkadot/Kusama ecosystem. The hope is then we would expand this to include other ecosystems, such as Algorand, Solana, etc. With these connections, an action such as borrowing X against Y would be routed through an ecosystem-agnostic path, maximizing for users’ preferred outcomes and parameters. The applications of such a stack are limitless.

Architecture

Composable’s vision is to create a protocol that allows for communication cross-ecosystem. The result is a Port Control Protocol like system for blockchains. The architecture is as follows:

• The Composable Cross-Chain Virtual Machine (the Composable XCVM) allows for cross-ecosystem communication.
• Communication layer/Innovation Availability layer (IAL):
• Polkadot-IBC cross-chain communication and asset transfers
• L2-L2 communication and transfers through our parachain
• Finality layer:
• Our parachain offering is Picasso on Kusama, and name to be determined on Polkadot.
• The Composable Routing Layer: Incentivized pathway selection to allow for users to perform actions, in an ecosystem agnostic manner.
• The Composable Liquidity layer: Mosaic — To ensure the facilitation of transfers, such that there is enough liquidity on destination layers, Mosaic is fit with multiple tools to ensure transfers occur, such as a dispute and security protocol.

The end result is multifaceted; users can perform cross-chain actions, and the overarching blockchain ecosystem is repositioned as a network of agnostic liquidity and available yield. Throughout this experience, Composable allows users to tailor their experience to maximize for a desired parameter while minimizing ecosystem-specific decision making.

The Composable Solution:

Below, we further break down the Composable Solution and each of its components, noting their roles and the progress we have made on each sub-project.

The Composable Cross-Chain VM:

The Composable XCVM provides a single developer-friendly interface to orchestrate the interaction with different bridges, manage routing, initiate callbacks into smart contracts, reliability, and finality. Our Mosaic ecosystem will leverage this virtual machine to facilitate the asset transfers, which allow cross-chain transactions and support parachain-L2 connections. Economic stakes guarantee the security of this system through fraud-proofs and disputes.

In order to facilitate this communication, we need two specific components that we are currently building: the Communication and Finality layers of our XCVM.

• IAL: This includes the following features:
• Polkadot-IBC cross-chain communication and asset transfers
• L2-L2 communication and transfer through our parachain
• Finality Layer: This will be our parachain offering — called Picasso on Kusama, and name TBD on Polkadot.

The idea of our solution , however, is not to create a new standard for cross-chain communication, which is already the object of a number of projects. Instead, the intention is to serve as a data availability layer for existing cross-chain communication protocols like IBC and Polkadot’s cross-chain message passing (XCMP).

Parachain Mission:

As mentioned previously, we will be pursuing the operation of both a Kusama and Polkadot parachain.

Given that our parachains are the foundational layer that powers our ecosystem, we have adopted a pallet-centric approach to adding products on our parachains. Meaning, we will offer projects the ability to deploy as pallets on our chain, with governance having the ability to upgrade these pallets into the runtime of our chains. We are excited to be able to offer this to the Kusama ecosystem, and have a grants programs for others to develop pallet projects using our technology, to be implemented into our parachain.

Projects that do well on the Kusama chain, can then upgrade to our Polkadot parachain.

Routing Layer:

Our Routing Layer will assess all of the possibilities for a given action (i.e. taking out a loan of 1000 USDC) across all potential layers and chains, and selects the optimal pathway for a user. This layer will be crypto-economically secured, with incentives provided for actors to properly select the best routes for user actions. Thus, this will act as a function aggregator, providing optimal services to users without them having to scour the entire expanse of the DeFi space themselves for the most promising opportunities and best deals.

One exciting application for this pathway execution layer is in cross-chain fee management. Our infrastructure as a whole intends to support a network of blockchain networks, meaning that there will be multiple potential pathways to the same destination. In this scenario, without a tool to do so for them, users would have to pathfind the most efficient and compliant route for value packets. Users may need to prioritize efficiency if the pathway must be especially liquid or secure, or if a specific regulatory requirement must be enforced (such as know your customer/anti-money laundering requirements, abbreviated KYC/AML). Therefore, the routing process would be both incredibly important and very time intensive. Our pathway execution layer will make this process simple for users and enable them to customize which parameter they want to optimize for when completing a given transaction.

Upon instruction and orchestration by the Composable Cross-Chain VM,the routing layer selects the most optimal route for the user’s desired outcome, which propagates communications cross-ecosystem, and to our to the dApp transport module, Mosaic, which then facilitates asset transfers, with settlement being recognized on the parachain.

Mosaic: The Liquidity Infrastructure Layer

Mosaic (the liquidity layer that communicates with Composable XCVM and the Routing Layer), serves to ensure liquidity is moving to the locations where it is needed, allowing the propagation of whatever instructions are required to satisfy the user’s desired outcome, as specified above. We are currently testing this capacity within the EVM ecosystem by running our Proof of Concept (PoC) of Mosaic. From there, we can generalize this liquidity problem and solution to other ecosystems.

Liquidity concerns are not new in DeFi. However, they have largely been resolved by automated market makers (AMMs) built into the popular DeFi exchanges like UniSwap and Sushiswap. The introduction of cross-layer and cross-chain applications is, however, making liquidity a more pressing issue than ever before; with so many different layer 2 applications and blockchains to balance liquidity across, and so little infrastructure to do so, liquidity is very siloed for interoperable applications.

Composable Labs has built a Liquidity Simulation Environment (LSE) to better explore the opportunity and best means of cross-layer liquidity provisioning (LPing). The first phase of this experimentation was to determine the viability of cross-layer liquidity provisioning by running test trade data through our model. This resulted in the prediction that LPs could be positioned to earn an impressive 16% return per week for providing liquidity for cross-L2 transfers. The second phase of this experiment is underway, wherein we have deployed our PoC of our cross-layer asset transferral system Mosaic, with the PoC being our Polygon-Arbitrum Cross-Layer Transferral System, to test out the associated dynamic fee model. Once we have scraped this data, we will be able to prove out the dynamic fee model and, as a broader goal, our passive liquidity provider role in this system. This data will also assist us with the rebalancing work I have recently released as well.

Lastly, our full solution will have an active management model as I have previously indicated as well. These bots will be working to reorganize transactions in a manner that maximizes fees, ensuring that trades are able to go through.

With this full model, we hope to generalize the model for meeting liquidity demands for cross-chain transfers. Initially, we are focused on the EVM universe, but will expand this vision for Mosaic to deliver the infrastructure needed for developers to create any of an infinite number of cross-layer dApps and have appropriate liquidity be available to their users.

Following this progress with the EVM, we want to expand from ensuring cross-layer liquidity on Ethereum to ensuring cross-layer liquidity on other chains as well; there are still cross-layer liquidity problems within the Inter Blockchain Communication (IBC) Protocol, Cosmos SDK chains, and Polkadot. We aspire to create a continual flow of liquidity between all of these ecosystems.

Roadmap:

Our near term goals are to complete development and drive usage of each layer of the Composable stack. Currently, we have Mosaic live, and with the Composable software development kit (SDK), we will be able to begin educating users about this cross-layer/cross-chain arbitrage opportunity, which can then lend itself to the understanding of our broader vision. Furthermore, we are continuously building more pallets to strengthen the foundational layer of our tech stack, that is our parachain.

The next phase for Composable is to integrate Picasso with the inter-blockchain communication protocol (IBC). Through this step, we will enable cross-chain communication with every blockchain that uses IBC.

To do this, we will be utilizing Substrate to create the bridge infrastructure to connect our parachain to IBC. Beyond this, we will work to improve Mosaic’s cross-layer communication so that our transferal system can connect with our IBC-Picasso bridge. With this integration, we will look to generalize Mosaic to be a liquidity model that will extend across ecosystems.

From there, we will begin drawing on the ink! VM model to develop the Composable Cross-Chain VM, which will spring forth the ability for developers and users to tap into the full Composable tech stack.

Calls to Action

There are many ways to get involved with the Composable Ecosystem:

1. Start building cross-layer applications with our Mosaic SDK.

2. Start building pallets that can be incorporated into our runtime of Picasso.

3. Are you a project that wants to deploy as a parachain? Consider working with us to deploy as a pallet within our parachain.

4. Are you a project that is currently multi-chain, but not cross-chain? Work with us to make your application unified across its different instances.

5. Do you have a random idea that you want to build with us? Hit us up on Discord.