A technical overview of the open money platform
Abstract
The open money platform consists of three components: 1) a distributed mesh of linked entities, 2) an event "churn" that generates the mesh, and 3) a currency specification language. The mesh, with its small number of entity types (accounts, namespaces, currencies, & flows) and various link types specific to each entity type, along with the currency specification language, allows us to represent a vast array of wealth acknowledgment processes, in a scalable, distributed, and appropriately secure fashion. Together these three components (mesh, churn and language) form an alphabet that allow us to write down and bring into shared existence a myriad of new wealth acknowledgment patterns, and thus, opens a new form of literacy, the literacy of wealth.
The Mesh
The mesh provides the ontological underpinnings for the open money platform. Everything in open money is built out of the entities and links of the mesh. There are four basic types of entities:
- Namespaces: Namespaces provide an addressing space that situates accounts, currencies and sub-namespaces. Namespaces are the abstraction that map to communities of identity. They are the "surface area" in which the accounts and currencies are identified.
- Accounts: Accounts represent the endpoints of wealth acknowledgments. They can be seen as the "wallets" of open money. They are the places between which wealth acknowledgments flow, serving as declarer or accepter of a flow.
- Currencies: Currencies are the entities that describe a set of rules of a particular form of wealth acknowledgment, when they can happen, what information they need to record, the conditions of such recording, etc. Currencies define a community of function between all the accounts that use that currency.
- Flows: Flows are the records of particular wealth acknowledgments. Flows exist in relation to declaring and accepting accounts, as well as approving currencies.
Links are the ontological component that establishes relationships between entities. Each link is a uni-directional statement of relationship. There are five link types:
- names: The "names" link relates namespacess to accounts, currencies and other (sub)namespaces. This link establishes that a particular account, currency, or namespace is named within a namespace.
- is used by (* includes? -- Think direction of authority *): The "is used by" link relates currencies to accounts. This link establishes that a particular account is a member of the source currency.
declares & accepts: The "declares" and "accepts" links relate accounts to flows. They indicate that an account either originated or accepted the wealth acknowledgment recorded by the flow.- approves: The "approves" link relates currencies and namespaces to flows. This link establishes that a currency has approved that the wealth acknowledgment recorded in the flow follows the currency rules (e.g. that credit limits at the time of the acknowledgment are acceptable). Some currency definitions, or namespace rules may also require namespaces to approve flows.
The entity-link ontology is easily extensible. For example one could add an "auditor" entity which is linked to a flow with a "confirms" link.
On the web, the mesh is implemented as REST accessible resources. Thus each entity maps to a URL. The open money platform includes a name resolution infrastructure that resolves open money names to URLs. This is akin to how DNS resolves domain names to IP addresses. For example, an open money name like zippy.cc.us.ny might resolve to https://myccserviceprovider.com/accounts/735. Thus, the mesh can be distributed around the Internet on a large number of servers. This diagram summarizes all of the entities and link types and depicts a small portion of the mesh across two servers.
Security Considerations
Access control to entities in the mesh is handled by the assumption that each entity will store a list of credentials that must be provided before access is granted. The access control specification is very open-ended in that it assumes many different credentials and credential types to handle tiered access to aspects of entities (i.e. read vs. write access), as well as the assumption that credential schemes will change over time.
It is assumed that other aspects of security are handled out-of-band. I.e. privacy concerns are ensured by using https for transport when necessary.
The Churn
Whereas the mesh is the accessible state of the players, their identity and functional relationships as the history of the wealth-acknowledgments between them, the "churn" is the process by which new entities are added to the mesh and by which existing entities become further enmeshed. This "enmeshment" is the result of discrete events. Thus the mesh is the "nouns" of the open money world, whereas the churn is its verbs. There are just a handful of events, and they can be seen as procedure calls with parameters.
- Create Namespace: parameters: new namespace name, parent namespace
- Create Account: parameters: new account name, parent namespace
- Create Currency: parameters: new currency name, currency specification, parent namespace
- Join Currency: parameters: account, currency
- Acknowledge Flow: parameters: declaring account, accepting account, flow specification
The Currency Specification Language
Key to the open money platform is a language that allows us to model the variety of wealth acknowledgment patterns that communities want to create. The basic building blocks of the currency specification language are:
- Data Fields: What data and data type are collected in a given flow. examples: "amount in kWh" or "rating (1-4 stars)" or "amount in Euros and description" or "pounds of emitted C02 and hours of labor and subjective rating of employee enjoyment". Included in the specification of data fields is a human interface specification for how they are to be presented by a client in preparation for posting an acknowledge flow event. Note that this is a broad specification that will evolve for very complex presentation, but begins with a very simple localizable linguistic approach, i.e. the specification is just: "{declarer} acknowledges {accepter} for {description} in the amount of {amount}." The client software can then convert that into an appropriate presentation for the user. If the client software is a web-server it would likely be turned into an HTML form. If the client software is running on a cell phone, that kind of statement could be converted into an audio stream with key-press choices, etc.
- Summary: How will the history of acknowledgments be summarized. e.g. "balance" or "average" or "some complex mathematical formula taking all the data fields as parameters." The summary specification includes human interface presentation similar to that of Data Fields.
- User classes: Currencies often have different user types. For example Issuer Credit currencies will want to specify that some accounts may be currency issuers and others currency redeemers. Thus when accounts join currencies their "is_used_by" link will be marked with an "as" parameter which indicates which user class the account is in for that currency.
- Rules: The currency rules specify all the different functional properties of the currency. These rules are the heart of the currency specification language, and are specifiable in standard programing languages. The rules include things like:
- Joining rules: What are the rules for joining, is it an open currency? Do you need to be approved by the currency steward? What contract are you agreeing to by joining the currency? etc.
- Acknowledgment rules: Under what conditions can flows be enmeshed? These rules allow for implementation of things like credit limits, ratings limitations (i.e. you can't rate yourself), etc.
- User class rules: What can different user classes do? Can they issue currency? Can they accept it? What portions of the system are visible to them? Can they view summaries, transaction histories, etc.?
