Does the closed-source xrpld 3.4.1 emergency release show the XRP Ledger is not decentralized?

The full answer

What happened with xrpld 3.4.1?

XRPL.org dated its release post for xrpld 3.4.1 September 25, 2026, and called it an emergency release to fix security-sensitive issues in the XRPL protocol [1]. The post told anyone running an XRP Ledger server to upgrade as soon as possible to ensure service continuity [1]. The GitHub release notes give a slightly later date. They say the release was first published as binary-only packages on September 26, 2026 [2].

The changelog lists two fixes. One rejects Batch inner transactions with the wrong wrapper, through the fixBatchV1_2 amendment. The other is assorted integer-arithmetic hardening in the payment engine and ledger helpers [1]. XRPL.org’s October 9, 2026 disclosure report described the two bugs as a Batch inner transaction wrapper validation error and a payment engine XRP overflow error [3]. The background to the fix is covered in why the emergency update was released in September 2026.

The source code was not published right away because of the security-sensitive nature of the fix, as the xrpl.org release announcement of September 25, 2026 explained, adding that it would be published along with a retrospective on a future date.

The September 25 post gave one reason. xrpl.org stated on October 9, 2026: “Additionally, the source code for xrpld 3.4.1 has now been published .” The post did list SHA-256 hashes for the Red Hat and Ubuntu packages [1].

The promised publication came on October 9, 2026. XRPL.org’s disclosure report that day said the source code for xrpld 3.4.1 has now been published [3]. The same report said the team is adding a re-verification step to its release process, in which every security finding marked as fixed is re-tested against the release candidate [3]. GitHub shows the tagged 3.4.1 release posted on October 10 [2].

Did the 3.4.1 fix skip the amendment vote?

No. The Batch fix went through the normal amendment process. The release set fixBatchV1_2’s default vote to “Yes” [1]. By September 25, 2026, XRPL.org said the amendment had already gained support from a supermajority of validators and was expected to become enabled on October 9 [1]. cryptonews.net reported on September 29 that the enablement depended on that supermajority support persisting [4].

It did persist. The October 9 report said fixBatchV1_2 became enabled on Mainnet that day and that older servers are now amendment blocked [3]. The GitHub notes say the same [2]. Shipping a rule in server software does not switch it on: crypto.news made that point about the 3.4.0 lending rules on September 23, 2026 [5]. How that vote works in general is set out in how XRP Ledger amendments get approved.

The overflow fix is different. The October 9 report says it applies immediately upon upgrade [3]. It had no separate vote.

What is the strongest case that this shows centralization?

The critique rests on the dates. From September 25 to October 9, 2026, operators were told to install a binary they could not inspect [1][2]. Once the amendment was enabled, servers left on older versions became amendment blocked and could not stay in sync with the network [1][3]. The decision to hold back the code was made by the release’s builders. XRPL.org credited the release to RippleX Engineering and the XRP Ledger Foundation [1].

The counter-case uses the same sources. Validators had to back fixBatchV1_2 before it took effect [1][3], and the code was public on the day of enablement [3]. Those facts show who writes the reference software in an emergency, a question taken further in who writes and pays for the XRP Ledger’s software. Whether the validators themselves are independent is a separate question, covered in the default validator list critique.

As of Sep 25, 2026, investigators still need to establish how the backend was penetrated, what privileges the attackers obtained, why existing controls did not reject the transactions, and whether additional authentication or transaction-policy safeguards could have stopped them.

As of October 12, 2026, neither XRPL.org’s posts nor the GitHub release notes name the validators that supported fixBatchV1_2 or give their number [1][2][3]. Neither reports an outside rebuild of the published source matched against the September package hashes [1][2][3].