Projects‎ > ‎Current Projects‎ > ‎

DIY Electronic Currency


Design the infrastructure to support the issue exchange of unlimited numbers private electronic currencies, then provide a partial implementation. Privately issued currency is not new. They were common in Australia before 1910 being first issued in the form of promissory notes by traders and later by banks. You can issue private commodity currency today in the form of a personal cheque but it is difficult to circulate cheques because it is hard for the recipient to determine whether it is redeemable. A properly designed electronic system can provide the mechanism for determining the value of an unlimited number of currencies. 

See the google repository page for this project and some background information.

Why Do We Need DIY Electronic Currency?

Online commerce is currently supported by a variety of transaction systems some of the most well known being Visa, Paypal, Linden Dollars (Second Life) and e-gold. They all require that transactions take place via a central authority, all are supported by taxing transactions and they issue private electronic commodity currency. Commodity currency comes with a promise it will be exchanged for some commodity of value by the issuer. For Paypal credits and Visa the commodity is one of several national currencies, for e-gold it is physical gold and for Linden dollars it is rent of virtual Second Life land. Users may not have the payment method requested by the merchant and exchanging funds between the systems is a manual and often difficult process. The credibility of each currency is dependant on the reputation of the issuer and fees are high, usually 2-3 % because customers want to use widely accepted payment methods and the switching costs are high. Seigniorage profits accrue to the issuer because the commodity currency is created at no cost to the issuer and exchanged with the purchaser for something of value. This can be significant with the bulk of the revenue for Second Life being obtained this way as the number of Second Life users has rapidly increased. Seigniorage can be particularly expensive for users where they are required to maintain balances in multiple payment systems. The shortcomings listed above can be circumvented by privately issued electronic commodity currencies that anyone can issue and exchange amongst themselves without requiring third parties.

How Could A Decentralised Private Commodity Currency System Work?

This is mostly the same but the current concept of using x.509 certificates alters some of the logic described here.

  • A creates a token with a unique identifier and appoints a registrar. A is certified to be A by a trusted party e.g. Verisign. 
  • A purchases a service from B and offers the token. 
  • B determines value of the token with an exchange service. B checks token is original and not a copy with the registrar. B accepts the token from A who signs the x509 certificate created by B and returns it to B. 
  • B sends the token to the registrar who can see it was signed by A from the public key. Registrar now shows the current owner of the token is the holder of the secret key for the certificate signed by A (which is B).
  • B purchases a service from C and pays with the token. C is concerned the value of currency issued by A may decline so C exchanges the token for a currency C trusts with an exchange service who profits from the service by maintaining a buy/sell spread.
  • The exchange service is also concerned about the stability of tokens from A so exchanges the token with another exchange service for a token it trusts.
  • This second exchange service can safely purchase the tokens issued by A valued at an amount nominated by A in Australian dollars up to the value of the balance of A’s bank account at Westpac because A has provided this exchange service direct debit access to A’s account. The tokens are returned to A in exchange for money from A’s bank account transferred to the exchange service account.
  • If A has a good reputation, holders of A’s currency will avoid the exchange fees by keeping them until they wish to spend thereby lowering transaction costs. A will then be able to issue more currency than can be exchanged at A’s bank confident in the knowledge that it will never be returned for exchange. If A’s reputation declines or A issues too much currency A’s currency will suffer inflation.

Using a hierarchy of X509 Certificates To Pass Value


 X509 certificates are a method of associating a common name with a public key. They are hierarchical with each issuer certifying the level below. They are widely used, commonly for certifying that a website is run by the organisation it purports to be.

An X509 certificate can be used a value token. The upper levels of the hierarchy certify the issuer is who they claim to be. The X509 certificate representing the value token is passed to another by signing a certificate for a new holder using the private key of the previous holder. A registrar is used to avoid double spending.

Token Structure

This is an x509 certificate with a:-

  1. Token Type = Identifier for this token type which is unique for this issuer e.g MobileMinutes.
  2. Token code = Short form identifier for this token type e.g. MM
  3. Quantity = How many of token type does this token represent. e.g 10 MobileMinutes
  4. Redeemer = URL where value of token is declared and redemption facilitated. There could be more than one.
  5. Registrar = URL where register of current holder is maintained. There can be only one of these. Needed to avoid double spending.Includes.
  6. Exchanger = Optional recommended exchanger services. Can be more than one.
  • Token type is uniquely defined by combination of token type attribute and issuer public key.
  • Token is uniquely defined by combination of Token Type and serial number.
  • Token is signed using an issuer certificate as a CA and the token credibility is determined by the issuer certificate credibility and the associated credibility of the issuer. Alternatively token credibility can be established by a credible redeemer promising to redeem a token issued by a particular issuer. 
  • An issuer certificate is the normal x.509 identity certificate which may have a token issuer field added and which has a common name (CN) field with a URL linking to information on the issuer. The identity in the issuer certificate can be certified by a credible certificate authority e.g. Verisign 
  • Issuer public key can be associated with an issuer comon name by a credible certificate authority e.g. Verisign.
  • The full certificate chain needs to be passed each time the token is passed so the next recipient can be certain that a registrar did not ever revert to a previous holder. The registrar makes visible an attempt by a token holder to double spend and passing the full chain makes visible an attempt by the registrar to roll back ownership to a previous holder.


