We propose a semantic model, a XSD schema, to be followed by any transaction service of any local community to represent the currency that builds on the explained principles.

The XSD model reflects a CONTRACT of the ISSUER and its associated COLLECTORS with respect a range of MERCHANDISES, for a valid period, with the HOLDERS of the currency. In other words, it´s a bond on goods sold by the COLLECTORS. The contract is validated as one of the Insula currencies. 

HOLDERS can be Electronic Accounts associated to registered CITIZENS or printed VOUCHERS. A paper voucher holds some amount of value associated with the currency the same way as an electronic account. 

The transaction model is:

1.  For electronic accounts, SPLIT of shares of a HOLDER and PASS over the splitted shares to another HOLDER.
2. For paper vouchers, circulation until redemption. Reconverting of vouchers as a deposit into an account is possible but not considered here. 
3. The XSD models offers an optional follow up system though BitCoin.

The currency represents a legal commitment of the issuer to deliver goods in exchange of the redemption of the currency. A transaction could consist of a currency HOLDER extending a new legal commitment with a new HOLDER to whom he/she wants to pay. However, this poses difficult legal questions and implies complex mechanisms. From the legal point of view, the payment consisting in giving a share, a part of my contract, is the simplest one. It´s the method used at sharing lottery vouchers. 

In summary, a payment consists of a HOLDER transferring a share of the original contract of the HOLDER with the LEGAL ISSUER, to a second HOLDER. It can be 100%. Still, it keeps the identity of the first legal commitment. Numeration of the splits follows this by adding digits. The concern of absolute security with top crypto-currency technologies is only secondary: It´s about local economies, with currencies that can only be redeemed by products of local enterprises. Any hacking would not go far. The level of security and anonymity of the technologies used for the transactions can be established at every Insula. At least the issuer has to be known. This can simplify a lot the architecture. 

• We do NOT propose any software to support the issuing, the accounts or the transactions. This is not a transaction server proposal. We assume that there is an informatics company at every Insula providing the Voucher Transaction Services. Local Universities or technical NGOs could also provide them. If there are P2P solutions available at local scale, the better.
• We do NOT propose any software to support the user electronic wallets. We would however recommend to design them using standard W3C XForms technology. We would also recommend to focus soon on mobiles. 
• We do NOT propose any specific encryption or protection software, although the model foresees places for different types of keys. For a local economy, the security requirements are not as high as for electronic money aimed at the global economy. Each Insula decides the security level. 

The reason to include an optional BitCoin account in the HOLDER fields is to facilitate settings where transactions are accompanied by a BitCoin transfer for a small fraction of the transaction value (a kind of a transaction fee). By that, all available BitCoin tracing tools could be used, thus facilitating the setup of transaction services. 

The second reason is more complex: for a second development stage, when we see the emergence of for profit enterprises or cooperatives operating in the new economy, in a system based on currencies representing goods, the money to pay the profits has to be put in circulation in CC at the beginning of the cycle. Instead of paying the stakeholders, we propose to invest in BitCoins, use them to feed the transactions circuit as a "transaction tax", and redeem them at the end of the sales cycle to pay the stakeholders.