An architecture for the internet of money

11/26/2014

An architecture for the Internet of Money v0.2.9

An architecture for the Internet of Money v0.2.9 An architecture for the Internet of Money version 0.2.9

1. Introduction Satoshi Nakamoto’s great invention of Bitcoin can be appreciated as having 2 distinguishing features: a. Bitcoin is a public decentralized cryptographic ledger with basic ledger contracting capabilities. b. The cryptographic ledger tracks balances of a new currency bitcoin.

Effort has been directed towards architecting a parallel financial system with bitcoin the currency as a base layer.

The driving force are flexibility benefits of cryptographic ledgers enabling new use cases like Multi­signature accounts, Decentralized exchange, Machine to machine transactions etc. This paper analyzes applications of cryptographic ledgers in the current financial system and aims to stimulate the discussion: What are the speed, cost and flexibility advantages that can be realized if financial institutions tracked asset and liability balances utilizing public decentralized cryptographic ledgers with basic ledger contracting capabilities?

Such ledgers enable new ways to build Real Time Gross Settlement systems like CHAPS and FedWire; Deferred Net Settlement systems resembling ACH, Bacs and correspondent banking; foreign exchange markets; stock exchanges and other pillars of the financial system. This article encapsulates these disparate elements into a coherent layer based framework christened “The Internet of Money”.

Perceived benefits from the Internet of Money will be enumerated along with system descriptions. These benefits form the motive for the proposal.

2. Abbreviations and Definitions ● ACH: Automated Clearing House, a system enabling Deferred Net Settlement basis retail payment processing in the United States. ● Bacs: A system enabling Deferred Net Settlement basis retail payment processing in the United Kingdom. ● CHAPS: The primary Real Time Gross Settlement funds transfer system utilized for high­value transfers in the United Kingdom. ● Consensus Pool: A set of servers, with defined owners, that continuously arrive at consensus on the state of a ledger using a fault tolerant algorithm. Healthy consensus pools are characterized by several servers controlled by different parties. ● DApp: Decentralized Application. ● DE: Decentralized Exchange. ● DEP: Decentralized Exchange Protocol, described in section 7a. ● DNS: Deferred Net Settlement. ● DNSP: Deferred Net Settlement Protocol, described in section 7d. ● FedWire: The primary Real Time Gross Settlement funds transfer system utilized for high­value transfers in the United States. ● FR: Federal Reserve of the United States. ● Issuer: A party that issues assets on a cryptographic ledger. The party can be a Bank, Company, Decentralized Autonomous Organization, Government or Private individual. The asset could be a commodity backed token, currency, informational commodity, share in a company, token representing airline miles etc. ● Ledger contracting: Please refer to sections 3 and 4 for an explanation. https://docs.google.com/document/d/1Bc­kZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

1/29

11/26/2014

An architecture for the Internet of Money v0.2.9

● ODFI: Originating Depository Financial Institution, the bank that initiates an ACH credit. ● OFI: Originating Financial Institution, the bank that initiates a FedWire credit. ● RDFI: Receiving Depository Financial Institution, the destination bank for an ACH credit. ● RFI: Receiving Financial Institution, the destination bank for a FedWire credit. ● RTGS: Real Time Gross Settlement. ● RTGSP: Real Time Gross Settlement Protocol, described in section 7c. ● SIPS: Systemically Important Payment System ● SL3P: Static Liquidity Payment Processing Protocol, described in section 7b. ● Tx: Transaction.

3. Framework Inspired by the OSI layer model, a framework for the Internet of Money follows in Figure 1.

Subsequent sections detail requirements and capabilities at each layer. The paper can be broken down into following segments: ● Sections 4 and 5 describe ledger contracting, an innovation pioneered by Bitcoin and conceptually upgraded by the Ethereum project. Ledger contracting forms the basis for multiple components in the article. Descriptions of Bitcoin in section 4, while correct from an abstract vantage point, diverge significantly from the current implementation. ● Sections 6, 12 and 13 deal with the ledger layer. Section 6 makes gross assumptions and omits justification. Justifications and detailing follow in section 12. Purpose of section 13 will be expressed in section 5. ● Sections 7a, 7b, 7c and 7d deal with Decentralized Exchange Protocol (DEP), Static Liquidity Payment Processing Protocol (SL3P), Real Time Gross Settlement Protocol (RTGSP) and Deferred Net Settlement Protocol (DNSP) respectively. This segment elucidates the core innovation underlying the Internet of Money. ● Section 8 shows protocols from section 7 can be unified to 2 fundamental ledger operations. This unification makes implementation tractable. ● Sections 9,10 and 11 respectively characterize the Pathfinding, Contract and Application layers. ● Section 14 posts important observations and open problems. ● References follow in section 15, and author details in section 16. https://docs.google.com/document/d/1Bc­kZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

2/29

11/26/2014

An architecture for the Internet of Money v0.2.9

Finally, notes on color coding:

● Dark blue bold fonts are used for section titles. ● Sky blue bold fonts are used for sub­section titles. ● Green bold fonts demarate Phases in multi­phase payment and exchange protocols. ● Grey bold fonts mark important definitions, observations or paragraphs. ● Article details other color and shape conventions as and when necessary.

4. Ledger contracting with Bitcoin Conventional ledgers are databases that track value balances corresponding to accounts. They permit clients to initiate operations subtracting X units from own account and crediting the same to a different account. To be a valid operation, the client’s account must possess a balance greater than X. Figure 1 is a visualization for 2 Citibank clients, Alice and Bob. Alice initiates the payment.

To above operation set, Bitcoin adds richness through ledger contracting. Ledger contracts are accounts that hold balances and operate with predefined rules. Entities external to Bitcoin, like Alice and Bob, cannot manipulate ledger contracts without fulfilling rules set during contract creation. This is implemented by having Bitcoin nodes reject transactions violating contract rules.

For instance, consider a scenario where Alice wants to transfer bitcoin to Bob with the proviso that Bob can spend the funds only after 31 Dec 2015. This is implementable by creating a ledger contract that holds the bitcoin balance temporarily. A transaction from Bob, claiming held bitcoins will succeed only after the date set in the ledger contract. Figure 3 plots such a transaction flow.

https://docs.google.com/document/d/1Bc­kZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

3/29

11/26/2014

An architecture for the Internet of Money v0.2.9

