xrpl.js backports its wallet entropy fix to the 4.x line most users still run
Serguey Asael Shinder2 min readThe maintainers of xrpl.js, the main JavaScript library for the XRP Ledger, have backported a fix for wallet generation from entropy to the older 4.x line of the xrpl package and to ripple-keypairs 2.x. The backports were merged on 28 September, and a release pull request for ripple-keypairs 2.1.0 was merged on 1 October. As of 2 October the npm registry did not yet list that version.
The bug, as the pull request describes it, had two halves. Wallet.fromEntropy passed its input through Uint8Array.from(), which accepts any iterable and coerces strings through Number(), so letters became NaN and were stored as zero. Calling Wallet.fromEntropy('abcdefghijklmnop') therefore returned a real, spendable wallet derived from 16 zero bytes, with no error. Separately, generateSeed in ripple-keypairs accepted any entropy of 16 bytes or more and kept only the first 16, so inputs sharing a prefix produced the same wallet.
The fix, first released in xrpl 5.2.0 and ripple-keypairs 3.1.0, makes fromEntropy validate its input and generateSeed require exactly 16 bytes. The reason for the backport is in the numbers the maintainers give: the 4.x line is 59% of weekly xrpl downloads, about 195,000, and ripple-keypairs 2.x is 60% of its weekly downloads, while the fixed 5.x and 3.x lines account for only 2.8% and 3.2%. Both halves are needed, the pull request notes, because a fixed generateSeed alone still accepts the all-zero array a string produces.
A second fix merged on 1 October makes signMultiBatch treat the sponsor of a sponsored inner transaction as a required Batch signer, matching the server-side check; previously the library threw and the required signature could not be produced at all.
Why it matters
A wallet derived from zero bytes is a wallet anyone can derive. The fix only helps code that upgrades, and most of the ecosystem is on the line that has not had a release yet.