Osmosis is one of the largest DEX on the interchain, where users can swap and earn hundreds of tokens and coins, as well as build customisable features.
Over the last 30 days, Osmosis facilitated 5,640,200 transactions, through 177,290 active addresses and 75,903 interchain channels, while 472 unique delegators have benefitted from 22.1% Staking APR.
In this deep dive, we first introduce Osmosis and its positioning in the wider context of DeFi. After, we break down Osmosis functionalities such as AMM as a serviced infrastructure, superfluid staking, fee abstraction, and IBC rate limit.
What is Osmosis?
Osmosis, a nexus for liquidity and trading in the Cosmos ecosystem, can be thought of as a combination of a Layer-1 blockchain and a decentralized application (dApp), producing an app-chain that specializes in decentralised exchange (DEX) functionality.
The Osmosis ledger is built using the Cosmos SDK and is secured by Tendermint, a Proof-of-Stake (PoS) consensus mechanism equipped with Byzantine Fault Tolerance (BFT).
Regarding interoperability, Osmosis uses Inter-Blockchain Communication (IBC) to enable cross-chain transactions within the Cosmos ecosystem. Currently, more than 50 blockchains are connected to Osmosis, and work is underway to enable IBC on Avalanche, Polkadot, and even Ethereum, allowing Osmosis to welcome new users, developers, and protocols. For reference, over the last 30 days, Osmosis’s interchain facilitated 5,640,200 transactions, through 177,290 active addresses and 75,903 interchain channels, while 472 unique delegators have benefitted from 22.1% Staking APR.
Thanks to its app-chain architecture, Osmosis differentiates itself from other protocols through features such as Concentrated Liquidity, Fee Abstraction, IBC Rate Limit, Superfluid Staking, Token factory, and Alloyed Assets. However, Osmosis’s two fundamental pillars can be boiled down to the Customisability of Liquidity Pools and the provision of Automated Market Maker (AMM) as serviced infrastructure.
Liquidity Pool Customisation
When it comes to liquidity pool customisation, Most major AMMs, like Uniswap, offer limited customizability, typically allowing basic parameter variations such as fixed two-token pools and standard swap fees. While simplicity aids user onboarding, it falls short as the DeFi market matures, necessitating flexible liquidity pools that are adaptable to varying market conditions, such as block time, slippage, and volatility.
AMM as Infrastructure
In terms of AMM as infrastructure, the rise of complex decentralized financial products, such as pegged assets, derivatives, and tokenized leverage positions, requires AMMs with specific bonding curves for market efficiency. Traditional AMMs often prioritize the AMM design over the financial product’s needs, forcing assets to either trade inefficiently on existing platforms or undertake the daunting task of building bespoke AMMs. Osmosis addresses this by offering ‘AMM as a serviced infrastructure,’ where creators can easily define custom bonding curves and leverage pre-existing AMM infrastructure. This approach significantly lowers the barrier to developing efficient, tailored AMMs for diverse financial instruments.
(Source: Map of Zones, 2024)
The OSMO Token
The OSMO token is a governance and rewards token of the Osmosis chain, with a total supply of 1 billion, a circulating market cap of $551M, and a price of $0.832 per OSMO as of June 30.
OSMO, which can be purchased via a Ledger wallet is used for functionalities such as governance, transaction fees, protorev, takerfees, superfluid staking, and other fees.
Transaction Fees
Fees are paid in OSMO by anyone who posts a transaction on the chain. The fee amount, varying between $0.002 and $0.004 on average, is determined by the computational and storage costs of the transaction.
Minimum gas costs are determined by the proposer of a block in which the transaction is included and the transaction fee is distributed to OSMO stakers on the network. Although validators can choose which assets to accept as fees for finalized blocks, all accepted assets are converted to OSMO before distribution.
ProtoRev (Protocol Revenue)
The ProtoRev module mints and burns the OSMO token to perform privileged arbitrage transactions and ensure that prices are balanced across all on-chain liquidity sources. As of now, no use for this revenue has been decided, making it a possible discussion point for future governance. All generated ProtoRev is being collected in this module address.
Taker Fees
Osmosis charges a default 0.1% taker fee on all trades. Several routes have reductions or exemptions that are managed by the Protocol Fee Controller subDAO. Accumulated OSMO collected is distributed to stakers, while 33% of Non-OSMO taker fees go to the Community Pool and 67% is converted to OSMO and distributed to stakers.
Superfluid Staking
Osmosis is secured by an active set of 150 validators and OSMO – the network’s native governance and validator rewards token, which must be staked to operate a validator. Those unable to run a validator can delegate their OSMO to trusted providers. To be selected as an active validator, a validator candidate must be ranked in the top 150 candidates in terms of the total OSMO stake (self-bonded + delegated).
The OSMO token is also minted and burned in the context of Superfluid Staking, an Osmos-specific function providing the consensus layer with more security via the “Proof of Useful Stake”. In superfluid staking, each person gets an amount of OSMO representative of the value of their share of those liquidity pool tokens that they stake and delegate to validators.
Superfluid staking is available in pools that contain OSMO in the pairing and have had this feature enabled by governance.
*Osmo is also used as a required fee for several on-chain tasks that prevent spam and encourage considered usage of features. All fees paid go to the Community Pool:
- Adding External Incentives to a pool: 50 OSMO
- Topping up External Incentives on an existing stream: 25 OSMO
Governance
OSMO stakers can participate in on-chain protocol governance, which varies from discussing topics in the Osmosis governance forum to submitting a proposal and voting on-chain.
Usually, a governance proposal is expected to be discussed on the governance forum before being put on-chain. Once on-chain, the proposal enters the deposit period, during which OSMO collateral must be accumulated to help deter spam proposals. If the deposit is not made within two weeks, it is forfeited, and the proposal is never put to a vote.
Stakers can vote Yes, No, NoWithVeto, or Abstain and pseudonymously change their vote at any time during the voting period. Delegated stake is counted as the validator’s vote but can be overridden by the delegator voting.
For a proposal to be valid, a participation quorum of 20% of the total staked OSMO must be met. Voting Yes or No indicates approval or disapproval of the proposal, respectively, while voting Abstain indicates that the user does not wish to contribute to the direction of the vote. NoWithVeto is mostly used for spam or malicious proposals and requires only 33.4% of voting power to veto the vote and burn the deposit.
For a proposal to be accepted, the following conditions must be met:
- 20% of the total staked OSMO quorum
- 51% Yes vote for the proposal
- NoWithVeto vote must be less than 33.4% of the participating voting power
Depending on the proposal type, a change may occur immediately, at a specific block height, or it may not change anything about the protocol level directly.
Features
Concentrated Liquidity
In standard AMMs, one gets better swaps and liquidity linearly, by adding more LP shares. This approach is straightforward as returns are increased by simple deposits and income can be earned passively. However, the drawback is that the liquidity is spread over a larger surface that can vary from 0 to infinity. Therefore, the returns per unit of capital deposited are not optimized due to market dynamics and functional variables such as slippage and friction.
The Concentrated Liquidity (CL) AMM, first introduced by Uniswap V3, aims to solve the above issue by allowing users to specify a range in which they want to provide liquidity for a specific asset pair.
For instance, a pool with stablecoin pairs like USDC/DAI has a spot price that should always be trading near 1. As a result, Liquidity Providers (LPs) can focus their capital in a small range around 1, such as 0.95 to 1.01, rather than the full range of 0 to infinity. This approach leads to an average of 200-300x higher capital efficiency and lower price impact because the shallow pools are made even more compact through range specification and much deeper due to the volume of capital available for the specified price range. Thus for a standard AMM to match the efficiency and depth of concentrated liquidity, it would need considerably more deposits to cover a wider surface of the price range whilst hitting the same height.
When it comes to choosing the price ranges, Osmosis uses a Geometric Tick Spacing with Additive Ranges – a measurement system used to measure the current price of the asset and the liquidity in a certain range.
These ticks can have smaller spaces and be more granular for smaller assets like stablecoins and meme coins, allowing for precise range setting and pricing. Alternatively, Ticks can have larger spacing for larger assets like Ethereum. The Gemoretric Tick Spacing allows Osmosis to support assets smaller than 0.000..001 and larger than it is possible to phrase.
Furthermore, tick spacing facilitates the creation of trading strategies at all levels of risk, including low, moderate, and high.
Low-risk tolerance users can still choose to trade between 0 and infinity, just like in traditional AMMs, while moderate risk-takers could choose an optimal line between high concentration and infinite range. Meanwhile, high-risk strategists could squeeze the price range and actively manage their positions.
Concentrated liquidity introduces new possibilities for offering liquidity rewards to targeted strategies. For instance, it incentivises liquidity providers based on how close their positions are to the current price and the duration they maintain those positions. Additionally, this framework supports a novel “range order” mechanism, akin to a limit order in order-book systems.
For more comprehensive technical information, you can read the full documentation here.
Fee Abstraction
The development of fee abstraction has been motivated by the desire of the community to use IBC tokens as transaction fees on any chain instead of having to use their native token and to take advantage of Osmosis’s swap router, ibc-hooks and async-iqc.
As a quick reminder:
- swap router: is a contract that defines on-chain routes that swaps from one asset to another will take. This is important as multiple pools per potential swap exist with differing variables such as fees, curves, liquidity depths, and liquidity types.
- Ibc-hooks: complements swap router as an IBC middleware, allowing ICS-20 token transfers to initiate contract calls. ibc-hooks allow cross-chain contract calls, that involve token movement, thus facilitating cross-chain swaps.
- asynq-iqc: a feature that did not go through the Osmosis v15 update, but is now implemented to allow one chain to query the balance of an account on another chain, fetching necessary data for transactions.
To abstract fees, the Fee Abstraction Module is integrated into the customer chain, which then becomes able to accept IBC tokens as transaction fees.
By using the Osmosis swap router and ibc-hooks, the module can efficiently handle token conversions and other operations, while the async-icq module supports non-blocking data queries across chains, improving the overall transaction process.
A hypothetical Fee-Abstarction Mechanism is set out below.
TWAP Data and Exchange Rate:
- Periodically, the Fee Abs module pulls TWAP (Time Weighted Average Price) data from Osmosis by using IBC to communicate with the async-icq module on Osmosis.
- Pulled TWAP data is then used to update the exchange rate between Osmosis tokens and the customer chain’s native token.
IBC Transactions:
- The updated exchange rate is used to calculate the amount of IBC tokens required for transaction fees.
- This allows users to pay transaction fees using IBC tokens instead of the customer chain’s native token.
Swapping IBC-Token Fees:
- The IBC tokens collected as transaction fees are periodically swapped back to the customer chain’s native token using Osmosis.
Funding by Osmosis Grants has already been issued to Notional to build 2 different modules for fee abstraction. The first version enables customer chains to pay fees in any IBC token on Osmosis, utilizing Oracle TWAP data.
The second version allows chains to convert accumulated fees into their native token using Osmosis.
In summary, the Fee Abstraction Module allows for more flexibility and efficiency in paying transaction fees across Cosmos chains by leveraging IBC tokens and the advanced features of the Osmosis network.
IBC Hooks
ibc-hooks is an IBC middleware that allows ICS-20 token transfers to initiate contract calls. The contract calls then facilitate cross-chain swaps by initiating token movement.
Ibc-hooks can be used as callback functionality and only the IBC packet sender can set the callback. When a cross-chain swap is implemented, an IBC transfer is initiated. However, If the transfer fails, the sender should be able to retrieve their funds, which would otherwise be stuck in the contract. Through the callback, users can retrieve these funds after the timeout period has passed.
By implementing callbacks, the system ensures that the sender is notified of the transfer’s success or failure, enabling appropriate actions to be taken, such as fund retrieval in case of failure.
Although posing a challenge to the traditional views of transactional irreversibility, Callbacks become increasingly important functionality, hedging against human error and security vulnerabilities.
IBC Rate Limit
To internalize blockchain bridge-related security risks, Osmosis introduced a safety control called the IBRC Rate Limit, which is responsible for adding a governance-configurable rate limit to IBC transfers.
This functionality aims to prevent any one bridge from being fully depegged in case of a software bug on Osmosis, on a counterparty chain, or on the IBC itself. The philosophy behind this module is that it is better to depeg 40% of assets in case of a hack, rather than lose 100% of the assets supported by the bridge.
IBC Rate Limit introduces a safety-liveliness tradeoff because the module alerts users of unusual on-chain activities and gives validators and developers time to analyze, react, and protect larger portions of user funds. The tradeoff is justified by the argument that it is optimal to sacrifice demand-driven liveness to prevent the net loss of funds.
Rate Limit Types
The rate limits are expressed in time-based periods such as 4-hour, daily, and weekly intervals and store the relevant amount of assets at the start of the rate limit. Rate limits are then defined on percentage terms of the asset and have discrete start/end times.
Hack possibilities stemming from malicious activities such as frequent back-and-forth transactions, are mitigated through the setting of separate rate limits for the inflow and outflow of assets. These separate rate limits are based on the net flow of assets on a channel pair.
For example, if the inflow rate limit is set higher than the outflow rate limit, it can help prevent a situation where too many assets are drained from the channel quickly. Conversely, controlling the inflow ensures that the channel does not get flooded with too many assets at once. The net flow helps in dynamically adjusting these limits based on the actual transaction behavior on the channel.
There are two types of rate limits, per denomination and per channel, although only the former type is live on-chain.
- Per denomination rate limits allow safety statements like “Only 20% of Stars on Osmosis can flow out in one week” or “The amount of Atom on Osmosis can at most double per 4 hours”. Although per denomination limits protect the type of messaging that is facilitated through IBC, it falls short of securely covering the entire chain because messages sent locally on Osmosis, not using IBC channels, are excluded from the rate limiting.
- On the other hand, per-channel rate limits restrict the total inflow and outflow on a given IBC channel, based on the “USDC” equivalent, using Osmosis as the price oracle.
Superfluid Staking
With Superfluid Staking users can contribute their assets to a liquidity pool and simultaneously stake those liquidity provider tokens (LP tokens), therefore earning rewards both from swap transaction fees and validation returns.
As a first step, users provide liquidity, to for example OSMO/ATOM pool, and get an amount of LP token representative of the value of their share of liquidity pool tokens. Moving forward, using Osmosis Swap, users can opt into Superfluid Staking by delegating a part of their LP tokens’ OSMO value to a validator.
As Osmosis LPs suffer from the same risk as the standard LPs, that is – impermanent loss, the Superfluid Staked OSMO is subject to the Superfluid Discount Factor which caps the LP tokens’ OSMO value that can be contributed towards staking. This cap stands at 50%.
To put Superfluid Staking into practice, let’s imagine that Bob wants to put $100 worth of Osmo to work.
- First, $100 of assets are placed in Pool #1 and Superfluid Staked.
- The 14-day bonding incentives would be earned on all of the value ($100)
- 50% of the value would earn rewards from Superfluid Staking ($50)
*It is important to mention that the value ($100) can experience volatility and is at risk if the validator that a user delegated to is slashed
When draining assets from Superfluid Staking using Osmosis, unstacking from the validator and unbonding from the pool will co-occur, meaning that users’ assets will be back to full liquidity in 14 days.
Since the value of the LP is erratic, the protocol checks the value of the LP token frequently throughout each epoch (~24 hours on Osmosis) to determine the appropriate staking rewards associated with the Superfluid LP tokens.
At the start of each day, the lockup module is checked to see how many Generalized Automated Market Maker (GAMM) tokens are locked, which in turn reflects the value of GAMM token shares.
The superfluid module has special messages, or “hooks,” that refresh the amounts that have been delegated and increase the delegation when more tokens are locked up.
Next, the value of the OSMO tokens that are currently delegated is compared with an expected value of the delegation amount based on the locked GAMM tokens. If the delegated OSMO is worth more than expected, OSMO tokens are undelegated and burned, reducing the supply. If the delegated OSMO is worth less, new OSMO tokens are minted to compensate for the difference and update the delegated amount.
In simple terms, it’s like checking a bank account balance daily and adjusting the amount of money you have based on how much you expect to have, either adding more if there’s too little or removing some if there’s too much. This process is shown in the diagram below.
ProtoRev transactions run outside of the regular block-building process (cannot be front-run, reordered, or left out) and allow osmosis DAO to capture the arbitrage profits that in other DEXs are lost to external agents like bots and centralized middleware providers.
The Osmosis DAO can use this revenue as needed including paying stakes, acquiring protocol-owned liquidity, and buying back OSMO or filling up community funds.
ProtoRev is a significant step towards MEV mitigation and capture, and it creates a sustainable revenue mechanism for DeFi applications, therefore establishing additional resources for the ecosystem growth.
Alloyed Assets
Due to a rapid rise of new protocols, token standards and dApps, composability, and fragmentation remain significant issues in user experience, since one coin can have many different iterations on various chains. For example, just on Osmosis DEX, there are 12 types of Ether including ETH.pica, cbETH, wstETH, and wETH.wh.
This can increase the probability of human error when it comes to interacting with Osmosis Dapps, especially for novice users, hence frustrating user experience and diminishing network adoption.
To solve this, Alloyed Assets have been introduced on the forum – a functionality that consolidates different versions of the same asset into a single, unified toke. For example, rETH, wETH, and cbETH would be alloyed into Alloyed ETH.
(Source: Goosenberg, 2024)
The combination of the assets under one token occurs within the DEX that is based on a liquidity pool, therefore Alloyed assets are just a representation of LP shares into one fungible token. So, if one were to deposit 6 rETH and 4 wETH into an LP, the user would get 10 alloyed ETH in return. By ensuring that assets transferred across diverse bridges become fungible within the Osmosis ecosystem, the Alloyed Assets system acts as a bridge aggregator or ‘bridge fungifier’. As this idea is in the discussion zone, the Osmosis governance has yet to determine which assets will be included in each Alloy.
Alloyed Assets leverage the ‘transmuter,’ a CosmWasm contract that facilitates 1:1 swaps without slippage, meaning that no value is lost after the Alloyed assets are received in exchange for other ones.
To manage risks associated with Alloying, Osmosis will utilize a two-tiered rate limiter comprising of Static Limiter and a Change Limiter.
- Static Limiter: This mechanism acts as a safeguard to ensure that no single version of an asset can exceed a specified threshold within the pool’s composition.
For instance, in an ETH Alloy, the Static Limiter can restrict ETH brought through the Wormhole bridge from comprising more than 30% of the Alloy’s total composition.
- Change Limiter: This limiter monitors and controls the rate at which an asset’s share of a pool can increase over a given timeframe, therefore providing a window for oversight and potential intervention and ensuring the pool’s integrity.
For example, an ETH alloy can limit ETH via the Wormhole bridge from increasing its composition by more than 15% in 24 hours.
Conclusion
Overall, Osmosis stands out as a dynamic and innovative chain within the Cosmos ecosystem, which actively addresses some of the most pressing issues of DeFi. By leveraging its unique app-chain architecture, coupled with technologies such as Inter-Blockchain Communication (IBC), Superfluid Staking, and Alloyed Assets, Osmosis enhances interoperability, security, and user experience. Its customizable AMM infrastructure and concentrated liquidity options cater to the evolving needs of DeFi markets, ensuring optimal efficiency and flexibility.
Meanwhile, innovative mechanisms like the Fee Abstraction Module and IBC Rate Limits facilitate seamless and secure transactions across chains. With its continuous efforts to integrate new protocols and technologies, Osmosis is making significant strides in creating a seamless, user-friendly DeFi experience, solidifying its position as a solid player in the DeFi landscape.
Disclaimer: This article contains affiliate links. If you click on these links and make a purchase, we may receive a small commission at no additional cost to you. These commissions help support our work and allow us to continue providing valuable content. Thank you for your support!
This article is provided for informational purposes only and is not intended as investment advice. Investing in cryptocurrencies carries significant risks and is highly speculative. The opinions and analyses presented do not reflect the official stance of any company or entity. We strongly advise consulting with a qualified financial professional before making any investment decisions. The author and publisher assume no liability for any actions taken based on the content of this article. Always conduct your own due diligence before investing.
