Category: Comparisons

Project Update – UI development

Quick updates on development progress: The documentation for the revised accounting system and IPP is about 30% done, but it got boring pretty quickly. So I switched to the user interface design and development, and decided to have view-related code on the client-side as much as possible. This decision necessitated the use of a Javascript library or framework for more rapid prototyping. I have tentatively settled on mootools after trying out jquery. Both libraries are relatively easy to work with, but it is easier to model desirable ‘transaction device’ UI features using mootools’ class functions.

There have been interesting discoveries along the way with regards to binding ‘this’ and lexical closure in Javascript. I’m trying not to get side-tracked into reading too much about the ‘functional’ programming approach, although Javascript may not be the best example of that approach.

After posting this, I realized that I forgot to mention other projects that I visited recently:

The cyclos documentation and interface is really impressive. Like CClite, Cyclos has the concept of a ‘System’ account-type, which gets debited when credits are issued to members (at least that’s how I understand it and I could be wrong). The System account-type is very similar to an ‘unused revenue’ budget in the revised accounting system that I am working on.

However, in a cc-implementation, a System account is primarily used to track the total credits that could circulate or are circulating in a system and tends to be a static quantity that is dependent on the number of members and debit limits. In contrast, an unused revenue budget tracks how much credits an entity intends to receive from the market and is dynamically (a) increased whenever the total expense budgets is increased, or (b) decreased when inflows are received. The unused revenue budget is expected to reflect inventory or productive capacity rather than the number of members in an entity.

The other projects that I visited in the last weeks are opentransact, flowplace and the marketplace module for drupal. There are also many discussion groups, including agile-banking and ripple-users, with participation levels that are somewhat encouraging.

Dynamic Binding at Transaction Time

One way to look at ‘coupling’ is the relationship that a transaction record implies between transactors. For example, the use of community currency implies membership in the same community or in communities that have an agreement in place to accept each other’s currency. In Ripple, direct transactions occur only if the transactors have preset limits with each other and payments have to be routed through pre-established accounts. These requirements may be viewed as ‘static binding’ or predetermined configurations to set limits on who could trade with whom.

In the case of mutual credit community currencies, it is not hard to see similarities with the pre-WWW philosophy that hyperlinks are to be made and maintained through a centralized database. A requirement that transactors must have an account with the same mutual credit accounting system highlights this similarity. But the similarity extends beyond considerations of ledger boundaries and into logical or abstract rules for initializing who could trade with whom. As long as the ability to transact requires a predetermined relationship, the ‘localized hyperlinks’ mindset applies even if the accounts were maintained in separate servers or accounting systems.

Under’s implementation scenarios, a transaction does not automatically imply that the transactors are members of the same community or that they have established credit limits with each other prior to the transaction. Anyone could potentially trade with anyone else. It is up to a potential recipient to accept or reject a currency brand at the time of transaction – essentially, the concept of dynamic or late binding as applied to a currency system design. This is similar to the WWW philosophy of allowing any web page to link to another page at-large, which is a less-controlled way of doing things but inherently more flexible and scalable. Even though mutual consent is required for an inter-entity transaction, such consent is only applicable to one instance of payment and does not imply past or future guarantees of currency brand acceptability between two brands.

Loose coupling, as described in a previous post, is expected to lower the barrier of setting up new currency brands, leading to more spontaneous currency brand creation (i.e., more ‘new web sites’ in the current analogy). Dynamic binding, as described in this post, is expected to lead to more diverse market selections and higher frequencies of inter-entity transactions (i.e., more ‘interdomain links’.)

As with all design trade-offs, however, there is a price to pay for such high expectations.’s design approach for achieving flexibility and scalability comes at a substantial cost of stricter reporting requirements and greater dependence on service providers to make make sense of huge volumes of transaction data. The challenges of reconcilable reports, auditors and currency brand indices arise since each entity is allowed and encouraged to set its own currency limits as budgets, without having to predetermine transaction boundaries or specific entities as revenue sources.

Reporting System Requirements

Now that I have finished concentrating on other projects and commitments, I look forward to continuing’s development work. One of the web sites that I visited recently was the community way (CW) in Comox Valley. The information design aspect that caught my interest was the ‘current numbers’ page with links to a graph and spreadsheets.

What follows is not a critique of the reporting system design as used by CW – for all I know, that design serves CW’s needs perfectly. I also do not question the community emphasis of the CW currency system and I sincerely would like to see such a system succeed wherever it is implemented. My goal in offering the following comparative analysis is to better explain the technical nuances behind tyaga’s evolving IS design requirements.

It has become obvious to me that the use of offline transaction instruments, such as minted notes, checks, or store-and-forward devices, could not be tracked efficiently and would not be conducive to the development of dynamic currency brand reporting systems. So while my earlier design notes referred to the importance of offline devices, I have since revised the technology requirements to focus on online devices. The most promising device in this regard is a basic cell phone with SMS capability, which is already widely deployed and inexpensive to own. While a QR-code app is not required to post transactions through SMS, a camera phone with that capability would simplify data entry and transfer between transactors.

