Three Switches Flipped: What Batch and Permission Delegation Actually Change on the XRP Ledger

1. TL;DR

In an eighteen-hour window on October 8–9, 2026 the XRP Ledger activated three amendments — its densest protocol window of the year. PermissionDelegationV1_1 went live first, allowing an account to grant up to ten granular permissions to a separate account without sharing the master private key. Twelve hours later the emergency security fix fixBatchV1_2 activated, and thirty-four minutes after that, BatchV1_1 followed: atomic groups of up to eight transactions that either all succeed or all revert. The active amendment count moved from 94 to 97. All three landed on their projected schedules, which is worth noting because one of them had already missed a target once, when validator support dipped below the 80% threshold and the two-week counter reset.

The substance is narrower and more interesting than the headlines. Neither amendment makes XRP more valuable, and neither changes what an ordinary payment does. What both do is remove two specific objections that a compliance officer or treasury architect would raise before building on this ledger — who inside an organisation is allowed to do what, and how a multi-step settlement executes without a half-finished state. This report sets out what actually activated, what the two primitives do in plain terms, why both had to be withdrawn once and re-issued, what every node operator is now obliged to do, and the six signals that would show whether anyone uses them — because activation is a capability, not adoption, and the difference is the whole story.

2. The fact on one page

Three numbers frame the window. Eighteen hours is the total elapsed time between the first activation and the last. Three is the number of amendments that had been sitting in the waiting window with majority support as of a Monday ledger read showing 94 already active. 80% for fourteen consecutive days is the threshold each had to hold, without interruption, before activation — which is the reason this window is a dating exercise rather than an announcement, and the reason one of the three slipped from September. A caveat that travels with every scheduled date produced by this process: the ledger computes activation from live validator support, so any of the three could have shifted again if support had dipped. It did not, and all three landed.

3. Permission Delegation: who is allowed to do what

Before this amendment, the XRP Ledger's access model was essentially binary. An account's master key could do everything — sign payments, change trust lines, set regular keys, adjust account settings — and anything short of full access meant no access. That binary is adequate for an individual and untenable for an institution, because it forces every operational role onto a single credential. The concrete problem it creates is that a payments team and a compliance team cannot share an account without sharing the ability to re-key it, drain it, or alter its trust lines. Auditors treat that as a finding, not a design choice.

Permission Delegation replaces the binary with a granular list. An account owner can grant up to ten specific permissions to a separate "helper" account, which then acts within exactly that scope and no further, while the owner's master key stays offline. The practical shape for a regulated business is direct: a payment-initiation account that can send but cannot change trust lines; a compliance account that can freeze or approve but cannot move funds; an operations account that can adjust settings but cannot sign transfers. Each role gets its own on-ledger identity, each is separately auditable, and none of them holds the credential that controls the whole. This is the control pattern that banks, custodians and stablecoin issuers are required to demonstrate, and the absence of it was one of the standing objections to building on this ledger.

Two limits belong in the same breath as the capability. First, ten permissions is a bounded list, not an arbitrary policy engine — the model separates roles, it does not implement an institutional approval workflow; multi-step approvals still have to be composed from the primitives available, which is precisely where the Batch amendment becomes relevant. Second, and more important for anyone reading this as an adoption signal: an amendment activating is not an account using it. The capability became available on October 8; whether a custodian, an exchange or a stablecoin issuer has since created a delegated-permission structure is a question about public ledger data that no reporting inside the week established. This report describes what is now possible and explicitly declines to claim it is being used.

4. Batch: atomic settlement and the half-finished problem

The Batch amendment solves a different problem that looks superficially similar: what happens when a logical operation requires several ledger transactions and the process dies in the middle. Before this amendment, a multi-step flow — swap, then transfer, then settle, or four legs of a portfolio rebalance — executed as a sequence, and a failure at step three left steps one and two settled on the ledger with no counterparty obligation fulfilled. In a pure trading context that is an annoyance to be cleaned up. In a settlement context it is the difference between a system a bank can use and one it cannot, because delivery-versus-payment requires that the asset leg and the cash leg either both settle or neither does.

