Streamline native stellard currency format about stellar-protocol

[MonsieurNicolas]

If we're going to revisit this, we should also think about ways to have multiple authorities (aka namespace). For example, STR, BTC are not in the list of ISO currencies (which seems to be fiat only) - in theory a country could decide that they want to use this and not worry about conflicting with a lesser used/known one. This may have to be unified with issuers in a user friendly way.

[johansten]

If demurrage/interest rate is move to the account itself, then you'll probably end up with one issuing account for each currency, so no direct connection with the gateway account. And in that case, the issuer IS the currency.

Assume I'm a gateway and I issue credits with precious metals backing. Gold, Silver, Platinum, etc. What if the storage costs are different? Just based on specific gravity, silver would take more space, and would cost more to store.

Or what if I'm taking deposits of STR and issuing an interest bearing STR backed currency with a couple of different maturities?

[irisli]

Yeah, I talked to Jed about this and I realized that it is better to keep the demurrage information inside a currency code.

What would end up happening is that a few characters of the 160-bit currency code is for the currency code itself and then a timestamp (or anything else, this is all arbitrary) can be stored in the currency to signify when this precious metal was first released. This would put the burden of calculating demurrage on the client and rather stellard (which should remain as light as possible).

[johansten]

I just though of this, but one more reason not to, is that it leaves the issuer free to change the interest rate/demurrage at will.

[jedmccaleb]

johansten: well you could make it where they could only set it once. but probably better to put it in the currency code.

[jedmccaleb]

no longer applies