The XRP Ledger has processed 3,254 transactions in a single ledger, according to XRPL validator Vet, marking the network’s largest reported transaction count for one ledger.
Most of the activity consisted of transfers worth just one drop of XRP, the smallest unit of the token. The unusually small payments indicate that the surge may have been intended as a throughput test rather than a period of typical user activity.
Adaptive capacity shaped the record
The milestone does not mean that the XRP Ledger has permanently increased its transaction limit. Unlike networks that use a fixed block-size target, XRPL operates with an adaptive transaction target that can respond to network performance.
Validators may process more transactions when a ledger closes quickly, even if activity exceeds the current target. The practical workload also depends on transaction type: simple XRP payments require fewer resources than more complex operations. As a result, 3,254 basic payments do not necessarily represent the same processing burden as an equal number of advanced transactions.
Protocol upgrades are in development
The record comes as developers prepare changes introduced with xrpld version 3.3.0, released on August 6. The update includes the BatchV1_1, ConfidentialTransfer, DynamicMPT, PermissionDelegationV1_1 and Sponsor amendments, alongside protocol fixes for XRP Ledger servers.
BatchV1_1 allows an account to submit up to eight inner transactions within a single batch. ConfidentialTransfer is designed to support private transfers for certain tokens, while Sponsor allows one account to cover another account’s transaction fees or reserve costs under protocol-defined conditions. The release also includes changes related to Multi-Purpose Tokens and account permissions.
On September 14, Vet reported that 27 of 35 trusted validators were signaling support for BatchV1_1, putting it closest among the proposed amendments to the required validator-support threshold. The reported transaction record and the amendment voting process remain separate developments: the former reflects a burst of mostly simple payments, while the latter will determine whether the proposed features become active on the network.