BatchV1_1 makes that possible by grouping up to eight transactions into a single atomic unit. The inner transactions can originate from different accounts, and every account involved must sign its own part — so a batch is not one party asserting authority over another's funds; it is a set of mutually signed legs bound together. In ALLORNOTHING mode the entire group reverts if any leg fails, and the outer batch transaction still pays its normal fee through the standard fee process, so a failed batch is not free. The ledger also supports more permissive modes where partial execution is allowed, and NFT-for-NFT trades can execute directly inside a batch without first converting through XRP or another token. The application list that has been described as already under contract or in active development includes atomic swaps, bundled DEX orders, and institutional settlement flows — capabilities that require exactly the all-or-nothing property the amendment provides.

One production caveat matters more than any of the above, because it is the first thing an operator will encounter. Servers still running a pre-xrpld 3.4.1 build enter an amendment-blocked state once fixBatchV1_2 is active: they cannot track ledger consensus until upgraded. That makes the week's validator and node upgrade rate a live reliability metric rather than housekeeping. It also explains why the three amendments arrived as a tight cluster rather than as three separate windows — the fixed Batch implementation and the security fix that guards it are a matched pair, and the community flipped votes so that the second would land with the first rather than after it.

5. The history that matters: two withdrawals, and what they say

The most informative part of this window is not that the amendments activated; it is that both had been withdrawn once, for cause, and returned as corrected re-issues. Permission Delegation's earlier iteration had a defect in which one account could charge transaction fees to any other account and drain it that way — which is to say the mechanism intended to give institutions granular control briefly gave strangers a way to spend someone else's money. Batch's original version contained a critical signature-validation flaw found in February 2026: when the function met a signer whose account did not yet exist on the ledger, it returned success immediately and skipped validation of every remaining signer, which would have let an attacker execute arbitrary transactions on behalf of victim accounts. The response in that case was to advise validators to vote no within hours, reproduce the issue with an independent unit test, and mark both Batch and its companion fix as unsupported. The amendment had never activated, so no funds were at risk. The corrected implementation shipped in xrpld 3.3.0 as BatchV1_1 after additional audits and adversarial testing, and the security fix that closes the remaining issue shipped in xrpld 3.4.1.

It is worth being precise about what this history does and does not imply. It does not imply that the ledger is unsafe — the mechanism that caught both defects is the one that is supposed to catch them, and public bug handling is the desired behaviour in protocol development rather than a scandal. It does imply two things about how to read this week. First, the correct frame is that the XRPL brought its technology up to date this week; nothing was launched, and no product went live. Two of the three activations were repairs of the project's own earlier mistakes, and the third was an explicit security fix to the batch procedure. Second, the version suffixes are meaningful: V1_1 on both amendments is not cosmetic, it denotes a corrected re-issue that passed a process the first version failed. A reader who wants to know whether a protocol is serious should look at whether its failures are published, corrected and re-attempted with new identifiers. On that test this window is evidence in favour, and the evidence cost the project two weeks and one reset.

6. Who can use it, and what changes for everyone else

The honest distribution of impact runs from narrow to negligible. The narrowest and most consequential group is regulated institutions with a separation-of-duties requirement — custodians, payment service providers, stablecoin issuers, and any entity operating accounts under dual control. For them Permission Delegation converts a design constraint into a configuration, and Batch converts a settlement risk into a transaction mode. The middle group is developers building settlement, swap and marketplace applications, for whom up to eight atomic legs, cross-account signing and NFT-for-NFT exchange inside a batch remove a well-known set of workarounds. For everyone else — every ordinary XRP holder making an ordinary payment — nothing changes at all. Payments work exactly as before, and the only indirect benefit is that the applications and services built on top may settle more reliably.

