XLS-34d: Token-Enabled Escrows and Payment Channels

[dangell7]

Update: see the XLS-34d spec here

Original discussion: #88

[intelliot]

In the spec, I recommend adding a link to the proposed implementation: XRPLF/rippled#4396

[intelliot]

@seelabs could you have a look at this?

[seelabs]

Yes, I will take a look.

[seelabs]

The fact that IOU balances can only be held by accounts has been rippled pain point. It restricts payment channels and escrows to XRP only. It also shows up in the AMM and sidechain designs. Since AMMs and sidechains need to deal with IOUs, the ledger object must be a type of account. I'm not sure we would have designed things that way if IOU balances could be held by non-accounts. I do understand the motivation for this proposal.

The biggest concern I have with this proposal is the way balances are now represented in the ledger. That's a fundamental concept, and I'd like to keep that clean. Before this change, a trust line represented a net balance between two accounts. After this change a trust line represents the net balance between two accounts as well as the balance of IOUs now owned by other ledger objects where the last owner of that IOU was one of the two accounts on the trust line. That's not a clean abstraction, and this is really a bedrock abstraction in the ledger.

I don't see any blockers - I do think this can be made to work. And I also can't think of a better alternative design.

The choices I see are:

1. We use the "locked" mechanism proposed here. This lets us support IOUs on non-accounts at the cost of making a fundamental abstraction less clean.
2. Keep the status quo. We don't support IOUs on payment channels/escrows.
3. We introduce a new asset type that's like IOUs, but can be owned by non-accounts (I'm thinking of CFTs here). Introducing a new asset type also has large costs - especially as all the asset types need to interact with each other. If we did this I suspect it will be a long time before it was introduced.
4. We introduce a new implementation of payment channels and escrows where the fundamental ledger type was an account. If we did this it would introduce redundant functionality and also complicate accounts objects - something that is already happening with AMMs.

I vote for (2). I don't love the design restriction where IOUs can only be between accounts, but lifting that restriction by changing how trust lines work seems like a bad trade-off.

I also want to mention: I'm speaking for myself. I understand that I'm more conservative than many people in the community or at ripple. But I did want to register my thoughts.

[RichardAH]

@seelabs Thanks for your consideration. We're going to close this and put it on the hooks sidechain instead. Perhaps in the future it can go on mainnet.

[RichardAH]

Whoops meant to close the PR on rippled :)

[ckniffen]

I find this feature to be very valuable and has been a major request by the community for some time. We should do what it takes to ensure this functionality applies to IOU on mainnet.

[seelabs]

@RichardAH I really hope my comment didn't come off as too negative. I didn't mean for the result of my comment to immediately close this. I do understand the benefits of this feature.

[RichardAH]

@RichardAH I really hope my comment didn't come off as too negative. I didn't mean for the result of my comment to immediately close this. I do understand the benefits of this feature.

As a rule, going forward, all amendments we write will first go live on the Hooks sidechain. This is a better model that will make all parties happier in the long run I believe.

[seelabs]

@ckniffen To be clear, I also find this feature to be very valuable.

[calvincs]

I am working with channels, and see the use of XRP alone, who's value is in constant flux, being an issue here.

If a vendor wants to ensure that the micro payments they offer won't fluctuate in value, they need a stable asset they can offer.

But because this is not yet possible, the recipient of micropayments, much like the recipient of an XRP payment will need to quickly exchange it into a stable asset.

However, unlike XRP payments which settle almost instantly and can be exchanged quickly, micropayments may not settle for some time, until claimed by recipient.

The risk here is small, and it's micro payments so the slippage is also minimal (likely).
But it's still something where having channels supporting issued tokens would be great.

Just throwing my hat in here as someone looking for this functionality.

[ralphsa]

Both of these are highly beneficial to issued tokens, having this as native functionality for these tokens is another positive for the XRPL over other chains which rely on smart contracts etc. to achieve this.

[alloynetworks]

Without IOU escrows, the XRPL remains in danger of being a toy network. I cannot understand why Ripple wouldn't be jumping at this with all hands on board. Escrowing a highly volatile asset is next to useless, other than for entities that want to lock up their native token for themselves for future release. As Richard says, this will go live on the side network.

[Silkjaer]

I think this PR is ready to merge, as the standard is a draft. Further edits and comments can be made in follow-up PRs.

[danielwwf]

We need token escrow on mainnet, it's beyond me why this isn't being pushed.

[ximinez]

I know I'm late to the party, but one thing I haven't been clear on, and I don't think any of these specs have answer is: What exactly are the LockedBalance and LockCount fields trying to solve?

In other words, if one were to do a "naive" implementation, and just move the balance from the source trustline to the Escrow object when creating it, and then move it from the Escrow to the source or destination when cancelling or finishing, respectively, what would be broken?

[dangell7]

When we do PayChan or Escrow for XRP the XRP is "moved" from the account to the LE. In this implementation the money is still in the account. It is Locked. The LockedBalance is the amount locked in the trustline. The count is the number of locks on the line. So if you had 2 escrows and 3 paychans for the same IOU the LockCount would be 5.

Technically doing it "naive" way that would go against the exact thing seelabs pointed out.

"The biggest concern I have with this proposal is the way balances are now represented in the ledger."

We don't actually do that. The balance stays in the account however the amount is not transferable because of functionality we implemented using LockedBalance.

[ximinez]

@dangell7 Thanks for that explanation.

[desimmons]

Commenting to add further validation that this feature is desired:

I'm a cofounder at Dhai. We're using XRPL payment channels to fund APIs via XRP micropayments. At the moment, our users are necessarily exposed to XRP volatility. We'd like to be able to avoid this for our users. Hence why we vote for this feature!