0088 XLS-88d: Service Fee

[RichardAH]

Title:       Service Fee - Inline Payments to Service Providers
Revision:    1 (2025-01-26)

Author:      Richard Holland

Affiliation: XRPL-Labs, Evernode-Labs, InFTF

Service Fee - Inline Payments to Service Providers

Introduction

Fees are currently charged (burned) by the network to prevent spam. However the network is not the only interested third party to any given transaction. The vast majority of transactions are submitted via commercial wallet softwares, such as: Xaman, Crossmark, Ledger, and others.

Historically cryptocurrency wallets have had a hard time monetizing their users. Users are reluctant to pay a subscription or other up-front or on-going fee to use this type of software. One strategy that has reliably worked for other chains is the "service fee" model: a small percentage of each outgoing payment is forwarded to the wallet provider. Herein I propose an amendment to mirror this for XRP Ledger Protocol chains.

New common field: ServiceFee

ServiceFee is an optional field that can appear in any transaction. It is an object that contains two inner fields: Amount and Destination.

"TransactionType": "<anything>",
"Fee": "1000", 
"ServiceFee": {
  "Amount": "10",
  "Destination": "rWalletProvider"
}, 

Constraints

Behaviour

ServiceFee is an "all-or-nothing" delivery of the stated fee to the stated destination. If for any reason the fee cannot be delivered, the transaction processes as normal and the service fee is disregarded.

Currencies

ServiceFee supports both native (XRP/XAH) and issued currencies. This assists use-cases where fiat-pegged stable coins are exclusively used by a group of users (who are therefore otherwise uninterested in the chain's native asset).

Amount

ServiceFee amount must be strictly greater than 0, otherwise it is disregarded.

Nothing created

The ServiceFee field cannot be used to create any object (e.g. trust-line or account) on the ledger.

No on-chain enforcement

The ServiceFee is not an enforced transfer on the ledger, meaning it can fail without affecting the transaction's success code. This is reasonable because wallet software can trivially enforce its own rules client-side, whatever those may be. If the user is unable to pay the required service fee, the wallet software can simply refuse to compose and submit the transaction. If a mistake is made and the service fee is submitted but cannot be completely delivered it is disregarded and the transaction processes as normal.

[sal666]

About using other currencies than the native one, where is it declared? Shouldn't the ServiceFee object include a "currency" field?

[dangell7]

The transaction would look like this.

"TransactionType": "<anything>",
"Fee": "1000", 
"ServiceFee": {
  "Amount": {
    "currency": "ABC",
    "issuer": "rIssuer",
    "value": "10",
   },
  "Destination": "rWalletProvider"
}, 

[mvadari]

Is this different from XLS-67d?

[RichardAH]

Yes it's basically a fully spec'd duplicate. I was unaware of the previous spec.

[trueIoV]

I personally prefer mandatory enforcement, but
while mandatory enforcement would benefit wallet providers and improve consistency, it may negatively impact user experience and protocol simplicity. An optional enforcement mechanism offers a middle ground, giving wallet providers the choice to enforce fees strictly if they prefer.

Alternative Proposal: Optional Enforcement

To strike a balance, the protocol could support an optional enforcement flag within the ServiceFee field.
For example:

"ServiceFee": {
  "Amount": "10",
  "Destination": "rWalletProvider",
  "Enforce": true
}

If Enforce is true, the transaction fails if the ServiceFee cannot be paid.
If Enforce is false (or omitted), the behavior remains as currently proposed: the transaction succeeds, but the ServiceFee is disregarded if it cannot be delivered.

[RichardAH]

There really shouldn't be any reason the wallet software needs to enforce this on-chain, and almost every edge case that arises from enforcing it causes a terrible user experience that helps no one. It adds lots of complexity to no benefit that I can see?

[trueIoV]

I agree with you, but it's hard for me to imagine how to guarantee a profit if the payment for a product/service is optional and more like a donation. My proposal adds flexibility and, if necessary, guarantees the developer a reward.
By allowing optional enforcement, these edge cases are mitigated because the transaction can still succeed even if the ServiceFee fails. This approach balances flexibility and functionality without compromising the user experience.

[RichardAH]

Just because it's only enforced client side doesn't mean its optional? Your iphone enforces all sorts of things client side, like for example that you must have an apple account or that you must only load apps from apple's app store or that you can only use apple pay for NFC payments. Do any of these feel optional for mere reason they're enforced on your device rather than on a server somewhere?