XRPL Batch and Permission Delegation: What Activates October 8-9

Home » XRPL Batch and Permission Delegation: What Activates October 8-9

October 1, 2026 0

Quick answer: Two XRP Ledger upgrades, BatchV1_1 and PermissionDelegationV1_1, are reportedly on track to switch on around October 8-9, 2026, if validator support stays above 80% for two straight weeks. Batch lets you bundle up to eight transactions into one package. Permission Delegation lets an account hand limited powers to another account without sharing its keys. Neither upgrade changes XRP’s supply or fee model, and the dates have already slipped once, so treat them as targets, not promises.

Editor’s review, October 1: we re-checked the dates against Cryptowisser (Sept 28), KuCoin (Sept 26), MoneyCheck (Sept 23) and Crypto Daily (Sept 25). The newer reports agree on October 8 (about 21:25 UTC) for Permission Delegation and October 9 (about 14:46 UTC) for Batch, so the older October 5 date is out of date. We still couldn’t load the live amendment tracker, so these remain secondary-source dates.

October 1 was also the day of Ripple’s monthly escrow unlock. It’s a separate story, but readers tend to bundle the two, so we cover both below.

What’s Actually Being Voted On

The XRP Ledger has no software release day in the usual sense. Changes arrive as “amendments,” and the validators the network trusts vote on each one. According to the XRPL.org amendment documentation, an amendment goes live after it holds more than 80% support for two weeks. If support drops below that line, it’s temporarily rejected and the two-week clock restarts.

That last detail explains most of the date confusion you’ll see in headlines. A countdown isn’t a calendar entry. It’s a timer that any group of validators can reset.

Batch: Several Transactions, One Outcome

Batch does what the name suggests. Per the XRPL.org Batch documentation, it packages multiple transactions and executes them as a single unit, with a maximum of eight inner transactions. It has four modes:

ALLORNOTHING: every inner transaction must succeed, or none take effect.
ONLYONE: the first one that succeeds is the only one that applies.
UNTILFAILURE: transactions apply in order until the first failure; the rest are skipped.
INDEPENDENT: everything is attempted, and failures don’t block the others.

Picture a simple case. You want to set up a trustline and receive a token in one step, and you’d rather not end up with half of it done. ALLORNOTHING is built for that. Anyone who has watched a multi-step transfer fail in the middle will see why developers wanted this.

The version going to a vote is BatchV1_1, not the original. The documentation says a signature-validation vulnerability found in February 2026 was addressed in this version, and that Halborn re-audited it in March and April 2026. The known amendments page adds that the original Batch was disabled in v3.1.1 because of a bug.

Permission Delegation: Limited Access Without Handing Over Keys

Permission Delegation lets an account authorize another account to send certain transactions on its behalf. The XRPL.org documentation frames it as role-based access: keep the master keys offline while delegates handle routine tasks with restricted powers. Each delegate can hold up to 10 permissions.

Some things can’t be delegated. Changing cryptographic keys, granting further permissions, and transactions for pseudo-accounts such as AMMs are off the table.

Why would anyone care? Think of a token issuer. One team handles compliance, another handles treasury, and the issuer wants neither to hold the keys that control everything. Hokanews, summarizing the same feature, describes that institutional split and also a use for preparing accounts before blackholing them. That’s their framing, not a protocol claim, but the use case is plausible.

The live version is PermissionDelegationV1_1, which Hokanews reports follows the XLS-75 specification and ships in xrpld 3.3.0, replacing an earlier iteration after developers found a serious implementation flaw. The XRPL.org docs add a caution: until a further amendment (fixCleanup3_4_0) takes effect, they recommend not delegating the PaymentBurn permission, because of potential unintended minting. That’s worth reading twice if you ever build on this.

The Dates, and Where Sources Disagree

Here’s what we found, and it doesn’t line up perfectly.

Permission Delegation: Reports from September 22 (Crypto Economy, Hokanews) said the two-week window had begun with 29 trusted validators approving, and pointed to October 5 at about 11:18 UTC. Later reports from September 26 to 28 (36Crypto, MoneyCheck) say October 8. Cryptowisser (September 28) says support lapsed on September 23, returned the next day, and moved the earliest activation from October 5 to October 8 at about 21:25 UTC, while KuCoin (September 26) reports both countdowns were reset. We haven’t confirmed any of this against the live amendment tracker.
Batch: Originally projected for September 29. Support then dipped below 80%, with KuCoin and 36Crypto reporting that validators reset the vote to line Batch up with a security fix. It was back at 30 of 35 trusted validators on September 25. The earliest activation is now October 9 at roughly 14:46 UTC, according to Cryptowisser, MoneyCheck and CoinCentral. A Coinpaper roundup published October 2 repeats the same timings (Permission Delegation about 21:25 UTC on October 8, Batch about 14:46 UTC on October 9) and adds fixBatchV1_2 at about 14:12 UTC on October 9, all still conditional on support holding above the threshold.
Live tracker: We couldn’t load the XRPL amendment tracker (its robots.txt blocks automated fetching), so check livenet.xrpl.org/amendments yourself for current vote counts.

