XRPL Batch V1.1 Reaches Majority: What Wallets Must Verify

What changed for XRP Ledger Batch V1.1

XRP Ledger’s Batch V1.1 amendment has reached a recorded validator majority, but remains unactivated in the September 15 ledger snapshot. Following RippleX’s security review, the practical question for wallets is whether they verify the complete authorization, selected execution mode and individual transaction results before reporting a settlement as complete.

The newest primary evidence is ledger state. At 21:14 UTC on September 15, AllAboutXRP queried the validated Amendments object through Ripple’s public server. Ledger 107010252 contained a BatchV1_1 majority timestamp of 14:06:41 UTC that day, while its enabled-amendment list did not contain BatchV1_1. The separately fetched XRPSCAN record reported 29 supporting validations out of 35, against a threshold of 28, and enabled: false.

That updates the timing context of CoinDesk’s earlier September 15 report, which described 27 supporting validators. Those are differently timed observations, not evidence that either snapshot describes the entire day. RippleX’s September 14 review supplies the development context: the replacement is included in xrpld 3.3.0, and the team describes additional review and authorization hardening.

Verification method: the public-server request used ledger_entry with ledger_index set to validated and the singleton Amendments object. The relevant amendment identifier is 9F287AED3CDB50A7BD1ACEC24296A30C9B5230CCD136219317AC790E3B884377. The majority timestamp comes from that object, while the vote count comes from XRPSCAN. Keeping those sources distinct avoids presenting an explorer’s current count as a permanent ledger fact.

Section sources[1][2][4][3][10][12]

A BatchV1_1 majority starts a conditional governance window

Confirmed: a majority entry and an enabled amendment are different ledger states. XRPL’s amendment process requires the necessary validator support to persist for at least two weeks. A vote count above the threshold does not let an application submit new mainnet transaction types immediately. Support can change, and a lost majority interrupts the path toward activation.

Conditional timing: adding two weeks to the recorded September 15 timestamp gives September 29 at 14:06:41 UTC. That is a threshold-based earliest window, not a promised launch appointment. Actual enablement must appear in the validated ledger. The calculation assumes the required majority persists; it does not predict how validators will vote or which precise ledger will carry an activation.

For operators, this makes the network state the deployment gate. A product announcement, software release and client-library update can prepare an integration without authorizing its use on mainnet. A team can test now, document a rollback plan and keep its production feature switch closed until the ledger shows the prerequisite has actually been enabled.

Section sources[1][2][9][10]

RippleX’s security review makes authorization scope the central issue

The February disclosure concerns the original Batch implementation. XRPL’s report describes a signature-checking failure found before that amendment activated. The important historical distinction is that this was a pre-activation vulnerability, not evidence of a Batch theft from live mainnet accounts. RippleX’s September review describes replacement work and a broader set of reviews after that incident.

Common Prefix’s published audit identifies a separate authorization problem: signatures could be reused across different outer batch submissions. Its reported resolution binds signing data to the outer account and sequence. In plain language, approval needs to identify the specific envelope carrying the instructions, as well as the instructions themselves. A signature on an ambiguous package creates a different risk from an invalid signature.

Analysis: the wallet’s review screen is part of this control. A signer should be able to understand the participating accounts, intended transfers and chosen mode before approving. Reusing a familiar counterparty name is insufficient if the submission details have changed. The useful acceptance test is whether a changed authorization context invalidates the old approval, with the expected behavior verified against the software being deployed.

Section sources[11][3][5][7]

Audit completion does not give every finding the same disposition

Halborn’s reassessment states an engagement period of March 27 through April 7, 2026 and identifies the reviewed commit as 36503b50178393e372d46f3be3aaeb71f30acd93. Its displayed findings summary contains three informational items: one solved and two marked risk accepted. Those labels describe different treatments. A reader should not translate an overall completion statement into a claim that every observation produced a code fix.

Common Prefix also records dispositions individually. For its redundant signature-verification finding, the report says no code change was made and describes a possible follow-up optimization if profiling establishes a latency concern. This does not by itself show an exploitable defect in the version under vote. It shows why the scope, severity and treatment of a finding matter more than an audit logo.

Unresolved: this article does not establish a complete mapping from every published audit observation to the exact binary installed by every validator. CoinDesk likewise reported asking whether the additional fixes had been independently reviewed against the version being voted on. Operators assessing readiness should retain the reviewed commit, remediation record and release identifier together, rather than treating a general security review as a perpetual guarantee.

Section sources[6][5][4][10]

XRPL Batch modes define what a successful workflow means

XRPL’s transaction reference supports batches containing between two and eight inner transactions and requires one execution mode. All or Nothing makes the group conditional on every inner transaction succeeding. Only One permits the first successful inner transaction. Until Failure keeps processing until the first failure and skips later entries. Independent processes the entries without making one failure cancel the other attempts.

Consider a hypothetical marketplace instruction containing a customer payment and a platform fee. If the business promise requires both actions to succeed together, All or Nothing expresses that dependency. Until Failure can leave an earlier successful payment in place when the subsequent fee action fails. Independent can likewise produce mixed results. Merely putting the two instructions in one wrapper does not choose the business promise.

Analysis: product teams should write the intended failure outcome before selecting the mode. Does the customer expect a complete reversal, a successful first alternative, or a record of individually attempted actions? The interface should describe that outcome in ordinary language. This is especially relevant when multiple accounts participate, because each person must understand the whole operation they are authorizing.

Section sources[8][7][5]

A successful outer Batch is not a completed settlement receipt

The XRPL integration documentation separates the outer transaction from its inner results. The outer record covers its own processing, including sequence and fees; it can return tesSUCCESS even when inner processing fails. Inner transactions have their own results and metadata, with ParentBatchID linking them back to the wrapper. An application therefore needs more evidence than one green success label.

Practical inference: a payment service should match its expected transfers to the committed inner records and check the applicable results before fulfilling an order. If one expected leg is missing, the service should explain the outcome using the selected mode. It should not manufacture a successful receipt simply because it located the outer transaction, or retry the entire business operation without first reconciling what was committed.

A useful release rehearsal would deliberately make the second leg fail, confirm the mode-specific result, and check what the customer receipt says. It would then repeat the reconciliation after reconnecting to the service, when the application has to recover from stored ledger records. These are proposed operational tests, not claims that any particular wallet has already passed them.

For XRP holders, the immediate milestone is a conditional protocol change and an integration workload. The reviewed material does not establish production settlement volume, named customer launches or incremental XRP buying attributable to Batch. Useful follow-up evidence would connect actual enabled ledger state to a named application and demonstrable transaction outcomes. Until then, readiness claims and realized usage remain separate questions.

Section sources[7][8][4][3]