What is Flow?

Conventional Blockchain application development used to be done on Ethereum, but technological progress and the increase in users has brought with it scalability issues. Flow was born as a new generation blockchain to solve these problems.

It has a unique architecture that allows it to scale without fragmentation in a secure, fast and simple way. In other words, its speed and performance are superior, and it also maintains a friendly environment for developers.

Flow operates with the Proof of Stake (PoS) algorithm. Its network protocol is designed to scale thanks to a multifunctional architecture in which each node fulfills its own function. And with the novelty that, instead of implementing a horizontal flow, the Flow platform uses the so-called vertical flow. Its advantage is that it separates the objective (deterministic) processes from the subjective (non-deterministic) processes.

Transaction Success Rate by Transaction Volume

The first approach is to look at the daily relationship between transaction volume and success rate of transactions since May 9th.

Daily

Once shown that the transaction volume and success ratio are not directly correlated, another approach is to focus on the recent drop in success rate to see if there is a pattern with a specific time of the day.

Hourly

Looking at the previous chart, no apparent relation was found between transaction volume and transaction success rate. On May 9th and May 27th, transaction volume was at its peak (around 800k daily transactions), but on the first the success rate was very high (0.93) while in the latter it was very low (0.36). Also, the success rate decreased on May 13th to 0.62, but it went up the next day. On the other hand, from May 26th to May 30th there was a massive decrease in the success rate. Thus, there is confirmation that there is no linear relation between success rate and transaction volume, as on May 28th the amount of transactions was lower than on the previous days and yet the success rate was at its lowest.

Methodology

The required data to obtain the transactions success rate was obtained from the flow.core.fact_transactions table. First, a table was created with the daily amount of successful transactions by filtering by tx_succeeded = TRUE. Then, the same process was followed for failed transactions by using tx_succeeded = FALSE. Those tables were used to get the following:

• Transaction volume = successful transactions + failed transactions

• Success Rate = successful transactions / transaction volume

Error Message Types

The chart above shows the hourly success ratio since May 25th, which is the day when the massive drop in success rate started. Even though, there in no clear relationship between exact hours, it seems like the morning (UTC time) has more failed transactions. We can make the mistake of thinking that this is due to the fact that at that time range there is more volume of transactions, but the following graph shows that the hours that have the best success rate have more volume of transactions than the ones with the lowest success rate on some days (May 26th), while the opposite can happen on others (May 30th).

Having analyzed the time metrics, data can also be interpreted based on what might be causing these failed transactions. Thus, another approach is to check what error messages were being obtained from failed transactions since May 9th. After doing some research, the following error codes were found:

Now that each error is understood, a count is done on how many errors of each type have occurred on failed transactions since May 9th to check if the number of any of them increased since May 25th (when the big drop in success rate happened).

These error codes can be interpreted as:

• 1006: Invalid proposal key. This means that the public key used on a certain account does not have a valid signature. This error also generates another error code (1008), which is due to an invalid payload signature. It won't be counted, as it is generated within the same failed transaction as the error code 1006

• 1007: As the previous one, it is also an invalid proposal key error. The difference is that this time it's because the account is using a public key that is not the one that has been given to it

• 1055: The authorization failed for the account. This happens when the payer account does not have sufficient signatures (1 < 1000)

• 1101: Cadence runtime error execution failed. It is usually due to underflow, but it can happen in other scenarios like when there is a failed precondition (e.g. when no token matches an ID for sale)

• 1103: The account is using more bytes of storage than its capacity (100000 bytes). Capacity can be increased by adding FLOW tokens to the account

• 1109: Failed to deduct transaction fees. This generates the error code 1105, which happens when the total event byte size exceeds the limit (256000). It won't be counted, as it is generated within the same failed transaction as the error code 1109

• 1110: Computation exceeds limit

• 1205: Storage used is not initialized or not initialized correctly

Error Message Type Frequency

From the previous chart we know that when the success rate decreased in May 25th, it was because most transactions failed due to the error code 1101.

Error Code 1101

The reason behind a decrease in the success rate is clear to be because of the error code 1101, but why is this error happening?

The above table shows that since May 25th, the main reasons why transactions failed were because of an account having an underflow, and because a pre-condition failed. Let's explain when these scenarios happen in detail:

• Underflow. It usually happens when the true result of a floating point operation is smaller in magnitude than the smallest value representable as a normal floating point number in the target datatype.

• Pre-condition failed. This situation occurs maily in two cases: when there in no token matching an ID for sale and when you want to swap a token in a pool, and there are not enough tokens in the pool to perform the swap. For example, imagine you want to perform a swap in a FLOW/USDC pool. If there are only 50 USDC in the pool and you want to swap an amount of FLOW higher than the equivalent of 50 USDC, the swap won't be able to be performed and you will get a failed transaction with the Error Code: 1101.

Nevertheless, by the number of failed transactions coming from each subtype of the error code 1101, underflow can be considered to be the reason behind the transaction success rate drop, as it happens almost five times more often than the second one.

The error is known now, but what has caused this recent increase in underflow errors?

Failed Transactions: Account 0a386460e7fe7e27

After analyzing the transactions, a pattern was discovered. There was an account created on May 20th 2022, that was the major cause of the recent transaction success rate drop.

The previous chart shows the correlation between the transaction success rate and the impact that this account has had over the overall failed transactions in the blockchain each day. As the impact that this account has on the amount of failed transactions increases, the succes rate decreases.

This account (0a386460e7fe7e27) has been doing arbitrage in FLOW, taking advantage of the low fees of this blockchain. It performs the arbitrage with a bot using Increment Finance and BloctoSwap as dex, and the FLOW/USDC pool (as it is the pool with the highest liquidity). Nevertheless, it gets so many failed transactions a day that the overall transaction success rate has dropped significantly in the FLOW blockchain.

It is confirmed that this account has been the responsible of the recent transaction success rate drop, as it accounts for 52% of all failed transactions that have occurred on the FLOW blockchain between May 25th and May 30th.

Arbitrage transaction success ratio can be measured as the amount of successful transactions divided by the total amount of transactions the account performs every day. It is shown that the transaction success ratio has been decreasing because the arbitrage bot is loosing efficiency. As days go by, it needs more transactions to obtain profit, resulting in more failed transactions and hence there is a decrease in the blockchain transaction success rate. As transaction fees in the FLOW blockchain are very low, the cost of increasing the number of daily transactions is not very big compared to the rewards that an arbitrage opperation might provide. Nevertheless, as most of the liquidity is in the FLOW/USDC pool, the more arbitrage is performed in this pool, the more similar the price will be in Increment Finance and BloctoSwap, and the fewer opportunities there will be to obtain benefits. At a certain point, the arbitrager will have to decide if it is still worth it to carry out such a high number of transactions for such a small profit. When this is no longer the case and the account stops arbitraging, the success rate should increase again.