Oddly, the XRPL.org Permission Delegation page we fetched calls the amendment “currently active.” That conflicts with the news coverage and may simply be documentation written ahead of activation. We’re flagging it rather than guessing.

Why the Batch Vote Was Reset

This is the part that’s easy to misread. Per 36Crypto and Hokanews, validators temporarily switched enough Batch votes from yes to no to drop under the 80% threshold. The aim was to sync Batch with fixBatchV1_2, an amendment that stops Batch inner transactions from using the wrong wrapper. It ships in xrpld 3.4.1, which has a default vote of yes and was described as an emergency release for security-sensitive protocol issues.

The details haven’t been published. MoneyCheck says there’s no evidence of XRP theft or mainnet exploitation and calls it a proactive measure. Take that as reporting, not a guarantee. Until the technical write-up appears, nobody outside the developers can say how serious the issue was.

Support was reported at 30 of 35 trusted validators for BatchV1_1, with 29 needed. That’s thin. Two validators changing their minds would reset it again.

Risks Worth Knowing

Another delay. One reset already happened. Another is possible, especially with a security fix in the mix.
Amendment-blocked servers. Per XRPL.org, servers running software without the new amendment’s code can’t validate ledgers, process transactions, or take part in consensus. The fix is upgrading xrpld. Operators who wait past activation risk exactly this, which is why the coverage stresses installing 3.4.1 early.
New-feature bugs. Both amendments have already had earlier versions pulled. Early-stage features on any chain deserve caution.
Misreading it as a price catalyst. Neither amendment is a demand driver on its own. They’re tooling.

If you only hold XRP in an exchange or wallet app, you don’t need to do anything. This is infrastructure, aimed at developers, issuers, and node operators.

The October 1 Escrow Unlock, Briefly

Since the date overlaps, a quick refresher. Ripple placed 55 billion XRP into escrow in 2017, with monthly releases capped at 1 billion XRP, per Yahoo Finance’s September 1 coverage. October 1 is the tenth scheduled release of 2026, according to KuCoin News.

The headline number overstates what hits the market. Both sources say Ripple has historically sent most of each release back into new escrow contracts. Our September escrow explainer put the typical re-lock at roughly 600 to 800 million XRP, and the September release was split into three transactions of 500 million, 400 million, and 100 million. Remaining escrow figures vary by source: about 31.14 billion, 31.28 billion, and “around 32 billion” depending on date and method. Whatever Ripple does with this month’s tranche, we won’t know until it moves on-chain.

What to Watch Next

Vote counts on the live amendment tracker for BatchV1_1, fixBatchV1_2, and PermissionDelegationV1_1.
Whether the xrpld 3.4.1 technical report gets published.
Whether activation actually happens on October 8-9 or the timer resets again.

For the usage side of the XRPL story, see our look at XRPL stablecoins versus chain fees.

Frequently Asked Questions

When will the XRPL Batch amendment activate?

Reports point to around October 9, 2026, down from an earlier September 29 projection, assuming support stays above 80% for two weeks. It could slip again.

When will Permission Delegation activate?

Sources say October 8, though earlier reports said October 5. Check the live amendment tracker.

What happens if validator support drops below 80%?

The amendment is temporarily rejected and the two-week period restarts, per XRPL.org.

Do I need to do anything as an XRP holder?

No. Node operators need to upgrade xrpld to avoid becoming amendment-blocked. Holders don’t.

Does the escrow unlock mean 1 billion XRP hits the market?

Not usually. Ripple has historically re-escrowed most of each release.

Key Takeaways

BatchV1_1 bundles up to eight transactions with four success modes. PermissionDelegationV1_1 gives limited, revocable powers to another account.
Targets are around October 9 for Batch and October 8 for Permission Delegation, but sources disagree and one reset already happened.
The Batch reset was deliberate, to align with fixBatchV1_2 in xrpld 3.4.1. Security details are still unpublished.
Node operators should upgrade. Holders don’t need to act.
The October 1 escrow release is up to 1 billion XRP, but most has historically gone back into escrow.

Sources & Further Reading

Want more data-first XRP coverage? Browse our escrow explainer and subscribe for the next one.

Disclaimer: This article is for information and education only and is not financial advice. Crypto assets are volatile and you can lose money. Do your own research (DYOR) before making any decision.

Batch transactions, Permission Delegation, Ripple, XRP escrow, XRP Ledger, XRPL amendments

Blockchain News

Sidechains vs. Layer-2s: What’s Actually the Difference?

October 26, 2026