Development Update

January 25, 2008

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.

Leave a Comment » | Implementation | Tagged: , , | Permalink
Posted by Edgar

The Credit Recipient in a Market Transaction

January 15, 2008

Instead of posting another development update, this time I’d like to present the role and perspective of a credit recipient in a market transaction under a satconomy framework.

The credit recipient in a transaction could be a seller, a tax collector, a nonprofit receiving a donation, a grantee, or others in a similar role. I hope that it is clear by now, after going through earlier posts, that each and every entity in satconomy issues its own currency brand, and therefore does not to receive credits from other entities in order to have currency to spend. It may be asked, then, what would be the point in having an entity act as a credit recipient in a market transaction, when that entity could already issue credits to itself (and its members)?

Remember that an entity issues or creates currency as credit-debit pairs. An entity accrues debits at the same time that it accrues credits. The rationale for accepting credits in a market transaction is for an entity to use those credits to cancel its self-accrued debt to the market.

An entity, by exchanging its products – goods and/or services – for the payment (credits) of a market participant does not receive profits, investment returns, cash or any ‘wealth’ in return. In a satconomy transaction, an entity simply gets to fulfill its self-determined obligation to the market. The partial or total fulfillment of its obligation to the market is quantitatively symbolized by the partial or total cancellation of its self-accrued debits.

The next question might be, why should a market transactor be selective as to which credits or currency brand to accept? It might seem counter-intuitive for an entity to reject any opportunity to cancel its debits. The answer should be found in an entity’s goals or mission statement, where it declares its specialization and target audience, and in the reputation of an entity with regards to its ability to provide value to the market. A trustworthy entity accepts its role in helping cultivate a robust and open market, so it should cater its products to benefit those entities that the market perceives as valuable contributors. If an entity is deemed to support unpopular regimes or monopolistic entities or free riders, then even though it has the ability to cancel its debt (using the credits received from the unpopular entities), market participants could still choose to reject its currency. In satconomy, noncooperation goes beyond the refusal to buy a product from an ‘unfair’ entity and extends to the rejection of that entity’s currency brand.

Leave a Comment » | Entity, Brand Evaluation, Trusteeship | Permalink
Posted by Edgar

Project Approved in Sourceforge

January 14, 2008

Sourceforge has approved/agreed to host the open-source development of the satconomy modules. I will upload the PHP code in about a month after I migrate the development site to a full pledge host and after testing what I’ve done up to that point. Any recommendations on web hosts? I’m thinking of AN Host.

Leave a Comment » | Implementation | Permalink
Posted by Edgar

Development Update

January 11, 2008

It looks like I should be able to provide initial working examples of both the Reporter and Entity modules by early next month. Nothing fancy. The modules are written in PHP script with the intent that they fit within existing blogging platforms that use MySQL databases.

Briefly, the reporter and entity modules will have about five and seven tables, respectively. The PHP-coded transaction engine will have dynamic rollback and rollforward features, and will be designed to handle arrays containing any number of records with five elements each: date, amount, to, from, instance (or reference/receipt). The engine will output two arrays, one containing the detailed transaction results for each submitted record and the other containing the summary results of affected reporter or entity accounts.

If an exact copy is not found in a pending table, a submitted record will be inserted in the pending table and the engine switches to processing the next record. On the other hand, if an exact copy is found,  the transaction engine moves forward with updating the corresponding to-from accounts in the verified record. That’s the general idea, details will be found in the working example and code text files to be provided elsewhere.

Back to work.

Leave a Comment » | Entity, Implementation | Tagged: | Permalink
Posted by Edgar

A Disclaimer

January 5, 2008

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 

Leave a Comment » | Implementation | Permalink
Posted by Edgar

Development of System Modules

January 3, 2008

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.

Leave a Comment » | Entity, Implementation | Tagged: , , , | Permalink
Posted by Edgar

Follow

Get every new post delivered to your Inbox.