Category: openmoney

Open Money Foundation update and logo

The Open Money Foundation is gathering interest.

I’ve discussed the idea to a variety of people in the last few weeks, ranging from virtual world developers to Web developers, community currency activists and gold currency advocates, and there is a strong agreement towards a very focused and simple goal of currency services interoperability.

This simple goal has to be viewed as a first and necessary step to realize the larger vision of Open Money or free currencies. In particular for community currencies, another cornerstone are economically-driven adoption models such as Community Way.

Open Money Foundation mission

In a nutshell, Open Money Foundation should define the OpenID of currency services:

Open Money = a set of open interface specifications designed for adoption that governs the interoperability between independent currency services and client applications.

Note that this is not restricted to community currencies currencies. We think World of Warcraft virtual gold coins, phone airtime minutes, digital gold currencies, Linden dollars or any virtual currency can benefit from this interoperability. Conversely, we think that community currencies will benefit from the participation of virtual/game/alternate currency providers.

A currency service that complies with Open Money Foundation specifications will enable the following benefits for end-users:

  • automatic discovery of currency services on the Internet.
  • one click currency registration request: users will be able to very easily request to join a currency service from their favorite currency application (“wallet”?).
  • single view of all currency balances: users will be able to view all their balances at various currency service from their favorite Open Money-compliant currency app.
  • transacting on any currency service from any Open Money compliant app.
  • starting a new currency on an existing currency service will be as easy as starting a group on Facebook (this is specific to credit currencies such as community currencies)
  • and more.

The goal of these specifications isn’t to re-invent the wheel. There are many open specifications to leverage to address some of the problems above (OpenID, OpenSocial, OAuth, OFX) and some currency systems already leverage these.

An important aspect of the suggested focus is to not focus on implementation but only on interfaces. In the case of a currency service, implementation is for instance how creditworthiness and credit limits are determined, or whether interest or fees are charged. An interface is simply: how do I request to the currency service a demand for credit. There are many advantages to focus on interfaces not implementation:

  • We don’t get into the philosophical discussions of what is a currency, what are its characteristics, etc.
  • We can each focus on our area of expertise: some on client applications that make it easy for users to use the currency, some on server scalability, some on currency design, etc.
  • We leave an opportunity for implementers to differentiate themselves and address various community requirements, either as a generic platform with a currency definition language or as an ad-hoc currency service for a specific community, either as a not-for-profit, or for profit.

Besides offering a forum for the development of these specifications, the Open Money Foundation will channel funding for the development of an open source reference implementation that everyone can at least use to test their own implementation, or build upon.

I’m looking forward for feedback on this topic. If you like these goals and are interested to participate in a way or another, please comment.

Open Money Foundation logo

Here’s a possible logo I’ve been working on several WEs ago.

Open Money Foundation logo

Thoughts on a Twitter Time Bank with multi-currency support

Today, Eiso Kant, the co-founder of Twollars announced that he had been working lately on a multi-currency version of Twollars, and that “soon everyone can start their own currency on Twitter”. This could be an interesting development for Twollars, which have so far acted as a multiplier and allocator of the generosity of the sponsors US dollars donations: Twollars are backed by commitment of sponsors to donate real US dollars to the charity of the donator’s choice (the first $1,000 was sponsored by Eisomac Ltd, the creator of Twollars themselves, and it seems they are now looking for a new sponsor for the next $10,000).

We will have to wait until more details emerge, as there are many different ways a multi-currency platform could be implemented.

In the meantime, I’d like to share some thoughts on the concept of a Twitter Time Bank, something I’ve been thinking about in the last few days.

Overview

The goal of the Twitter Time Bank is to allow people to bring the reality to the idea that “time is money”, and allow anyone to issue their own time-based money they can use to pay others for products/services or to donate to others.

Here is an example of how it would work:

“(from @glebleu) give @receiver 1 hr for …” would give the receiver the right to schedule 1 hour of my time with him/her/them, through an operation called “redeeming”. Alternatively, they could transfer the time/money I gave him/her/them to someone else via the following Tweet: “(from @receiver1) give @receiver2 1 @glebleu hr for …” (receiver1 gives one hour of glebleu to receiver2).

Give syntax

Anyone is free to give their own time money to anyone else they want for whatever reason they want. They can give as much as they want (but there is an obvious limit, as each person’s time is limited). Anyone is also free to transfer other people’s time money they received to someone else. Here is the syntax:

Short syntax (@giver = @issuer) “give @receiver 5 hr ….”  or  “give @receiver 10 mn …”

Long syntax (@giver <> @ issuer) “give @receiver 5 @issuer hr” or “give @receiver 10 @issuer mn”

