Osmosis Updates From The Lab

Celestia | Shogun | Aug 23, 2023

Hosts: Aaron Kong | Sunny Aggarwal (Osmosis)
Guests: Evan (Celestia)| Rahul, Marcus (Shogun)

TL;DR

• Chain Upgrade: Successful chain upgrade with new supercharged liquidity pools. Frontend updates may be needed. Most incentivized pools upgraded except Atom-Osmo and USDC-Osmo, classic pools still available at a discount.
• New Transaction Type: Introduced a transaction type to convert LP positions to Staked Osmo. Can exit liquidity pool, convert assets to Osmo, and stake for 14 days. Enhances returns and helps with impermanent loss.
• For developers : Added tokenfactory hooks for integrating Cosmwasm logic into token transfers. Offers similar user experience to CW20 tokens.
• Upcoming Upgrade: Next upgrade to include governance-approved protocol swap fee for Osmo stakers on swaps. Governance can adjust fees for specific pairs, focusing on preventing governance burnout. Enhancing governance module for subdao delegation.
• Volume Splitting Incentives: Introducing volume-based incentive distribution. Incentives automatically split based on trading volume for grouped pools, reducing governance intervention.
• WBTC Audit: Successful audit for native WBTC launch on Osmosis. Transmuter to facilitate asset upgrades. Multiple token upgrades planned including WBTC and noble USDC.
• Shogun aims to address the gap in the interchain ecosystem, particularly in smart order routing and interchain liquidity utilization. Shogun’s decentralized interchain market making involves peer-to-peer order matching, cross-chain routing via IBC, and Jit LP vaults for immediate liquidity.
• Celestia provides data availability and validity verification across chains using lite clients. Mesh security and rollups address similar issues, streamlining reorg resistance, censorship resistance, and data availability.

Aaron
Hello everyone, Sunny will start with lab updates. Then we’ll discuss developments with the Celestia and Shogun teams.

Sunny
Today’s chain upgrade went smoothly, introducing more supercharged liquidity pools. These pools are active, but their frontend may still need updating. Most incentivized pools except Atom-Osmo and USDC-Osmo are now upgraded. You can move liquidity to concentrated positions, though classic pools remain available with a 5% rewards discount.

Sunny
In this upgrade, a new transaction type allows converting any LP position to Staked Osmo. Whether you’re locked or in a superfluid stake, like in Osmo/Juno for 14 days, you can exit the liquidity pool, by converting assets to Osmo and stake Osmo for 14 days. This doesn’t affect chain security, only increases staked Osmo. Useful for those facing impermanent loss, especially with supercharged liquidity. Our notification system, active since yesterday (temporarily disabled for bug fixing), identifies if your LP APR is lower than staking APR. You can then one-click upgrade to staked Osmo, enhancing returns. These changes, along with the new supercharged pools, are the key user-facing aspects of this upgrade.

Sunny
For developers, new additions include tokenfactory hooks. This allows integrating Cosmwasm logic into your tokenfactory token transfers. Now, your tokenfactory token offers a UX similar to CW20 tokens, eliminating the need for CW20s moving forward.

Sunny
We’re trying to do another upgrade within the next two weeks or so. This will include the governance approved protocol swap fee for Osmo stakers on swaps, starting with 15 Bits protocol swap fee for Osmo stakers. But governance will also gain the ability to adjust this fee for specific pairs. For instance, on stable swap pairs like USDC to Tether, a 15 bits fee might be uncompetitive. Governance can step in to tweak fees for whitelisted pairs, potentially through a SubDao system to reduce manual interventions. With DaoDao on Osmosis, our goal is to delegate parameter adjustments to subdaos, easing the load on governance. This focuses on preventing governance burnout, a priority as we’re rapidly approached 500+ proposals in just two years of Osmosis. We’ll enhance the governance module for seamless subdao delegation.