Another design change, as described in a recent post, is the use of public keys for better non-repudiation and auditing capabilities. The example index on this site clearly illustrates the required tracking and metrics at the level of an entity, as represented by its currency brand, and not simply aggregated for a whole community as shown in CW’s current numbers graph. I am not sure of CW’s requirements for auditability, but tyaga’s design requirements include the auditability of any published performance and evaluation information for each entity.

Finally, it is clear that an under-developed reporting system does not hinder CW’s implementation. In contrast, a robust and dynamic reporting system is required to implement tyaga’s concept of spontaneous, targeted non-cooperation against specific currency brands. A currency brand index, constructed with dynamic information from reporting systems, should help participants make informed decisions on whether to accept or reject a currency brand in a transaction.

Again, I applaud CW as one of the rare, actual, working implementations of alternative trading systems. At the same time, I am reminded that there are not many development or implementation efforts that seek to address tyaga’s main information systems requirements.

Reputation Basis

While reputation may be derived from many relations and concepts, these bases are frequently observed in the design of reputation currencies: ownership, membership and trusteeship.  

Owner reputation is a primary basis of lender-oriented currency design. The benefactor evaluates how likely the recipient is to return or compensate a trade. For example, the recipient might own cash and thus immediately return a favor by giving the seller reusable currency tokens. The currency design is, therefore, aimed at facilitating direct reciprocity.

Member reputation is a primary basis of community-oriented currency design. The benefactor evaluates if a recipient benefits a common cause or resource and how likely that member’s contribution to the community will continue. Even though indirect rather than direct reciprocity is facilitated, there is a strong expectation of a closed-loop circulation of currency within the community. 

Trustee reputation is a primary basis of brand-oriented currency design. The benefactor evaluates if a potential recipient belongs to an entity with a worthwhile specialization and acceptable market performance. The emphasis is on indirect reciprocity without any expectation of closed-loop currency circulation within a predetermined boundary.

To illustrate the concept of trusteeship, imagine a hospital whose mission is to provide healthcare. If the hospital has a reputation for effectively allocating its limited resources to serve patients, then a benefactor would have a good reason to support and accept that hospital’s currency brand. The benefactor should not be concerned whether or not it would eventually benefit directly from using the hospital’s services. Rather, the benefactor should focus on establishing its own reputation as a trustee by effectively fulfilling its specialization.

The preceding comparison does not imply that reputation currencies may emphasize only one conceptual basis. Different reputation bases leads to different approaches to improving market access. On the one hand, it is easy to see that a brand or trusteeship-oriented currency design provides access to the widest market possible since currency use is not limited to direct reciprocity or within community boundaries. On the other hand, it may be argued that a trustee’s reputation offers the least guarantee on redeemability since trusteeship is not as easily qualified or quantified in comparison to ownership or membership.

Indirect Reciprocity and Image Scores

Recently, while researching reputation attacks that could threaten currency brand indexes, I happened across another perspective that I feel compelled to study and learn.

Nowak and Sigmund’s article in Nature magazine discusses the evolution of indirect reciprocity in the context of hunter/gatherer populations. An idea that immediately comes to mind is that currency is an attempt to externalize image scores. Others have also realized that connection, and besides another blog, there is even a published article on money as externalization of confidence (unfortunately for me, I do not read Japanese).

In hindsight, I could see how Prowl is just another attempt to scale indirect reciprocity by tracing reputation to a market entity’s domain name, exposing helper-recipient interactions to declared and random observers through PaCT, and promoting auditable reputations through parsable reports. The extended sequence of PaCT even illustrates how a reporter may query for advisories on whether to accept or reject a transaction opportunity, which is analogous to the decision to help others or not. It should not matter whether a transaction is called a sale, charity or paid service — the recipient (e.g., buyer) still receives a benefit and the originator (e.g., seller or donor) still accrues the cost in hopes of improving her long-term fitness (through redeemable reputation tokens or supporting others who make life better, more satisfying.)

Reading through research and literature published on the evolution of cooperation, it’s amazing to see theories and scoring strategies objectively compared using accepted frameworks for modeling, simulation and experimental studies. I see the concept of scoring strategies (image scoring, standing, etc.) as analogous to currency design. Good currency designs, like good scoring strategies, are more likely to persist in simulations and actual implementations.

My take-away lesson from evolutionary game theory is that overall fitness determines selection, and not the amount of tokens or currency that is owned by an individual. That perspective runs contrary to most economic game theory that uses the accumulation of money as the quantitative measure of success. Evolutionary selection by accrued fitness seems more natural. I was inspired enough to create a basic simulation program for modeling the spread of benefits/costs in a population that uses a particular currency design. However, I am still unsure of how to model selection in a saturated market population. I don’t think evolutionary selection is representative of the situation wherein market participants are cognizant of various currency designs that they would like to earn and use.