The ledger contract should be imagined as a neutral automated third party mediating a transactional relationship between Alice and Bob. Readers must bear in mind that above diagram is an abstraction, and Bitcoin is implemented differently.

Figure 4 provides a second illustration. Alice is a buyer and Bob is a seller; goods traded have a long delivery time. Trent is a third party trusted by both Alice and Bob. At purchase, Alice stores purchase value in a ledger contract, with the condition that: ● Two parties out of the 3 involved must sign transactions attempting to unlock contract funds. ● If goods received are faulty, Alice and Trent can route funds back to Alice. ● If and when sale concludes successfully, Bob and Trent complete the payment to Bob. Figure 4 shows transaction flow during successful sale and delivery. The ledger contract acts as neutral automated third party mediating a transactional relationship between Alice, Bob and Trent.

Bitcoin ledger contracts are coded using a stack­based bytecode language called ‘Bitcoin script’. Each ledger contract has code and a temporary data structure (stack) associated with it.

The Bitcoin contracting system has 2 significant limitations: https://docs.google.com/document/d/1Bc­kZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

4/29

11/26/2014

An architecture for the Internet of Money v0.2.9

● Value­blindness: Contracts cannot dispense value lower than the total funds stored inside them. In other words, at retrieval time, claimant must withdraw all of the funds in one operation. ● Lack of persistent storage / state: Contracts cannot store data, and this limits applications such as Decentralized Exchange.

Figure 5 plots a hypothetical scenario highlighting limitations. Alice wants to leverage a ledger contract to exchange Bitcoin for Dogecoin. She creates a ledger contract, and loads it with bitcoins desired for exchange. The contract is coded such that, when a counterparty furnishes Proof of Dogecoin payment to Alice’s address; the contract releases bitcoins to an address chosen by the counterparty.

The value­blindness limitation implies that Bob, a counterparty, must exchange exactly the amount Alice loaded in the contract. Counterparties could desire a smaller exchange size, and therefore prefer to retrieve a fraction of funds embedded in the ledger contract. This operation is not possible with a single Bitcoin ledger contract.

Assuming fractional exchanges are possible, the Bitcoin ledger contract must store proofs of payment that have been utilized. If such storage is absent, the counterparty can furnish the same proof of payment repeatedly to drain the contract unfairly. Lack of storage and value­blindness constrains applications such as decentralized exchange.

The previous example is solely intended to highlight limitations. It has other unstated flaws. Decentralized exchange with bitcoin would be better implemented through a different construct called Atomic Cross Chain Trades. It suffers from the same value­blindness limitation.

Next section highlights the elegant Ethereum approach, and forms the basis for protocols described herein.

5. Ledger contracting with Ethereum The Ethereum project introduces many innovations, of which the following are important for this proposal: a. Ledger contracts are value­aware and possess a persistent storage capacity. b. Ledger contracts can be loaded / unloaded with funds when required. Conditions for loading / unloading can be mandated by contract code. c. Messages containing data can be sent to ledger contracts. Contracts can respond with data replies and value transfers to inputs.

Utility of the above is demonstrated in Section 7. Hence examples are avoided here.

Other Ethereum innovations, being peripheral to our discussion, will be engineered away in section 12: https://docs.google.com/document/d/1Bc­kZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

5/29

11/26/2014

An architecture for the Internet of Money v0.2.9

a. Ledger contracts have access to certain types of random data. The intent is to provide an entropy source for gambling applications. b. Scripting language used to create ledger contracts is Turing complete, enabling contract logic to contain loops. c. Ledger contracts can create other ledger contracts, and hence have the same power as an external account controlled by a human. This is referred to as the “Contract first class citizen property”.

The combination of points b. and c. mean that infinite loops can potentially be triggered while updating the Ethereum ledger. The Halting problem places a limitation on evaluating whether an arbitrary script will terminate in finite time and prevents network nodes from rejecting transactions resulting in infinite loops. Ethereum uses its transaction fee structure to prevent and incentivize participants from submitting transactions triggering infinite loops.

The risk introduced by latter innovations is two­fold: a. The transaction fee method of preventing infinite loops will prove deficient in some, as yet unknown, way. b. Cleverly designed malicious contract code could escape the Ethereum Virtual Machine and cause damage to network nodes.

Section 12 deals with an approach to remove risk while enjoying certain benefits from Ethereum’s architecture.

The driving force is to reduce risk and complexity at seed stages of proposal implementation.

Sections 6­10 assume complete set of Ethereum ledger contracting abilities are valid.

6. Ledger layer The ledger layer is built using a protocol that enables a single party or group of parties to create ledgers and issue assets as required. Each ledger has an issuer of asset, a number for ledger identification, and an identification for the asset issued.

Minimal properties for ledgers are: a. Issuer of asset for each ledger is different from entities maintaining the ledger. b. Ledgers are maintained through a decentralized consensus process. The set of nodes participating in the consensus process is called a Consensus Pool. c. Ledger account balances, contracts and transactions are public. d. Transactions are initiated through the use of digital signatures. e. Multi­signature accounts are a fundamental requirement. f. Basic ledger contracting capabilities are required at each ledger. Set of minimal capabilities is detailed in section 12. g. Fast ledger transaction times, preferably less than two seconds for full confirmation. This is achievable for decentralized ledgers if identity of consensus pool nodes is known. We assume the same in the subsequent exposition. h. A time alignment mechanism for consensus pools and associated ledgers.

Section 11 provides justifications for aforementioned properties. Hyperledger enables maintenance of ledgers through the Practical Byzantine Fault Tolerance consensus algorithm, and is an example of a ledger layer protocol.

Bitcoin and Ethereum projects assume that network nodes are anonymous. Here, we assume that identity of consensus pool nodes is known, and this is a major point of divergence from other cryptocurrency projects. In addition, the focus is to propose a financial system interoperable with commodity backed currencies, informational commodities like bitcoin, fiat money, shares and other assets. Finally, the proposed system does not necessitate creation of any new currency or asset. https://docs.google.com/document/d/1Bc­kZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

6/29

11/26/2014

An architecture for the Internet of Money v0.2.9

Figure 6 visualizes a section of the ledger layer. Ledgers with the same asset type possess the same color. A black dot inside a colored circle stands for an account. Accounts corresponding to asset issuers are shown. Issuer names have been chosen to aid with visualization. Large banks and firms, being naturally and rightly conservative, are not initial customers for technology described herein.

