0055 XLS-55d: Remit: Atomic Multi-Asset Payments for XRPL Protocol Chains

[RichardAH]

XLS-55d - Remit: Atomic Multi-Asset Payments for XRPL Protocol Chains

Title:         Remit: Atomic Multi-Asset Payments for XRPL Protocol Chains
Revision:      1 (2023-12-4)
Author:        Richard Holland
On behalf of:  XRPL-Labs

Introduction

Remit is a new payment transactor designed for XRPL Protocol Chains, which allows a sender to send multiple currencies and tokens atomically to a specified destination. It is a push payment that delivers "no matter what" and is designed for retail and Hooks use-cases.

Constraints

Using Remit the sender may send:

• one or more Issued Currencies, and/or,
• one or more pre-existing URITokens owned by the sender and/or,
• one new URIToken created in-line as part of the transaction.

The transactor has the following behaviours:

• If the destination does not exist, the sender pays to create it.
• If the destination does not have the required trust-lines, the sender pays to create these.
• The exact amounts and tokens are always delivered as specified in the transaction, if validated with code tesSUCCESS.
• The sender pays all transfer fees on currencies, and the fees are not subtracted from the sent amount.
• Where the sender pays to create objects, this is a separate amount not taken from the amounts specified in the transaction.
• The transaction is atomic, either all amounts and tokens are delivered in the exact specified amount or none of them are.
• The transactor does no conversion or pathing, the sender must already have the balances and tokens they wish to send.
• When no amounts or tokens are specified, the transaction may still succeed. This can be used to create an account or ensure an account already exists.

Specification

A Remit transaction contains the following fields:

Field	Required	Type	Description
sfAccount	✅	AccountID	The sender
sfDestination	✅	AccountID	The recipient. Does not need to exist. Will be created if doesn't exist.
sfDestinationTag	❌	UInt32	May be used by the destination to differentiate sub-accounts.
sfAmounts	❌	Array of Amounts	Each of the currencies (if any) to send to the destination. Sender must have funded trustlines for each. Destination does not need trustlines.
sfURITokenIDs	❌	Array of URITokenIDs	Each of the URITokens (if any) to send to the destination.
sfMintURIToken	❌	URIToken	If included, an inline URIToken to be created and delivered to the destination, for example a receipt.
sfBlob	❌	Blob	A hex blob up to 128 kib to supply to a receiving Hook at the destination.
sfInform	❌	AccountID	A third party. If supplied, their Hooks will be weakly executed (but the sender will pay for that execution).
sfInvoiceID	❌	UInt256	An arbitrary identifier for this remittance.

Example Transaction

{
      "TransactionType" : "Remit",
      "Account" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
      "Destination" : "raod38dcxe6AGWfqxtZjPUfUdyrkWDe7d",
      "Amounts" : [
         {
            "AmountEntry" : {
               "Amount" : "123"
            }
         },
         {
            "AmountEntry" : {
               "Amount" : {
                  "currency" : "USD",
                  "issuer" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
                  "value" : "10"
               }
            }
         },
         {
            "AmountEntry" : {
               "Amount" : {
                  "currency" : "ABC",
                  "issuer" : "rpfZurEGaJvpioTaxYpjh1EAtMXFN1HdtB",
                  "value" : "12"
               }
            }
         }
      ],
      "URITokenIDs" : [
         "C24DAF43927556F379F7B8616176E57ACEFF1B5D016DC896222603A6DD11CE05",
         "5E69C2D692E12D615B5FAC4A41989DA1EA5FD36E8F869B9ECA1121F561E33D2A"
      ],
      "MintURIToken" : {
         "URI" : "68747470733A2F2F736F6D652E757269"
      }
}

Unwanted Remits

Users who do not want to receive Remit transactions can either set the asfDisallowIncomingRemit on their accounts or install a Hook that will regulate incoming Remits. Alternatively they can simply burn unwanted URITokens or return unwanted Issued Currencies in order to claim the reserve that was paid by the sender.

Chain Requirements

XLS-55 depends on the adoption of XLS-35 on the applicable chain.

[WietseWind]

Yay, payment + loyalty + voucher at once :)

Retail, store:

• Product price: €10
• Discount when sending 500 loyalty points: €1
• Voucher (URIToken) for 20% off

» Send one atomic TX with the voucher, 500 loyalty points & (10-1)*(1-0.2) Gatehub.EUR 🎉

[MarvinSunday]

I'm trying to understand the logic about the above transaction Wieste.
Is it the retail store that is sending the remit or is the product buyer?
I also understand that the Loyalty points will be minted as a new URIToken by the transaction, am I wrong?

[WietseWind]

It doesn't really matter who initiates, can be the store:

• Store: "that'll be 10€"
• Customer: "I have this voucher and I also would like to cash out 500 points"
• Store: "ok here's a sign request for a ttREMIT with (see exmaple)"

... can be the user:

• "OK, let me use this and that to check out"
• Click pay
• Get presented a sign request to pay accordingly

Loyalty points can be anything, I'd say simplest would just be an issued currency. But that's not the point of this proposal, it can be anything. The proposal is about atomic transactions with different representations of value (issued assets, native asset, URIToken, ...) where either all inner transactions (transfers of value) fail, or all succeed.