Diversity in Currency Brands

As the development effort in 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.

The Robustness Principle and Brand Evaluation

I have recently come across Postel’s Law, which is typically quoted as: “Be conservative in what you do; be liberal in what you accept from others.”

This is also known as the Robustness Principle. It reflects tyaga’s vision of how independent currency brands should operate and interact: “Be strict in setting your own limits and performance, be tolerant in accepting other currency brand’s limits and performance.”

In other words, in order to promote the adoption and spread of independent currency brands, it is important to expect that most entities will likely have poor performance relative to its initial budgets. The important thing is to observe work with dedication and perserverance, and not to expect immediate success. A dynamic index is therefore a means for evaluating the progress of an entity through its currency brand, and not a means for avoiding transactions that could help another entity reach its goals. Something to think about when studying and promoting the use of dynamic indices.

Study Plan for Currency Brand Indices

I have taken a short break from coding accounting system and reporter features in order to present a rough vision for implementing the concepts and components that have been described in this site.  In this vision, the information system under development will be packaged for exploratory studies of dynamic currency brand indices.

All of tyaga’s work relates to the development of reliable and compelling currency brand indices. The impact of dynamic indices on the spread of ledger-based currencies will be comparable to the impact of search engines on the usability and growth of the Web. This is an optimistic statement that begs to be tested on empirical grounds.

Of course, there are different ways to establish currency brand indices. Stephen DeMeulenaere / Strohalm publishes something similar once-a-year for complementary or alternative currencies, but the information is not sufficiently dynamic, and is neither easily auditable nor traceable to economic activities of market entities. When the “tower” analogy was posted in 2007, there were no apparent published efforts that appreciated the importance of this challenge. As a result, was established to actively research and develop strategic approaches for establishing dynamic brand indices. So far, the strategy involves the following concepts and components:

  • Prowl’s publisher-reporter emphasis encourages the simultaneous development of multiple index applications.
  • PaCT results in instantenously cross-verified and updated transaction information that indices could pull and evaluate
  • OCAUP facilitates audits and reconciliation of information in internal ledgers, published reports and indexed evaluation metrics.
  • The concept of independent currency brands (ICB) promotes traceability to and indexing by specialized market entities, instead of communities-members or lenders-borrowers.
  • The IS infrastracture plan and diagram present the conceptual separation of concerns
  • The Prism classification convention encourages new perspectives and critiques on currency design

The proposed study plan is one way to test the validity and effectiveness of various design elements, including tyaga’s assumptions made with regards to the design of information system.

Currency Brands, OCAUP and Prowl

I have revised the hastily drafted game-design representation of tyaga’s goals. In reviewing the simplified “game rules”, I was reminded of the standards that underlie the success of the World Wide Web. The web standards, listed in order of importance by Tim Berners-Lee, include the URI, HTTP and HTML. In other words, the Web is primarily defined by the use of URIs, a standard that is easily taken for granted while HTTP and HTML receive more attention.

It was also no accident that URIs use the Domain Naming System, which was designed to be globally scalable and was already widely supported. For the same reasons, Prowl also specifies the use of domain names to simplify the implementation of the similarly crucial concept of Independent Currency Brands (ICBs). The use of separate registries would have added unnecessary complexity and led to collisions as more market entities establish independent currency brands.

After the concept of ICB, the second-most important design aspect in Prowl relates to accounting models. Just as web and gopher clients offered interoperability in each other’s early protocol versions, Prowl is also designed to understand different market transaction requirements and effects on account balances. For example, would transactors have to be members of the same community to transact (mutual-credit, cc model)? Would the ‘buyer’ accrue debt which would have to be settled later (lender-borrower model)? By default, Prowl reporters are expected to support the cross-verification of OCAUP-based transactions, where the buyer entity’s unused expense and seller entity’s unused revenue budgets decrease by the same amount. The default notary support for OCAUP is similar to the default support for HTTP in web browsers.

The third-most important design aspect in Prowl relates to the representation of transaction information. Prowl specifies default published record syntax, report structure and query-response conventions. However, Prowl should support other representations as they emerge. As inter-regional trade in ledger-based currency grows, Prowl would need to support currency activity representations in different dialects.

The game-design representation also shows tyaga’s infrastructure building blocks as a list of ‘game equipment’. Through Prowl standards and PaCT payment sequence, establishing and using independent currency brands should become simpler and more fun.

Scalable Currency Design

In an effort to facilitate the discussion of open money standards, I have created two diagrams that others might find useful, proposed architecture and prowl vs. twollar layers.

If you have questions or strong opinions about the proposed architecture and comparison diagrams, please join the discussion at Just recently in that forum, I have tried to discuss some details of the Prowl design that concerns potential collaboration areas with other currency projects.