If Carol holds assets on ledger 4, we assume that a trust relationship exists between her and the issuer of ledger 4 (Wells Fargo).

The case of Alice, holding USD assets on ledger 1 and wanting to transfer them to Bob, a customer of the same issuer on the same ledger, i.e intra­ledger transfer, is trivially resolved. Next section will consider inter­ledger transfers.

7. Payment and Exchange Layer This layer is tasked with resolving two situations faced by Alice and Bob: Situation 1: Alice possesses V USD issued by Citibank on ledger 1, and wants to exchange them for W Euros held by Bob on ledger 2. Fidor bank is the issuer of Euros. Section 7a tackles this scenario.

Situation 2: Alice holds V USD issued by Citibank on ledger 1, and wants to make a payment to Bob. Bob is a USD Wells Fargo customer on ledger 2. Sections 7b, 7c and 7d present resolutions.

The layer works by deploying one of four protocols. Section 7a deals with Decentralized Exchange Protocol (DEP), 7b with Static Liquidity Payment Processing Protocol (SL3P), 7c with Real Time Gross Settlement Protocol (RTGSP) and 7d with Deferred Net Settlement Protocol (DNSP). Micro­transaction payments are considered in Appendix A. 7a. Decentralized Exchange Protocol (DEP) https://docs.google.com/document/d/1Bc­kZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

7/29

11/26/2014

An architecture for the Internet of Money v0.2.9

Decentralized Exchange can be implemented as two interlocking ledger contracts created to mediate an exchange relationship. Figures 7a, 7b, 7c and 7d provide a visualization. For convenience, we name the two contracts as Dispensing contract and Accepting contract. The protocol proceeds in four phases and assumes Alice creates an offer accepted by Bob as a counterparty: Phase I: Alice creates Accepting and Dispensing contracts on the two ledgers a. Figure 7a is a representation of phase I. b. Alice creates Accepting contract on Ledger 2 and Dispensing contract on ledger 1. c. Combination of Accepting and Dispensing contracts constitute Alice’s offer for exchange. Pricing information is held as a storage entry in both contracts. d. Alice loads Dispensing contract with value V. e. Capabilities of Accepting and Dispensing contracts are elaborated in the text to follow.

Phase II: Bob credits Accepting contract and claims value from Dispensing contract a. Figure 7b visualizes phase II. b. Bob verifies that Accepting and Dispensing contracts constitute an acceptable offer and are structured correctly. c. Bob credits Accepting contract with value W. d. Accepting contract holds funds in a state that Alice needs claim message from phase IIIc to withdraw them. e. Bob furnishes proof of payment from previous step to Dispensing contract on ledger 1.

https://docs.google.com/document/d/1Bc­kZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

8/29

11/26/2014

An architecture for the Internet of Money v0.2.9

Phase III: Dispensing Contract releases funds to Bob and sends claim message to Alice a. Figure 7c sketches steps for phase III. b. Dispensing contract verifies proof of payment and checks whether the same has not been used previously. When valid it transfers value V to Bob on ledger 1, and adds proof of payment data to contract storage. c. Dispensing contract sends a claim message to Alice on ledger 1. This can be used to claim funds from Accepting contract immediately or per Alice’s convenience.

Phase IV: Alice uses claim message to extract funds from Accepting contract a. Figure 7d is a representation of phase IV. b. Alice sends claim message to the Accepting contract. c. Accepting contract verifies veracity of claim message, and checks whether the same has not been used in the past. https://docs.google.com/document/d/1Bc­kZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

9/29

11/26/2014

An architecture for the Internet of Money v0.2.9

d. If claim message is valid, Accepting contract releases funds to Alice on ledger 2. It adds data about claim message to storage.

Capabilities of Dispensing and Accepting contracts a. Dispensing contract must hold value V in escrow, and be capable of verifying proof of payment from ledger 2. Used proofs need to be stored in memory to prevent re­use. b. Accepting contract must hold value W in escrow, and be able to verify claim messages from ledger 1.

Claim messages already utilized must be written to contract storage for preventing re­use.

Aforedescribed flow assumes that the exchange is atomic i.e. value V in Dispensing contract is claimed in a single transaction. This is modifiable to include scenarios with Bob claiming a fraction of the offer by transferring value X (X<W) to Accepting contract in phase II. Additionally, there are two edge cases to be considered: a. Insufficient balance at the Dispensing contract: Because there may be no restriction on the number of counterparties transferring funds to the Accepting contract in phase II, it can transpire that there exists insufficient balance at the Dispensing contract for Bob to claim his funds. To prevent loss of funds for Bob, an additional functionality must exist enabling Dispensing contracts to send ‘Exchange rejected’ message to Bob on ledger 1. Reject message can be utilized by Bob to reclaim funds on ledger 2. No claim message is sent to Alice, and hence she cannot unlock funds on ledger 2. b. Order cancellation for Alice: Alice must posses an ability to withdraw or add funds to the Dispensing contract, with a complete withdrawal signifying order cancellation. Such an ability does not interfere with the transaction flow described previously. Insufficient balance resulting from withdrawals can be handled by the Reject message flow described in the previous point.

Although DEP is trustless and peer­to­peer, there exists a niche for information services tracking exchange offers on different ledgers. Services can query consensus pool nodes for offers and verify that ledger contracts are structured correctly. Counterparties can remunerate services to access updated information. Purely informational services are the Internet of Money equivalent for order books.

DEP is powerful as it eliminates the need for mediating parties in currency and share exchanges. Figure 8a plots parties and relationships required in conventional share exchanges between Alice and Bob. Figure 8b with DEP https://docs.google.com/document/d/1Bc­kZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

10/29

11/26/2014

An architecture for the Internet of Money v0.2.9

delivers a contrast to 8a, and underscores the potential for low cost exchanges. A similar parallel exists for currency exchanges.

The role of the Central Securities Depository and Custodians is replaced by the public Apple shares cryptographic ledger. Brokers and Stock exchanges are replaced by information services tracking offers on ledgers. There is no requirement for a Clearing House as Alice and Bob bear no counterparty risk and protocol execution takes ~4 seconds for Bob.