Sunny
In the upcoming upgrade, we’re also introducing volume splitting incentives. Unlike the current setup where incentives are pool-specific, this feature lets us group pools together. In these groups, incentives distribute automatically based on volume. This is handy for similar pair pools; say, multiple Atom-Osmo pools with varying fees. The remarkable part is that it works across different pairs too. You might desire incentives for Osmo with stable coins, not specifying USDC or Tether. We allocate a percentage of Osmo incentives to the Osmo stable coin, adjusting according to volume between Osmo-Tether and Osmo-USDC. This applies to staking derivatives too. For instance, incentives for Atom staking derivatives split based on volume across providers like Stride, Quicksilver, or Persistence. This system empowers the market to determine liquidity destinations, reducing governance intervention.

Sunny
In other news, our WBTC audit is complete and successful. The WBTC Dao includes valuable members such as the osmosis foundation, Wintermute, Coinlist, Chorusone, Figment, and BitGo. We’re excited to launch native WBTC on osmosis soon, accompanied by a transmuter to facilitate asset upgrades. Multiple token upgrades are on the horizon, including WBTC and noble USDC. For a smooth process, we propose testing Composable’s DOT, the recently launched Polkadot IBC implementation, for our first upgrade. This will build confidence for larger token upgrades like WBTC, USDC, and Tether. We’re dedicated to ensuring a seamless user experience during these upcoming changes. These are the key updates from the Osmosis dev team.

Aaron
One question about the sharing of the fees going to stakers. Is this going to be shared in kind or will it be swapped in the Osmo?

Sunny
There is the protocol fee. It’s it’s all there in the governance prop right now. But the idea is that it will be swapped into the, quote, asset of every trade. And then distributed in kind in the quote, asset.

Aaron
Awesome. A lot of things are pretty soon to come, especially with the big USDC, Twitter announcements, and six new ecosystems coming in, in the next two months. It’s going to be very exciting. We can hop over with the Celestia team and the Shogun team. Could you guys introduce yourselves?

Evan
Hey, I’m Evan, a celestial core Dev. I mainly work on our fork of comet BFT. I’ve been fortunate enough to do tiny bit of work on the data availability side and even rollkit, which is how we build rollups. I also run a validator on osmosis called Uncle Ed. We’re at the bottom of the barrel right now.

Marcus
Hi. This is Marcus. I’m the CTO for the Shogun project, and lead developer as well.

Rahul
Hi, I’m Rahul. I’m, the business lead at a Shogun. My background is in investing in the space, worked at a few different definitive hedge funds. And I’ve done a deep dive researching within Cosmos for two years. We have one more lead quant Roland, who’s trying to get a speaking spot, but I think it’s a little buggy.

Sunny
Let’s start with Shogun. Can you a summary of what is Shogun? What is it gonna do for the interchain Dex ecosystem?

Rahul
We’ve identified a significant gap in the interchain ecosystem, particularly concerning smart order routing. Optimizing interchain liquidity utilization is vital, with various protocols addressing this, such as Catalyst, Split, and the former White Whale. Our three-part process for decentralized interchain market making, or DIM module, involves off-chain peer-to-peer order matching and settlement, followed by cross-chain routing via IBC for unfilled orders. We’re also developing Jit LP vaults, acting as immediate liquidity sources after order matching. Osmosis is a crucial partner due to its interchain liquidity, with orders routed through its highly efficient DEX. Our market-making vaults will be rebalanced to prevent impermanent loss, involving both osmosis and third-party debts for the near to mid-term. So that’s sort of what we’re building.

Aaron
Rahul, Could you touch on Jit valuts a little more in a simple manner for the crowd?

Rahul
So essentially, users deposit liquidity into designated vaults, such as Osmo-USDC, Atom-USDC. These vaults are intended to be used for orders not matched in the account matching engine. When a user wants to swap, let’s say 100 Atom for USDC, buyers and sellers are initially matched on the account matching engine, typically filling around 15–20%. The remaining 80–85% requires further handling. If the order involves a whitelisted asset like Atom-USDC, our vault provides secondary liquidity, optimizing capital use. If this vault deviates by over 5%, rebalancing occurs through third-party debts, retaining arbitrage profits for LPs and this is actualizing in an interchain setting.

Aaron
I think the final most obvious question would be, what does Jit stands for?

Rahul
It’s Just in time.

Aaron
Awesome. Maybe Evan, you can hop in and talk about how Celestica and Shogun came to connect and how you expect that to unfold?

