Data Structure for a Currency Platform

What follows is my attempt to describe what might be necessary for an extensible currency platform that takes into account (no pun intended) the subtleties of flow language. Eric Harris-Braun has already looked into this problem deeply and has developed the “mesh + churn” of Open Money. Please see those materials for another angle on these issues.

A currency platform will need several components to be fully functional. Let’s go through them in order.

1) Account – An account, as I am defining it, is the place where information about ONE currency is aggregated and transformed for output. In a mutual-credit currency, my account would do a summation on my transactions within the currency, and tell me whether my account balance was positive or negative. In a “thumbs up, thumbs down” reputation currency, my account would display the average of the ratings given to me by my trading partners (1 for thumbs up, 0 for thumbs down) as a percent (80% thumbs up). The account is an aggregation of transactions that happened within a particular domain, transformed to be relevant to the user within that domain. I will call this transformed informational output the "account balance.” Accounts could even use account balances in other currencies as input when calculating their own balance (think Dow Jones Industrial Average). To summarize, an account is what interacts with other accounts.

2) Transaction – A transaction is an interaction between two accounts. It is a record of what happened and describes a mathematical relationship between the two accounts. I.E. On February 10th 14:50 “account A” pays 50 to “account B”. This transaction describes the relationship between the two accounts, and records the time it occurred. Transactions could be transferable (debited to the payer, credited to the payee), or non-transferable (not debited to the payer, but still credited to payee) such as a reputation transaction or a thank you. In order to have the maximum extensibility to this platform, receipts for all transactions within a currency could be aggregated on a server(s) (such as Twitter). These receipts would contain all the information about that transaction specified by the currency. Third party applications could be written that would derive other metrics from this aggregated transaction history, and project that information into new accounts (as allowed by the rules of a given currency), and even new currencies.

3) Currency – A currency is set of rules defining the types of accounts, how their balances are calculated, and how these accounts can transact with each other. A currency could have multiple different classes of accounts. For instance, a mutual credit currency might only allow businesses to be issuers of the currency (allow their balances to be negative). This stipulation would necessitate multiple types of accounts within the currency. A currency would define these different types of accounts and their privileges.



4) Currency Complex – A given currency defines just one domain of measure. However, most currency environments depend on several different currencies interacting with one another. For instance, a “thumbs up, thumbs down” reputations currency can be used in concert with a mutual credit currency to give visibility to the reliability of the potential trading partners using the mutual credit currency. Many different currencies could be cross-referenced to produce a rich and resilient tapestry. Because currencies are modular within the currency complex, currencies can quickly evolve in an extensible way. Rules for currency could be contingent on metrics both inside and outside a given currency. For instance, let’s say you wanted to have a credit limit in a mutual credit currency be dependent on the user's volume of transaction in the currency multiplied by the percent of "thumbs up" ratings. The user would need two accounts within the mutual credit currency, and an account in a second reputations currency. The user's buying power in the mutual credit currency would be a sum of all transactions. The user's transaction volume would be the sum of the absolute values of all their transactions (calculated in separate account). The user's history in the "thumbs up, thumbs down" currency would be calculated as an average. The credit limit for the first, could be linked to the second and the third (credit limit increases to 1000 when you have conducted 10,000 worth of business with 90% thumbs up).


5) ID – A person using this platform will need to have some sort of identity boundary on the currency platform. This is distinct from having an account, since an account, as I am defining it, is merely the place where one currency is aggregated. An ID will be able to have multiple different types of accounts within one currency, participate in multiple currencies within one currency complex, and participate in multiple currency complexes. The ID simply allows multiple different currencies to be grouped and displayed according to user.