Alternate Token Enabled Escrows and PayChan

[ximinez]

Introduction & background

I've been thinking about the XLS-34 proposal to allow putting tokens into Escrows and PayChans (which I'll call "instruments" for the rest of this document):

• https://github.com/XRPLF/XRPL-Standards/tree/master/XLS-34d-paychan-escrow-for-tokens
• PaychanAndEscrowForTokens: Token-Enabled Escrows and Payment Channels support (XLS-34d+) rippled#4396

In addition to the concerns raised by @seelabs in #112 (comment), I have three concerns, specifically about the "LockedBalance" mechanism, that I consider very strong blockers to merging the proposed code changes.

1. Ownership of the token / money is not truly moved from the account to the instrument in the same way that XRP is moved. It is, in effect, copied. Arguably twice, since it's also accounted for by the LockedBalance
2. It requires changes to every place that interacts with trust lines to account for the locked balance.
3. It ignores the fact that trust lines are designed to be bidirectional. They're not often used that way, but that's no reason to neglect the design.

Idea for an alternate approach

The following idea is based off of XLS-34, but is intended to supersede and replace it.. Anything not related to the Locked… fields should be considered as included by reference (e.g. the addition of TransferRate). If it moves to a more formal specification, it should at minimum use a different amendment name to prevent potential conflict, and the authors of XLS-34 should be offered co-author credit.

This is not a fully fleshed out spec, but I wanted to get a discussion going before the current proposed implementation is merged to develop.

These are the two big changes:

1. When creating an instrument with a token, add the instrument to the counterparty / issuer's directory. (This implies adding an sfCounterpartyNode or sfIssuerNode to the instrument object alongside Owner Node and Destination Node.) The requested tokens will be transferred from the owner's trust line with the issuer to the instrument's "Amount" field (the "Amount" will always be positive, unlike trust line balances), ignoring transfer rates. Note that the "Amount" is already represented by an STAmount, so no new logic should be needed to do that, and the issuer's account ID will automatically be included.
   1. When the token instrument is redeemed / finished, the tokens will be transferred from the instrument to the destination's trust line with the issuer, but will account for the better of the issuer's transfer rate and the transfer rate stored on the instrument.
   2. When the token instrument is canceled, the tokens will be transferred back to the owner's trust line with the issuer, again ignoring transfer rates.
   3. No new trust lines will need to be created on ledger, though the implementation may use some internally if that makes the implementation easier.
2. Store arrays of "pointers" to the instrument objects in the trust Line. Although these are redundant with the directory entries, they'll make it easier to find the associated objects given only the trust line, and their presence will indicate that the line is in non-default state. There will be High and Low arrays corresponding the two sides of the trust line. It may be worth splitting into two arrays each for a total of four, so High and Low and Escrow and PayChan. These do not necessarily have to be full index values, just enough to drive the keylet given the source and dest accounts - maybe just the transaction Sequence.
   1. If the arrays turn out to be overkill, then a counter may be sufficient, so long as there is one each for the High and Low accounts.

Example

Alice has a trust line with GW and holds $1000/GW. Bob also has a trust line with GW, and holds $100/GW. Alice submits an EscrowCreate transaction to escrow $100/GW for Bob. When the transaction is done, Alice's balance will be $900/GW, Bob's will be unchanged at $100/GW, and a new Escrow object will be created that holds $100/GW. Alice's owner count will be increased by 1, and the Escrow object will be added to Alice, Bob, and GW's owner directories. GW's current transfer rate will be stored in the Escrow object. Assume that it is 2%.

If Bob submits an EscrowFinish for Alice's $100/GW escrow, Alice's balance with GW will remain unchanged. Bob's balance will increase $98/GW (because of the transfer fee). The escrow object will be removed from all three owner directories, and deleted. Alice's owner count will be decreased by 1.

If, instead, Alice submits an EscrowCancel for the escrow, Alice's balance with GW will increase by $100/GW (ignoring the transfer fee). Bob's balance will remain unchanged. The escrow object will be removed from all three owner directories, and deleted. Alice's owner count will be decreased by 1.

Pros

• The instrument objects essentially become alternate-format trust lines. I think/hope this goes a long way to address @seelabs's concerns by extending to these instruments the ability to hold IOUs outside of account trust lines.
• The values represented in the objects represent the "real world" values without any manipulation. This keeps the fundamental abstractions clean.
• "Community credit" use cases are preserved. For example, assume friends, Alice, Bob, Claire, who all trust each other for a reasonable amount of BUX. If Bob holds 5 BUX/Claire, he can escrow it to Alice and have a trust line balance of 0 with both Alice and Claire. Bob can later send Clair 5 BUX/Bob without restriction or modifying the Escrow. Clair could then escrow the 5 BUX/Bob to Alice, again leaving all the trust lines with 0 balances.

