Error Merging two addresses with "oops error There are account objects that prevent you from deleting this account"

[AussieWayne]

Guys I am trying to merge delete one address into another but I keep getting this message

oops error There are account objects that prevent you from deleting this account

There are no visible Trustlines set as viewed within Xumm BUT on investigation in XRPScan there is a leftover "fragment" of a long deleted Trustline for

XmemePropertyPool A scam token I believe.

{ I think Tyler is another one that is lingering in the background on another wallet but haven't tried to merge that one but now expect that same problem in prospect?}

This is preventing me in completing the merge due to some unresolved registration on the Ledger by this token?

Does anyone have any idea how to get around this roadblock please?

I note that there are over 700 of these Trustlines set so theoretically 700 wallet addresses that will not be able to claim their  XRP back at anytime?

[at3n]

It's hard to know without looking at your account, but I dug into this concept a while ago (although it was asked from the opposite viewpoint - deleting the issuer account):

https://www.xrpchat.com/topic/39648-what-happens-to-the-assigned-trustlines-if-the-coin-issuers-accounts-delete-their-account/?do=findComment&comment=981828

My conclusion was that if a malicious actor (as you suggest this one is) was to set a trustline to your account, even if you did not issue any tokens to them, you would be unable to delete your own account. Normally if you set a trustline to a genuine issuer, they wouldn't set a trustline in the reverse direction; so when you delete your "side" of the trustline, the "ripplestate" object is fully deleted. However, if the issuer did set a trustline to you as well, then the ripplestate object will only be deleted if both of you delete your halves of the trustline. If the ripplestate object still exists, neither account can be deleted.

If you can dig through all the info I pulled together, then maybe you can relate this to your situation? Also the code may have changed since I posted this, so it may be inaccurate.

[AussieWayne]

Thank you very much for your explanation and I will have a look through this material.

I attach a copy of the XRPScan (address removed) Hopefully that might mean something to someone??

 

[at3n]

Right, I looked into the issuing account for the XMEME token (rwrARYbfw3XBQfM19qyJBWupMGvxFyfKpE), and I think I understand what's going on.

I can't comment on your account in particular because I don't know which it is, but if you look generally at one of the ~700 trustlines still open to rwrARYbfw3XBQfM19qyJBWupMGvxFyfKpE, in xrpscan you will see that "Rippling" is set to YES (looking from the point of view of the issuing account). This is normal for an issuing account to do. However, usually an issuing account would use the "Default Ripple" setting on their account to globally enable Rippling on all of their trustlines by default.

rwrARYbfw3XBQfM19qyJBWupMGvxFyfKpE does not have Default Ripple enabled, and instead has enabled it manually on each trustline that has been created to it. This manual change to each trustline has caused the issuer's side of each trustline to be in a non-default state, which means that it still exists even after your side of the trustline is deleted. Therefore the ripplestate object linking you to the issuer cannot be deleted, which therefore means neither account can be deleted.

It's a nonsensical way to do things, as it means that the issuing account has a very high reserve. In fact its reserve is far higher than the amount of XRP that it holds, so that account is unable to do anything now until it's funded by over 1000 XRP.

So, I don't think there's anything you can do about this, unfortunately.

If anyone would like to confirm or deny my theory, I'd welcome it!

Edited April 18 by at3n
Clarifications

[AussieWayne]

Well first of all thank you very much for taking the time and making the effort to respond to my question. Especially so when the information you have provided is so clear and concise that even I can fully understand it.

I guess this is a problem that SHOULD be rectified for the future security and functionality of the ledger, somehow. Are you aware of where I might turn to from here with this information in the hope of informing the relevant party and maybe having the problem fixed, if at all possible?

I wonder if the Tyler token is the same story as I see that token seems to persist in my other wallet (in the DEX app) despite the trustline having been deleted some time back. And of course there may be many more as yet unidentified so this problem(s) could be far wider than we can see at the moment.

[at3n]

I agree that it's undesirable behaviour and hopefully it can be removed in the future. The ability to delete accounts is still relatively new, so I guess it needs time before issues are fully ironed out.

At the same time, the concepts behind accounts owning objects and the way trustlines work are fairly fundamental to the operation of the ledger, so it's possible that it's a difficult problem to fix. It's probably a small subset of users who are affected in practice, and it only impacts your last 10 XRP which up until recently would have been locked forever anyway. So I could see it being tolerated as a "necessary evil" for some time.

I'm not sure what's the best way to raise it, you can open an issue on the Github repo https://github.com/XRPLF/rippled, but we haven't tested this yet, so I would try to recreate it using test accounts to make sure that my theory is correct, before opening an issue. I did a quick search and there's bit of discussion about other account delete issues here: https://github.com/XRPLF/rippled/issues/4365 but I couldn't find this specific issue.

@mDuo13, if you still come around here, do you know if this issue has been raised before? Seems that account A can arbitrarily make account B undeletable by creating a trustline to it, even if the trustline from B to A is in its default state. It seems like this is expected behaviour, but can be exploited to maliciously make accounts undeletable at a low cost.

Edited April 21 by at3n