I've been doing some thinking about "local currencies" (a.k.a. "community currencies" or "complementary currencies") and how cryptocurrencies might be able to make these projects easier. These sorts of currencies exist as a way to encourage funds to circulate locally, helping foster community engagement and small businesses in the area to grow.

Local Currencies

A few examples of such currencies that already exist are the Bristol Pound, Brixton Pound, and several others. The community of Hull created HullCoin as a cryptocurrency-based local currency, though it is its own proof-of-work, mined cryptocurrency, so non-local people can earn it, and add more into circulation.

Though there are some questions as to how much of a benefit these currencies have; they're mean to encourage local trade, but they should not restrict non-local trade in the process (which would be putting an economic sanction on yourself, which is not viewed as a blessing ^ref).

In order for a local currencies to have an effect, there needs to be some incentive for people to use it. Many community currencies seem to be bootstrapped by the local government either allowing or requiring that municipal taxes and fees be paid in the local currencies. Some business that accept the community currency may give a discount if you pay in it (either just to be altruistic and support the local currencies, or as a trickle-down of cost savings for the business in not needing to pay shipping costs to send their product further away, or from the savings they get from buying locally from the vendors they as a business use).

A key benefit some of the existing community currency sites claim is to have a better fee for electronic payments. Compared to credit card or PayPal transactions, local currencies can set a lower fee to be more competitive compared to those other traditional payment means.

Local Exchange

