The XRPL mainnet just made something happen: PermissionDelegationV1_1 (XLS-75) is now active.

The timestamp is set in stone: 2026-10-08 21:29:50 UTC, ledger 107524865. XRPSCAN marks it as enabled, and the transaction hashes are all verifiable. This isn’t “expected next week”—it’s already live.

What’s it for? An account can delegate up to 10 specific permissions to another account to sign transactions, without handing over its master key. DelegateSet establishes the relationship; the permissions list replaces the entire list rather than accumulating permissions. Clear the list and delegation is revoked immediately. The delegate pays the transaction fees, while the primary account’s sequence number continues as usual.

Three reality checks:

1️⃣ Activation ≠ $XRP a price catalyst. This is a protocol-level ops building block, not a moonshot story.

2️⃣ For PaymentBurn, the official team still advises against delegating it for now—until fixCleanup3_4_0 goes live, the item could, in certain circumstances, shift from “burn” to “still mintable.” The patch proposal is still up for a vote; it won’t happen tonight.

3️⃣ Changing keys, changing multisig settings, reauthorizing, deleting an account—these admin-level actions still can’t be delegated. You can hand off the tasks, but not the keys to the kingdom.

This is also different from September’s countdown: back then it was “if above 80% for 14 days, then as early as [a certain date]”; this time, it’s already enabled on mainnet. BatchV1_1 hasn’t been greenlit yet, so don’t lump the two together.

The only things to screen for: the mainnet switch has been flipped; whether it’s used day to day and who dares delegate PaymentBurn are up to each issuer’s own risk controls.

This is not investment advice.