Dear UX community,
Not so long ago, we announced we’re in discussions with Osmosis for a potential merger, and the reactions were overwhelmingly positive…from both communities.
As nearly a quarter has passed since then, we figured an update would be fitting. Since the announcement, we have been researching the different solutions, auditing development roadmaps around different options, getting feedback from community members as well as investigating the cost benefits of one approach versus the other.
First and foremost, discussions are ongoing, so everything is subject to change.
Secondly, in order to have a better view of the different paths that lie ahead of us, we can place them on a ‘merger spectrum’, which spans from: mesh security to rewriting UX’s functionality in CosmWasm. Don’t panic, it will all be explained. This plethora of possibilities is enabled by UX’s unique position of running on its own sovereign app-chain, built using the Cosmos SDK.
Mesh security sits at the lower end of the ‘merger spectrum’, meaning that neither UX, nor Osmosis, would benefit from each other’s functionality natively. However, by allowing UX and Osmosis validators to validate both chains, one could define this as a merger of security. This approach wouldn’t require much effort from either side, it would be readily implemented and further bolster security, but it would not drive additional end-user utility. Mesh security is still in research and development so there may still be unknown variables here.
At the opposite end of the spectrum lies rewriting UX’s native modules as CosmWasm smart contracts which would be deployed on Osmosis. While this avoids any major engineering and troubleshooting efforts from Osmosis, it would imply rewriting UX’s codebase in CosmWasm. Make no mistake, this would not be a facile task and it would require dedicated efforts from our engineering team for at least 8 months. However, this approach would allow Osmosis to seamlessly integrate UX’s functionality and supercharge each other (i.e. unlocking margin spot trading). Moreover, by merging with the leading DEX of Cosmos, TVL would exponentially increase for both parties.In this case the Umee team can rewrite the core leverage, meToken and incentive modules in CosmWasm. Another large scope of work for this type of merger would be the integration of a new oracle. In this scenario we have looked into using the slinky oracle by Skip being built for Osmosis. The Slinky oracle would allow us to use our own price feeds while relying on Skip for validating that information and propagating it to the rest of the chain. We would need to write a new CosmWasm contract that takes our tried and true Historacle price mechanism and applies it to the Skip oracle. We have also looked at using Pyth or the Osmosis Dex itself however, we wish to minimize complications and focus on an implementation that can be immediately plugged into the leverage module code that has been tested throughout the years.For those that don't know, smart contracts in Cosmos are written with CosmWasm/Rust, similar to how Ethereum contracts are written in Solidity. It's a relatively new smart contract framework that still has some room to grow. As previously stated, it is less of a burden on the Osmosis chain but would be a large scope of work for the UX team. Although Cosmwasm isn’t inherently dangerous, securing UX liquidity is top priority, so we are doing our due diligence. There are security concerns with Cosmwasm considering the history of vulnerabilities discovered in production code.
In this case we would consider migrating the UX token to be a native asset on Osmosis. The UX chain would no longer be necessary, lowering the overall maintenance of the UX protocol which would effectively give the UX engineering team more time to focus on features.
An alternative to SDK modules -> CosmWasm conversion would be to directly merge UX’s SDK modules with Osmosis’. While this approach takes less of a significant toll on our engineering team, it could lead to an increase in complexity of the Osmosis core codebase. In turn, this would translate to slower chain updates and longer troubleshooting times. However, the same functionality and TVL benefits would apply, similarly to the previous scenario.In this scenario we would still need to translate our oracle module to use a native Osmosis oracle solution like Slinky. This is easier than relying on osmosis validators to fully onboard the UX oracle, which is what would be necessary if we wanted Osmosis to adopt our own Historacle setup. With the current throughput of osmosis, this may put unwanted pressure on the osmosis chain. Another factor to consider is the compatibility between Osmosis and UX chains. Both chains would need to upgrade to SDK version v0.50.0 to avoid compatibility issues between the modules and to integrate the latest Slinky oracle. In all of these scenarios we would leave the UX chain with its TVL, and mechanisms intact, giving users ample time to migrate their liquidity to the new protocol. We have also designed a robust and easy to use migration tool to help move over any positions to the new protocol that would live on Osmosis.
The optimal strategy focuses on leveraging the strengths of both the UX and Osmosis chains by utilizing IBC and CosmWasm smart contracts for interactions between the two. By keeping core lending modules on the UX Chain and integrating with Osmosis through smart contracts that serve as UX asset vaults to be used for margin trading and other use cases, this approach ensures seamless functionality and high performance. It combines SDK modules for essential operations with CosmWasm contracts for extended features, creating a streamlined and efficient framework.
This strategy alleviates the burden on Osmosis’ codebase and accelerates integration by avoiding the need to adapt UX core functionalities into CosmWasm, while maintaining critical Oracle functions for lending usability and preventing the need for TVL migration. Moreover, it facilitates Cross Chain Margin trading, effectively bridging the functionality gap between UX and Osmosis chains and maximizing their respective benefits.
From an economic perspective, it is important to realize that by allowing this margin trading functionality between the largest spot DEX in Cosmos as well as the largest lending protocol in Cosmos, Trading volume on Osmosis will dramatically increase due to the additional activity. Also TVL on the UX chain will also increase due to more desire to use the network as a lending facility.
The mechanism that would allow for this cross chain Margin trading would be similar to a Flash loan from UX to Osmosis with a Cosmwasm smart contract as a custodian for active trading. While we can accomplish the required functionality with current technologies, this user experience would be dramatically improved with atomic IBC transactions. Atomic IBC is still not available in Cosmos today but a few teams are building it and we expect to see it in the upcoming months.
By merging the functionality of both chains using the CosmWasm smart contract that allows bridging, we can expect to see further growth of Product Market fit in Cosmos DeFi.
Now what about UX chain and UX token?
Needless to say, our focus is on ensuring the UX community’s best interest. Both chain and token will continue to exist considering this current set up, and tokenomics are still being considered based on community feedback.
Upon further analysis, this approach seems to be the first time in history that two separate blockchains are connected not by a bridge, communication protocol, or message passing layer, but rather a shared smart contract interface that allows combined functionality between the core SDK modules of both Cosmos networks.
Needless to say, our focus is on ensuring the community’s best interest.
We hope this update answers most of your questions and we are eager to hear your opinions and thoughts!
Umee is U and Me :)