mDuo13
commented
4 years ago 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 1015 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
whotooktwarden
intelliot
kennyzlei
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
currencyobject (owned by that account) on the ledger that has the specific flags/settings. This would allow the following scenarios:McDollarand the currency code is nowMCD, 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.BTCthat must not be freezable, but I also want to issueEURthat 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_currencytransaction 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)?