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, tyaga.org 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.
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.
If you have questions or strong opinions about the proposed architecture and comparison diagrams, please join the discussion at http://groups.google.com/group/prowl-users?hl=en. 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.
I have tried to catch up with some Prowl related updates, most of which have been in places other than the discussion group. So I just took the liberty of copying and pasting excerpts to help consolidate previously scattered discussions in one place. I also included some email excerpts that I thought might be interesting to others. Please feel free to ask questions or post comments that will help clarify not just Prowl, but the whole currency design.
I have to admit that I was surprised to find, in another site, the same core ideas expressed in here and satconomy.org — traceability, accountability, transparency, auditability, even certain implementation aspects, repeated within the same context albeit in fancier words. The surprise mostly came with disappointment that while there was some mention of Twollars as an inspiration, apparently Prowl’s earlier announced release and demo failed to spark the same insights that I have been expounding and struggling to embody for a long time now.
But I’ll remain committed to openly discussing updates, example codes and potential strategies, which others are encouraged to build upon or tweak as necessary. There are many opportunities to develop your own designs on the evolving Prowl-like currency services that are sure to come within this year. I would especially like to see designs that cater to unsophisticated user groups – that’s a key aspect that people often forget.
Would it be possible to reconcile the fundamental differences between the following two approaches:
“Currency designed for transactions between members of independent entities or brands”
“Currency designed for transactions between members of the same entity or community”
My doubts have resurfaced after reading some recent online discussions related to currency information systems. At issue is the importance of interoperability between different currency entities as supported by adhoc service providers.
With community-oriented currencies, the expectation is for the majority of transactions to occur between members of the same currency entity, so the administrative system of one currency does not have to worry about understanding information from another currency system. This obviously has the advantage of freeing each currency issuer to configure their currency and transaction grammar as needed, without worrying about what other issuers are doing.
In contrast, tyaga.org expects that separation of concerns and scalability would inevitably lead to a majority of transactions occuring between members of different currency entities. Where each entity specializes in serving a particular market need, access to product diversity is only possible through interentity trades. Each entity could still configure currency settings and use proprietary messaging/record formats. However, the need for publishing and reporting conventions is going to be unavoidable under a scenario of global interentity transactions.
It was interoperability concerns that led to the development of Prowl as a potential starting point for discussing uniform representation and standardized accounting terms, while still allowing for variations in parameters and calculation specifications. Without interoperability, it would not be possible to achieve traceable and auditable currency brands.
One of the key differences between satconomy and other ledger-based currency systems arises from the concept of ‘obligations’. In other posts, I have used the term ‘debits’ as a quantification of obligation, and I’ll continue that usage here.
In Ripple, debits represent the obligation of a participant to the neighbor node that it used as a payment intermediary. It doesn’t matter in this analysis whether or not there is an actual manual settlement of ‘debts’. The main point here is that the obligation arises as a result of a market transaction, or what some alternative currency proponents refer to as property transfer.
In LETS, obligation also arise from a market transaction. The difference with Ripple is that the debits are owed towards the whole community, and anyone that belongs to that community may cause a member to accrue debits or cancel it through a market transaction. In contrast, Ripple credit-debit issuance and cancellation are specific to neighboring nodes.
In satconomy, obligations arise even before any market transactions take place and without prior contractual arrangements. Even before an entity’s obligations are quantified as debits, the obligation is already there, qualified as mission statements or organizational goals. Debits are declared as soon as an entity issues equivalent credits for member contributions towards its goals. Again, no market transaction precipitated the recording of new credits and debits, or at least it would be absurd to call the process of product creation as a case of ‘property transfer’, when technically the credit issuer and recipient within the entity end up becoming co-trustees of the entity’s product inventory and debit account.
In satconomy, debits represent the quantification of an entity’s obligation to the market as a whole. Not because other market participants have necessarily made any demands on the currency issuing entity, but simply because that entity has made it an obligation to specialize in delivering certain goods or services to the market. There’s nothing new in this concept of ‘self-determined duty’, entrepreneurs are always trying to research and develop new product offerings all the time without explicit prompting from the market.
But someone might argue, how could a currency issuing entity cancel its self-accrued debits when it owes no one in particular? By selling its products to other entities that it perceives as engaging in sustainable market activities. All that happens in a satconomic market transaction is the cancellation of equivalent credits and debits (quantified obligations and contributions). No new ledger entries are recorded out of expectations for future reciprocity in a market transaction.
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.