[MarvinSunday]

Crazy! I get it now Wieste, thanks this is awesome 😎
I feel like this transaction type ttRemit will help alot of real life applications to thrive on the Xahau.
Great one @RichardAH 👏🏾👏🏾

[tequdev]

It will be more processing compared to other transaction types, but is baseFee still the default?

[RichardAH]

It's actually less than a pathing payment (considerably less). It will be charged as a base fee unless someone can show objectively that it should be charged as more.

[mvadari]

Shouldn't the ability to create trustlines for someone else be opt-in instead of opt-out? I could imagine a scam where someone sends a bunch of remits with dust to every account that doesn't have asfDisallowIncomingRemit enabled/a hook preventing those transactions (likely most of them) just to bump up the number of trustlines their token has to make it seem more legit/game token rankings.

[mvadari]

Creating a new account is 5x as expensive as creating a trustline for an already-existing account. All those accounts that set up trustlines anyways can still opt-in to remits.

I'm not suggesting removing the feature of being able to pay for + create a trustline on behalf of someone else - I think that's a pretty neat feature - just that it should be opt-in instead of opt-out.

[hazardcookie]

I think the more technical minded folks might understand the amount of trustlines doesn't mean its credible. However i'd argue that the vast majority of end users value that metric. It's one of the metrics sites like onthedex and xpmarkets use as one of their key data points. Yes we might know that we shouldn't put much stock into that number, but if we put ourselves in the place of average users, i think they would find that to mean its "trustworthy".

[RichardAH]

XRPL allows push payments for XRP that can contain memos which contain advertisement for scams. Should we disallow push payments for XRP as well because they can be used by scammers to spam unsuspecting users? This is the logic, no?

[xVet]

Isn't that essentially how ETH and other evm chains work?

[Cbot-XRPL]

Im pretty certain this is how it works on evm.

[Mwni]

For this amendment to work, the XLS-35 URITokens amendment needs to be active as well. What happens if this amendment gets voted in, but URITokens don't?

[RichardAH]

You could always write an implementation of it that works with xls20?

[RichardAH]

Changed the title to clarify that this standard can apply to any XRPL protocol chain (although only one such chain with required xls-35 adoption currently exists).

[mvadari]

A couple of additional thoughts:

• Can there be a flag on Remit to allow senders to opt out of creating a trustline (if needed), if they don't want to give up their 2 XRP?
• What happens with authorized trustlines?
• What if someone sends a remit for USD.bob instead of USD.Gatehub (and some other currencies/URITokens) and creates that trustline? Wouldn't you still have to send back the other currencies and URITokens, defeating the purpose?

[WietseWind]

• If one opts out of creating a TL, and that was needed, the entire Remit would fail as the TX needing the TL would fail, thus all would fail.
• Authorized TL: if unauthorized: that TX would fail, so the entire Remit fails
• If someone sends the wrong thing, then yes, it needs to be reverted. But you can't prevent stupid ;)

[mvadari]

• Re flags: Yes, I'm saying that should be an option for senders, just like with authorized trustlines.
• Re sending something else: I'm not talking about mistakes, I'm talking about scams. Not re sending worthless tokens to many people, but tricking a merchant into thinking they sent a legitimate token when they actually sent something worthless.

[WietseWind]

but tricking a merchant into thinking they sent a legitimate token when they actually sent something worthless

That's something they can catch on the receiving with a Hook, and simply by checking what comes in. They have to do and manage these checks anyway, because what if the client simply doesn't pay enough?

Let's take a retail example, I'm in a store, have to pay 9USD+100 points. I pay 9 EUR. Store gives me my money back, points are never taken from my membership card. I either pay 9USD+points, or nothing at all.

With Hooks this would be even nicer because the recipient kan simply reject anything that isn't USD, and again nothing would go through if it doesn't match those conditions.

[Cbot-XRPL]

Going along with previous comment. Would there need to be a flag if a sender did not want to fund creating the destination account? I could see a situation where the remit sender does not want to be the root of destination accounts.

[tequdev]

If defaultRipple is enabled for the destination account, wouldn't an attacker be able to steal funds via Rippling?

[dangell7]

Can you elaborate more on how you think this is possible?

[tequdev]

I checked the Remit Amendment, and it appears that the LimitAmount of the trustline automatically created by the Remit transaction is 0, so this does not seem to be a concern.

[tequdev]

If I send multiple types of tokens (native/issued), what value will meta.delivered_amount have?

[dangell7]

delivered_amount will be undefined because the delivered_amount is the sfAmount and in this case it doesn't exist on this transactor.

[tequdev]

There is a possibility of balance inconsistencies when depositing to the exchange via Partial Payment.

If the exchanges can set DisallowRemit flag, it's not a problem, but I don't know if all exchanges can handle it.

For reference:
#162 (reply in thread)

[dangell7]

There is no Partial Payment with ttREMIT

[tequdev]

As others have mentioned, I prefer opt-in instead of opt-out.
Also, some kind of illegal token or URIToken should not be accepted by default.

Or it could happen that they send issued tokens to accounts on exchanges that have not set the disallow flag to put pressure on them to support tokens.