Finally, DEP serves as a bridge connecting fiat currencies and informational commodities such as ether and bitcoin.

7b. Static Liquidity Payment Processing Protocol (SL3P)

https://docs.google.com/document/d/1Bc­kZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

11/29

11/26/2014

An architecture for the Internet of Money v0.2.9

Unlike Decentralized Exchange, which is an evolutionary improvement over the current system, SL3P is a new modality of payment processing.

Consider the situation in Figure 9a. Alice possesses V USD issued by Citibank on ledger 1, and wants to make a payment of the same value to Bob. Bob is a USD Wells Fargo customer on ledger 2. There also exists Carol, a party unrelated to Alice and Bob, holding balances on both ledgers. Carol: a. Trusts both Citibank and Wells Fargo as Issuers. b. Is indifferent to the magnitude of individual balances held at both ledgers, as long as their total remains constant. c. Holds greater than V USD with Wells Fargo. d. Has no immediate need to transact with balances held at both ledgers i.e. her balance is Static Liquidity.

Following transaction set, pictorially depicted in Figure 9b, resolves the payment: a. Alice pays Carol V USD on ledger 1. b. Carol pays Bob V USD on ledger 2.

https://docs.google.com/document/d/1Bc­kZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

12/29

11/26/2014

An architecture for the Internet of Money v0.2.9

SL3P leverages two ledger contracts to enable multiple desirable properties with above transaction logic: a. Ledger contracts assure Alice that Carol will pay Bob on ledger 2, or she will receive her money back on ledger 1. b. Ledger contract can be persistent i.e. Carol structures contracts once and contracts process multiple payments between different parties autonomously. c. Carol can charge processing fees for payments enabled by her Static Liquidity.

The protocol proceeds in four phases: Phase I: Carol opens an SL3P channel by creating contracts on both ledgers a. Figure 10a is a representation of phase I. b. Carol creates SL3P contract 1 on ledger 1 and SL3P contract 2 on ledger 2. c. Combination of symmetric SL3P contracts 1 and 2 is called an SL3P channel. Contracts store magnitude of fees charged per transaction as data entries. d. Carol loads contract 1 with value X, and contract 2 with value Y. e. Capabilities of SL3P contracts are elaborated in the text to follow.

Phase II: Alice credits SL3P contract 1 and claims a payment to Bob from SL3P contract 2 a. Figure 10b visualizes phase II. b. Alice wants to pay Bob value V and verifies that SL3P contract 2 contains a balance larger than V. If yes, she proceeds to next step. c. Alice transfers V USD to SL3P contract 1. d. SL3P contract 1 holds funds in a special state. These funds can be withdrawn only after phase IV, or if SL3P contract 2 fails to pay Bob in phase IIId. e. Alice pushes proof of above payment to SL3P contract 2, and initiates a transfer to Bob’s account on ledger 2.

https://docs.google.com/document/d/1Bc­kZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

13/29

11/26/2014

An architecture for the Internet of Money v0.2.9

Phase III: SL3P contract 2 verifies claim and makes a payment to Bob a. Figure 10c sketches steps for phase III. b. SL3P contract 2 verifies proof of payment and checks whether the same has not been used previously.

When valid, it transfers value V to Bob and ‘State change message’ to Carol on ledger 2. Proof of payment data is added to contract storage. c. State change message can be used by Carol to make SL3P contract 1 funds deposited in phase IIc withdrawable by her. d. If balance is insufficient, contract sends a ‘Payment reject’ message to Alice on ledger 2. Alice can use the reject message to claim funds from SL3P contract 1. e. There is no role for Bob in the protocol except to verify for successful transfer.

Phase IV: Carol uses state change message to render funds withdrawable by her a. Carol pushes state change message from previous phase to SL3P contract 1. b. SL3P contract 1 verifies state change message, stores message in memory to prevent re­use, and converts value V to be withdrawable by Carol in the future. https://docs.google.com/document/d/1Bc­kZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

14/29

11/26/2014

An architecture for the Internet of Money v0.2.9

c. Only funds that are withdrawable by Carol participate in future SL3P payments. Carol can delegate phase IV to a third party. Third party monitors SL3P contracts and ensures they have sufficient participating static liquidity.

Capabilities of SL3P contracts a. SL3P contracts must hold balances in escrow and be capable of verifying proofs of payment and state change messages. Used proofs and messages need to be stored in memory to prevent re­use. b. In case of insufficient balance to complete an SL3P payment, destination contract must issue a ‘Payment rejected’ message to the initiator. Payment rejected messages should enable value reclaiming from the other paired contract. c. SL3P contracts must allow Carol to make deposits or withdrawals provided such actions do not violate contract conditions. Channel termination is a complete withdrawal of balances from both contracts by Carol followed by resolution of all outstanding payments.

The protocol can also work in the reverse direction. Because SL3P contracts are symmetric, Dave can initiate a payment from Ledger 2 with the destination being Eve on Ledger 1.

Payment processing is converted to a peer­to­peer format paving the way to a competitive market. The protocol is a combination of 2 transfers and contract computation, and therefore can be executed in ~4 seconds.

Domestic correspondent banking can be visualized by assuming Carol as one of the 2 interacting issuers. For instance, assume issuer for ledger 1 is Issuer 1. If Issuer 1 opens an SL3P channel with deposits on ledger 2, resulting structure is the equivalent of a domestic correspondent banking relationship. Readers should bear in mind that domestic corresponding banking is increasingly an anachronistic solution.

SL3P improves over Deferred Net Settlements because issuers do not assume credit risk for payment processing.

To mitigate against credit risk in Deferred Net Settlements, issuers are required pledge collateral with the national clearing house. SL3P introduces no such necessity.

Another key advantage is the creation of new pools of liquidity for payment processing. Liquidity cost is the determining factor for pricing of RTGS payments. A core assumption in the current system is that liquidity needed for payment processing is furnished by issuers. SL3P can break this assumption, build a larger liquidity pool and therefore result in cheaper payments. https://docs.google.com/document/d/1Bc­kZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

15/29

11/26/2014

An architecture for the Internet of Money v0.2.9

7c. Real Time Gross Settlement Protocol (RTGSP) Similar to SL3P, RTGSP solves the problem: Alice possesses V USD issued by Citibank on ledger 1, and wants to make a payment of the same value to Bob. Bob is a USD Wells Fargo customer on ledger 2.

