Category: Implementation

A Disclaimer

Before delving into other topics, I’d like to first explain where I’m coming from. My self-perceived role in all of this effort is to paint a picture of what needs to be done and to explain why it needs to be done. I do not claim to be an expert at anything, and therefore my ideas about strategies must not be taken as an ‘absolute’ pathway for the implementation of satconomy. In fact, I am optimistic that I may chance upon readers who are far more qualified than I am in terms of outlining alternative strategies, leading the development of the system modules and/or who could provide better day-to-day results. It is up to those interested to examine their capabilities and limitations with regards to the general projects areas that I’ve outlined, and to let me know which areas might lead to effective collaborations (if I’m even needed.)

That being said, I will continue to do what I can regardless of whether or not help is forthcoming. The Reporter Module that I am working on, to be online within a month or so, is rudimentary at best and would not win any “coding awards”, but it would serve just fine as a starting point for anyone who have better ideas and skills to offer. If you feel that the idea of satconomy is full of potential whereas the presenter (me) is lacking, please feel free to start an implementation project and team that you’d feel comfortable working with. The specifics of who does what and where doesn’t concern me much at this point, as long as things get started and done.

Lastly, something that I’ve been reminding myself a lot lately, which should give the reader a sense of my motivation: “Whatever you do will be insignificant, but it is important that you do it.” Gandhi 

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.

Implementation Analogies: Boundaries, Bridges and Towers

To illustrate the overall implementation strategy in satconomy, it is worth comparing and contrasting it with the strategies that could be inferred from mutual credit and Ripple currency systems.

The implementation strategy in mutual credit currencies might be likened to building boundaries. Members are allowed inside the boundary and could trade with one another, while non-members are invited to join this mutually beneficial community relationship where the currency stays within common boundaries. Satconomy is not concerned with erecting community boundaries where the members trade with one another. Rather, satconomy promotes the creation of entity boundaries where members work with one another to provide products to the market in general. Entity-issued credits and products, rather than being restricted from flowing outside each entity’s ‘boundaries’, are meant to flow between entities in open market transactions.

The implementation strategy in Ripple might be likened to building bridges between nodes or islands of market participants. The unique payment routing feature in Ripple is intentionally restrictive in that only the directly connected participants are allowed to cross the bridge between them. If participant A does not have a direct bridge to the island of participant C, but B has direct but separate bridges to both A and C, then Ripple enables a transaction by requiring an IOU to ‘cross’ from A to B and a separate IOU to ‘cross’ from B to C. In this sense, B acts as an indirect relay person that converts the payment between A and C. Participant A’s payment does not reach C directly. In satconomy, there is always a direct payment between market transactors, causing the immediate cancellation of credits and debits between the involved entities. In contrast to how Ripple offers a manual settlement option for the cancellation of credit-debits pairs after a market transaction, satconomy requires an automatic cancellation-settlement of credit-debit pairs at the completion of the transaction itself.

The implementation strategy in satconomy might be likened to building towers, through which market participants could assess the value that each entity brings to the market. If an entity is deemed to provide benefit to the market, then the currency brand that it issues would be perceived as acceptable in a transaction. If the news or perspective from the ‘tower’ is not favorable towards a certain entity, then its currency brand would also lose favor in the market. In an effective implementation of satconomy, this metaphorical ‘tower’ facilitates access to highly transparent, up-to-date and verifiable information about market activities, entity account reports and analyst opinions.