Evan
Is Shogun osmosis specific? Is it like smart contracts on osmosis?

Rahul
No, So part of the orders will get filled or settled on our own sovereign roll up and then residual orders will get directed. And I’m using osmosis example because it has the most amount of depth right now. And so, yes, there will be residual orders that will get settled on the osmosis network. It’s like a 1Inch. But for this, like asynchronous network state.

Evan
I see. How is Shogun using its sovereign rollup? Does it need to be a roll up to connect to other rollups?

Rahul
That’s a definitely a deeper conversation. Shifting to Celestial’s role in the ecosystem, shared settlement layers hold promise for our utilization. Our vision involves constructing our sovereign roll-up via the sovereign SDK. This leverages aggregators to foster composability within the ecosystem. In version one, we’re set to deploy smart contracts on Neutron. Given Neutron’s direct link to osmosis, connectivity is facilitated through Neutron. The eventual transition involves migrating to our personal roll-up using the sovereign SDK.

Rahul
There’s an additional ZK bridge integrated into this structure, facilitating connection to the broader cosmos ecosystem. Via Neutron’s IBC infrastructure, we can access platforms like osmosis, canto, injective, and more.

Evan
Celestia’s role includes verifying zk proofs across chains and confirming data availability. This can be done in various ways, like a method similar to IBC where Celestia’s validator set is trusted. However, to truly leverage Celestia’s innovation — lite clients — validators from chains like neutron or osmosis can actively use these lite clients. These lite clients act as socially slashable Data Availability Oracles, monitoring data, sampling, and detecting fraud. This setup ensures secure data verification using Celestia’s lite clients and fraud proofs, reducing trust assumptions and enhancing scalability. Rather than IBC’s approach of forwarding state proofs with headers, this process forwards the data route, as seen in the quantum gravity bridge connecting data availability to the EVM in a gas-constrained setting. The recent Celestia announcement suggests the potential for validators to embrace these light clients for the Celestia network.

Sunny
This pertains to our efforts with Osmosis and how Celestia fits into our mesh security model. Currently, our mesh security is designed for flexible slashing, allowing various slasher setups using Cosmwasm contracts. It can cover diverse conditions, like Oracle errors or double signing. Starting with the common tendermint double signing, we’re aligning with Cosmos’ practices. As we progress, we aim for state validity proofs, which the Cosmos SDK’s role in building a fraud proof system exemplifies.

Yet, we want to enhance user experience. Unlike most fraud proof systems with a waiting period, we suggest an “optimistic bridging” approach for IBC transfers. This permits immediate IBC asset bridging while enabling subsequent fraud proof submission. This prevents reversals and promotes slashable actions. To ensure constructible fraud proofs later, blocking on data availability is crucial. This data availability assurance is quicker than the fraud proof window.

The concept involves attaching a proof or claim to an IBC transfer, possibly via Celestia. Osmosis validators running Celestia’s light clients could verify data availability before processing incoming IBC packets. This proactive step ensures the availability of data for potential fraud proofs.

Sunny
Currently, we’re focused on developing the v1 MVP of mesh security, centered around the Tendermint light client. However, the evolution towards state machine slashing from light client security is the next step for mesh security. I’m eagerly anticipating the synergies and possibilities that leveraging Celestia DA will bring to this progression.

Evan
Yeah, I always found mesh security really interesting, specifically because I think mesh security and rollups are trying to address similar issues. I often refer back to a tweet I made, summarizing the four levels of blockchain security: reorg resistance, censorship resistance, data availability, and validity. Roll-ups delegate the first three, excluding validity, to Layer 1, streamlining reorg resistance behind one token. However, mesh security adopts a distinct route, prioritizing reorg resistance and validity. It’s captivating because it tackles data availability (DA) and censorship resistance differently. I’m curious about your perspective on whether mesh security’s approach also contributes to data availability and censorship resistance?

Sunny
If a slashing condition can be formulated, then it’s feasible. Data availability (DA) introduces challenges in creating attributable slashing conditions, especially in Celestia’s current DA approach. However, you can construct slashing systems for DA. For instance, implementing challenge games where validators are randomly tasked with providing a hash from a specific leaf in the Merkle tree. Failing to submit this challenge could trigger slashing, verified on-chain with Cosmwasm.

