Cyber Capital founder Justin Bons has launched a pointed attack on the XRP Ledger, arguing that presenting the network as decentralized to retail buyers constitutes straight-up fraud. His comments center on an emergency software release and the structure of the network's trusted validator system.

Closed-Source Emergency Release Draws Fire

Bons focused on the xrpld 3.4.1 update issued on September 25 to address security-sensitive issues. The release was distributed as binaries while the matching source code remained unpublished. By early October, the last publicly tagged version in the repository was still 3.4.0, yet the validators Bons examined were already operating on 3.4.1.

He noted that all 35 validators on the published default list had adopted the new version. Bons contended that requiring node operators to run unaudited binaries creates a transparency problem. He contrasted the approach with practices on other networks, where developers can share patched binaries alongside open-source code without immediately revealing vulnerability details.

Network documentation stated the code would be released later with a retrospective to avoid exposing the issue before upgrades occurred. Bons accepted the security rationale but objected to the period of closed-source operation.

Validator List and Governance Concerns

Beyond the temporary code withhold, Bons argued the deeper issue lies in how rule changes take effect. He distinguished the roughly 204 validators tracked publicly from the much smaller default list of 35 whose votes carry decisive weight for servers that follow the recommended set.

According to his review, the lists published through the relevant foundation and company domains were identical. He described Ripple and the XRP Ledger Foundation as holding outsized influence through control of that default trusted list, characterizing the arrangement as closer to a permissioned authority model than an open consensus system.

The amendment known as fixBatchV1_2, included in the 3.4.1 software, reached the required support threshold on the published list shortly before the public announcement of the release. By early October, all 35 default-list validators carried the amendment with no opposing votes recorded.

Consequences for Non-Upgrading Nodes

Bons also examined the amendment process itself. Changes require sustained support above 80 percent from trusted validators for two weeks before activation. Servers that do not recognize a newly enabled amendment become blocked. Such nodes lose the ability to validate ledgers, process transactions, join consensus or vote on future amendments, effectively separating them from the chain followed by the default validator set.

In his view, this dynamic limits the practical ability of dissenting operators to remain active participants under alternative rules.

Broader Criticisms of Supply and Marketing

Bons linked the software episode to longer-standing concerns about XRP's original token distribution and Ripple's historical sales activity. He maintained that concentrated influence over both the recommended validator list and software compatibility undermines claims of decentralization marketed to the public.

He acknowledged that operators can configure alternative validator lists and that delaying public disclosure of a security fix can limit exploitation risk. His central contention remains that the practical importance of the default list and the mandatory nature of compatible software still concentrate meaningful control.

The remarks form part of an ongoing debate over the degree of centralization in the XRP Ledger and the accuracy of descriptions presented to retail participants.