Mosaic Phase 2: Deploying an MVP for Transfers Across a Number of L2s, with Bot-Facilitated Liquidity
As previously announced, the first phase of Mosaic is a Proof of Concept (PoC), with transfers supported by a passive manner of providing liquidity into a layer 1 (L1) liquidity pool. We will release data based on the performance of our dynamic fee model from the POC as we begin to close it out. We will take this data and apply what we’ve learned from it to the design of phase 2, which is as follows.
The second phase of mosaic makes two major updates to the first phase: allowing for active liquidity provisioning strategies through programmable bots, and incorporating a full range of L2/scalability solutions to provide additional user convenience and opportunities.
Thus, phase 2 of Mosaic delivers a minimum viable product (MVP) for users seeking streamlined, affordable, and efficient cross-layer transfers along the most heavily-utilized portion of the layer 2 space.
Liquidity Considerations for the Mosaic MVP
To ensure there is appropriate liquidity to accomplish the cross-layer transactions in our MVP, we allow liquidity to be provided on both L1 and L2. Further, liquidity providers have two different options: they can provide liquidity in a typical and simple way, or they can frontrun trades that are pending and gain access to a different fee model. These two options are detailed as follows:
Passive Liquidity Providers (Receipt Token Receivers)
Users that provide liquidity will be minted a receipt token to acknowledge that liquidity. Composable will dynamically distribute the liquidity among the different connected networks to ensure that there is enough liquidity on all tokens and networks available on the system, using available bridges to do so (through bridge aggregation). This will be done via automated scripts or by collaborating with protocols such as Gelato. The dynamic fees generated by the system will be distributed for all passive liquidity providers by an off-chain script that will monitor all the fees earned on all the networks. Users will have the opportunity to withdraw their liquidity on any network they desire, and even as a different token to the one they provided liquidity with, as Composable will be integrated with various automated market makers (AMMs) deployed on different layers. This liquidity will be deployed into yield farms, if it is not used.
Active Liquidity Providers (IOU Receivers)
At times, the availability of liquidity on a network may not be enough for some bigger operations to take place. For example, if we have $1 million USDC on a Polygon vault, but there is a request of moving $1.5 million USDC of a user from Arbitrum to Polygon, we are in need of additional liquidity in Polygon. Anyone will be able to provide this liquidity and some can even create strategies around this system, spawning new DeFi opportunities, which may exist in the form of bots. Bots will be able to provide temporary liquidity (with the option to become permanent if they so choose) when it is detected there is a liquidity gap across vaults. In such an event, a higher proportion of generated fees will be awarded to them (on a scaled 80/70/60–20/30/40% distribution), splitting fees with passive liquidity providers.
Bots will receive an IOU token representing their principal available in the system. We are also designing a yield token, as a representation of their fees entitlement. Each bot will be able to define maxNoOfBlocks for their IOU, which will have an impact on the fees earned from the respective trades that have happened between startBlock and endBlock enabling multiple rewards tranches. Ideally these details should not be retained on the IOU itself, as it minimizes its fungible properties and blocks us from creating a market around it. In addition, each IOU allows the user/strategy (i.e. the bot) to withdraw their principal from any layer connected to the system, in any other token, similar to the normal receipt token, unblocking their funds any time. After endBlock, that liquidity is automatically transformed into passive liquidity, allowing the bot to continuously earn rewards generated by the system.
Besides passive providers and bots (active providers) for liquidity, Composable aims to have off-chain rebalancing scripts that will constantly monitor all connected layers and will try to detect (based on previous trade sizes) when one layer can become low on liquidity, making it so a transfer from L1 to that specific L2 transfer (using the official bridges) is done upfront.
Addressing Protocol-Specific Extractive Value in Mosaic’s Phase 2
Miner or maximal extractable value (MEV) is a growing concern in the DeFi space. This involves the frontrunning of user transactions (typically by bots) to effectively “cut the line” in participating in value generating transactions. This cuts the typical DeFi user out of the ability to make a profitable movement.
However, the concept of MEV can be leveraged for the benefit of users. Composable’s dynamic fee model introduces protocol-specific extractive value, but uses this to optimize user transfer behavior. Bots in our model can be built to maximize their profits from the dynamic fee model for providing liquidity to Mosaic, by doing a variety of things such as choosing which transactions to fill first, and potentially reordering the transactions flowing through the Mosaic system. The benefit of this extractible value is that we now harness the competitive nature of gain-seeking, in order to help provide a smooth flow of liquidity (as the active liquidity providers mentioned above). Extractive Value built into the system can thus be a value add for the platform. Additionally, because the bots will earn a fee that is partially passed onto the passive liquidity providers, their activities will actually benefit the Mosaic system as a whole.
Other MVP Features
Relayer
To perform various operations across layers, we will use an off-chain service we call “the relayer”, that will dispatch information (or bundles) to different layers connected to our system. The relayer will also pack transactions into bundles making it more liquidity friendly. For this relayer service, we will also develop and release an insurance model, that includes staking LAYR to be able to facilitate transfers. We will provide further information about this in the coming weeks.
Connecting with Automated Market Makers
In order to allow users to withdraw their liquidity on a different token than the ones they provide, we need to have an on-chain reference of the exchange rate between the original token and the final one. We will use a custom wrap of deployed AMMs in each network to fetch this exchange rate, and:
If the token is supported by our vault and we have enough liquidity, we will send it directly from our balances.
If the token is not available in our vault, we will use those AMMs to exchange the token and send them directly to the user.
This option will allow cross-layer arbitrage opportunities, a very interesting topic for projects like Uniswap for example.
Dynamic Fee Model
Liquidity (token) movements like transfer swaps will generate fees on Mosaic, creating revenue for network maintainers and Composable itself. However, perfecting the fee model in DeFi can be complex. Setting the fees too high drives away users; setting it too low compromises the income to those maintaining the Composable network.
We are thus implementing a dynamic fee model for Mosaic. This model is dynamic in the sense that it charges retail users differently than large-transfer users (whales). In this way, it is elastic to supply and demand, ensuring continued organic user growth together with maximized revenue. In developing our fee model, we also consider that the fees need to be tailored to the usage to strike a balance between platform and revenue growth.
There are many questions to be answered in terms of arriving at an optimal liquidity distribution, and the goal of phase I of Mosaic (our proof of concept and simulating test trades as well) is determining which distributions will not work. That was the purpose of the POC.
In phase II, Composable will utilize data generated from Mosaic thus far to optimize our dynamic fee model for our Intelligent Liquidity Engine (ILE).
Leveraging Data Generated from our POC in our Liquidity Simulation Engine
In my article detailing Mosaic, I have already explained the simulation we have used to predict the value opportunity and other associated metrics of liquidity provisioning for cross-layer asset swaps. The real-world user data gathered in phase 1 of the MVP will be further used to refine this model and determine the optimal means of liquidity provisioning cross-layer.
Thus, with these additional features for Mosaic, we consider Mosaic to be at an MVP phase. Additional layers will be added rapidly, and we will announce further partnerships to participate in Mosaic in the coming weeks.
If you are a developer with a project you think fits our ecosystem and goals, and you would like to participate in our interactive testing landscape at Composable Labs, reach out to me on Telegram at @brainjar.