units supported: hr or mn

Accept syntax

Although you are free to give your time money to anyone for something, they are also free to acknowledge it or reject it. Acknowledgment would be done via the following Twitter syntax:

Short syntax: (@issuer = @giver) “accept 1 @giverissuer hr for …”

Long syntax: (@issuer <> @giver) “accept 1 @giver hr from @issuer for …”

Creating fungibility with community currencies

“Fungibility is the property of a good or a commodity whose individual units are capable of mutual substitution.”

Personal time money is hard to get accepted, obviously. With the above scheme, each time you are given some time money, you need to review the issuer for the value of his/her time to you and his/her creditworthiness.

To make personal time money useful, we need to make it fungible, but obviously all people’s time is not fungible. It is only within specific groups/communities that it may be.

To create mutual substitution, we need to allow people to spontaneously mutually agree to make their time money substitutable with one another. This agreement is a currency. In Twitter terms, @user1, @user2, etc. create a community whose currency is for instance called #bernal (say for the Bernal Heights neighborhood in San Francisco to support neighborhood “barn raising” events). In the community currency configuration, the community admin can decide:

  • how people can be accepted in the community (ex. unanimous vote, cooptation from a minimum number of existing community members, verification of affiliation, etc.)
  • the limit on each community members’ un-redeemed issued time.
  • whether the currency can be sold for US$ to highest bidder (note that there is no way to prevent it from happening, so it’s better for the process of buying/selling currency for US$ to happen in a way that can be tracked and users protected from theft).

Once this is set up,  community members can issue community currency backed by their own personal time money. For instance, if I’m a member of #bernal, when I tweet “give @receiver 1 #bernal hr for…”, I automatically have an additional @glebleu hr that is accounted for in my un-redeemed issued time. If I exceed the personal issuing limit set for my community, the issuance is rejected (the received can’t accept it).

Web service

A Web service would provide a Web version of give and accept actions, as well as the following actions:

  • reports:
    • un-redeemed issued time,
    • un-redeemed (but scheduled) issued time,
    • total redeemed issued time
  • search profiles of people that you can redeem your personal money or community currency with
  • request redemption (schedule time & location, or redeem for US$)
  • confirm redemption
  • bid in US$ for redeemable personal time money or community currency
  • personal profile/preferences
    • auto-accept given money (default is no for personal time money, can be configured on a per community currency basis)
    • authorize personal time money issued to be sold for US$ to highest bidder (default is no, but there is no real way to prevent it to happen)
    • community currencies joined
    • schedule w/ booked time.
    • geo location, services/products provided for 1 hr, delivery (F2F, online), etc.

Business Model

The business model would quite simply to take a % of the time money sold for US$ (the system would allow users to prevent their issued time money to be put up for sale in US$ if they’d like to).

What a personal data currency may look like

I was challenged tonight in an email to explore where VRM and Open Money concepts may intersect.

Here are my notes:

  • To make personal data a currency, you would have to issue redeemable promises to deliver personal data to anyone “holding” the promise, say your location.
  • You may want to assign circulation rules to your currency so that it has no value outside of your social network (and you don’t end up being stalked by strangers).
  • Until redeemed by you the issuer, the currency could be exchanged for goods/services.
  • After redeeming the promise i.e. obtaining the data from the currency issuer, the promise would no longer have any value.
  • To have significant value, the currency would have to be issued by you (and ideally, certified by other parties).
  • You may want to provide foreign exchange services.

Of course, I haven’t answered the key question yet: why anyone would want to make their personal data a currency.

The need for an Open Money Foundation

I’ve discussed this topic with Michael Linton and Marc Armstrong this WE.

Problem: community currencies are a $0 Billion market and promoting their development in a way that ensures and maximizes their potential for communities is expensive. Examples include travel costs or Web hosting costs. Today, although many parties are interested in the development of community currencies, there is no organization that represent their common interests that is able to officially receive donations for interested parties. These common interests today are mostly public awareness and technology interoperability, but will eventually include – should we be successful – right to exist under rules dictated by the government of each nation where these currencies are used.

Solution: we formalize Open Money into an Open Money Foundation, a non-profit dedicated to ensuring and maximizing the potential of community currencies. We use Community Way to raise money: corporate sponsors that may include telcos, computer manufacturers, airlines, etc. These companies donate to the foundation their excess capacity in the forms of consumer coupons/vouchers (ex. voice minutes, bandwidth, computers, offices, miles, etc.) and the foundation uses these donations to finance its mission either by directly using them, or by reselling them for the currency needed.

What community currency networks we learn from barter networks

