Accept other tokens for transaction fee

[wojake]

Summary

Allow the usage of other authorized tokens (Tokens) to pay for transaction fees (USD, EUR, CNY, MYR / BTC, ETH).

Authorized Token:

A token issued by a trusted organization, with proper audits to ensure the asset is 1:1, 
and has strong liquidity in the native DeX to support (token)/XRP swaps.

Requirements to be an authorized token:
---

1. Token must be issued by a trusted organization such as Ripple or a Central Bank. [Confidence and Assurance]
Reasoning: Assurance and confidence in the market, this can boost the liquidity of the token, which will speed up Offers (https://xrpl.org/offers.html).

---

2. Token must be audited to ensure an asset or currency is pegged to 1:1. [Confidence and Assurance]
Reasoning: Requirement 1 is a great step to make sure the token is not fraudulent, this is an addition, this will also boost the liquidity of the token.

---

3. Token must have strong liquidity in the native DeX to support (token)/XRP swaps. [Reduce Swap Latency]
Reasoning: Token must have a strong liquidity in the native DeX, the reasoning behind this is to nsure that there is no unnecessary latency during (token)/XRP swaps when a transaction fee is presented with the authorized token.

Flowchart

Motivation

Anyone, anywhere, anytime can use other alternative currencies without restrictions to fund their transactions on the XRP-L. Further more, this will also reduce the dependency of XRP to fund transactions.

The XRP Ledger will be serving more then 7.5+ billion people within countries that have different currencies, the XRP Ledger needs to be able to accept these different currencies to expand the usability of the XRP Ledger for international payments.

@JoelKatz @nbougalis @mDuo13 @intelliot @WietseWind

[intelliot]

It's an interesting idea. If there is liquidity in the DEX, then I think it's easier to understand (and easier technically) for the user to first trade the token for XRP, and then use XRP to pay for fees. The reason is that fees are minuscule.

Obviously, if fees were very high, then your proposal makes a lot of practical sense. But today, with fees at 10-12 drops, just 1 XRP is already enough to pay for ~80,000 transactions, making this a non-issue.

[WietseWind]

Thanks for sharing your idea @firefly3582!

Personally, with the low fees the XRPL is known for, plus the fact that fees can be paid for from the reserved amount of XRP (the 20 XRP account reserve can be spent on fees) makes this quite a significant change (e.g. exchange token to XRP, then to cover the fee, then to execute the rest of the transaction) for a problem that may not exist (?)

Another thought is that the list of trusted assets is a bit problematic. Who audits? Who trusts the audits? Where's the whitelist/blacklist? Who or what is in charge of that? It's hard to combine decentralization / an open ledger with something like this.

[wojake]

@intelliot,

Personally, with the low fees the XRPL is known for, plus the fact that fees can be paid for from the reserved amount of XRP (the 20 XRP account reserve can be spent on fees) makes this quite a significant change (e.g. exchange token to XRP, then to cover the fee, then to execute the rest of the transaction) for a problem that may not exist (?)

I think this idea is more onto the fact that the dependency of XRP is lowered for the average joe wanting to send $100 to Alice, yes, they could still use XRP to facilitate the transaction fees but they could use their own native CBDC for transaction fees. This idea is not intended to lower transaction fees.

Also, this new transaction type would be more expensive as what @WietseWind said:

(e.g. exchange token to XRP, then to cover the fee, then to execute the rest of the transaction) for a problem that may not exist(?)

for a problem that may not exist (?)

Well, the problem is not the fact that transaction fees being ridiculously expensive for the general public. This idea is to add more options for the general public/institutions to choose from when funding transactions, limiting transaction fees to only XRP is not that great when the people expect XRP-L/XRP to replace the traditional financial system

[MarkusTeufelberger]

This would just combine 2 transactions (the actual transaction and a sell order of a tiny amount of some random IOU, no need for audits or any weird "authorization process" - if it sells, it sells) into one. I suspect a lot of issues in the details (what if there is too much/too little delivered to cover the fee from the tiny trade, will transactions that use this mechanism be more expensive because they cause a lot more work to calculate and execute, what about transfer fees+pathfinding just to deliver a handful of drops...) with very little benefit, but it definitely could be emulated with 2 transactions for test purposes or just for convenience behind the scenes by a wallet application.

[wojake]

@MarkusTeufelberger Yup, it would combine 2 transactions into 1, this would increase the amount of resources needed to finalize in the XRP Ledger, so naturally, the cost of this transaction would be higher then your normal transaction.

The reason I included "authorization process" is due to liquidity and volatility concerns that may cause transaction errors if the token doesn't have enough liquidity in the native DeX. We don't actually need to verify anything, the authorization process would increase the liquidity which would make the feature work more efficiently

Also, this transaction was meant to allow the usage of other currencies as payment for transaction cost, we would still be needing XRP to create accounts, create orders, add trustlines and XRP is still needed in the native DeX to allow this feature to work.

In my opinion, the XRP Ledger needs to accept other currencies to allow for a more broader usage, not limited to XRP for the end user.

[MarkusTeufelberger]

I don't see how limiting the number of potential tokens would increase some liquidity measure. This proposal only removes (tiny amounts of) market depth and thus would reduce liquidity in all cases. Also volatility and liquidity are not of much concern, transactions are atomic after all. I forsee issues with how to fail such a transaction though in case the trade portion is very complex but failing ultimately.

As said, you can already emulate this since the ledger started and the fact that nobody seems to do it feels like an indication that this is not something that's actually in demand.