Counting on-chain transactions alone to illustrate pretty much anything is wrong. One should take into account at least TX batching.
A possibly better way is to calculate based on new UTXOs created excluding the change outputs.
Doing rough calculations, we assume the worst case of every TX having a change output, so the results are the most pessimistic version and actual numbers are better.
Month | TXs | UTXOs created | Net UTXOs [1] | Naive TPS [2] | Actual TPS [3] |
---|---|---|---|---|---|
DEC 2017 | 11,190,438 | 30,666,017 | 19,475,579 | ~4.18 tps | ~7.27 tps |
NOV 2017 | 9,345,256 | 25,120,209 | 15,774,953 | ~3.60 tps | ~6.08 tps |
MAY 2017 | 10,061,195 | 24,804,799 | 14,743,604 | ~3.75 tps | ~5.50 tps |
Data source: https://oxt.me/charts
[1]: Assuming the worst case of every TX having a change output
[2]: Plain TXs population divided by period secs
[3]: Bottom range of effectively the actual transactions per second rate
Setting aside blockchain forensics to identify change outputs, for slightly more accurate results, one could include single output TXs to the results which should increase the "actual TPS".
Note that OXT counts OP_RETURN outputs as UTXOs and you may want to substract them from your figures.
On the other side, I'm not sure that we can consider all OP_RETURN being the same. For instance, while it would seem fair to remove those created by timestamping services, I don't think that we should remove those transferring assets (color coins, etc).
Anyway, considering the low number of OP_RETURN (340,193 in DEC 2017), it's not going to change the conclusion of your results (e.g. DEC 2017 => ~7.14tps with all utxos removed).