Summary

Osmosis is an automated market maker (AMM) built on Cosmos that enables cross-chain transactions through Inter-Blockchain Communication (IBC). This gives the protocol an added layer of interoperability and composability. Unlike most existing AMMs, Osmosis is deeply customizable and allows developers to leverage many different changeable parameters to build truly unique AMMs that can dynamically fit a variety of outcome goals. Ultimately, Osmosis enables developers to design and deploy custom AMMs that can quickly adjust to changing market conditions and allow market participants to decide which iterations provide the most optimal results, rather than relying on the protocol itself.

Introduction

In the introduction of this dashboard, I will give a definition of osmosis so that we can get a little familiar with this topic, and then we will continue to analyze the question.

**We got help from this link : **

Overview

Most existing AMMs are confined to operate within the native blockchain in which they were originally built. While there are workarounds, this places certain limitations on developing a truly chain-agnostic AMM that can execute transactions across different networks seamlessly and efficiently. In addition, while the features between AMMs can vary quite significantly, they are often hardcoded into the protocol, leaving a rigid infrastructure that is unable to adapt quickly to the demands of an ever-changing market. Developers very rarely have the freedom to change key parameters like swap fees, token weights, let alone the more infrastructure-drive values such as the curve algorithm or TWAP calculation.

For instance, popular AMMs like Uniswap V3 allow users to create liquidity pools with different fee sizes, specifically between 0.3% and 1%. This creates a bit of a quality of life improvement for casual users in that they are not required to spend time tinkering with the underlying tokenomics and implications of a given set of LP fees. It also provides some flexibility and is useful in cases that involve more exotic token pairs. For more sophisticated users, however, additional parameterization might be useful to better react to changing market conditions. This approach also shifts the focus of fee structures away from how common or how rare a given token pair is to be more comprehensive by including other factors such as slippage and market volatility. Ultimately, there is no single solution that fits all AMM design goals, and an additional layer of customization helps developers fine-tune optimal strategies around fees and liquidity provision, and takes into account other factors that may directly impact success of the AMM.

Osmosis attempts to solve these shortcomings in many different ways. To begin, the protocol was developed using the Cosmos SDK which allows it to operate across chains. This gives Osmosis access to any chain built on the Cosmos ecosystem which unlocks over $10B in TVL. It also allows Osmosis to integrate with non-IBC enabled chains, such as Ethereum, giving it even more composability and interoperability.

From a design perspective, Osmosis is focused on user experience and a deep level of customization. The protocol extends AMM functionality beyond simply token swaps and implements a host of other features such as bonding curves, dynamic fee swaps, and multi-token liquidity pools. It therefore enables developers to build, design, and deploy their very own AMM, fully customized with novel parameters and fully connected to the IBC ecosystem and beyond.

Mechanism Design and Tokenomics

$OSMO is the native token of the protocol and is used primarily for governance and staking. Token holders can delegate their $OSMO to a validator and receive staking rewards and voting rights in return. Once staked, token holders can engage in governance by making proposals and voting on different issues including protocol upgrades, determining the base swap fee of the Osmosis network, and allocating liquidity mining rewards. More features can be added to voting as the scope of governance expands over time.

One particularly interesting feature of Osmosis governance is that it is tied to liquidity pool rewards provision. That is, token holders that participate in governance are responsible for selecting which liquidity pools are eligible to receive liquidity rewards. This is an interesting mechanic in that it allows stakeholders to dynamically incentivize liquidity pool provision and determine strategies that constantly evolve over time, adjusting to changing market conditions. An obvious downside, however, is that this assumes that token holders, given that they have a long-term vested interest in the protocol’s well-being, also know which stratagems to implement to best incentivize liquidity pools. If token holders guess incorrectly, then general liquidity volumes could suffer as liquidity providers exit to other AMMs to enjoy more favorable conditions. If they guess correctly, then Osmosis would presumably be able to poach liquidity providers from other AMMs, given that their native reward-incentive scheme is superior to competitor models. 

\n

The method of solving this bounty

In order to be able to answer the question of this bounty, I used these tables in the first step :

