<p>Currently, only three-letter currencies that exist as IOUs can be created as a custom currency. And if someone else uses that same three-letter identifier for something else, each account can only transact in one of those conflicting currencies. So you could use "XBR" to mean people owe each other beers and you could use the ripple system to track how many beers you owe people or they owe you. You could accept payment in beers.</p>

<p>There are plans to introduce more customized currencies. There are some things you can't do without some specialization. For example, charging a storage fee as some gold storage agents would like to do. This is still in the design stages.</p>

<p>You can, of course, create IOUs denominated in any currency, subject only the what other people are willing to take. But if you want to create two accounts and have one owe the other $1,000,000, you can.</p>

CC BY-SA 3.0
2013-02-12T09:51:40.943Z
That's kind of a big limitation.
David
CC BY-SA 3.0
2013-02-12T10:25:38.687Z
@David: If you can be more specific about what you see as a limitation and why, that might have an affect on the implementation schedule. One of the things holding up custom currencies is that lack of good use cases. (Currently, demurrage is about the only use case.)
David Schwartz
CC BY-SA 3.0
2013-02-12T14:00:50.710Z
I'd say the currency code should reflect who issued the IOU, because otherwise it's going to be confusing to have EUR in your account and have to open a second account to deal with EUR IOUs issued by a different gateway. Did I misunderstand something ?
David
CC BY-SA 3.0
2013-02-12T14:33:09.240Z
So long they both represent the same currency, there's no problem. The problem would be if someone else used `EUR` to represent grams of europium. ;) The issue is that all `EUR` IOUs that you personally issue are indistinguishable and you'd have no good way to handle the changing exchange rates between the two different metrics.
David Schwartz
CC BY-SA 3.0
2013-02-12T20:31:11.570Z
I guess that would require a separate question, but how do you distinguish IOUs denominated in the same currency but issued by different gateways ?
David
CC BY-SA 3.0
2013-02-13T23:06:27.893Z
By the issuing account public key/address
jtimon
CC BY-SA 3.0
2013-02-14T02:40:07.540Z
@David: If you mean in the system, when one account extends trust to another, a node is created in the ledger for the triple of the two accounts and the currency. When we say "Jeff holds $50 in Jack IOUs", what happens in the system is the "Jeff/Jack/USD" node holds a balance of $50 in favor of Jeff. If you mean in the client, I don't think it does a good job yet of letting you easily work with IOUs from multiple issuers in the same currency. There's still a lot of "inherent complexity" that the client hides.
David Schwartz
CC BY-SA 3.0
2013-02-11T14:33:53.457Z
2013-02-11T15:17:15.330Z
2013-02-11T15:17:15.330Z
David Schwartz
<p>Does <a href="https://ripple.com/">Ripple</a> allow one to issue their own currency, similar to how ripples (XRP) were created at the system's inception?</p>

<money-supply><currencies><ripple>
Does Ripple allow one to issue their own currency?
ThePiachu
# Does Ripple allow one to issue their own currency?

(Asked by: username_0 on 2013-02-11)

Does [Ripple](https://ripple.com/) allow one to issue their own currency, similar to how ripples (XRP) were created at the system's inception?

**Tags:** money-supply, currencies, ripple


---

## 1 answers

### Answer by username_1 on 2013-02-11. Score: 5

Currently, only three-letter currencies that exist as IOUs can be created as a custom currency. And if someone else uses that same three-letter identifier for something else, each account can only transact in one of those conflicting currencies. So you could use "XBR" to mean people owe each other beers and you could use the ripple system to track how many beers you owe people or they owe you. You could accept payment in beers.

There are plans to introduce more customized currencies. There are some things you can't do without some specialization. For example, charging a storage fee as some gold storage agents would like to do. This is still in the design stages.

You can, of course, create IOUs denominated in any currency, subject only the what other people are willing to take. But if you want to create two accounts and have one owe the other $1,000,000, you can.

> **Comments:**
> **username_2**: That's kind of a big limitation.  
> **username_1**: @username_2: If you can be more specific about what you see as a limitation and why, that might have an affect on the implementation schedule. One of the things holding up custom currencies is that lack of good use cases. (Currently, demurrage is about the only use case.)  
> **username_2**: I'd say the currency code should reflect who issued the IOU, because otherwise it's going to be confusing to have EUR in your account and have to open a second account to deal with EUR IOUs issued by a different gateway. Did I misunderstand something ?  
> **username_1**: So long they both represent the same currency, there's no problem. The problem would be if someone else used `EUR` to represent grams of europium. ;) The issue is that all `EUR` IOUs that you personally issue are indistinguishable and you'd have no good way to handle the changing exchange rates between the two different metrics.  
> **username_2**: I guess that would require a separate question, but how do you distinguish IOUs denominated in the same currency but issued by different gateways ?  
> **username_3**: By the issuing account public key/address  
> **username_1**: @username_2: If you mean in the system, when one account extends trust to another, a node is created in the ledger for the triple of the two accounts and the currency. When we say "Jeff holds $50 in Jack IOUs", what happens in the system is the "Jeff/Jack/USD" node holds a balance of $50 in favor of Jeff. If you mean in the client, I don't think it does a good job yet of letting you easily work with IOUs from multiple issuers in the same currency. There's still a lot of "inherent complexity" that the client hides.  

---