Issuer: The token itself says nothing about the value of token. The value can be defined by a signed statement at the URL of the issuer but doesn't need to be. The issuer promises to redeem the token for a commodity and is ultimately responsible for honouring the token. Other parties are representatives of the issuer. If they fail the issuer is ultimately responsible to the holder. The value of the token may be floating and the willingness of an holder to hold it will depend on the reputation of the issuer. The issuer may appoint a third party to monitor the registrar to keep track of most recent holder. An issuer that isn't trusted could still present trusted tokens where the new holder gets a quote from a trusted redeemer so that the holder relies on the reputation of the redeemer. 

Registrar: A registrar is needed to prevent double spending. A token offerree checks with the registrar who currently owns it and becomes the holder when they possess a copy of the token and the registrar shows that the current holder is their x509 certificate. Double spending can only be initiated by a previous holder. The registrar checks this is not happening. The registrar has a minimal role.

An enquiry of token on the registrar returns the X509 certificate of current holder signed by the registrar. An update of token on the registrar is registered when a valid x509 certificate is provided, signed with the private key of the previous holder. The registrar can charge a fee.

Redeemer: Is the representative of the issuer who provides the administrative function of redeeming the token for the issuer. An holder may have more trust in the redeemer than the issuer. Generally a token will have no value unless it can be redeemed for a commodity which could be anything e.g. mobile phone minutes US$ paid to a bank account or gold. Redeeming may be a burdensome process. The redeemer can change the redemption value at any time. The redeemer should advertise the commodity value and procedure for redemption and be willing to provide a quote guaranteed by the redeemer to a holder or potential holder that would allow the holder to redeem the token for a fixed quantity of commodity for a fixed time so that the purchaser can accept a token that is effectively guaranteed by the redeemer. The redeemer can reserve an amount of the commodity previously provided by the issuer to avoid risk. The redeemer can not make an open ended offer as there is no way to know the quantity of tokens issued. The redeemer should monitor registrar for X509 certificate of current holder on behalf of issuer in case the registrar fails and then accept tokens that have ever been shown to be current by the registrar.

Exchanger: Provides a service exchanging one token for another for a fee. Not formally part of the system but outsources the problem of valuing and acquiring correct tokens. A person would normally work through one or several exchangers who would exchange the tokens they have for whatever they want. The exchanger would provide a quote on all the tokens their customer owns and exchange tokens with other exchangers to get the tokens they need for their customers or offload those they do not want. A holder then does not have to deal directly with redeemers. Tokens can potentially circulate for a long time prior to redemption.

Transaction Process

  1. Seller makes an offer with price expressed in some token type. Seller can advertise exchanger who will provide tokens.
  2. Buyer acquires token type required by seller from their favourite exchanger who may get it from elsewhere.
  3. Buyer provides copy of tokens.
  4. Seller verifies validity of tokens offered, accepts or rejects them and if accepted provides x509 certificate for signing by the buyer. Buyer signs certificate provide by seller and returns certificate to seller. Buyer or seller updates token with registrar.
  5. Buyer transfers tokens by adding new holders x509 certificate and updating to registrar, then notifying seller.
  6. Seller checks with registrar they own tokens and transfer is complete.

Failure Modes and Solutions

Issuer fails to honour: Loss to holder. The issuer is ultimately responsible and the holder has to trust either the redeemer or the issuer to get value.

Holder loses private key of X509 certificate: Token can not be redeemed.

Holder transfers tokens but new holder not aware: Token can not be redeemed.

Registrar shows previous holder as current holder: In this case a seller could inadvertently accept a token that is already owned by another. This token can only be offered by the holder shown by the registrar who would have to collude with the registrar to double spend. The certificate of ownership provided by the registrar to the new holder is the proof for the holder that the registrar failed in their duty.

Registrar fails to respond: The redeemer should have a record of the most recent holder but this could have been superseded before the redeemer found out. After a suitable delay (maybe 2 days) in which the registrar failed to respond redeemer accepts token from last known holder or new later holder if one is presented. Registrar can not be replaced as there is then the possibility of double spending. Tokens are ultimately still redeemable.

Redeemer purports to redeem but fails to deliver: Holder seeks assistance from issuer. In general do not accept tokens with untrustworthy redeemers.

Redeemer fails to redeem (perhaps out of business): Issuer can appoint a new redeemer and advise at URL of issuer.

Example token and holder certificates


  • February, 2nd 2008
    1. Discuss the system plans and the modules involved therewith.
    2. Who will act as a guarantee provider for the currency? This is imperative, as trust is a crucial aspect of the exchange of currency. Ans: There are unlimited currencies and the issuer of each one is responsible for guaranteeing it.
    3. What benefits are enjoyed by the guarantee provider? No institution would agree to to be the guarantee provider without any form of reward. Ans. The guarantee is provided by the issuer who gains the benefits of being an issuer. All other service providers e.g. exchanger, registrar will charge a fee. None of these providers is irreplaceable.
    4. Who can be the guarantee provider? A few suggestions brought up are banks, authority figures and powerful nations. Ans. The issuer guarantees the currency.