XRPL Upgrade Watch is only accessible on laptop and desktop screens.
Please open this site on a device with a screen wider than 1024px.
The Batch (XLS-56) and fixBatchV1_2 amendments are expected to activate around October 9, 2026. This matters primarily to validators, node operators, and infrastructure providers — and it affects all users holding XRP — whether on a Ledger hardware wallet or any software wallet — so everyone should go through the amendment and upgrade before October 9.
Validators, operators, institutions, and wallet teams coordinate ahead of activation day.
Two amendments go live together — by design.
Lets multiple transactions from multiple accounts execute atomically in a single ledger close — all succeed or all fail. Enables complex multi-party settlement without escrow workarounds.
Fixes a minor issue where Batch inner transactions could carry the wrong wrapper. Shipped in the urgent xrpld 3.4.1 release (Sept 25, 2026). No mainnet impact, no loss of funds.
The original Sept 29 target slipped when validator support dipped below 80%. Ripple and validator Hussein "Vet" Zangana deliberately flipped votes to Yes→Nay to reset the two-week clock so Batch and its fix activate together.
Everywhere the XRPL community gathers — hover to pause the roll.
Ripple, Ledger, wallets, and exchanges building on the XRP Ledger.
It's quieter than you think — and that's the danger.
A blocked node can no longer validate ledgers, process or submit transactions, or vote on future amendments. Your vote beforehand is irrelevant — the network follows activated amendments.
A blocked node keeps responding to requests — it just serves stale data. Uptime monitoring won't catch it. You need ledger-gap monitoring.
Yes — everyone holding XRP is affected, whether your XRP sits on a Ledger hardware wallet or a software wallet. Your funds are never at risk on your device, but the services behind your wallet run nodes: if they haven't upgraded to xrpld 3.4.1, you may see delayed transactions or temporary outages around October 9. Update Ledger Live / your wallet app and confirm your exchange is ready.
Do this before October 9 — and re-verify on the day itself.
Quick answers for the questions everyone asks.
Yes — all users should go through the amendment. Your XRP itself is never at risk — amendment-blocking only affects node liveness, never balances, and your keys stay safe on your Ledger device. But the wallet apps, exchanges, and backend nodes you interact with run on node infrastructure: if they haven't upgraded to xrpld 3.4.1 before October 9, you could experience delayed transactions or temporary service interruptions. Update Ledger Live / your wallet app and confirm your exchange has upgraded.
It stops moving with the network: no validation, no transaction processing, no consensus votes. It still responds to API calls with old ledgers, which is why silent-failure monitoring is the classic trap.
Validator support fell below the 80% threshold, which restarts the mandatory two-week activation window. Validators then deliberately held the reset so the fix and Batch would activate as one — avoiding a window where Batch was live but its fix wasn't.
It's the earliest activation date. The actual moment is only knowable on the day itself, at a flag ledger where support stays above 80%. Build your upgrade plan around "before Oct 9," with a re-check on Oct 8.
Last updated: September 29, 2026 · Governs use of this site
This site is an independent educational summary of publicly available XRPL network information. Nothing here constitutes financial, investment, legal, or technical operation advice. Always verify against official XRPL documentation before upgrading production nodes.
Nothing. This site runs entirely in your browser: no analytics, no cookies for tracking, no data leaves your device. Your consent choice below is stored only in your own browser's local storage.
Amendment activation dates are estimates and can shift at any flag ledger. Node operators act at their own risk. The authors accept no liability for downtime, amendment-blocking, or losses arising from use of this information.