RTGSP is the proposal’s equivalent of the FedWire system used for high value transfers in the United States. It allows interacting issuers to settle inter­bank liabilities accruing from payments on the FR ledger. Figure 11 plots the FedWire transaction flow.

Alice initiates a FedWire credit, with Citibank acting as the OFI and Wells Fargo as the RFI. Citibank debits Alice’s account immediately and Wells Fargo credits Bob’s account after a few minutes.

Internally, Citibank submits a credit request to the FR, which then forwards it to Wells Fargo. The FR processes a settlement transaction sending money from Citibank to Wells Fargo on the FR ledger. As the transaction happens in real time and the complete settlement amount is transferred in gross, this modality of payment processing is called a Real Time Gross Settlement (RTGS). Citibank and Wells Fargo assume no credit risk.

This point onward, we refer to Citibank as Issuer 1, and Wells Fargo as Issuer 2. The objective is to demonstrate a payment protocol assuming Citibank, Wells Fargo and the FR operate cryptographic ledgers.

SL3P provides a route as sketched in Figure 12. Issuers open one­way SL3P channels between the FR ledger and ledgers tracking their own assets. An SL3P channel maintained by Issuer 2 is plotted in Figure 12. On ledger 2, Issuer 2 creates assets and loads one end of the channel, sketched in dark pink.

‘One­way SL3P channel’ refers to a modified construction where payments flow only in one direction. This is a simple modification of ledger contracts from section 7b.

Alice initiates the transaction by transferring value V to Issuer 1. The transaction contains data specifying destination ledger and Bob’s account. This effectively destroys assets held by Bob and issued by Issuer 1. https://docs.google.com/document/d/1Bc­kZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

16/29

11/26/2014

An architecture for the Internet of Money v0.2.9

Assuming Citibank has requisite liquidity, it transfers value V to SL3P contract maintained by Issuer 2 on the FR ledger. Next, it pushes a proof of payment to other side of the channel on ledger 2, and claims a transfer to Bob’s account.

Assuming sufficient contract balance, ledger 2 SL3P contract verifies proof of payment and completes the transfer. Issuer 2 keeps loading funds periodically into the contract to keep RTGSP transfers flowing. In case of insufficient contract balance, Issuer 1 can re­try or claim back funds from the other end of the channel.

Although the previous set demonstrates that RTGSP is feasible, it does not tackle the central challenge of an RTGS system: liquidity management. Appendix B considers methods for the same.

RTGSP could enable automation of FedWire and other Gross settlement systems, with the role of the FR reduced to being a pure issuer. The system can stay operational as long as Consensus Pool for the FR ledger is reachable.

Currently, use of the FedWire system is restricted to between 09:00 and 18:00 ET in the United States.

Decentralization of the FR ledger and RTGS system can be a good operational risk reduction and business continuity policy. Nodes can be distributed geographically, made dependent on different power systems, and data redundancies / backups created. In general, all Systemically Important Payment Systems tangibly benefit from decentralization through operational risk reduction.

7d. Deferred Net Settlement Protocol (DNSP) DNSP solves the same problem as SL3P and RTGSP: Alice possesses V USD issued by Citibank on ledger 1, and wants to make a payment of the same value to Bob. Bob is a USD Wells Fargo customer on ledger 2.

https://docs.google.com/document/d/1Bc­kZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

17/29

11/26/2014

An architecture for the Internet of Money v0.2.9

Instead of payment clearing and settlement being a transfer on the FR ledger like RTGSP; DNSP results in the creation of a debt obligation from Citibank to Wells Fargo. Multiple obligations are aggregated, and net amounts are transferred between issuers as bilaterally agreed on the FR ledger. Payment clearing is the creation of inter­ issuer debt obligation and payment settlement is the transfer on the FR ledger. DNSP defers payment settlement to a timepoint after payment clearing. The protocol has a requirement for inter­issuer trust unlike the others.

A combination of DEP, SL3P and RTGSP can be sufficient to handle a large part of banking transactions. DNSP is included for the sake of completeness. It is the equivalent of the ACH system in the United States.

Central to DNSP is the construct of traversal transactions pioneered by Ryan Fugger and the Ripple project. A traversal ledger, which enables traversal transactions, has following properties in addition to ledgers hitherto considered: a. The ability of accounts to create trust lines to other accounts. A trust line is an approval from an account holder to the consensus pool, allowing the pool to change account balances pursuant to values and parties specified in the trust line. b. The ability of consensus pool to route a payment from one account to another by changing balances in other accounts, subject to limitations imposed by trust lines.

Figure 13 considers a US dollar traversal ledger, with 4 participants: Eve, Frank, Gary and Harry. Figure 13a, on the left, shows the current status of trust lines. A line originating at Frank and terminating at Eve with value M USD signifies Frank’s approval to have Eve owe him a maximum of M USD. Participants can alter trust line values dynamically.

Figure 13b, on the right, shows a traversal transaction payment from Eve to Harry worth W USD. Before payment, we assume none of the participants owe each other any money. After the transaction, Eve owes Frank W USD, Frank owes Gary W USD and Gary owes Harry W USD. Harry accepts this as a payment of W USD. Net balance for each account equals funds owed to participant minus funds owed by participant. Net balance for Frank and Gary remain unchanged by the transaction. Gary and Frank do not actively participant in the transaction. Harry’s role is to verify the payment.

Because the ledger may contain more participants; the consensus pool computes the optimal payment path, sketched through red arrows in 13b, and adjusts balances autonomously.

https://docs.google.com/document/d/1Bc­kZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

18/29

11/26/2014

An architecture for the Internet of Money v0.2.9

For DNSP, we assume multiple issuers are part of a domestic traversal ledger. Traversal ledger becomes a payment clearing mechanism, with trust lines negotiated between pairs of issuers. DNSP proceeds in 2 phases, sketched in Figure 14a and 14b.

