The XRP Ledger processed a record 3,254 transactions in a single validated ledger, setting a new high for transaction count during a concentrated burst of network activity. The record occurred in ledger 106,965,249, which closed on September 13 before being highlighted publicly by XRPL Foundation community director and validator Vet on September 14.
Vet said most of the activity consisted of extremely small XRP payments and appeared consistent with throughput testing rather than a sudden increase in ordinary user demand. Two thousand of the transactions came from 20 accounts sending 100 one-drop payments each, with one drop representing one-millionth of an XRP.
One-Drop Payments Drive the Record
The composition of the ledger is important because different XRPL transaction types impose different computational loads. Simple XRP payments are comparatively lightweight, while decentralized exchange trades, cross-currency payments and other more complex operations can require substantially more processing. A record transaction count therefore does not translate directly into an equivalent record for computational throughput.
The record ledger also contained other activity, including decentralized exchange orders, ticket creation and check-related transactions. At least 890 transactions reportedly returned tec failure codes, meaning they were included in the validated ledger and paid transaction costs without successfully completing their intended operation. The 3,254 figure measures transactions included in the ledger rather than 3,254 successful economic transfers.
The event followed two other short-lived records of 2,713 and 2,768 transactions within roughly the same period. The rapid succession of unusually large ledgers adds further evidence that the activity was deliberately testing how the network behaved under concentrated transaction load.
XRPL Uses an Adaptive Transaction Target
Unlike a blockchain governed by a fixed transaction count per block, XRPL uses an adaptive soft limit as part of its fee and transaction-queue system. The official XRP Ledger documentation states that servers can increase the soft limit when the preceding ledger contains more transactions than the target, while the limit can decrease if consensus takes longer than five seconds. The mechanism is designed to let throughput respond to observed network conditions while protecting consensus performance.
Once activity exceeds the soft target, XRPL’s open-ledger transaction cost can also rise rapidly, encouraging lower-priority transactions to wait in the queue. That design means the 3,254-transaction ledger should be viewed as a burst handled under adaptive network conditions rather than a newly established permanent capacity of 3,254 transactions per ledger.
No network disruption or validator failure was reported during the event, and Vet said the ledger maintained acceptable closing performance. The practical significance of the record is therefore that XRPL absorbed an unusually concentrated batch of mostly lightweight transactions without establishing a new fixed throughput ceiling.