Regarding threshold decryption, our objective is to enable fraud proofs. For instance, sharing a decryption key for an unfinished transaction should be slashable. We’ll include slashing conditions for this scenario. The core idea behind mesh security is ensuring economic stake supports various processes, wherever describable and attributable slashing conditions exist.

Evan
Going back to data availability and the random validator sampling, we’ve considered some concepts. With Celestia, validators already download block data. Assuming an honest quorum or a portion thereof signs off on a block, all validators have that data. So, I’m uncertain about the additional value brought by random sampling in this scenario.

Sunny
It gives you some guarantees of persistence of data. Currently, it only ensures data download, not long-term retention. Challenges, like verifying specific Merkle tree leaf, would guarantee actual data retention by validators.

Evan
Cool. I’ll have to have to think about the censorship resistant thing, and chew on it for a while. That was pretty interesting to do with the encrypted mempool, I also just want to play around with more encrypted mempools.

Sunny
We’re exploring ways to streamline reward distribution for Osmosis. Currently, this process involves pausing the blockchain daily to distribute incentives, which is slow and costly. To improve this, we’re considering shifting the reward logic off-chain and employing a Merkle drop mechanism. This entails validators running off-chain logic to create a Merkle tree of rewards. Once two-thirds of validators submit the same Merkle root to a contract, participants can initiate a Merkle drop to claim their rewards.

Comparing this with experiences like Neutron’s airdrop claim, which relied on copying data from their site, we seek to enhance decentralization. Our vision involves validators storing the Merkle tree data and undergoing random data challenges to ensure data retention. Furthermore, we plan to post Merkle tree data on Celestia, offering an alternative data source for reward claims. By having validators run Celestia nodes, we can synchronize the Merkel drop with data inclusion on Celestia, ensuring a reliable and decentralized process.

Evan
Yeah, that’s pretty neat. Is osmosis ever planning on becoming like a bridge to rollups?

Sunny
A bridge to roll ups is definitely something we are working on. Recently, we unveiled our plan to introduce Hyperlane to Osmosis, a significant announcement made at the modular summit. Most roll-up solutions currently lack IBC support, while Celestia exclusively utilizes IBC. Collaborating with Celestia’s team and various roll-up projects, we’re establishing a standardized process: transfer assets via IBC to Osmosis, then utilize Hyperlane to bridge to diverse roll-up solutions. In essence, we’re becoming a bridging hub within the Celestia ecosystem.

Sunny
Let’s flip back a little bit to Shogun here. What is your strategy for how you get the order flow?

Rahul
Certainly. Initially, we’ll focus on our front end, with wallet integrations coming later. Our version one involves implementing smart contracts on neutron, accompanied by our independent front end. To kickstart adoption, we might incentivize users with GUN tokens and employ a token-incentivized order builder. These orders would settle on neutron initially, with any residuals directed to osmosis.

Over the next few months, as we align with the Sovereign SDK, we plan to transition to our own Sovereign roll-up solution. We’ll maintain our connection to Cosmos, possibly even exploring a direct link with osmosis. Our current roadmap features a zk bridge, routing orders through neutron and subsequently to the wider interchain network.

Sunny
Cool. We should probably open it up to the audience questions.

Aaron
Can you clarify on rumor that osmosis team is working with SEI directly or collaborating something given the canonical Atom over Sei is all through the routing of osmosis. Is that the case?

Sunny
That was not a coordinated thing. We have always urged everyone to do direct point to point IBC connections. That is the right way for Cosmos to scale. So no, that was not on purpose. I don’t know why they chose to do that.

Aaron
Interesting. The other question going on was the whole balancer v2 thing. Does that have any relation to osmosis or is that entirely separate?

Sunny
No. This is completely separate. If you go on the osmosis Read me, it says balancer inspired because the original version of osmosis is AMM or very balancer inspired. But there is no code overlap, no bugs. The current situation in balancer’s completely unrelated to osmosis today.

Aaron
Good. Thank you for clarifying those things. Thank you, Evan, Marcus, Rahul for coming on and speaking today. Alright, see you everyone.