Unified privacy tokens and interoperable apps >
Incognito’s privacy multichain protocol is solving a key problem Incognito platform is facing as described in the previous topic: inconvenient experience in usability as swapping with Incognito exchange’s fragmented liquidity. But more than that, in this topic let’s explore an important use-case that the protocol is bringing to our privacy supporters: a possibility to send an arbitrary message from a blockchain to another with anonymity.
Desires of sending arbitrary messages across blockchains
The past few years have seen a surge in the number of sidechains, rollups, and Layer-1 blockchains which support and scale applications handling billions of dollars worth of value. The multichain future is here, but it requires a protocol that enables interoperability and composability across chains, while unlocking new areas of design and possibility in cryptonetworks.
Incognito privacy multichain is a protocol that will enable users to send tokens or any kind of message in a single transaction across applications that live on various chains and is generalizable enough to run on any chain.
Let’s check out some popular use-cases via the illustrations:
Cross-chain DEX
Message 1: sending USDC from a Ethereum to Polygon
Message 2: swapping USDC from Ethereum for MATIC with Polygon’s Uniswap
The protocol enables a cross-chain DEX that play directly with native assets, an app using Incognito multichain protocol to send messages between chains can be built such that liquidity pools exist on both chains, and users can simply deposit their native assets in one pool and withdraw native assets from another (message 1).
Furthermore, the users can deposit their native assets in one pool on a source chain and then use the native assets from another pool to swap for other assets with a DEX on a destination chain (message 2).
Multi-chain lending
Similarly, for example, a user with USDC on Ethereum wants to take advantage of an opportunity on Polygon. The protocol allows the user to lend his USDC out then directly borrow in MATIC with a lending dapp on Polygon.
Message 3: lending USDC from Ethereum out to borrow MATIC with a lending dapp on Polygon
Multi-chain aggregation
Currently, aggregators typically operate within the area of single chain ecosystems. One downside of those single chain aggregation systems is that they can not take advantage of any yield opportunities (for yield aggregators like Yearn Finance) or liquidity (for liquidity aggregators like 1Inch) outside of their current ecosystem, potentially missing out on many of the best yields or rates respectively.
A multi-chain aggregator would be strictly better than a single chain aggregator, as in the worst case the strategy would degrade to taking advantages on only one chain, and in the best case it would have exponentially more opportunities to choose from.
These three examples represent typical (but not exhausted) possibilities that the protocol enables developers to write their applications without worrying about differing semantics between inter- and intra-chain transactions.
Notes: Thanks for reading till here, although you could feel that the previous section repeats some parts we discussed in the topic, we believe that it deserves to state it again in a more generalized way in order to clear out the potentials of the protocol. Also, users will be able to choose what to do with their resulting assets: either unlock to a destination chain’s address or re-deposit to Incognito to re-achieve privacy. In the above figures, we only illustrated the former flow for more simple illustration.
Caveats
One advantage of the protocol is that it won’t issue wrapped tokens on the destination chains like existing bridge solutions but allow users to use directly native assets on the destinations for their desires. But this is introducing a foreseeable problem we need to address: lack of liquidity (the native assets) on the destination chains.
In an ideal situation, we assume different people with different desires will eventually “serve” each other but in an extreme case where a liquidity pool has much more demand than others, it likely that pool’s liquidity will be shortage very soon and without liquidity, the above use-cases are not possible.
Solutions
Lack of liquidity on chains with higher demand is also a question raised a couple of times by the community members and we’ve discussed a few solutions to attack the problem in different lens and approaches. It looks like there is no a sort of silver bullet for it, each has its own pros and cons.
On-demand serving
This seems to be a quick and practical solution - once one wants to use liquidity of a chain but the pool doesn’t has enough liquidity, he could either: (1) choose to use another liquidity pool on different chain that has sufficient liquidity or (2) place an order into a queue along with a reward to incentivise someone who willing to provide the needed liquidity to serve the user’s request.
The idea is super simple, for example, a user A wants to send 100k USDC from Polygon to BSC, but there is only 40k USDC in BSC’s liquidity pool and needs another 60k USDC to be able to fullfil the demand. The user would place an order to request 60k USDC into a request queue and willing to pay 0.04% of the 60K USDC to anyone who help to serve the order.
User B who has 10k USDC could repeat 6 times a process of:
-
Step 1: Deposit his 10k USDC to a CEX (eg. Binance).
-
Step 2: Deposit the 10k USDC from that CEX to Incognito via BSC bridge.
-
Step 3: Withdraw the 10k USDC from Fantom pool back to the CEX via Fantom bridge (assume that Fantom pool has USDC liquidity).
When the user B repeats the process 6 times that costs him:
6 * $1.5 (Incognito deposit & withwrawal fees) + 6 * $1 (CEX withdrarwal fees) = $15
And he would be able to serve the order of the user A with a profit of $60k * 0.04% - $15 = $9
(Please note that the 0.04% above is a parameter that is subject to change over time to balance out the motivation of those two actor types, aka the user A & B in the above example)
Motivation for liquidity provision
While the on-demand serving is designed to attack directly the lack of liquidity problem, it’s not perfect since it passively waits for liquidity demand to be present through liquidity orders. The UX doesn’t seem to be smooth where users have to wait for their orders to be fulfilled as well as suffer the fees.
For those reasons, having incentive for people to actively provide liquidity to pools would be a perfect complement to the on-demand serving. We’re going discuss the initiative in the next topic to avoid making this one mega long.
Closing thoughts
We’ve just presented an overview for the privacy multichain protocol’s design and its applications. Apart from the motivation for liquidity provision that we owe you as stated above, you could also realize that there would always be a tradeoff between UX convenience and privacy (even decentralization sometimes), we are trying to figure out a way to balance out the tradeoff but always look forward to discussing with you about that, feel free to drop your comments below, this would absolutely be an interesting discussion we believe.
Thank you!