Add on-ledger token/issued currency definition objects (controlled by issuers)

[MarkusTeufelberger]

Currently, most of the bits in currency codes are unused, which both makes them easier and harder to use. There was an early attempt to use some of these bits for encoding interest/demurrage (that never made it into rippled, only into upper layer software).

I'd like to propose that it should be possible for an issuing account to generate a currency object (owned by that account) on the ledger that has the specific flags/settings. This would allow the following scenarios:

• Gatehub fifth wants to de-list an asset and freeze all current and future trust lines towards them with that currency code.
• The US government decides that the US Dollar is now called McDollar and the currency code is now MCD, since McDonald's won a 20 year sponsorship contract. All trust lines need to be re-done and the gateway wants to offer a fee-less transfer for USD --> MCD conversion, but not for any other IOU.
• A gateway wants to encourage use of a certain IOU and offer lower fees there, compared to its other IOUs.
• I want to issue BTC that must not be freezable, but I also want to issue EUR that by whatever law must be freezable from my account.

The traditional advice is to create one issuing account per currency if these scenarios should be covered (https://developers.ripple.com/issuing-and-operational-addresses.html#multiple-issuing-addresses). This has not been followed in practice so far and has its challenges like user confusion and frustration - even just with 2 addresses owned by the same entity you can check out how many people put trust lines towards hot wallets instead of issuing accounts. There is also no real way to say that one account will ONLY issue a certain currency.
This leads to ledger spam and wasted time, money and nerves (user support...).

Instead imagine that it would be possible to do a create_currency transaction that tells everyone that my account now also wants to issue some IOU. This transaction would create a dedicated object on the ledger (with its hash being a https://developers.ripple.com/currency-formats.html#nonstandard-currency-codes) and in there could be a (longer!) human readable name of that asset, global freeze flags, transfer fee settings...

The exact details (how high should the owner reserve be, what flags need to be in there etc.) are to be discussed, I'd just like to know if this is in general something that could be implemented on XRPL in the medium term (say until 2019/2020)?

[mDuo13]

In the future, these Currency Definition objects could also define additional properties about how the issued currency works, which might be quite useful! For example, a couple options that would be quite appealing:

• Limited Supply - An optional setting defining a maximum amount of the currency that can be issued. Unlike the current option of blackholing the issuer, this would allow the total amount in circulation to fluctuate as long as it stays under the specified amount. Any transaction that would cause the issuer to owe more than this amount would fail with a path-dry error or something like that. Basically, like a trust limit, but on the sum of the issuer's lines rather than on any individual line.
• Discrete Units - An option that would make the issued currency use a fixed UInt64-based math (same as drops of XRP) rather than the custom big-decimal math that issued currencies currently use. This would make specific calculations easier to replicate in third-party software and would enforce a specific minimum-divisible size for the currency units. It would also prevent the rounding weirdness that occurs when trust lines of very different scales interact. (In the ledger today, "dust" amounts of issued currency can be effectively created or destroyed by rounding when two trust lines' scales are greater than 10¹⁵ apart...)

Note, I am not suggesting these features as requirements for the first pass of the "currency definition" object, but simply as extensions that would be easier to implement that way than they would to the existing AccountRoot-only model.

[MarkusTeufelberger]

David's idea of using price feeds as "stablecoins" (https://www.xrpchat.com/topic/33079-suggestion-xrp-collateralized-stablecoins/) would also be easier with this model I think, since issuer fee settings on these would/should likely be different than actual IOUs.

[whotooktwarden]

I would like to be able to issue an IOU with the granularity of the IOU set so that you may only purchase whole units of the IOU, no decimal amounts.

[mDuo13]

There are also several account-level settings that would make sense to be available as per-token settings that a currency definition (token definition?) object could override:

• TransferRate
• TickSize
• Require Auth (authorized trust lines)

Maybe even the Default Ripple setting could be per-token?

[MarkusTeufelberger]

Yes, there's about half a dozen settings that make more sense to be modifiable individually for each token/IOU/issuance/currency/...

I'm of course not married to the name, but the lack of this concept itself is something that's already caused issues and confusion in the past years.

[intelliot]

Someone in the community mentioned that this issue is a good candidate to be extended into an actual standard proposal. It could be a solution to standardizing asset icons and descriptions, similar to memos, instead of just an overloaded 160-bit currency code. Just food for thought

[mDuo13]

Another often requested feature for tokens that could be part of a token definition object is to have the transfer fees paid out to a specific address (similar to how that works for XLS-20 NFT transfer fees) rather than having transfer fees simply "canceled out" and erased from the ledger.

[intelliot]

@kennyzlei and team - when you have time, could you triage this?

[MarkusTeufelberger]

Also feel free to get in touch, in general I'd be willing to write or review a standard proposal, but I can't currently implement this in the code here.

[kennyzlei]

Hey @MarkusTeufelberger, appreciate the feature request you shared awhile back. I think there is value in having more token-level information and settings. While there may be various ways to solve for this capability, one potential solution is XLS-33d XRPLF/XRPL-Standards#109 that @ledhed2222 @sappenin @nbougalis are proposing. That proposal is a bit larger but would be curious to hear your thoughts on that approach and if it would be a good solution to the problem you're trying to solve

[MarkusTeufelberger]

Tl;dr: I don't view adding another alternative to the current objects as a solution to this issue.

Long version:
XLS-33 might be a nice redesign for XRPL 2.0 with lessons learned from the last 10 years. As long as the current system still exists however, offering a simplified solution for very similar use cases is a nice (and confusing) thing to have, but doesn't solve the issue with the fully featured system in place currently. There is also functionality missing (probably because it could be added via amendments later - but then, why not amend the current system?) such as changing the currency code or description and some omitted by design (such as rippling, issuing a larger amount of curencies than 32 per account, explicit opt-in to receiving something other than XRP).

Most of the changes in XLS-33 might even be possible to implement gradually through flags in currency objects (e.g. integer/decimal math instead of floating point per currency) instead of having to invent a completely new system. Already the difference between "Offers" and "NFTokenOffers" feels a bit... weird. In the future there might also be a different token type for these proposed "stablecoins" that are only defined by price tickers as fungible currencies. Or would they be implemented in the somewhat rippling-floatingpoint-acount-centric-but-fully-featured current system or as CFTs? Both? Issuer chooses? How to trade these then? XLS-33 feels more like yet another system and abandoning the existing one instead of fixing it to me and also the proposal doesn't touch on any other features than issuing, simple payment transactions, preauth and freezing. The real headaches start with escrow, checks, trades and payment channels (and in the future: AMM and stablecoins).

[kennyzlei]

@MarkusTeufelberger Gotcha, yeah I think your rationale seems reasonable. I currently am not aware of anyone else that is putting together a standards proposal around this, but I would definitely encourage you to put together your thoughts in a spec discussion here: https://github.com/XRPLF/XRPL-Standards/discussions. If you feel like you would want some guidance to support you in this process, I can potentially find some folks to help with that as well

[intelliot]

Most of the changes in XLS-33 might even be possible to implement gradually through flags in currency objects (e.g. integer/decimal math instead of floating point per currency) instead of having to invent a completely new system.

I like that idea. @MarkusTeufelberger , could you propose that in a discussion here?