Justin Bons Slams XRP Ledger Over Closed-Source Emergency Code and Validator Control
Cyber Capital founder Justin Bons has renewed his criticism of the XRP Ledger, arguing that the network’s emergency software process exposes what he sees as a deeper centralization problem
His strongest claim is that marketing XRP as decentralized while validators depend on a permissioned list amounts to misleading retail investors
Bons’ criticism centers on xrpld 3.4.1, the emergency release issued on Sept. 25 to address security-sensitive problems in the XRP Ledger software
According to the material he published, the release was distributed as binaries while the corresponding source code was withheld
XRPL’s own release notice said the code would be published later together with a retrospective because revealing the fix immediately could expose the vulnerability before validators upgraded
Bons does not dispute that security was the reason given. His objection is that the network spent days running software that outsiders could not independently inspect
The first part of his argument focuses on transparency
Bons’ research shows xrpld 3.4.0 as the last publicly available tagged release in the GitHub repository at the time of his Oct. 8 review. Meanwhile, the validators he checked were already running 3.4.1
His infographic says all 35 validators on the published default list had moved to version 3.4.1, while the source for that build was still unavailable publicly
Bons argues that this creates a trust problem: node operators were effectively asked to run binaries they could not audit against public source code
He contrasted that with what he described as better emergency practice on other networks, where developers can direct operators to a patched binary and matching open-source code without necessarily disclosing the exact vulnerability until enough of the network has upgraded
The larger issue for Bons is not only that the code was closed temporarily, but who actually determines whether a rule change takes effect
His analysis distinguishes between the roughly 204 validators tracked by XRPScan and the much smaller set appearing on the published default validator list
The infographic puts that list at 35 validators, noting that these validators’ votes are the ones that matter to servers following the default list
Bons says the list published through unl.xrplf.org and vl.ripple.com was identical in his review. From that, he argues that XRPL operates much closer to a permissioned authority model than to a fully open consensus system
He describes Ripple and the XRP Ledger Foundation as “kingmakers” because, in his view, control over the default trusted list gives those publishers outsized influence over which validator votes matter
That is his interpretation of the governance model, not a neutral description of XRPL consensus
Bons also points to the rollout of fixBatchV1_2, which was carried by the 3.4.1 software
His timeline says the amendment passed the 80% threshold on the published validator list at 14:12:51 UTC on Sept. 25, while the public announcement of 3.4.1 followed about 35 minutes later at 14:47:54 UTC
He uses that sequence to argue that the default validator set was already running and voting with the new software before the broader public had been told about it
By Oct. 8, his data showed 35 of 35 validators on the published list carrying the fixBatchV1_2 amendment, with none voting against it
The fourth part of Bons’ argument focuses on amendment blocking
XRPL’s amendment process requires more than 80% support from trusted validators for two weeks before a change is enabled. If enough support remains in place, the amendment becomes part of the network rules
Servers that do not understand the newly enabled amendment can become amendment-blocked
Bons emphasizes that such a server can no longer properly follow the ledger until it upgrades. His material lists several consequences: it cannot determine ledger validity, process transactions, participate in consensus, or vote on future amendments
For Bons, that strengthens his centralization argument because rejecting the software does not preserve an alternative position inside the same network
A node that remains on incompatible rules effectively separates itself from the chain followed by the trusted validator set
Bons’ language goes much further than a technical critique
He argues that selling XRP to the public while describing the network as decentralized is “straight-up fraud.” He also repeats his longstanding criticism of XRP’s original supply distribution and Ripple’s historical sales
Those are allegations and opinions from Bons, not established legal findings
His broader case is that XRPL combines a published trusted validator list, mandatory software compatibility and, in this instance, temporarily unpublished source code in a way that he believes gives too much power to a small group
The material itself also acknowledges the opposing argument: any XRPL operator can configure a different validator list, and withholding the security diff until the fix is enforced can reduce the risk of attackers exploiting unpatched servers
Bons’ response is that those safeguards do not change the practical importance of the default list
In his view, the real question is not whether an operator can choose different validators, but whether a server that disagrees with the dominant rules can continue participating in the same network
That is the core of his latest attack on XRP Ledger governance
