Don't Share Your XRP Seed. Permission Delegation Is a Limited Pass, Not Yet Live
XRPL.org lists PermissionDelegationV1_1 as expected Oct. 8, 2026. It is not enabled. A limited grant is not your secret key.
Don't Share Your XRP Seed. Permission Delegation Is a Limited Pass, Not Yet Live
Someone offers to send an XRP payment for you and asks for your secret key or recovery phrase. Do not send it. Those words restore the wallet. Anyone who has them can spend the XRP.
The XRP Ledger's official documentation describes a different design. You would grant another funded account a limited, revocable set of permissions. That helper would not receive your secret. The amendment that would turn this on, PermissionDelegationV1_1, is listed as expected on October 8, 2026. It is not enabled on Mainnet.
What permission delegation would do
On the Permission Delegation concept page, the account that owns the funds is the delegator. The helper is the delegate. The delegator first sends a DelegateSet transaction that names the helper and the permissions. A later DelegateSet can change that list. An empty list revokes the grant and deletes the Delegate object.
If the helper then sends an allowed transaction, the funds still come from the delegator's account. The helper signs. The helper pays the network fee. The XLS-75 specification, marked Final, states that fee rule so a helper cannot drain the owner's XRP by setting a high fee.
Each grant is stored as one Delegate ledger object. That object counts toward the delegator's owner reserve. XRPL's reserves page lists the current Mainnet figures as 1 XRP base reserve and 0.2 XRP per owned object. A helper can hold up to 10 permissions. The helper must already have a funded XRPL account. You cannot grant this to a pseudo-account such as an AMM.
A delegated transaction that cannot apply to the open ledger fails immediately. Official docs say it is not held in the transaction queue.
The October 8 date is expected, not guaranteed
The Known Amendments page, checked on September 26, 2026, lists PermissionDelegationV1_1 as expected on October 8, 2026. The concept page shows the same expected badge. Neither page shows the amendment as enabled.
XRPL's amendments documentation explains the voting rule. A change needs a supermajority of trusted validators for two weeks. If support falls below that threshold, the timer starts over. An expected date can move. Check the live Known Amendments page for the current status.
What a helper still cannot do
The permission values reference lists transaction types that cannot be delegated. The reader-relevant ones are AccountSet, SetRegularKey, SignerListSet, DelegateSet, and AccountDelete. Those actions can change keys, rewrite signers, grant more permissions, or delete the account. The protocol is designed so a limited helper cannot take those steps.
Payment permission is still a high-trust grant. If you allow Payment, the helper can send the delegator's XRP. Official docs also warn that you cannot customize a grant down to one currency. The granular list is fixed. Revoking the grant later does not undo a payment that already succeeded.
Multi-signing is a separate tool. Signers on a multi-sign list can send almost any transaction, and the account owner pays the fee. A delegate can send only the granted permissions, and the delegate pays the fee. One does not replace the other.
Why the 2025 version never reached Mainnet
The original Permission Delegation amendment was never enabled on Mainnet. XRPL published Vulnerability Disclosure Report: XRPL Permission Delegation on September 29, 2025. The report date is September 15, 2025. It covered rippled 2.5.0 through 2.6.0 if that amendment had been turned on.
The flaw involved the order of checks. Permission was checked before the signature. A missing permission returned tecNO_DELEGATE_PERMISSION. tec results charge a fee. The report says a transaction with a high fee could then debit another account before the signature was verified. Validators were advised to vote no. The replacement on the current Known Amendments list is PermissionDelegationV1_1.
That 2025 bug is historical context for why the first version did not go live. It is not evidence of a current Mainnet exploit.
What remains unknown
CryptoWorkPro has not submitted a Mainnet DelegateSet. Wallet and exchange apps may not show this control even after the amendment enables, if it enables. The October 8 date can change if validator support changes.
XRPL.org and the XLS-75 spec are protocol records. Ripple company pages are separate. This article uses the ledger documents, not a Ripple product announcement.
Until PermissionDelegationV1_1 is enabled, and until your own wallet documents the grant, treat a request for your secret or recovery phrase as a request for full control. A limited pass is not available on Mainnet today.
Sources
- XRPL Permission Delegation concept page: https://xrpl.org/docs/concepts/accounts/permission-delegation
- Known Amendments: https://xrpl.org/resources/known-amendments
- Amendments process: https://xrpl.org/docs/concepts/networks-and-servers/amendments
- DelegateSet transaction: https://xrpl.org/docs/references/protocol/transactions/types/delegateset
- Reserves: https://xrpl.org/docs/concepts/accounts/reserves
- Permission values: https://xrpl.org/docs/references/protocol/data-types/permission-values
- Multi-signing: https://xrpl.org/docs/concepts/accounts/multi-signing
- XLS-75 Permission Delegation: https://xls.xrpl.org/xls/XLS-0075-permission-delegation.html
- Vulnerability Disclosure Report, September 29, 2025: https://xrpl.org/blog/2025/vulnerabilitydisclosurereport-bug-sep2025
Disclosure: This article summarizes XRPL.org documentation and the Sept. 29, 2025 permission-delegation disclosure as they stood on Sept. 26, 2026. Amendment expected dates can change if validator support changes. The featured image is a generated illustration, not a photograph of a real wallet handover. This article is not financial, legal, or investment advice. AI-assisted research and writing. Cited sources, not AI alone, support the claims.