|
| 1 | +<pre> |
| 2 | + xls: 55 |
| 3 | + title: Remit |
| 4 | + description: Atomic Multi-Asset Payments for XRPL Protocol Chains |
| 5 | + author: Richard Holland (@RichardAH) |
| 6 | + created: 2023-12-03 |
| 7 | + status: Final |
| 8 | + category: Amendment |
| 9 | +</pre> |
| 10 | + |
| 11 | +## Introduction |
| 12 | + |
| 13 | +**_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. |
| 14 | + |
| 15 | +## Constraints |
| 16 | + |
| 17 | +Using _Remit_ the sender may send: |
| 18 | + |
| 19 | +- one or more Issued Currencies, and/or, |
| 20 | +- one or more pre-existing URITokens owned by the sender and/or, |
| 21 | +- one new URIToken created in-line as part of the transaction. |
| 22 | + |
| 23 | +The transactor has the following behaviours: |
| 24 | + |
| 25 | +- If the destination does not exist, the sender pays to create it. |
| 26 | +- If the destination does not have the required trust-lines, the sender pays to create these. |
| 27 | +- The exact amounts and tokens are always delivered as specified in the transaction, if validated with code tesSUCCESS. |
| 28 | +- The sender pays all transfer fees on currencies, and the fees are not subtracted from the sent amount. |
| 29 | +- Where the sender pays to create objects, this is a separate amount not taken from the amounts specified in the transaction. |
| 30 | +- The transaction is atomic, either all amounts and tokens are delivered in the exact specified amount or none of them are. |
| 31 | +- The transactor does no conversion or pathing, the sender must already have the balances and tokens they wish to send. |
| 32 | +- 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. |
| 33 | + |
| 34 | +## Specification |
| 35 | + |
| 36 | +A _Remit_ transaction contains the following fields: |
| 37 | +Field | Required | Type | Description |
| 38 | +-|-|-|- |
| 39 | +sfAccount | ✅ |AccountID | The sender |
| 40 | +sfDestination | ✅ |AccountID | The recipient. Does not need to exist. Will be created if doesn't exist. |
| 41 | +sfDestinationTag | ❌ |UInt32 | May be used by the destination to differentiate sub-accounts. |
| 42 | +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. |
| 43 | +sfURITokenIDs | ❌| Array of URITokenIDs | Each of the URITokens (if any) to send to the destination. |
| 44 | +sfMintURIToken | ❌| URIToken | If included, an inline URIToken to be created and delivered to the destination, for example a receipt. |
| 45 | +sfBlob | ❌ | Blob | A hex blob up to 128 kib to supply to a receiving Hook at the destination. |
| 46 | +sfInform | ❌ | AccountID | A third party. If supplied, their Hooks will be weakly executed (but the sender will pay for that execution). |
| 47 | +sfInvoiceID | ❌ | UInt256 | An arbitrary identifier for this remittance. |
| 48 | + |
| 49 | +## Example Transaction |
| 50 | + |
| 51 | +``` |
| 52 | +{ |
| 53 | + "TransactionType" : "Remit", |
| 54 | + "Account" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", |
| 55 | + "Destination" : "raod38dcxe6AGWfqxtZjPUfUdyrkWDe7d", |
| 56 | + "Amounts" : [ |
| 57 | + { |
| 58 | + "AmountEntry" : { |
| 59 | + "Amount" : "123" |
| 60 | + } |
| 61 | + }, |
| 62 | + { |
| 63 | + "AmountEntry" : { |
| 64 | + "Amount" : { |
| 65 | + "currency" : "USD", |
| 66 | + "issuer" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", |
| 67 | + "value" : "10" |
| 68 | + } |
| 69 | + } |
| 70 | + }, |
| 71 | + { |
| 72 | + "AmountEntry" : { |
| 73 | + "Amount" : { |
| 74 | + "currency" : "ABC", |
| 75 | + "issuer" : "rpfZurEGaJvpioTaxYpjh1EAtMXFN1HdtB", |
| 76 | + "value" : "12" |
| 77 | + } |
| 78 | + } |
| 79 | + } |
| 80 | + ], |
| 81 | + "URITokenIDs" : [ |
| 82 | + "C24DAF43927556F379F7B8616176E57ACEFF1B5D016DC896222603A6DD11CE05", |
| 83 | + "5E69C2D692E12D615B5FAC4A41989DA1EA5FD36E8F869B9ECA1121F561E33D2A" |
| 84 | + ], |
| 85 | + "MintURIToken" : { |
| 86 | + "URI" : "68747470733A2F2F736F6D652E757269" |
| 87 | + } |
| 88 | +} |
| 89 | +``` |
| 90 | + |
| 91 | +## Unwanted Remits |
| 92 | + |
| 93 | +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. |
| 94 | + |
| 95 | +## Chain Requirements |
| 96 | + |
| 97 | +XLS-55 depends on the adoption of XLS-35 on the applicable chain. |
0 commit comments