Phase I: Alice initiates payment and Issuer 1 reserves value V on ledger 2 a. Issuers create an escrow contract on ledgers tracking their assets, and load it with funds. Capabilities of escrow contract are explained later. b. Alice transfers value V to Issuer 1 on ledger 1. Transaction contains destination ledger and Bob’s address as metadata. c. Issuer 1 makes a traversal transaction payment worth value W to Issuer 2 on the domestic clearing ledger. W is smaller than V and can be ~5 USD. d. Issuer 1 pushes proof of above payment to escrow contract on ledger 2, requesting contract to reserve value V. e. Escrow contract verifies proof of payment. Next steps assume a valid proof. f. If contract possesses funds greater than V, it reserves V for time T. During period between 0 and T, V can be transferred only to Bob when Issuer 1 completes Phase II. T can be approximately 1 minute. g. If contract does not possess requisite funds to complete the reservation, it transfers W to Bob, and sends Issuer 2 a ‘Reservation rejected’ message.

Phase II: Issuer 1 transfers value (V ­ W) on clearing ledger and claims payment to Bob a. Assuming reservation has succeeded, Issuer 1 transfers value (V­W) to Issuer 2 on the clearing ledger. https://docs.google.com/document/d/1Bc­kZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

19/29

11/26/2014

An architecture for the Internet of Money v0.2.9

b. Issuer 1 pushes proof of above payment to escrow contract on ledger 2, and claims a payment of value V to Bob. c. Escrow contract verifies proof of payment, and if valid, transfers reserved funds to Bob on ledger 2. d. Incase Issuer 1 is unable to complete phase II within time T for which funds were reserved, it can claim a transfer worth value W to Bob. There can be a penalty value X (X<W) levied by escrow contract for such scenarii.

In its current state, DNSP suffers from one deficiency. During Phase I, escrow contract may be depleted and contain value less than W. This can lead to Issuer 1 suffering a loss of W. Deficiency can be tolerable due to following reasons: a. Value at risk is low. W can be approximately 5 USD and is small in scale compared to payments handled by the fiat system. b. If escrow contract is depleted, all DNSP payments on ledger 2 are stopped and problem is escalated as ledger 2 is public. Reputation of Issuer 2 will be damaged through periods of DNSP shutdown.

Debt obligations between issuers arising out of DNSP are settled on the FR ledger as bilaterally agreed.

Settlement is a simple transfer from one issuer to another on the FR ledger, and is therefore not illustrated.

DNSP separates the clearing and settlement processes, resulting in a speedy transfer (~10 seconds) to Bob’s account. Many current systems, like ACH in the United States and Bacs in the United Kingdom, clear and settle transfers once a day. Hence, DNSP could be an improvement. Additionally, the ‘trust line design’ of clearing ledger removes the 2­tiered centrally operated membership systems present today. Any issuer can take part in clearing as long as it is able to obtain a trust line from another issuer.

https://docs.google.com/document/d/1Bc­kZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

20/29

11/26/2014

An architecture for the Internet of Money v0.2.9

Being a Systemically Important Payment System, decentralization of the Clearing ledger reduces operational risk and can be a good business continuity approach.

8. Unification Previous section with its characteristic proliferation of protocols can appear daunting from the perspective of implementation. This apparent complexity is a result of interactions in the fiat system, and can be reduced to an elegant simplicity at the implementation level.

A key observation is that ledger contracts utilized for DEP and RTGSP are derivatives of SL3P. Figure 15 expresses the statement.

For the above statement; perhaps the challenge is to visualize how Dispensing and Accepting contracts are derivatives of the SL3P contract. Please refer to Section 7b and replace Carol with Alice; Alice and Bob with Bob. In addition, instead of the ledger dealing with a single currency, have them deal with different currencies.

Transaction flow resulting from these substitutions is a currency exchange.

We can elect to stop referring the protocols by different names, although the author believes it is helpful to differentiate.

9. Pathfinding Layer At the pathfinding layer, protocols described previously are treated as atomic operations of 5 types: a. Value transfers between 2 accounts on one ledger. Execution time is assumed to be ~2 seconds. b. Value exchanges between 2 ledgers tracking the same or different asset types through DEP. Execution time can be assumed to be ~4 seconds. c. Value transfers between 2 ledgers tracking the same currency type through SL3P. Execution time can be assumed to be ~4 seconds. d. Value transfers between 2 ledgers tracking the same currency type through RTGSP. Execution time can be assumed to be ~6 seconds. e. Value transfers between 2 ledgers tracking the same currency type through DNSP. Execution time can be assumed to be ~10 seconds.

Any global payment, remittance, asset purchase or exchange originating at one cryptographic ledger and ending at another can be broken down into atomic operations of the 5 types mentioned above. The pathfinding layer is tasked with calculating the optimal set of atomic operations to be executed for the desired value transfer or exchange. https://docs.google.com/document/d/1Bc­kZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

21/29

11/26/2014

An architecture for the Internet of Money v0.2.9

Small world networks such as social networks provide short connecting distances between any 2 nodes. We suppose, without proof, that the Internet of Money financial network will also be a small world network.

Practically, this means that any global transfer / exchange of value can be executed in maximum 5­7 atomic operations. A maximum transfer time of 1 minute globally looks acceptable at this juncture.

The raw data for the pathfinding algorithm is of following types: a. Real time database of DEP offers on different ledgers. b. A set of SL3P channels operating between ledgers. c. A set of globally recognized RTGSP networks. d. Sets of issuers that participate in RTGSP networks. e. A set of globally accredited DNSP networks. f. Sets of issuers that participate in DNSP networks. g. Cost function data for monetary costs towards executing atomic steps.

The analogue for the pathfinding layer in the architecture of the Internet are routing protocols such as RIP, OSPF and BGP. Communication routing through the internet requires routers and nodes to broadcast reachability information continuously; and can be visualized as a quasi­distributed algorithm across multiple routers / nodes.

In the Internet of Money, centralized services where a routing query can be sent and an optimal path received look feasible. Data gathering and computation are outsourced to these services relieving the clients from workload.

Consideration of exact algorithm to calculate optimal paths from raw data is left for a future article.

Once optimal paths are received by the client, it proceeds to execute the atomic operations resulting in global value transfer and exchange.

Figure 15 is a visual representation of pathfinding. Alice owns Swiss Franc assets on the UBS ledger and wants to purchase Apple shares. She issues a routing query to pathfinding server. Pathfinding server has a database of RTGSP networks, DNSP networks and contracts on different ledgers. It evaluates 3 alternative paths, indicated in the figure, that Alice could take. It forwards the optimal path to Alice after accounting for payment and exchange fees.