A similar system is a "Local Exchange Trading System" (LETS), where people trade services with each other. Each service is given a "credit amount" of some sort, and individual members offer and bid on those services adjusting their credits. The Simbi online service seems to be a variant of this, with their "Simbi credits" serving as the intermediary credit tracking system. These sorts of systems are like bartering (directly exchanging goods or services that both parties hold to be equal in value), but it allows for daisy-chaining trades together (Alice has A and wants B, Bob has B and wants C, Carol has C and wants A. Alice trades her A to Carol and gets C. Alice doesn't want C, she only got it so now she can trade C to Bob for his B, which she does want) without needing all parties present and agreeing to one trade, since there's an intermediary monetary credit in play, with the understanding that the intermediary credit can only be spent within the system.

Use existing?

So why not just use an existing cryptocurrency like Bitcoin or Ethereum? Both those established cryptocurrencies have lower fees than credit card processors. However, they then don't have the ability to restrict usage to a local area. If many businesses in a downtown area all decide to start accepting bitcoin in payment, it doesn't restrict those businesses from using the bitcoin they acquire from customers from using it globally, defeating the idea of community focus.

So why not make your own cryptocurrency? With these sorts of community-focused systems, they rely heavily on the community involvement and being altruistic in order for it to thrive. A business solely looking to maximize profits likely would be able to find cheaper wholesalers outside the community, and individuals who value flexibility in their funds wouldn't want to lock their currency into "gift cards" only available at certain stores rather than all. Launching an entire cryptocurrency (as HullCoin is) requires dealing with bad actors and has to be built from the ground up assuming there will be attackers and those looking to exploit the system, and being decentralized, it would need to self-defend itself.

These sort of community projects benefit from centralization (if the local government manages it and enforces off-chain benefits), so seems to be a good fit for an Ethereum token. Ethereum as a protocol handles the bad-actor and network infrastructure management.

What to build?

So, how best can a community leverage Ethereum's Smart Contract technology to get the most benefit of a local currency, with the minimum amount of custom work (since if City A and City B both want to create a local currency, it would be great to have them be able to share code/methods and not have each city have to reinvent the wheel each time)?

Individual currencies

One option would be for each City who wanted to create a local currency could simply create their own ERC20 token, where the municipality has ownership over the token and its issuance. There's then no need for control over movement of the tokens as each city's membership only accepts their city's currency.

However, this does not prevent users from swapping City A tokens for City B tokens, or City A tokens for ether or other assets. So the restriction on moving currency out of the city couldn't be enforced. But probably the only outside users who'd want to make such a swap would be those who did business in that city (otherwise why trade away ether for City A tokens if you don't have a place to spend them), unless it became an investment opportunity; people who thought a given city might grow in the near future could purchase City A tokens and hold them, thinking they'll grow in value, and eventually sell them for ether, never having done any transactions in the city locally at all. So this sort of setup could help cities raise outside funding, but it could also put smaller cities at a disadvantage to bigger cities (City A tokens would be worth less than City B tokens if City A is a lot smaller than City B and has less businesses/locations where City A tokens could be spent).

Global HOURS token

Using the "Local Exchange" idea as a basis, one other option is to have one global token that represents an "unassigned" credit that's worth one hour of time. Cities that want to implement a local exchange would create a new smart contract that represents their municipality's government, which would allow users to deposit ("stake") their HOURS into that city. Once in the city, users could transfer HOURS between members of that same city.

Cities could make it impossible to un-stake HOURS once staked (like a gift card, once designated for a specific purpose, you can't "cash it out"), or could allow them to become withdrawn at a loss (e.g. 30% of the HOURS are donated to the city if you want to move that currency back outside the city), or the Cities themselves could serve as exchanges for users who wish to cash out into ether (at whatever ratio the city chooses to set).

Cities themselves, as the likely final stop for a local currency (paying city taxes/dues/fees, etc.) should be allowed to cash out HOURS into ether, but not average citizens.

So how would that be enforced? HOURS in this scenario could not be a standard ERC20 token, since we would need to restrict citizens from being able to transfer it among themselves (which would allow exchanging/selling for other assets), but Cities need to. Instead, there would need to be a membership/shareholder contract paired with the HOURS token contract, and if an address wishes to transfer HOURS, either the source needs to be a member (the transaction is a city making a withdrawal) or the destination needs to be a member (the transaction is a citizen staking HOURS into a city contract). There would need to be some governance model on top of the HOURS membership list to allow new cities to join and be approved by the existing members.

The "City" contracts would be similar to ERC20 token contracts in that they would keep track of the asset allocations for each address, and provide the same methods for moving tokens around. These transfer methods would not be restricted, so members could transfer credit between themselves. The city contracts would need an additional deposit method, which would trigger a transferFrom action on the main HOURS contract, moving HOURS tokens from the citizen to the city, but then the citizen address gets credit at the city contract in the same value.

The question then becomes where do HOURS tokens come from in the first place? In a "Local Exchange" setup, a user doing work (volunteering) causes credit to be generated. But in this setup, that would mean two citizens in a city would be able to create City-HOUR credits and hand them to each other. Would these then be backed by real HOURS tokens? Looking at the Simbi community, instead of new tokens being brought into existence when a user provides a service (does work), all transactions are moving Simbi tokens from provider to recipient. All new users get a pool of tokens to start with, and Simbi as a parent entity provides bonus tokens for doing certain actions. Using that model, it would mean that Cities when they join the HOURS community would get a pot of HOURS generated for them, which would belong to them as City-HOUR credits in their own contract. The city could then dispense those credits however they wish (new members doing some action off-chain to join the system could be gifted some amount, or could accept ether or other on-chain assets in exchange for City-HOUR credits). The membership governance of the HOURS token would then be in charge of monitoring the token supply and would have power to mint new tokens into existence.

In this situation, should anyone be able to pay ether (or other on-chain assets) to buy HOURS (creating new HOURS to feed into the system)? Since City contracts are able to transfer HOURS (as well as City-HOUR credits) out to anyone, they could accept an ether donation from some investor, and in turn grant them City-HOUR credits at that city, or if they advertised that they were willing to sell HOURS at a certain ether rate, someone could buy the HOURS credits (the city sending the HOURS to the buyer would un-stake them from their city) and the city receive ether it could do what it wanted with.

So, citizens of a city need to first acquire HOUR-credits, either by acquiring them from the City somehow (paying, lottery, etc.), or by doing work for citizens who already have HOUR-credits and getting paid in that. Citizens of a city using a Local Exchange could still participate even if they didn't have any HOUR-credits since they could trade service-for-service with other citizens (no assets transferred), or do work for other citizens to earn some.

This sort of setup doesn't put small cities at a disadvantage, since an "hour of time" is the same city to city. So that variable for differences in value would be removed, but some variance in demand would likely still exist due to availability of places to spend it. If City A only had a few businesses accepting CityA-HOUR credit, and City B had many accepting CityB-HOUR credit, then a citizen would likely stake more of their HOURs into City B, even if it's a smaller city, since there's more liquidity there (this is the same as a gift card to a specific department store being slightly less desirable than a prepaid debit card even if they have the same dollar amount on them and you live right next door to that department store).

Citizens or businesses could still offer goods in exchange for HOUR credits: a citizen could buy a gallon of milk for 1 HOUR, even though neither the citizen nor the grocer selling it spends a literal hour of time on the transaction. Because that actually represents the end of a chain of transactions that could have happened: For a gallon of milk, the original "work" being done would be done by a dairy farmer who might spend 0.5 hour to milk the cow, pasteurize the milk, and bottle it. The dairy farmer then can sell it to the grocer for 0.75 HOUR (to account for the farmer's transportation time, as well as a profit for them), who then sells it to a citizen for 1.0 HOUR. In that way, the HOUR credits act like a currency; able to facilitate trade and give profit.

Smart Contracts needed:

• HOURS Membership: A shareholder contract to keep track of which addresses represent "Cities"
• HOURS Token: Main currency token for this ecosystem. Uses the HOURS Membership contract to determine what transfer transactions are allowed to go through (only those to or from a member). Adheres to the ERC20 token interface standard, but has additional restrictions on transfer most tokens don't have.
• HOURS DAO: A governing organization that looks to the HOURS Membership contract to determine who can vote on proposals. This contract has ownership control over the HOURS Token (to be able to mint new coins) and over the HOURS Membership contract (to be able to add/remove members). Triggering those sorts of changes would require proposals to be presented and voted upon.
• City Token: A token contract that adheres to the ERC20 token interface standard. Implements a deposit function that points to the HOURS Token contract to allow users to transfer funds in.
• City DAO: An owner of the City Token, such that actions taken by the city aren't controlled by a single account.
• City Local Exchange (optional): A contract for each City where citizens could post needs and wants (and their HOUR-credit valuation of each), and be matched up with others who match their needs.
• HOURS Exchange (optional): A contract where City Token contracts could create offers to buy/sell HOURS. Anyone could take them up on that offer (even other City Token contracts) and the HOURS Exchange contract would act as escrow to ensure everything went smoothly.

There would be multiple "City Token" contracts, and all could be identical, or Cities could customize them for their own needs.

Conclusion

Having a global HOURS token adds an additional community/organization layer above the individual Cities and provides a touchpoint for sharing information and knowledge across the City implementations that the current system (or the system of each City making its own ERC20 token) lacks.

The Smart Contracts could be standardized, but still provide the flexibility for if the Cities wish to do something custom, they could do so without breaking the infrastructure.

This is just an initial idea of mine; are there any glaring holes in the logic I've laid out that would need to be addressed in order for this to be a viable option?