Category: Implementation

Durable Goods

A valid concern that could be raised by potential study participants is, “What if I sell an old mobile phone using independent currency brands, but then the recipient turns around and sells that product for conventional money?”

In other words, a currency system could be attacked by participants whose purpose is to accumulate durable products to be sold later for profit. If that happens, sellers might become more sensitive to the perceived loss in conventional profits when participating in implementations of alternative currency systems. This concern might become prevalent enough that transaction offers are rejected by sellers without even considering the buyer’s currency brand reputation. Since transactions involving conventional money are not tracked under the information system proposed here, it would be difficult to detect such attacks and side-channels.

A deeper consideration of this issue reveals the fundamental shift in perspective required in trusteeship-oriented currency design. It is important to recognize that this attack does not apply to strictly nondurable products such as services and product consumed at the point of purchase (e.g., meal at a restaurant.)

For durable goods such as a mobile phone, a study participant does not have to sell but could rent or lease it out instead. The recipient would be restricted from selling the rented phone for profit since ownership was not transferred in the transaction. As long as potential side-channel attacks exists, leasing would be preferred for durable good transactions which results in the cancellation of self-accrued debt (such as accounted in the ocaup model.)

On the one hand, this type of transaction favors a recipient who likes the flexibility of being able to easily upgrade to newer product models. On the other hand, leasing would force the owner to be more involved with the whole product lifecycle, including eventual recycling and disposal, instead of simply transferring that responsibility to the recipient. The predicted effect is that only dedicated owners would want to deal with the lifecyle responsibility of durable goods, leading to better product traceability and accountability.

In the long run, independent currency brand transactions will likely flourish in a service-oriented economy, where ownership transfers or trade boundaries are less emphasized.

Diversity in Currency Brands

As the development effort in tyaga.org moves closer to the packaging stage, I would like to discuss a topic that is directly related to currency brand indexes: What type of currency diversity should an index represent and track?

There are many ways to design a currency index, but the approach advocated in satconomy is to represent and track the diversity of specialized market entities and their activities through the concept of independent currency brands. Each entity issues currency as unused revenue and expense budgets. In a transaction between two entities, the unused expense budget of the payor’s entity decreases by the same amount as the unused revenue budget of the recipient’s entity. Both entities publish and report depersonalized transaction information to promote traceability and auditability.  This approach has the following advantages with regards to the design of a currency index:

Tracking by currency brands leads to diversity in both quantitative and meaningful terms. Each brand represents a specific entity that contributes and takes from the market. In contrast, other approaches emphasize the potential diversity in different currency designs, which would naturally have less diversity than the number of market entities and be of interest only to currency designers and not the general public.

The OCAUP currency life cycle in satconomy aligns closely with a market entity’s typical use of “money”: to budget for organizational goals, to make or receive payments and to evaluate market performance. In contrast, other approaches emphasize other aspects of currency design such as a common means for storing or expressing wealth. Although these design aspects are important, they are not emphasized in satconomy.

A currency index in satconomy represents the existing  diversity of market entities that issue independent currency brands. The accounting systems and interoperability requirements are intended to be as simple as possible. In contrast, other approaches attempt to put a new layer of accounting configurability and/or currency type diversity on top of existing entity diversity.

In all of the currency systems, platforms or frameworks that I have surveyed, I have not observed any that emphasize the utmost importance of currency indexes. In contrast, the research, development and establishment of relevant, sustainable currency indexes is a unifying theme in satconomy. A dynamic, reliable and informative currency index is an essential component and goal in satconomy. A brand index is not simply an option – it is a mandatory feature that promotes public monitoring and self-regulation of market entities that issue currency.

Proposed Standards

I have uploaded three short documents that outline proposed standards for the satconomy framework. Those documents are in the Standards page. There is also a draft powerpoint are also two slide presentations in the Implementation page. Please post your comments, questions, suggestions. I am also currently developing an interactive demonstration of my implementation projects at tyaga.org – will provide updates here when that becomes active.

