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.)
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.)
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.