0091 XLS-91d: Beneficiary - An Inheritance Solution for XRPL #269
Replies: 6 comments 20 replies
-
|
How does it work if the account has been blackholed? If it doesn't work if the account has been blackholed, you need to define what blackholed status is. (is it only when the master key has been disabled and the regular key is a ZERO/ONE Account? etc.) |
Beta Was this translation helpful? Give feedback.
-
|
There is currently no check for blackholed accounts. If you want to have your beneficiary be a blackholed account thats up to you. |
Beta Was this translation helpful? Give feedback.
-
|
This refers to the case where Alice blackholes her own account after setting Beneficiary. This function will cancel the blackhole, right? |
Beta Was this translation helpful? Give feedback.
-
|
Given the spec currently says that any regular key would be overwritten, then yes, this would essentially un-blackhole the account, but the beneficiary clearly needs to be set first. I see no issue with this, and any sites displaying an account as being blackholed woudl need to just update their logic to check for the presence of beneficiary, before attesting to it being blackholed Interestingly though, it does open up to some interesting ideas which are occurring to me know after reading the new smart escrow proposal. If you had some issued assets on an account; then set the beneficiary with a time lock of one year, then set a beneficiary account, then blackholed it, you just achieved a form of escrow for an issued asset. Just occurred to me. Is this good or bad ? Q: Should we work work to prevent this? |
Beta Was this translation helpful? Give feedback.
-
|
nit: Transactions are usually named in the form of |
Beta Was this translation helpful? Give feedback.
-
|
noted, we can update :-) |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
Now that I think about it 2/3 transactors that all adjust the same LedgerEntry but have different names might get confusing for future updates as well. LedgerEntry is a winner here imo. Thank you for your valuable inputs! |
Beta Was this translation helpful? Give feedback.
-
YW! |
Beta Was this translation helpful? Give feedback.
-
|
Wouldn't we need also a delete beneficiary tx? In case i want to cancel between last tx and timelock period |
Beta Was this translation helpful? Give feedback.
-
|
BeneficiarySet can be used to perform disable, as well as an enabled and update. |
Beta Was this translation helpful? Give feedback.
-
Is there any particular reason the proposal doesn't require the I worry about scenarios where the original account is no longer accessible, and the beneficiary account becomes inaccessible in a surprising or unforeseen way (this might be due to errantly setting the beneficiary to a blackhole/special address, loss of private keys of the beneficiary, or otherwise). By forcing the beneficiary to prove access to the beneficiary account, we know funds can't be pulled into an inaccessible beneficiary account (because that account must sign). |
Beta Was this translation helpful? Give feedback.
-
Circular beneficiaries!!! That might actually be a valid use case for, for example, spouses. |
Beta Was this translation helpful? Give feedback.
-
The funds aren't "pulled" anywhere, the regular key is just changed. |
Beta Was this translation helpful? Give feedback.
-
Good points -- these aren't crucial to my worry though. I'm more thinking about not getting funds locked-up on accident.
Despite my initial worry, this is a really good point. I need to consider the tradeoffs here a bit more. |
Beta Was this translation helpful? Give feedback.
-
Taking @ximinezs example further. What would happen if Account A uses account B as a beneficiary and account B uses account A as a beneficiary, and both accounts meet the conditions to submit the |
Beta Was this translation helpful? Give feedback.
-
|
The same thing that would happen if you submitted 2 SetRegularKey transactions with the same details right? |
Beta Was this translation helpful? Give feedback.
-
|
Is there a potential issue here if the user was already primarily using their regular key instead of their master key (e.g. when using the XRPL Labs Vanity Address service)? The situation I'm imagining:
|
Beta Was this translation helpful? Give feedback.
-
|
This is a potential issue regardless of who can trigger the beneficiary switch - we've all read stories of e.g. kids who scheme to get their parents' money as early as possible. |
Beta Was this translation helpful? Give feedback.
-
|
I acknowledge your point, but I advocate taking the approach of making the feature as flexible as possible and empowering users to make the informed decision they choose. These discussions so far make me lean towards allowing both options and simply empower the user to take responsibility for their decision by setting a simple boolean as part of the feature OR we build smart feature functionality into this amendment from day one, leave the protocol open and allow it to be locked down with an extension. I do think we are all on the same page here, the problem is there are genuinely trade-offs to both options. Does anyone have any solid reason why we should not allow both, if so, it is just a case of determining the best way to implement it. |
Beta Was this translation helpful? Give feedback.
-
|
Actually, why does the regular key have to change at all? Why can't the beneficiary just be an additional key that can sign for the account? |
Beta Was this translation helpful? Give feedback.
-
...You could get rid of the |
Beta Was this translation helpful? Give feedback.
-
|
I think we would ultimately take advice on this, but... from my understanding, what you describe would be adding/changing a fairly significant area of code; whereas what we tried to do was keep it as simple as possible, re-using functionality that essentially already exists; yes its a new transaction but the code behind it is really really simple. I think this is just a design choice, so lets treat it as such. |
Beta Was this translation helpful? Give feedback.
-
XLS-91 Beneficiary - An Inheritance Solution for XRPL
Introduction
The need for a secure and reliable inheritance mechanism on the XRP Ledger has been a recurring topic within the community. In the event of an account holder's death, without access to the private key, the assets in the account are effectively lost forever, causing significant concern for users who want to ensure their digital assets are passed on to their beneficiaries.
Existing solutions, like sharing private keys with executors or family members, pose significant security risks and are often impractical due to trust issues or technical limitations.
This proposal aims to introduce a simple, secure, and user-friendly inheritance mechanism on the XRP Ledger by leveraging new transaction types and modifications to the
AccountRootledger entry. This mechanism allows account holders to set a beneficiary who can claim access to the account after a specified period of inactivity, ensuring assets can be passed on without compromising the account's security during the holder's lifetime.Problem Statement
When an XRP Ledger account holder dies without sharing their private key:
Users need a way to ensure their assets can be securely passed on to beneficiaries in the event of their death, without compromising their autonomy or the security of their account while they are alive.
Amendment
The proposed amendment introduces a new inheritance mechanism on the XRP Ledger by adding two new transaction types and extending the
AccountRootledger entry.New Transaction Types:
SetBeneficiaryInvokeBeneficiaryAccountRoot Ledger Entry Extensions:
New Transaction Type:
SetBeneficiaryThe
SetBeneficiarytransaction allows an account holder to designate a beneficiary account (sfBeneficiary) and specify a time lock period (sfTimeLock). Once set, these fields are added to theAccountRootledger entry of the account.Transaction Format
SetBeneficiary(ttSET_BENEFICIARY).Example
SetBeneficiaryTransaction{ "TransactionType": "SetBeneficiary", "Account": "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v", "Beneficiary": "r4G4ZUPkMpXhB6sSpCD1HN2LZUjWkAp8ie", "TimeLock": 15552000 // e.g., 180 days in seconds }AccountRoot Ledger Entry Extensions
The
AccountRootledger entry will be extended to include the following new fields:sfBeneficiary(AccountID): The account ID of the designated beneficiary.sfTimeLock(UInt32): The time lock period in seconds for inactivity.sfLastInteraction(UInt32): The timestamp of the last outgoing transaction from the account.Updated AccountRoot Ledger Entry Format
The
AccountRootledger entry will now include:Handling
SetBeneficiaryTransactionWhen a
SetBeneficiarytransaction is submitted:Validation:
Beneficiaryfield must be a validAccountID(account exists).TimeLockmust be a positive integer representing the time lock period in seconds.Update AccountRoot Ledger Entry:
sfBeneficiaryandsfTimeLockfields are added or updated in theAccountRootledger entry of theAccount.sfLastInteractionis initialized to the timestamp of the current ledger (if not already set).Transaction Result:
tesSUCCESS.Updating
sfLastInteractionsfLastInteractionfield in theAccountRootledger entry is updated to the timestamp of the current ledger whenever an outgoing transaction (a transaction where theAccountis the sender) is successfully processed.sfLastInteraction.New Transaction Type:
InvokeBeneficiaryThe
InvokeBeneficiarytransaction allows the beneficiary or any other party to initiate the claim process. The transaction will succeed only if the time elapsed since thesfLastInteractionis greater than or equal to thesfTimeLock. Upon success, thesfRegularKeyof the account is set to thesfBeneficiaryaccount ID, giving the beneficiary full access to the account.Transaction Format
InvokeBeneficiary(ttINVOKE_BENEFICIARY).Example
InvokeBeneficiaryTransaction{ "TransactionType": "InvokeBeneficiary", "Account": "rAnyAccountId", "Owner": "rAliceAccountID" }Handling
InvokeBeneficiaryTransactionWhen a
InvokeBeneficiarytransaction is submitted:Validation:
Ownerfield must be a validAccountIDof an account that hassfBeneficiaryandsfTimeLockset in itsAccountRootledger entry.Time Lock Verification:
sfLastInteraction:TimeElapsed = CurrentLedgerTime - sfLastInteractionTimeElapsed >= sfTimeLock.Update AccountRoot Ledger Entry:
sfRegularKeyof theOwneraccount to thesfBeneficiaryaccount ID.sfBeneficiaryandsfTimeLockfields from theAccountRoot.tecNO_PERMISSION).Transaction Result:
tesSUCCESS.Access Granted to Beneficiary
By setting the
sfRegularKeyof the account to the beneficiary's account ID, the beneficiary gains full access to the account through theRegularKeymechanism of the XRP Ledger. ThesfBeneficiaryandsfTimeLockfields are removed to prevent re-triggering of the inheritance process.Security Considerations
SetBeneficiarytransaction to update or remove the beneficiary designation by settingBeneficiaryto an empty value or omitting the field.sfLastInteraction, resetting the inactivity timer.RegularKeymechanism is standard in XRPL; however, account holders should be aware that setting theRegularKeyto the beneficiary account effectively grants full control over the account to the holder of that key, once the timelock conditions are satisfied.Examples
Scenario: Setting a Beneficiary
Alice wants to set Bob as her beneficiary, with a time lock of 6 months (15,552,000 seconds). She submits a
SetBeneficiarytransaction.{ "TransactionType": "SetBeneficiary", "Account": "rAliceAccountID", "Beneficiary": "rBobAccountID", "TimeLock": 15552000 }Upon successful processing, Alice's
AccountRootledger entry is updated with thesfBeneficiary,sfTimeLock, and initializessfLastInteractionto the current ledger timestamp.Scenario: Invoking Beneficiary
After Alice passes away and no transactions are made from her account for over 6 months, Bob (or any other party) submits a
InvokeBeneficiarytransaction.{ "TransactionType": "InvokeBeneficiary", "Account": "rAnyone", "Owner": "rAliceAccountID" }If the time elapsed since
sfLastInteractionis equal to or greater thansfTimeLock, the transaction succeeds, setting thesfRegularKeyof Alice's account torBobAccountID, and removing the beneficiary fields.Bob can now use his own secret key to sign transactions on behalf of Alice's account via the
RegularKeymechanism, effectively gaining access to the assets.Edge Cases and Handling
sfTimeLockperiod elapses, thesfLastInteractionis updated, resetting the timer.InvokeBeneficiarytransaction succeeds, the beneficiary fields are removed from theAccountRoot, preventing further claims.RegularKeyset, setting the beneficiary does not interfere with that. However, when theInvokeBeneficiarytransaction is successful, thesfRegularKeyis updated to the beneficiary's account ID, overriding any existingRegularKey.Open Questions
TimeLockperiod to prevent excessively long or infinite time locks?RegularKeyto be set in this manner?Beta Was this translation helpful? Give feedback.
All reactions