Alice’s client has protocol software to execute actions required for atomic operations. She does the same and achieves the desired asset purchase.

https://docs.google.com/document/d/1Bc­kZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

22/29

11/26/2014

An architecture for the Internet of Money v0.2.9

10. Contract Layer The contract layer enables the intersection of value and arbitrary code running to alter value balances. This would be implemented through the construct of programmable oracles conceived by the Codius project and Gavin Andresen.

From the vantage point of the contract layer, lower layers act as a singular global ledger. This abstract ledger can hold balances and move any assets in under 1 minute.

Funds intended for a smart contract are channelled into an M­of­N multi­signature account controlled by a set of specialized entities (programmable oracles) and the contract code is simultaneously sent to all of these entities.

Every time contracting parties wish to send a message to the contract, they direct the message to the oracles. The oracles run the code to compute participant balances. If code execution leads to withdrawal of funds from the contract to some particular address, then the oracles circulate a transaction transferring the funds and sign it. Fund transfers are handled by the lower layers of the Internet of Money. Figure 17 visualizes the contract layer.

https://docs.google.com/document/d/1Bc­kZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

23/29

11/26/2014

An architecture for the Internet of Money v0.2.9

Section 12 deals with quantifying differences between ledger contracting and the contract layer. In general, ledger contracting is used to build Payment and Exchange protocols. Other smart contract use cases are implemented at the Contract Layer.

As an example, an application is a London brent crude oil futures contract between Alice and Bob. The contract is represented by computer code executed by the oracles; these entities fetch external data to compute new balances for Alice and Bob at settlement time. After code execution, balances are credited back to Alice and Bob using lower layers of the Internet of Money.

A second example is sophisticated buyer and seller intermediation of the type sketched in Figure 4. Alice, the buyer, and Bob, the seller, would like payment amount to depend on time taken for successful delivery. Bob needs to be penalized for longer delivery times. A contract is created and Alice loads funds. Contracting service verifies proof of goods delivery and pays Bob accordingly.

A third example is an auction for digital assets. Contracts can be structured to carry out rules for an auction if ownership of digital asset or title are handed over to the programmable oracles.

11. Application Layer Parallel to the TCP­IP protocol suite, this layer houses applications and user interfaces for consumers. In particular, the following appear commercially significant: Debit and credit based payment networks Although the Internet of Money is foreseen to deliver an order of magnitude improvement in speed of value transfer globally, some use cases require payment networks like Visa and Mastercard. Such cases are: a. Situations where transfer confirmation needs to be instantaneous like in­store purchases. b. The requirement for multiple atomic transfer and exchange operations necessitates private keys to be used multiple times. A dedicated payment network could deliver additional security. https://docs.google.com/document/d/1Bc­kZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

24/29

11/26/2014

An architecture for the Internet of Money v0.2.9

c. Payment networks could facilitate arbitration between buyers and sellers.

It is feasible to reduce settlement risk borne by payment networks as a result of fast payment and exchange times facilitated by this technology. Visa’s estimated settlement exposure stood at $53.8 billion on September 30, 2013.

Finally, the contract layer enables new methods of arbitration like double deposit escrow.

Futures, options, derivatives, prediction and other markets One key design principle behind this article is the principle of unbundling: Each function for the Internet of Money is operated by distinct specialized entities. For example, consensus pools specialize in ledger maintenance, banks in asset issuance and regulations, pathfinding services in pathfinding, and other firms in contracting and applications.

The contract and application layers enable competitive markets for development of futures, options, derivative and prediction markets. Different services can specialize in slices of these markets.

Games of Hazard as smart contracts As a demonstration, the game of Roulette can be visualized as a contract with the following logic: a. Spinning of the Roulette wheel is emulated by a source of entropy. b. Alteration of player balances is represented by code with the generated entropy as input. c. Value transfers and exchanges occur through lower layers of the Internet of Money.

We state, without proof, that all games of hazard including poker, blackjack are implementable as smart contracts.

Decentralized Applications The abstract ledger is a strong foundation to build Decentralized Applications. Current approaches have relied on creating new tokens for accessing services such as decentralized storage, mesh networking and reputation systems. The Internet of money provides an alternative to build token­less DApss. As an example, a design outline for a hard disk space sharing DApp is considered in Appendix C. 12. Revisiting the Ledger layer This section will consider some issues to develop a better understanding of minimal requirements at the ledger layer (Section 6): Why can’t ledgers be controlled by issuers?

Payment and Exchange protocols are structured such that entities different from the issuer execute transactions on a ledger. An example is RTGSP: Issuer 1 is routing a payment to Bob on ledger 2 without involvement from Issuer 2. Now assume that a server belonging to Issuer 2 is the only node in consensus pool maintaining ledger 2.

Issue with the above is that Issuer 2 can possibly create a new ledger history, inconsistent with the previous history, claiming that Issuer 1 never completed the payment to Bob. If old history data is unavailable to Alice and Issuer 1, there may not be a good way to dispute the new history. The legal cost of disputing could be larger than expected reparations.

Solution posited is to have multiple parties maintain ledgers through a decentralized consensus process. Through decentralization, issuers and consumers can be assured of impartial ledgers. Hence: Decentralization serves to increase confidence in the impartiality of ledgers. The more diverse and numerous the composition of nodes in consensus pool maintaining a ledger, stronger is the guarantee of impartialness. https://docs.google.com/document/d/1Bc­kZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

25/29

11/26/2014

An architecture for the Internet of Money v0.2.9

Tradeoff inherent with decentralization is efficiency. Nodes need to verify each other’s processing and communicate to arrive at consensus. This necessitates higher computation and bandwidth than an equivalent centralized ledger.

Decentralization for decentralization’s sake is not a strategy to be advocated. The article’s perspective is: Extent of decentralization required for a particular use case is an optimization problem Factors impacting efficiency, defined as transactions processed per NPV dollar of investment in nodes, are: a. Choice of consensus process. b. Node identity assumptions. Efficiency improves dramatically when identity of nodes is known. Bitcoin nodes are anonymous and network incurs a high cost, ~$500 million per year, to arrive at consensus. c. Number of nodes. Generally the larger a consensus pool, lower the efficiency.

