0067 XLS-67d: Charge

[tequdev]

Abstract

One way to monetize NFT, AMM and other platforms that use XRP Ledger is to charge a fee from separate Payment transaction. XLS-56d (Batch/Atomic Transaction) has already been proposed as a way to do this in a single transaction. Here, I propose a feature that focuses on fee collection and makes monetization easier and simpler for platforms, wallet services, and users to use.

Specification

Transaction common field

Add the following field as one of transaction common fields.
This field is an optional field and be available for any transaction.

Field Name	Required?	JSON Type	Internal Type
Charge		object	Object

Charge Field

Field Name	Required?	JSON Type	Internal Type
Amount	✅	object or string	Amount
Destination	✅	string	Account
DestinationTag		number	UInt16

Amount Field

Like the Amount field used in other transaction types, it represents a native token when specified as a string, or an issued token when specified as an object.

For tokens for which a TransferRate has been specified by the issuer, this field represents the amount of tokens sent by the sender of the transaction and doesn't guarantee the amount of tokens the destination account will receive.

Destination Field

The account to which the fee will be sent.

It is not possible to specify the account from which the transaction originates or an account that has not been activated.

Matters to Consider

These are not included in the above specifications, but are subject to discussion.

SendMax Field

We could add SendMax to specify exactly how much the sender pays and how much the receiver receives, but that would be more complicated.

CrossCurrency

It is possible to make cross-currency payments by specifying different currencies in the SendMax and Amount fields, but this will increase transaction load.

The Path field cannot specified and the default Path is used.
e.g.

• AAA/BBB without XLS-60d
• AAA/XRP, BBB/XRP, AAA/BBB with XLS-60d

Multiple charges

Multiple currencies can be set as fees by specifying multiple Charge fields as an array in the Charges field, but this increases the transaction load (especially if cross-currency is also available).

[xVet]

Great proposal Tequ! Question, what's the difference to a Payment transaction? I thought you would do a pull payment and take Amount from the destination but you describe it as just a payment to destination

[dangell7]

It would go on the transaction. Example:

{
  "TransactionType": "NFTokenMint",
  "NFTokenTaxon": 0,
  "URI": "DEADBEEF",
  "Flags": 1,
  "Charge":  {
      "Amount": "1000000",
      "Destination": "rH4KEcG9dEwGwpn6AyoWK9cZPLL4RLSmWW"
  }
}

Where the Charge destination is the UI platform. Like a service fee.

[xVet]

I see, thanks for the example, made it more visible!

[shefi]

Great proposal, Tequ!

It should help those building the UI tremendously. If they all can make money, they will have enough capital to push the marketing far and wide for their offerings on XRPL. This way new engagement will be brought in to XRPL and help with the overall growth of the ecosystem.

I would like to suggest for the Charge field to be an array to allow for multiple amount and destination pairs. Array or any appropriate type for rippled codebase, because I don't have knowledge of it. I think I saw STArray somewhere.

Why?

It could be useful if there will be a time that a non-profit bounty reward system will come to life as described in this X Post I have shared. UIs could give their users an option for them to donate an amount (however small) to any such non-profit they want to donate to.

It could be something like Kyber Swap has with their tipping feature for DEX Screener on this screenshot for example:

Here is the link to that interface.

It should all be optional, but if they build right their users will appreciate the value they are getting and will definitely choose to pay either the fees, donations, or both.

I hope this proposal gets accepted and goes live. It will help a lot all those developing for XRPL to monetize their products so they can survive and keep pushing more and better. As well as maybe help with funneling those community donations for further developments of the core ledger or other ecosystem solutions.

[EnchStyle]

Can you provide a straightforward explanation of what this feature does and how it improves upon XLS-56d, without using technical jargon? The abstract on itself does not answer my question or help me to understand the perspective. :)
Thanks

[mvadari]

You can take a look at the spec here: #162

[shefi]

I will try to take a look at it and see if I can follow tomorrow, because I am on a mobile device now and it's not easy to follow the flow.

I am shooting blind here, but one drawback I may foresee is the need for paying the transaction fee for each transaction in the batch vs paying only once this way? I could be wrong though, and please correct me if I am. This is how I learn as well.

[mvadari]

Yes, that's the primary difference I see as well - but I'm not sure that that's worth a whole different spec to solve the same problem.

[shefi]

Yes, it's not necessarily bad, since it helps with the deflationary economics of the native token as well.

However, if there is any kind of workaround, while maintaining the same quality requirements, that can be done to avoid paying extra fees, it might be worth to explore that route.

[EnchStyle]

@mvadari maybe you could kindly provide more clarification? as you clearly understand XLS-56d better than anyone and can compare to this. As I am still not sure if I understand the nuances and differences between two.

[rothexD]

should we add a [optional]DestinationTag to the charge field?

[shefi]

Yeah, that's also great suggestion. Destination tag should be in for sure.

[Panosmek]

Great proposal that needs to pass asap! Is it possible to charge a percentage instead of an amount? If a UI wants to charge 0.1% on each transaction for example, can it be done?

[mvadari]

You can just calculate that when you generate the transaction.

[mvadari]

Is there a method to support multiple charges on one transaction, such as if the UI wants to charge a fee and the wallet also wants to charge a separate fee?

[tequdev]

As others have pointed out, changing the field to an array would allow for multiple charges.

[tequdev]

The Batch functionality, which has some overlap with this proposal, is currently under development, and I don't see this proposal moving forward to the next phase at this time.

The unique point of this feature, as opposed to the Batch, is that it is clear from the presence of the Charge field that the amount will be collected as a fee.

If anyone would like to move this feature forward, please let me know. I will be happy to help.

[mvadari]

@tequdev should this spec be moved into PR and kept in the repo or should it be closed? Note that this does not mean that the spec has been accepted/implemented/finalized.

I will move it to PR by copy-pasting the existing draft if there is no response in the next week.