Information Driven Market Ecology

A market entity may be viewed as a species that performs a ‘niche’ role in an ecological system. So, for example, a farmer cooperative perfoms the role of food producer, while a clinic or hospital seeks to address the market’s health-related needs. Since each market entity has a particular niche or specialization, it is only reasonable to expect that none could become completely self-sufficient since, in this scenario, everyone is only able to concentrate on addressing a limited set of human, social or market need. In short, the general goal of a market entity is not self-sufficiency within itself and exclusive of others. Rather, an entity seeks to cultivate a self-sufficient market by contributing to the diversity of product choices in it and by influencing how resources are used for the production of ‘desirable’ products.

Of course, no one can summarily dictate what products are to be offered by market entities, or which products are desirable for whom. It is simply hoped that goods and services would naturally be produced by entities who see a need for them, and market participants would self-determine those products that they need and the choices that they prefer. It would seem that this expectation could lead to resource exploitation and unmet needs, and there might even be support for that viewpoint with the current state of market economies where, for example, one person could live in a 40 bedroom estate while hundreds are homeless on the streets.

However, the satconomy market framework is designed to offer active feedback to a market entity through the acceptance or rejection of its currency brand by other entities. This is different than current market situations where sellers blindly accept ‘generic’ currency regardless of how that money was earned. In satconomy, currency is traceable to a specific market entity and its activities. If market sellers are not willing to accept an entity’s currency brand due to its reputation, members of that entity are likely to run out of product choices, and without employees or members, that entity is destined to failure or extinction. Therefore, each and every entity in a satconomy framework is expected to actively regulate itself against public opinion in order to promote and maintain its market reputation. Please note that there is a similarity between this expected form of self-regulation and the current stock-price-oriented management of a publicly owned company.

In order for this feedback regulation in satconomy to work as expected, market participants must have reliable access to timely and accurate information that they could use to evaluate whether or not to accept someone’s currency brand. Even now, companies regularly update investors with financial results and ‘stewardship’ performance. Market entity information is also currently available as a constant ticker of stock symbols and price fluctuations. All that needs to happen in order to implement satconomy on a wider scale is to adapt existing information technology to serve the need for performing currency brand evaluation. I am not implying that it will be easy, only emphasizing that all of the ingredients are already available – we just need cooks in the kitchen. Or, perhaps more appropriate in the current analogy, new entity species simply need to evolve and take on a niche in this market ecology – its easier to establish a new currency brand before more competition arrives.

Summary Document and Implementation Examples

I have not posted here in awhile, but there is a good reason for that spell of blog inactivity. When I use a blog to discuss certain aspects of the satconomy framework, each post ends up having a very narrow focus and seem to become more and more disconnected from each other as the discussions get more detailed. I thought that a cohesive summary document would be useful for those who would like to see the bigger picture painted as a whole, and so I spent some time last month writing this document for that purpose. The summary document provides more relational structure to the concepts and principles that have been presented here under different categories.

I am also spending more time in developing implementation examples at the tyaga.org site, which now includes basic currency brand evaluation metrics here and online donation portal here. Please visit these links; I believe the online examples, in contrast with mere discussions, are able to illustrate the practice of satconomy more clearly.

Project Update

The source code for the pre-alpha vesion is available here. It is also available in sourceforge cvs for viewing and/or download. The tyaga.org website is a demonstration of how an independent currency-issuing entity might operate in a satonomy framework. It declares it goals and milestones, post job announcements and reaches out to its target market. It manages its curency brand similar to how public companies manage its share price in the stock market. The difference is that instead of trying to push up stock share price,  a satconomy entity simply tries to promote the widespread acceptance of its currency brand by market sellers, thereby increasing its members’ access to market products.

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.

Project Approved in Sourceforge

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.

Development Update

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.