Category: TraceEval

2012 Q3 Update

Yesterday at the University of Washington, I gave a seminar talk of my thoughts on community and alternative currencies. Lots of good, challenging questions. This marks the first time that I presented TraceEval to a group of people, and although I was nervous at first, I was glad that I did it.

I’m also waiting to hear back from  other opportunities to present my ideas. In addition, I want to finish prototyping an easy-to-use implementation that I’m hoping to deploy next year. I will follow-up on the invitation to try Flora as a testbed and continue prototyping for the remainder of the year.


TraceEval is the new, unifying project name that ties-in the various components that have been proposed and prototyped on this site. ‘TraceEval’ evokes the main goal of, which is to prototype a framework of traceable currencies that are evaluated for acceptability at the time of payment. The primary considerations in TraceEval are:

(1) Brands

A currency ‘brand’ is traceable to the issuing person or organization the serves a market or social need. This approach is different from both community currencies, such as LETS, and peer-to-peer lending systems, such as Ripple. There is no guarantee of currency brand acceptability between entities. For example, a seller would only accept a payment, or a nonprofit would only accept a donation, if the recipient supports the mission and activities of a payer or donor.

Prototypes that are planned under the ‘brands’ category are example websites, inventory systems, and simple online commerce systems. There are older prototypes using blogger, and the obviously made up ‘’ and ‘’ on this site, but those were part of Prowl which I consider outdated and pretty much abandoned (unless I could be convinced to go back to it).

(2) Budgets

Currency is self-issued periodically as revenue and expense budgets of an entity.  This is how currencies are made traceable in TraceEval. Budgets are non-transferrable between entities, which lessens the pressure for an entity to accept payments, since every entity is able to issue its own expense budget.

Prototypes that fall under the ‘budgets’ category include the proposed OCAUP accounting lifecycle/convention/model, the implemented NPX accounting system with the smart-phone inspired user interface, and the Interentity Payment Protocol (IPP).

(3) Bots

Indexers, auditors, and other service providers are needed to make sense of published currency activity and to advise on currency brand reputation. The evaluation part in TraceEval would not be possible without these service providers. The expectation is for TraceEval service provider to spontaneously arise much like the diverse offerings of browser options or search engines in the early days of the Web.

There is much work to be done as far as prototyping TraceEval bots. So far, there is only a mock-up of what a currency brand index website might look like, maybe similar to a NASDAQ of currency brands. The only other prototype to-date was coded as part of simulation studies.

Most of this post was borrowed from another post in another blog. There will be a slow shift away from the ‘satconomy’ moniker in favor of TraceEval. The philosophical or conceptual framework in satconomy is, I think, still valid. TraceEval just happens to be a better term that captures the goal of the framework and the motivation behind the prototypes.