About three weeks ago I posted an amendment that would resolve a...
Wietse Wind - 🪝☝️🛠 Xaman® + XRPL + Xahau@WietseWind
20 views
Nov 06, 2026
~1 min read
Advertisement
1
About three weeks ago I posted an amendment that would resolve a locked-out multi sign setup, causing one of our community members to be locked out of 50k XRP.
If we allow tech to bail on users this way, we're failing the ecosystem (in my opinion). Three weeks later not much has happened. There's a proposal for a different approach, that (imo) doesn't cut it. Why?
There are a few approaches to fixing XRPL accounts that get stuck because their signers independently changed their own key setup:
- Ban invalid signer configs at transaction time. Doesn't work. The lockout happens across multiple accounts over time, each transaction was valid when submitted. You can't prevent it without restricting what people do with their own keys.
- (Counterproposal by Ripple staff) Let a disabled master key still work as a signer on someone else's account. Gets the job done for already-stuck accounts but breaks a core assumption: disabled means disabled. If you turned off your master key because it leaked, you don't want it suddenly usable again in some other context.
- (Our approach) Nested multi-sign. Walk the signer-of-signer chain recursively, detect cycles, relax quorum where needed. Recovers stuck accounts without changing what "disabled" means. DoS concerns are real but solvable with a global signature verification cap per transaction (Batch already allows 288 sig verifications today, nested multi-sign caps at 64).
I strongly believe option 3 is the right path. It's the only one that actually fixes things without weakening security guarantees.
PR: github.com/XRPLF/rippled/…
XLS: github.com/XRPLF/XRPL-Sta…
⏳
If we allow tech to bail on users this way, we're failing the ecosystem (in my opinion). Three weeks later not much has happened. There's a proposal for a different approach, that (imo) doesn't cut it. Why?
There are a few approaches to fixing XRPL accounts that get stuck because their signers independently changed their own key setup:
- Ban invalid signer configs at transaction time. Doesn't work. The lockout happens across multiple accounts over time, each transaction was valid when submitted. You can't prevent it without restricting what people do with their own keys.
- (Counterproposal by Ripple staff) Let a disabled master key still work as a signer on someone else's account. Gets the job done for already-stuck accounts but breaks a core assumption: disabled means disabled. If you turned off your master key because it leaked, you don't want it suddenly usable again in some other context.
- (Our approach) Nested multi-sign. Walk the signer-of-signer chain recursively, detect cycles, relax quorum where needed. Recovers stuck accounts without changing what "disabled" means. DoS concerns are real but solvable with a global signature verification cap per transaction (Batch already allows 288 sig verifications today, nested multi-sign caps at 64).
I strongly believe option 3 is the right path. It's the only one that actually fixes things without weakening security guarantees.
PR: github.com/XRPLF/rippled/…
XLS: github.com/XRPLF/XRPL-Sta…
⏳
Wietse Wind - 🪝☝️🛠 Xaman® + XRPL + Xahau@WietseWind
It is Aug 16, 2025. In my Twitter DM's, a worried community member asks for help/advice.
He has $200k in XRP in an XRPL account, and he set up Multi Sign. Then he set up multi sign for the accounts he used for the initial Multi Sign. Unknowingly, he created a "nested Multi Sign" setup.
While the XRPL allows one to configure this, it creates a condition that can never be resolved: even with access to the secrets belonging to the nested Multi Sign accounts, the XRPL will never accept the signatures because of the nested condition.
At @XRPLLabs we can't just fix this, because code is law and the XRPL code happens to allow setting up a condition where one is locked out of their wallet 🥹
The only way to resolve this, is an amendment. An amendment that allows for nested signatures. I don't know many people who can actually code this, but I happen to have the privilege of working alongside of one of the few: @RichardXRPL. And @sereneblade is a loing long time contributor to the XRPL and good friend of @XRPLLabs.
So what did we do? We discussed, and started coding. Resulting in an amendment we submitted today to the rippled/XRPL code base. With this code change, merged into a future release by @RippleXDev and voted in by validators, our community member reaching out to me on August 16th last year will get access to his funds again.
Here's the (hopefully to be merged and voted in) amendment: github.com/XRPLF/rippled/…
There are some take-aways here 😉
Yours,
Your friends at @XRPLLabs 🙏
He has $200k in XRP in an XRPL account, and he set up Multi Sign. Then he set up multi sign for the accounts he used for the initial Multi Sign. Unknowingly, he created a "nested Multi Sign" setup.
While the XRPL allows one to configure this, it creates a condition that can never be resolved: even with access to the secrets belonging to the nested Multi Sign accounts, the XRPL will never accept the signatures because of the nested condition.
At @XRPLLabs we can't just fix this, because code is law and the XRPL code happens to allow setting up a condition where one is locked out of their wallet 🥹
The only way to resolve this, is an amendment. An amendment that allows for nested signatures. I don't know many people who can actually code this, but I happen to have the privilege of working alongside of one of the few: @RichardXRPL. And @sereneblade is a loing long time contributor to the XRPL and good friend of @XRPLLabs.
So what did we do? We discussed, and started coding. Resulting in an amendment we submitted today to the rippled/XRPL code base. With this code change, merged into a future release by @RippleXDev and voted in by validators, our community member reaching out to me on August 16th last year will get access to his funds again.
Here's the (hopefully to be merged and voted in) amendment: github.com/XRPLF/rippled/…
There are some take-aways here 😉
Yours,
Your friends at @XRPLLabs 🙏