Cons

• Issuers / gateways, especially those who automate auditing their balances, will need to update their software to understand the modified instrument objects. We don't want to break backwards compatibility for gateways before they're ready, nor do we want to punish them for following current best practices. This can be mitigated by one or more of the following:
  • The most obvious solution and my preference is a one-way "allow IOU instruments" account flag. The only downside of that is that existing blackholed issuers won't ever be able to set the flag. There are workarounds they could implement which I won't get into here.
  • The next obvious solution is a reversible "disallow IOU instruments" flag. The problem with doing it this way is that issuers may have to race to set the flag once the amendment is enabled.
  • Maybe some kind of crazy solution that would create extra trustlines tied to the accounts AND the instrument object, but which is unusable anywhere else. I don't think this is a good idea, because it recreates some of the problems I enumerated above, and takes even more ledger space, but I didn't want to ignore it.
• This design is completely incompatible with the current XLS-34 proposal and implementation. Though it's not on mainnet, any side chains that have implemented and enabled it will have to decide whether to migrate, ignore this design, or find another solution. I am willing to help, but I haven't thought through what that would look like.

Interaction with other features and mechanisms.

• Freeze. Individual and global freezes will be treated identically.
  • Create / fund: No instruments will be able to be created or funded if the sender / owner's trustline is frozen. The destination / recipient's freeze state is irrelevant. This allows the use case of "I can't pay you now because your line is frozen, but when that's straightened out, the payment will be waiting in escrow."
  • Finish / redeem: No instruments will be able to be redeemed by the destination if the destination's trust line is frozen. The sender's freeze state is irrelevant. This makes the instrument a truly independent object.
  • Cancel: As sort of an exception, the instrument can be canceled regardless of any of the freeze flags. This allows the sender to reclaim their reserve from the instrument, even if the trust line is frozen, preventing the sender's reserve from being "held hostage" by the issuer. (Remember, the account can recover the trust line reserve by sending their balance to the issuer and getting the remaining values into the default state.) The funds will still be unspendable.
• Clawback: Because the instrument is tied to both accounts, I don't think it will make sense to allow issuers to claw funds back from them. Which account are they reclaiming the funds from? I think it's reasonable to require the issuer to claw back from one trust line or the other, and if the balance is not sufficient, to freeze the line until it is. In unusual edge cases, the issuer could freeze both trust lines. That's for them to determine.
• As with XRP instruments, token instruments will be ignored by the payment engine, offer crossing, path finding, etc.

Potential Objections

I want to address one potential objection here, even though I'm sure there will be others:

• "IOU balances can only be held by accounts and trust lines, and this does neither". In a very real sense, this is true. This change is introducing a fundamental shift in the way the XRPL treats IOU balances. Counter-points:
  • The same thing happened with XRP escrows and payment channels. Before those features were added, XRP could only be held on AccountRoot objects. Those new instruments introduced new objects that could also hold XRP. Tooling (particularly "total XRP in existence computations") had to be updated so that XRP wouldn't be considered "missing" when it was moved to an instrument. XRP was easier because there was no counterparty to worry about, but I don't think it's fundamentally different.
  • My preferred approach is to make the feature opt-in for issuers, thus giving them as much time as they need to update their tooling and accounting. This will certainly slow adoption, but it should also make the migration a lot easier to manage for all stakeholders.

[shortthefomo]

Can you elaborate on that bit bi-directional usecase or point us to docs of it or something?

Thanks @ximinez

[ximinez]

Sure:

1. https://xrpl.org/tokens.html#community-credit provides a very brief summary of "community credit", which relies on trust lines being bidirectional.
2. https://xrpl.org/trust-lines-and-issuing.html#trust-lines-and-issuing

   • Each "trust line" is a bidirectional relationship consisting of:

   • (Emphasis in original)

Also, consider the structure of the trust line or "Ripple State" object itself. Other than the balance, and some record-keeping fields, all the other fields are identical between the "low" and "high" accounts.

• Low
  • sfLowLimit
  • sfLowNode
  • sfLowQualityIn
  • sfLowQualityOut
• High
  • sfHighLimit
  • sfHighNode
  • sfHighQualityIn
  • sfHighQualityOut
