Transactions Failing On Osmosis

    Establish the failed transaction rate for Osmosis over the last 4 months. Make a case for what is causing the failed transaction rate that you assess and provide recommendations to mitigate it.

    Introduction To Osmosis Lab

    Osmosis is an AMM (Automated Market Maker) Built on Cosmos SDK, which enables the creation of customized AMMs; that is the reason it's called a lab since developers and users can initiate their liquidity pools with various parameters which are changeable, and make it possible to reach to optimized situation that works for you. Osmosis tries to extend to use cases for bonding curves through options like custom-curve AMMs, dynamic adjustments of swap fees, multi-token liquidity pools, decentralized formation of token fundraisers, interchain staking, options market, and more for the Cosmos ecosystem.

    What are we looking for?

    In this bounty, we are starting to take first looks on Osmosis database provided by flipsideCrypto. We are looking at failed transactions on Osmosis, how they look, what could be the possible reason and solution for it? Also following this dashboard lets you get more familiar with some fundamental structures of osmosis database.

    Let's start with some broad perspective of failed transactions and its ration in the past 4 months. First chart depicts the number of daily failed transactions and shows the obvious growth that happened after May 9th; with 526k failed transactions on May 12th at its peak!

    Loading...
    Loading...

    To make sure this is not just due to increasing the overall transactions count, I calculated the daily Ratio of Failed transactions/Total transactions; this confirmed that number of failed transactions are growing significantly starting from May crash and Terra falling; on May 12th 58% percent of transactions Failed!

    So the problem looks serious and demands further investigation. What can be found inside a failed transaction info? First of all, it's tx_code. It seems that every failed transaction falls into a numerical category which represent its type. I grouped this categories to which ones contain more failed transactions:

    Loading...

    A step further we can see that evert tx_code contains some codespace representing a form of textual name of the type of transaction that was broadcasted and recorded. I took top 5 tx_codes to see which codespace they are having:

    Loading...

    gamm and SDK are by far responsible for most failed transaction codespaces. so we do one more test to see if they are responsible for latest growth in failed transactions:

    Loading...

    This chart shows that we can evidently take gamm as the responsible function for most failed transaction on osmosis recently. so what is gamm? Im not a technical blockchain guy so i'm quoting from Osmosis Docs:

    The x/gamm module implements an AMM using Balancer style pools with varying amounts and weights of assets in pools.

    How this module can fail?

    Well, there are a lot of functions running with this module, but let's take joining and exiting pools as an example:

    when you want to join or exit a pool, there is instant calculation which determines the maximum tokens you are willing to provide for a certain share of the pool and minimum tokens you get for burning a certain share of pool's LP. So, if this instant calculation make you ineligible, transaction will fail.

    Why do I believe this was the case with Osmosis?

    I expect this failure happen in times of high volatility in market when people start to withdraw their liquidity to save their assets or positions. considering the set point for growing failed transactions was the beginning of terra death spiral, this make sense perfectly. since the calculation is instant, the minimum token that you get for burning your LPs decrease every second and make it impossible to withdraw successfully. This is also true in case of swaps when slippage is increasing every second.

    chart below shows that this is not a simple scaling issue and congestion as gas keeps it's ratio:

    Loading...

    Possible solution for this:

    • Letting people decide themselves what would be their minimum or maximum of entering and exiting the pool instead of determining this automatically.
    • putting some limit on amount so huge transactions won't let to failing of so many other transactions and providing equal chance for everyone.
    • optimizing the gamm module in any possible way