Try Quests to earn cryptoOsmosis Transaction Failures
A blockchain is like a publicly accessible computer. Everyone willing to pay gas can execute code in the form of transactions on it. It's a given that some of that executed code will fail. Maybe because someone made a mistake, maybe because something on the chain changed or maybe even because something malicious was tried. In this dashboard we will look into common causes for failed transactions on the Osmosis chain.
If at any point during the transaction execution a error comes up, a specific error code will be stored which can then be used to identify what happened. On flipside that column is called 'tx_status' Let's take a look at the raw numbers, how many transactions do we have in total and how many of those fail?
Findigs
During most of 2022 the ratio of failed to total transactions was constant or even slightly decresing. All that changed on May 9th. After a huge spike in failed transactions the error rate continued to be a lot higher than in the previous months.
Suspicion
Given that the entire Terra disaster really started to pick up speed on the 9th and Osmosis providing liquidity pools for trading Luna and UST this could be a reason for the many failed transactions.
Let's at first look at the most common TX status values amongst failed transactions.
Error Codes
- 7 Slippage Tolerance Exceeded ( and invalid address format )
- Invalid address is very rare, basically all code 7 errors are caused by the slippage tolerance.
- 32 Incorrect Account Sequence
- 30 TX Timeout Height
- 5 Insufficient Funds
- 11 Out of Gas
Slippage Tolerance
When swapping assets in a liquidity pool there can be swaps executed in that pool between you submitting your transaction and your transaction being executed. This can either happen randomly or intentionally (front running). In order to protect yourself from price changes there is a "slippage tolerance" value which makes the transaction fail if the price changed more than a specified minimum amount.
In order to investigate the previous suspicion we will also take a look at the distribution before and after the terra "incident"
Both before and after May 8th most failed transactions were caused by the slippage tolerance check. It makes sense to see a steep increase of slippage tolerance being exceeded during the LUNA incident as prices were moving fast and a lot of pairs existing that allow swapping for UST.
Yet I would expect a lower percentage of tolerance slippage fails before the incident and in general a lower percentage. Checking about 20 example transactions manually I found that all of them were actually transactions trying to perform arbitrage. Likely bots which explains why they can account for such a large percentage.
Events often included in failed transactions
In Osmosis transactions can create events during their execution. Many common segments of transaction execution already automatically emit events. (Coins being received, sent or trasfered...) Looking at the event types emitted by failed transactions gives us yet another angle to view transaction errors from.
Looking at this graph you immediately notice something weird. message, coin_received, coin_spend and transfer all share the exact same percentage of events in failed transactions. This strongly suggests that there is exactly type of transaction that emits all of those events and no transaction type that emits only a subset of them.
Looking at how many distinct events types (excluding tx) are emitted by every failed transaction that emits at least one of those 4 types we find that 100% of transactions emit all 4. This verifies the previous suspicion that all transactions that emit one of those events do emit all of them. Sadly the tables do not provide enough information to figure out which transaction types are actually used though.
Concluding
Most Common Errors for the average user
- Slippage Tolerance Exceeded
- Out of Gas
Preventing those
- Increase the slipping tolerance in times of high volatility
- Include a higher gas limit especially in times of network congestion (also often around high market volatility)
Most Common Errors for manual transaction makers (Tools for end users generally prevent running into those issues)
- Incorrect Account Sequence & Insufficient Funds
- Those come down to transaction order. Make sure previous transaction are complete before sending new ones. If you need to send transactions in quick succession you should consider putting them into a single transaction (Osmosis does support aggregating them!)
- TX Timeout Height
- This can be used to prevent transactions from locking up something e.g. in cases of network congestion. As you need to manually add this to a transaction it comes down to what you are using it for.