The XRP Ledger recorded 3,254 transactions in a single validated ledger, setting a reported new high for the number of transactions included in one ledger. Ledger 106,965,249 contained the record transaction count during an unusually concentrated burst of activity on September 13, with the underlying ledger available through the XRPL live explorer.
The headline figure requires an important distinction. Of the 3,254 transactions included in the ledger, 2,295 returned successful results while 959 produced non-success outcomes, meaning the full transaction count should not be treated as 3,254 completed payments. The validated ledger closed at 20:51:50 UTC on September 13.
Small XRP Payments Drive the Record
The activity was heavily concentrated in simple XRP transfers. Twenty submitting accounts generated 2,000 successful small-value payments, with each account submitting 100 transactions, supporting the possibility that at least part of the burst represented deliberate throughput testing rather than organic payment demand. The identity and intent of the operator have not been publicly confirmed.
That transaction mix also matters when evaluating network performance. A ledger filled with simple XRP payments does not impose the same computational workload as an equivalent number of DEX trades, complex payment paths or other state-intensive operations. Transaction count alone therefore cannot establish a permanent or generally applicable throughput ceiling for XRPL.
The record should also not be attributed to the recently introduced fixCleanup3_3_0 amendment. Official XRPL documentation defines fixCleanup3_3_0 as a collection of targeted bug fixes rather than a throughput upgrade, covering areas including freeze checks for pseudo-accounts, Checks validation, permissioned DEX offers and AMM quality calculations.
XRPL Uses an Adaptive Transaction Target
XRPL does not rely on a rigid transaction count for every ledger. Its servers calculate a soft transaction limit based partly on the size and performance of previous ledgers, while transactions exceeding that target face progressively higher fee requirements or can be pushed into the transaction queue.
The mechanism can adjust automatically as conditions change. If a ledger contains more transactions than its soft target, the target can increase for the next ledger; if consensus takes longer than five seconds, the target can decrease. This allows XRPL to adapt transaction density while prioritizing timely consensus instead of treating a single high-count ledger as the network’s new fixed capacity.
The record therefore provides evidence that validators reached consensus on an unusually dense mainnet ledger, but it does not establish sustained throughput above 900 successful transactions per second or prove that XRPL can continuously process 3,254 transactions every ledger. Failed transactions can also be included in validated ledgers and consume fees, further limiting simple TPS calculations.
The next meaningful indicator will be whether similarly dense ledgers can recur under more diverse transaction workloads without materially increasing consensus times. Sustained performance across payments, DEX activity and other transaction types would provide stronger evidence of practical throughput than a single record dominated by concentrated small-value transfers.
Jack Reynolds is SatoshiPick’s infrastructure mind. Based in Denmark, he follows Bitcoin, Ethereum, Layer 1 networks, stablecoins and DeFi with a practical question always in the background: does this actually make crypto work better?
His articles focus on the systems beneath the headlines: settlement rails, protocol upgrades, stablecoin usage, DeFi coordination and the regulatory limits around them. Jack avoids turning technical coverage into a maze. He explains what is live, what is still experimental and why the difference matters.