Durable Goods

September 25, 2009

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

July 3, 2009

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.


Reporter / ICB Index Demo

September 28, 2008

A mock-up of an independent currency brand (ICB) index is available here. The demo ICB index has example market performance charts and news. I hope the demo gives more insight into one of the more popular post category in here, that of currency “brand evaluation.”


Proposed Standards

August 24, 2008

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

July 22, 2008

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

July 22, 2008

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

February 7, 2008

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

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.


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.


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.


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 


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.


Implementation Analogies: Boundaries, Bridges and Towers

December 3, 2007

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.


Follow

Get every new post delivered to your Inbox.