Factors affecting confidence in impartiality of ledgers: a. Consensus pool composition. When a reputable firm like Google owns nodes in a pool, it boosts confidence in the pool. Malicious act originating from a Google­owned node will damage its hard won market reputation. At stake are real goodwill assets of Google which arguably total over a billion dollars. b. Choice of Consensus process. For instance, Practical Byzantine Fault Tolerance can tolerate up to 33% malicious nodes in a pool. c. Number of different entities controlling nodes in a consensus pool. Higher the number, more the confidence.

Amount of confidence required for a ledger depends on the value at risk. The strategy advocated is to: Aim for an optimal balance between value at risk, efficiency and confidence in ledgers.

For instance, a small homogenous pool may be suitable for tracking loyalty points scheme of a 2­store grocery chain. Citibank’s ledger will benefit from a high degree of confidence / decentralization.

The optimal ledger layer protocol Because each use case has a different optima for pool composition, number of nodes etc., the ledger layer protocol needs to be extremely flexible. There should not be restrictions on usage, openness and development of the protocol. Consensus process should deliver best feasible efficiency in a large cross­section of scenarios.

The Hyperledger project is a pioneer in this direction. Hopefully, other projects with similar objectives will follow.

Why should ledgers be public?

All payment and exchange protocols described herein depend on ledgers being public. Counterparties cannot view offers or verify payments on private ledgers.

If applications posited are valuable, counterbalancing privacy enhancing technologies need to be developed. In parallel, Governments need a method to monitor financial transactions. Investments in the Internet of Money can be viewed as bets that the cost of ensuring financial privacy will not exceed consumer benefits accruing from applications such as decentralized exchange.

Provided the privacy aspect can be resolved, the author is excited about potential advancements to theories of economics and crises management resulting from open access to transaction data globally.

On multi­signature accounts https://docs.google.com/document/d/1Bc­kZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

26/29

11/26/2014

An architecture for the Internet of Money v0.2.9

In addition to the consumer security enhancing benefits of multi­signature accounts, recall that the contract layer requires the same to assure trustworthy execution. Smart contracts should ideally be verified and executed by multiple distinct programmable oracles. A pool of oracles needs to own joint multi­signature accounts for daily operation.

On time­alignment mechanism for a consensus pool A time­alignment mechanism provides a method for pool nodes to consistently agree on the same clock time with an acceptable skew tolerance (up to 1 sec is admissible). Good design emanates from the desire to create powerful systems with minimal components. This paper has utilized time based transactions for DNSP and MTXP (Appendix A). Methods to do away with building a time alignment mechanism while retaining functionality need to be discovered.

13. Reducing risk and complexity at seed stage

14. Observations and open problems The fundamental advantage of cryptographic ledgers This paper posits that cryptographic protocols built utilizing cryptographic ledgers enable the formation of low trust financial relationships between participating issuers and consumers. Low trust relationships serve to reduce transactional and exchange costs, which can be passed down to consumers as a net saving.

Scalability Analysis Implementation of pull based payments The use of digital signatures lead all cryptographic ledger systems to be push based. Current implementation of ACH enables pull based ACH debits, and it has multiple applications like insurance payments, loan installments, utility payments etc.

A mechanism to enable such applications can be built at the contract / application layers. Consider the situation of Alice, a customer to Bob, a utility company. Alice and Bob create a smart contract hosted by mutually trusted oracles; and Alice loads the contract with funds intended for monthly utility payments. The contract contains rules letting Bob withdraw upto a certain amount every month.

Implementation of an Identity and Anonymity layer Compliance with regulations creates a problem of duality: Identities behind public keys must be accessible to certain organizations (issuers for example) yet should resist unmasking methods such as taint analysis. A consistent method of verifying issuers and ledgers is also a prerequisite.

15. References 1. https://bitcoin.org/bitcoin.pdf 2. https://en.bitcoin.it/wiki/Script 3. Pages 20­28, The TCP­IP Protocol Suite, 4th Edition, Behrouz A. Forouzan 4. http://hyperledger.com/ 5. https://www.regaltek.com/docs/understanding­ach­network.pdf 6. https://github.com/TierNolan/bips/blob/bip4x/bip­atom.mediawiki 7. https://github.com/petertodd/bips/blob/checklocktimeverify/bip­checklocktimeverify.mediawiki 8. http://gendal.wordpress.com/2014/01/05/a­simple­explanation­of­how­shares­move­around­the­ securities­settlement­system/ https://docs.google.com/document/d/1Bc­kZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

27/29

11/26/2014

An architecture for the Internet of Money v0.2.9

9. Pages 323­374, The TCP­IP Protocol Suite, 4th Edition, Behrouz A. Forouzan 10. https://github.com/codius/codius/wiki/Smart­Oracles:­A­Simple,­Powerful­Approach­to­Smart­ Contracts 11. http://gavintech.blogspot.ch/2014/06/bit­thereum.html 12. http://www.sec.gov/Archives/edgar/data/1403161/000140316113000011/R19.htm 13. http://bithalo.org/wp­content/uploads/2014/06/whitepaper_twosided.pdf 14. https://www.ethereum.org/pdfs/EthereumWhitePaper.pdf 16. Authorship and acknowledgements The author Meher Roy can be reached at: Email 1: meher.roychowdhury@gmail.com Email 2: mr@hyperledger.com LinkedIn: https://www.linkedin.com/pub/meher­roy/43/969/254 Twitter: https://twitter.com/MeherRoy Special thanks to Tim Makarios for pointing out errors, and suggestions regarding Responsible Traversal Transaction Protocol.

Possible updates for version 0.4 Alignment with Hyperledger whitepaper Hyperledger is the best example of a ledger layer protocol and the aim is a pair of 2 compatible papers (Hyperledger white paper + the current document).

Consideration of Responsible Traversal Transactions Protocol as a better DNSP Details can be found at: http://ideophilus.wordpress.com/2014/11/05/a­responsible­transitive­transactions­protocol/ Completion of appendices A, B and C Appendix A: Microtransaction Protocol (MTXP) Appendix B: Methods for RTGSP Liquidity Management Appendix C: An architecture for Decentralization Applications (DApps)

https://docs.google.com/document/d/1Bc­kZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

28/29

11/26/2014

An architecture for the Internet of Money v0.2.9

Published by Google Drive – Report Abuse – Updated automatically every 5 minutes

https://docs.google.com/document/d/1Bc­kZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

29/29