# What are the best ways to calculate the time for XLM transaction based on the projected growth of the network?

I'm curious how to best estimate the time per transaction as the existing number of transactions double/triple/10x.

Currently I know the infrastructure of federated endpoints is meant to optimize for speed. Stellar transactions are very fast in comparison to larger digital currency (ie. Bitcoin/Ethereum).

Is there a clear sense of how the transaction costs, in regards to time, will grow/change based on the network's size?

On Google's cloud servers they managed 36,000,000 transactions per second hour. Visa handles 24,000. So as far as time goes I suspect it will take the same amount of time as it does now unless it gets way way bigger than Visa. Even then there are likely still ways it can be better optimized but we haven't gotten to the point where it's a concern.

The fee is always equal to the number of operations times the base fee which is currently set at 0.00001 XLM (0.000004 USD) and will remain mostly fixed.

edit: per hour not per second. 36,000,000 transactions/hour = 10,000 transactions/second.

• Those tests don't seem that realistic but are useful to get an idea of the upper bound - at the end of the day the limits are defined by the hardware and network connectivity that validators are using. If most validators are cheap (and ideally we can keep the bar of entry for validators low), the software has to compensate for it. We had people try to run core on raspberry pi - of course that won't scale to large number of tx/s (but would be extremely cheap), the other extreme is everybody pays big \$\$ for running in GCP. The good news is that the cost of transactions is not tied to validators Commented Jan 18, 2018 at 2:48

Throughput is 1000 transactions per second. If the network load was demanding 2000 transactions in a second then it would take 2 seconds to fulfill that need. If that need was maintained for 4 hours, then how long does it take the last transaction at the 4th hour to process?

I think this is the type of question this is asking. I will try to answer:

At the end of the 4th hour we have been asked to process 8000 transactions. Of those, only 4000 were fulfilled. That means we need 4 more hours to fulfil the last transaction. Let us try to put this in a formula, but please note this formula is taking into account a constant need where in reality need fluctuates. We also need to know the current backlog size.

Trx Backlog Qty

4 hours * 60 mins * 60 secs * 1000 unfulfilled trxs = 14,400,000

Transaction Wait Time (Seconds)

Trx Backlog Qty (14.4M) / XLM Transactions Per Second (1000)

Transaction Wait Time (Seconds) = 14,400 seconds = 4 hours

One more example at x7 overload over 5 hours.

Trx Backlog Qty

5 hours * 60 mins * 60 secs * 6000 unfulfilled trxs = 108,000,000

Transaction Wait Time (Seconds)

108,000,000 / 1000 = 108,000 seconds = 30 Hours

It would take 30 hours for the last transaction at the 5th hour to process.

This is why when an ICO happens on ETH, people have to wait a long time for a transaction to process.

Peace!