Blackholed Accounts & Token Escrow

[cryptored3ye]

Will blackholed accounts ever be able to use Token Escrow in the future — whether through a fix amendment or via Smart Escrow functionality?

[danielwwf]

I think this is something a lot of issuer want and we fumbled the ball on this a little. However, I am not sure if this could be resolved. @dangell7

[shortthefomo]

Reference XRPLF/rippled#6171

[xVet]

Will blackholed accounts ever be able to use Token Escrow in the future — whether through a fix amendment or via Smart Escrow functionality?

It would certainly need another amendment.

Ideally we make all token escrow default opt in and you need to
opt out actively.

This way we can keep the flags etc, we just switch the meaning.

[ximinez]

Ideally we make all token escrow default opt in and you need to opt out actively.

Until now, the only place to find an IOU balance was on a trust line linking two accounts. Issuers need to be able to find their issued tokens for accounting, auditing, etc. Token Escrows move tokens off of trust lines and in to other objects. An issuer that hasn't updated their systems to know how to look in those objects will lose track of their issued funds. Imagine how bad the consequences could be if an issuer couldn't find all their issued funds in the middle of an audit. At least a global freeze while they figured it out, and updated their systems. That's not good for any holders.

The opt-in is a signal that the issuer knows where to look for their issued tokens. The only reasonable way that token escrow could be implemented without an opt-in is to move the funds to another trust line, instead of an escrow, and you'd have to have some way to guarantee that the "alternate" trust line was not modified by anything other than an Escrow-related transaction. None of these things are trivial to implement.

[ximinez]

Some off the cuff ideas for storing Escrowed tokens on a separate trust line:

1. A pseudo-account for every escrow. The pseudo-account has the trust line to the issuer, which holds the funds. Will require reserving 3 object increments: Escrow, pseudo-account, trust line.
2. A single pseudo-account per issuer. The pseudo-account has a trust line to the issuer, which holds all aggregated funds. Won't require extra reserves, because the cost of the two objects will be amortized across all Escrows. This might be exploitable, since anyone can be an issuer. It also introduces the risk of rounding errors making the trust line appear empty when there are still Escrows pending.
3. Add an alternative way to index trust lines (currently Account1, Account2, Currency. Could add an additional value to the index, like Sequence number of the EscrowCreate - same as is used to index the escrow object.) Link the trust line from the EscrowCreate account to the issuer, using the additional information to differentiate it from the "real" trust line. Add field(s) to the trust line object to indicate that it is a "pseudo-trust line". The index of the escrow object would be a good candidate. Will require reserving 2 object increments: Escrow, and the "pseudo-trust line".

[mvadari]

Reference of past discussion: #133