Tagged: System Development

Development Update

I’m hoping to upload working examples of the modules to a web host, by next week or even during the weekend. I’ll upload the php code in sourforge after that, after I do some more testing. What I’ve done so far is basic stuff, something that could easily integrate in any blogging platform such as WordPress. The idea is for any entity – any blogger or organization – on a basic web host plan to each have the ability to establish and manage its own currency brand to be used for inter-entity market transactions.

I don’t know if there is anything similar to what I have developed so far, which is a currency lifecycle oriented accounting system. This approach promotes the traceability of currency issuance to a specific entity, by not allowing currency issuance or transfer between entities. The system categorizes each transaction into three distinct events:

  • Currency Creation – There is a net increase in an entity’s credit and debit limits, i.e., the absolute value of spendable or usable currency units increases. For example, an entity’s expense account budget limit increases, accompanied by an increase in its revenue account budget. The sytem allows intra-entity-only currency creation.
  • Currency Assignment – There is no net increase or decrease in usable currency units. For example, an expense account might assign some of its spending quota to an employee account, or a store might allocate some of its sales budget to another store. The sytem allows intra-entity-only currency assignment.
  • Currency Use – There is a net decrease in the usable credit and debit limits. For example, the buyer’s expense limit decreases as his credit’s are used to cancel the seller’s debits which are held in a revenue account. The system not only allows but also promotes inter-entity currency use. Within an entity that I envision joining, I would even discourage intra-entity currency use. 

It’s likely that there are other systems that might be tailored to what I have in mind, like Cyclos and other bookkeeping software. If that’s the case, it might mean less work for me. Even though my development work so far might have been redundant, I feel that it nevertheless provided the necessary background for me to be able to describe the fundamental accounting functionalities that are needed to implement satconomy. At least that’s what I’m hoping the working examples will provide – a blueprint for future development strategies or for configuring existing accounting systems to fit the requirements that are outlined here.

Development of System Modules

I have been busy the last few weeks, not just for the holidays, but mostly because I started exploring possible collaborations with other alternative currency proponents. I have not been able to give a lot of specifics, mostly vague concepts, which I’d like to clarify here.

Firstly, there are a lot of ways to structure an entity cluster, but the following illustration of currency flow represents what seems to be the most logical arrangement of core accounts around a brand node, subject to debate and refinement. Even with the partial shading, the core Expense and Revenue nodes should be visible. (Click to expand image.)

Inter-Entity Currency Flow

Although not shown here, it is worth emphasizing that each entity independently issues currency as credits to its expense accounts (general, personal and emergency funds), paired with an equal amount of  debits issued to its revenue nodes. In satconomy, self-accrued credits within an entity (such as ABC currency brand) are primarily intended to be used to cancel another entity’s debits (such as XYZ currency brand). In a transaction, the buyer redeems his credits for products of other currency-issuing entities in the market, and the entity which provides the product cancels its debits as a symbol of satisfying its self-declared obligation to the market.

In the next illustration, I have tried to highlight the system modules that could be separately and simultaneously developed for an effective implementation of satconomy. (Click to expand image.)

 Reporting System Modules

I am currently working on a satconomy Reporter Module, an ongoing project that previously didn’t have a name or clear development goal. I likened the project to building a tower in an earlier post. As I see it, the reporter node would be similar in function to a stock exchange or financial market bulletin. The main difference is that in satconomy, the information will be about a diversity of currency brands and entity reputation instead of stocks, bonds and traditional currencies. I’ll have more to say about my development strategy, based on PHP and MySQL, in another post. 

The Entity Module is essentially a small-scale, open enterprise software that keeps track of entity currency issuance and cancellation, plus various account maintenance features to promote highly transparent currency issuing entities. This module will be developed to interface with the Reporter Module, in light of the information service each module is designed to provide. For example, the Reporter Node that I am developing will not keep track of an entity’s unused credit and debit balances – that task will be handled within an Entity Module. My main goal is for highly flexible, secure and platform independent modules to be able to link to each other for information auditing purposes.

The Offline-Transaction Module is another puzzle piece awaiting development – any early takers?  I have particular ideas about this module as well, namely that an offline transaction device should be capable of being used for both buyer and seller roles – no special card readers, highly mobile, small size, long-battery life (if needed), like a small wrist watch, mp3 or cell phone device. The store-and-forward model is favored, in order to facilitate the implementation of satconomy in infrastructure-challenged regions where always-on connectivity and/or provider fees may be prohibitive.

I’ll provide more details and updates within the next few weeks, for anyone interested in finding out more.