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.
Bons Says Validators Ran 3.4.1 Before the Public Had the Code
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.
35 Validators Sit at the Center of His Criticism
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.
All 35 Supported fixBatchV1_2
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.
What Happens to Nodes That Do Not Upgrade
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 Calls XRP’s Decentralization Claims “Fraud”
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.
Be the first to comment