Barter networks such as ITEX, BarterCard or IMS are very poorly understood systems. The word “barter” conjures archaic, depression- or war- era visions of people swapping food for medical supplies.

In reality, these systems are membership-only closed networks or clubs where small to medium business (typically less than 50 employees) trade their surplus capacity using a currency that is proprietary to each network (most businesses do not operate at full capacity, for instance, many hotels operate at 60% occupancy rate). These small businesses could include a florist, Web site designer or lawyer.

Instead of trading with, say, U.S. dollars and having to sell their products/services at huge discounts (in buying power) in the open marketplace, they trade with ITEX credits or BarterCard credits, which can only be earned by selling to another business or the network, and can only be redeemed for goods/services from another merchant in the network. The result for participating businesses is that they keep their buying power, but from a limited set of businesses: same buying power with less choice.

These networks work almost conversely to the national money-based marketplace we are all familiar with. In our marketplace, money is relatively more scarce than the people who accept it. In a barter network, people who accept the club-only money are relatively more scarce than the money, which gives essentially artificial demand (compared to the actual demand on the open marketplace) for their unsold products/services. For instance, some members drive 100 miles to buy wine from another member, simply because they have credits they earned and that member accepts their credits.

The functions of the operators of these networks are interesting:

  • supply/demand monitoring and balancing: when a business applies for membership, their business is reviewed for relevance. Obviously, you don’t want to have too many businesses providing the same goods/services, since it would defeat the advantage of a membership-only marketplace.
  • credit allocation. Depending on the network’s rules, the member may have to earn credits before it can spend them, or it may be able to get a certain quantity of credits just based on the relevance of their business to the network, i.e. expected demand for their goods/services.  So, a business with very relevant offering gets credit, while one whose business is already overrepresented may not or may get a smaller credit. In some networks, the actual creditworthiness of the business as measured by credit bureaus might be a factor as well.
  • debt collection. If a member leaves, debts may be seeked using standard legal debt collection procedures (in national currency this time).
  • risk management. In some cases, a member goes out of business with a negative balance. To compensate for these losses, the trade network will typically tax all members a small fee on a regular basis, in the propriety currency, not national currency.
  • banking. The network needs to keep track of accounts, credit extended, as well as provide various ways for members to use their balance (check, online, mobile, etc.). The network also generates tax filing reports (barter transactions are taxable in the US via form 1099-B). There is typically no foreign exchange service provided (exchange of trade dollars for national money) and no interest earned/charged on positive/negative balances.

I’m not saying that barter networks are the panacea. I think they serve the need of their members, but most importantly or their shareholders. In contracts, community currencies server the purpose of their community: neighborhood, social network, etc. Yet, there are several things that community currency systems can learn from these barter networks:

  1. Self-sustainability. A closed community with a proprietary monetary system can sustain only if the system is self-sufficient. The system has to be thought as a self-sustaining ecosystem, and great care must be placed on the participants encouraged to join so that not a single category is over-represented, and so the currency circulates. (Similarly, an open community with its own monetary system that would offer convertibility to other currencies must have balanced flows of goods/services (trade balance) with other communities using other currencies, or will risk a run on its currency: trade matters.)
  2. Fault-tolerant credit system. A credit bureau and a loss pool is probably necessary if the network is quite large. The credit bureau is a pre-emptive tool, and the loss pool is just a practical answer to the reality of business cycles.
  3. Strong debt fulfillment incentives. Debt collection is a problem in a community currency, and IMO this can only be solved by making membership something valuable enough to the member that it would do anything possible to not default on its debt. This can be achieved by making membership socially desirable to members i.e. something they can use to advance their status within their society. The stronger the incentives, and the lower the debt default risk, the stronger the currency.
  4. Reliable and secure operational infrastructure.

Using CommunityWay to save a local community service in San Francisco

Like many community services, Access SF, San Francisco public access station might close its doors because of a $500K budget cut.

I think Community Way might be a good model for them to raise these $500K. Here is how it would work:

  1. Access SF issues Access SF dollars.we could also call them vouchers or coupons
  2. Access SF negotiates with local businesses to get Access SF dollars accepted as payment for part of what is owned by customers. For instance: a local restaurant would accept 10% payment of the bill in Access SF dollars. Access SF explains that they will advertise Access SF dollars benefit on their channel and Web site, which will attract new business.
  3. Access SF sells Access SF dollars to SF residents on their Web site and at their office. These US dollars are used to fund the $500K.

Local businesses get advertising. Local residents get to support a community service without losing purchasing power. The community service gets its real dollars.

If Access SF sells $50 worth of Access SF dollars on average to 10,000 local residents, they’d get their $500K.