• Other
  • sfBalance
  • sfPreviousTxnID
  • sfPreviousTxnLgrSeq
  • Edit: I realized that I neglected to include the common fields:
  • sfLedgerIndex
  • sfLedgerEntryType
  • sfFlags

That isn't by mistake or some unintentional side effect. That's a very conscious design decision to allow both sides to set their own parameters on trust lines, including non-zero limits, and to let the balance be "owed" from either side to the other.

[adrianhopebailie]

Always been a fan of Payment Channels and would love to see them available for IOUs. Great work @ximinez. What has to happen next to get this into an amendment?

[adrianhopebailie]

Maybe I'm misunderstanding the goal here but that would mean that XRPL and Xauhau would potentially have different and conflicting implementations.

Is the goal with Xauhau to simply push code faster so that it's harder to ship alternative implementations on mainnet or is a divergence in functionality intended?

[ximinez]

Maybe I'm misunderstanding the goal here but that would mean that XRPL and Xauhau would potentially have different and conflicting implementations.

That would unfortunately be true.

[RichardAH]

The idea of sidechains is precisely to allow different feature sets. The chains are not supposed to be identical clones of each other.

[desimmons]

Just to confirm, did Xahau release the amendment, that @seelabs raised concerns over, into the Xahau mainnet @dangell7?

[desimmons]

Also, what sort of timeframe are we looking at for something of this calibre (@ximinez proposal) to be available on mainnet?

[desimmons]

We're super interested in this feature at dhali.io

[desimmons]

Bumping this comment. We're having further conversations with other businesses who have interest in non-XRP based payment channels but concerned about the lack of XRPL support

[EnchStyle]

So, I personally see no issue with this proposal, neither I have any improvements. The question is what road blocks are we experiencing now in order to bring this to XRPL main net?
This is a critical feature. Without it, XRPL's ecosystem is vulnerable to scams and token dumps. It has no programmatic lock mechanism for tokens. As a result, no single project is able to even remotely set vesting to provide healthy and predictable tokenomics. Until this is live, XRPL will never ever will be able to see accurate data in terms of market caps of individual projects, token buyers will never be safe and sure that team will not dump on them so called "locked" tokens, and project will treat XRPL as limited functionality blockchain with closes to zero interest.

What we can do to support and facilitate implementation of this element? We have been demanding it nearly since day 1 of our existence on XRPL.

[ximinez]

@EnchStyle Thank you for your feedback. I don't really have an answer for you question beyond the standard "resources and prioritization issues" that keep anything from getting done because something else needs to be done more.

[EnchStyle]

So, my goal here is to initiate a discussion and understand how to kick off the implementation.

While I see and agree about priorities, it is somewhat difficult to agree on "recourses".

The problem is that no one in the dev community really understands what the priorities are. Also, who sets those priorities? Ripple has no product owner (to my knowledge) for XRPL to shape its future, nor Ripple actually speaks with developers trying to understand what is really needed. Any collected feedback is disregarded and thrown into the bin, hence I don't even bother in most cases. It is clear that our priorities are completely out of match.

How do you think lack of escrow is not a priority? Not a priority from whom and why? We always keep worrying about safety and security, yet one of the most obvious and critical pieces is missing. As a result, projects are borderline scam as simple checks just don't exist. Then people complain there is no community and 10 developers. I wonder why, right?

It is like doing AMM without yield farming, lending, and rest DeFi infrastructure. Half measures - sort of a signature of XRPL.

I don't want to be negative, but XRPL is 10+ years. Does XRPL fulfils its requirements for XRP? Yes, it does. Does XRPL work as layer1 blockchain? No, it is the worst L1 chain on the market right now for ecosystem development. Why? You have no programmability, no consistency in development, no plan, no commitment, no follow ups on previously made commitments. Imagine you are a business. So, what business can you make? Only transactional, where you send funds from A to B. Can you make something more complicated? Yes, in a centralised manner, but then why would you need a blockchain? There is a never ending list of issues with XRPL that are being communicated and never actually addressed. Very often I have a feeling people working on XRPL are not aware other chains exists, otherwise they would just copy some of the ideas. But then you have Xahau, Evernode, Coreum, etc., that even more contribute to fragmentation of the ecosystem without actual added value. Do you see the problem? Everyone is trying to fix XRPL, but not Ripple.

My frustration with XRPL is reaching peak levels because of the mismatch in promises/commitment and actual developments.

[desimmons]

Regarding this pre-proposal, to what extent will multi-asset payment channels be compliant with Interledger standards?