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".
@LaurentMT: at least at this point meta-protocols like Omni or Counterparty have dedicated outputs for recipients, while the OP_RETURN script only holds the command such as "send n tokens to the recipient".