That distribution is why this report resists the temptation to score the window as a win for the token. The mechanical score is simple and it is not favourable: an amendment activating does not buy XRP, does not reduce supply, and does not change any fee. The market's own verdict was unambiguous — XRP fell 8.3% in the same week, though for reasons that had nothing to do with the ledger (a hawkish set of Fed minutes and a market-wide liquidation cascade). The correct way to hold both facts is to treat the activations as a change in the ceiling rather than in the floor: they raise what can be built here, and they say nothing about whether anyone will build it. Long-run protocol value arrives through adoption, and adoption is a different dataset with a different cadence.

7. Confirm / falsify

Six signals, each observable in public data, that will decide whether this window was infrastructure or ceremony. The framework is written so that the falsifying branch is as specific as the confirming one.

The framework's design note is that every confirming branch is a usage signal rather than a capability signal, and every falsifying branch is the absence of one. That is deliberate: the capability already exists and is now documented, so any future reading of this window should not need to re-argue whether Batch works. What remains genuinely open is whether the primitives were the missing ingredient or merely a necessary one — and that question is answered by ledger data, not by commentary, which means it will be answered slowly and unambiguously.

8. Risks to this framework

Four things could make this framework look naive in hindsight, and each deserves to be named before it happens rather than after. First, the usage case may be structurally thin. Atomic settlement on a public ledger competes with private, permissioned alternatives that banks have used for years, and a compliance officer satisfied by Permission Delegation may still prefer a consortium chain with a legal agreement attached. Removing an objection is not the same as winning a mandate. Second, the operator burden is real and it arrived as a cliff. Servers that skip xrpld 3.4.1 do not degrade gracefully; they become amendment blocked, unable to track consensus. If a meaningful cohort of lower-resourced validators is slow to upgrade, the network's effective validator diversity narrows in a way that is hard to reverse and that is uncomfortable to disclose. Third, the security history is not over. Both amendments in this window were re-issues of code that had shipped with defects, and the security fix that landed alongside BatchV1_1 was itself an emergency release addressing a protocol-level issue found days before activation. A ledger shipping fixes this urgently is behaving correctly; a ledger needing three emergency interventions in one year is also a fact about its maturity. Fourth, and most likely to be misread, is the price disconnect. If XRP rallies next month, this window will be retro-fitted as the cause, and if it falls, the window will be dismissed as irrelevant. Both readings are unfalsifiable, and both are worse than the honest one: the amendments changed what is buildable, the market in the same week was pricing a Fed minutes release, and those two statements have no causal relationship in either direction.

9. Bottom line

The XRP Ledger activated three amendments in eighteen hours on October 8–9, 2026 — PermissionDelegationV1_1, fixBatchV1_2 and BatchV1_1 — moving its active amendment count from 94 to 97 and completing the two institutional primitives it had been promising for over a year. Permission Delegation replaces an all-or-nothing access model with up to ten granular permissions per delegated account, which is the separation-of-duties structure regulated custodians, issuers and payment providers are required to demonstrate. Batch groups up to eight transactions from different accounts into one atomic unit with each party signing its own part, which is the shape delivery-versus-payment settlement requires. Both are corrected re-issues of amendments previously withdrawn for genuine defects, both shipped with published post-mortems, and both arrived on schedule after one earlier reset when validator support dipped.

What this week did not do is change anything for the token. XRP fell 8.3% over the same seven days, for macro reasons, and no amendment activates a buyer, reduces supply, or alters a fee. The correct reading is that the ledger's ceiling rose while its floor was set by something else entirely — and the test of whether that matters is not in commentary but in ledger data. Watch for batch transactions and delegated-permission accounts appearing in public data from operators with names attached. Until then this window is a well-documented capability with an unproven customer base, which is a genuinely useful thing to have shipped and a genuinely incomplete thing to celebrate.

FAQ

Related reading

• XRP & Ripple Weekly News Review — Week of October 5–11, 2026
• XRP Ledger Weekly Data Report — Week of October 5–11, 2026
• Weekly Intelligence — Week of October 5–11, 2026
• XRP Market Intelligence — Week of October 5–11, 2026