<p>There's a self-regulating mechanism that keeps the network running so that it's not as fast as the fastest validator (as that would make attacks too easy) nor as slow as the slowest validator (as that would provide poor performance). But Ripple has never claimed on ledger transactions rates that high. To get to 50,000 TPS, you need to use off-chain scaling schemes like payment channels.</p>

<p>This is a fundamental scaling limit with all public ledgers that try to create fungible tokens. Every full node must process every transaction and thus if you try to get the number of on chain transactions very high, you impose high bandwidth, CPU, and storage costs on everyone. (You can trade off some fungibility, as IOTA does and as some sharding schemes do.)</p>

CC BY-SA 4.0
2018-06-16T15:55:25.180Z
Is there a limit to the number of transactions that can be processed in any single round?
Rich Apodaca
CC BY-SA 4.0
2018-06-19T00:18:27.693Z
There is no hard limit. There is a heuristic that admits transactions into the round based on how large a fee they pay and the performance of recent rounds. If a large backlog of transactions accumulate, each round will include more and more of them until either the backlog clears or consensus starts to degrade. If consensus degrades, fees will go up and the number of txns allowed per ledger will go down.
David Schwartz
CC BY-SA 3.0
2017-12-30T09:25:28.313Z
2017-12-30T09:25:28.313Z
David Schwartz
<p>I've tried wrapping my head around the Ripple &quot;<a href="https://ripple.com/build/xrp-ledger-consensus-process/#footnote_7" rel="nofollow noreferrer">consensus process</a>&quot;. From my understanding, Ripple creates a new ledger version every 4 seconds, computed by a set of &quot;validating nodes&quot;.</p>
<p>But herein lies my question, how will the validating nodes push a new ledger version at the scale of their advertised capacity<sup><a href="https://ripple.com/xrp/" rel="nofollow noreferrer">[1]</a></sup>? How would validating nodes with slower connections keep up?</p>
<p>[1]: <a href="https://ripple.com/xrp/" rel="nofollow noreferrer">https://ripple.com/xrp/</a></p>

<blockchain><ripple><consensus>
How will Ripple handle the 50,000+ advertised TPS?
kemp
# How will Ripple handle the 50,000+ advertised TPS?

(Asked by: username_0 on 2017-12-30)

I've tried wrapping my head around the Ripple "[consensus process](https://ripple.com/build/xrp-ledger-consensus-process/#footnote_7)". From my understanding, Ripple creates a new ledger version every 4 seconds, computed by a set of "validating nodes".

But herein lies my question, how will the validating nodes push a new ledger version at the scale of their advertised capacity[[1]](https://ripple.com/xrp/)? How would validating nodes with slower connections keep up?

[1]: <https://ripple.com/xrp/>

**Tags:** blockchain, ripple, consensus


---

## 1 answers

### Answer by username_1 on 2017-12-30. Score: 1

There's a self-regulating mechanism that keeps the network running so that it's not as fast as the fastest validator (as that would make attacks too easy) nor as slow as the slowest validator (as that would provide poor performance). But Ripple has never claimed on ledger transactions rates that high. To get to 50,000 TPS, you need to use off-chain scaling schemes like payment channels.

This is a fundamental scaling limit with all public ledgers that try to create fungible tokens. Every full node must process every transaction and thus if you try to get the number of on chain transactions very high, you impose high bandwidth, CPU, and storage costs on everyone. (You can trade off some fungibility, as IOTA does and as some sharding schemes do.)

> **Comments:**
> **username_2**: Is there a limit to the number of transactions that can be processed in any single round?  
> **username_1**: There is no hard limit. There is a heuristic that admits transactions into the round based on how large a fee they pay and the performance of recent rounds. If a large backlog of transactions accumulate, each round will include more and more of them until either the backlog clears or consensus starts to degrade. If consensus degrades, fees will go up and the number of txns allowed per ledger will go down.  

---