osmosis.core.dim_prices and osmosis.core.dim_labels and osmosis.core.fact_swaps and osmosis.core.fact_liquidity_provider_actions

there are two type of pools:

single side and both side i checked the charts weekly.

According to the single side and booth side, we analyze the graphs based on the number of users, the number of transactions and the volume of transactions.

According to the graph of the number of users, what we see is that in the first weeks of the graph, the number of users of both side is more than the number of users of single side, but in the weeks after July 2022, we can say that the number of users is almost equal.

According to the graph of the number of users, what we see is that in the first weeks of the graph, the number of users of both side is more than the number of users of single side, but in the weeks after July 2022, we can say that the number of users is almost equal. The accumulated sum in the chart opposite Boothside is higher than Singleside and the number of Boothside users is approximately 205,000 users and Singleside is approximately 100,000 users, which is almost twice as much according to the diagram.

charts weekly

In general, almost 63% of the users are both sided and almost 36% are single sided.

both side : 78.5 K

single side : 44.5 K

According to the graph of the number of weekly transactions that we see in front of us, the number of booth side transactions is more than the single side in most weeks, but in the final weeks, the number of transactions is almost equal.

In total, almost 70% of the number of transactions is for both side and almost 30% of the number of transactions is for single side, which is equal to 305 thousand for both side and 134.5 thousand for single side.

According to the weekly volume chart, in most weeks the volume of Booth side is higher than that of Single side. According to the chart, the largest volume of Boothside is related to the last week of October 2022 with 5.5 billion dollars.

Our observations are almost the same as the average volume

The average volume of the booth side is 88.9 percent of the total, and the single side is approximately 21.1 percent.

The cumulative volume of the booth side is approximately equal to 11.3 billion dollars, and the cumulative volume of the single side is also equal to 620 million dollars.

According to the diagram we see above, based on the volume of the OSMO, the largest volume in both side and single side is assigned to itself, and it is in the next position of the ATOM.

OSMO and ATOM have the most transactions respectively.

OSMO : 5.2 B in both side and253.7 M in single side with 243.8K transaction in both side and 105.4 K transaction in single side

ATOM: 899.6 M in both side and 31.5 M in single side with 129.3 K transaction in both side and 19.3 transaction in single side

NUMBER OF USER:

20.1K in both side and 14.5K in single side below 10 $

23.3K in both side and 14.2K in single side beetwen 10$ to 50$

18.8K in both side and 8436K in single sidebeetwen 50$ to 100$

22.5 K in both side and 10.1 K in single sidebeetwen 100$ to 250$

18.3 K in both side and 7674 K in single sidebeetwen 250$ to 500$

16.4 K in both side and 6771 K in single sidebeetwen 500$ to 1000$

23.8 K in both side and 9.8 K in single sidebeetwen 1000$ to 10K$

7970 in both side and 2813 in single sidebeetwen 10K$ to 100K$

1357 in both side and 380 in single sidebeetwen 100K$ to 500K$.

NUMBER OF TRANSACTION:

71 K in both side and 40.5 K in single side with one transaction

33.3K in both side and 17K in single side with two transaction

16.2 K in both side and 7319 in single side with 3 transaction

8983 in both side and 3874 in single side with 4 transaction

5527 in both side and 2238 in single side with 5 transaction

3726 in both side and 1357 in single side with 6 transaction

2596 in both side and 940 in single side with 7 transaction

1896 in both side and 616 in single side with 8 transaction

1453 in both side and 427 in single side with 9 transaction

1115 in both side and 330 in single side with 10 transaction

3955 in both side and 1049 in single side with beetwen 11 to 25 transaction

603 in both side and 193 in single side with higher 25 transaction

final conclusion

In the end we realized that:

the number of users, what we see is that in the first weeks of the graph, the number of users of both side is more than the number of users of single side the number of weekly transactions that we see in front of us, the number of booth side transactions is more than the single side in most weeks in most weeks the volume of Boothside is higher than that of Singaside the volume of the OSMO, the largest volume in both side and single side

Discord: Sagharkari#0109

Twitter: @sagharkflipsid1

Tweet Link For This Dashboard:

The code’s credit is for masi#0814 in Discord