full screen background image
Monday 20 November 2017
  • :
  • :

Cash and Credit in a Cryptocurrency Economy, part 2 – Open-Transactions

Open-Transactions is the cypherpunks’ vision of a cryptography-based contract system, embodied. Even when cryptography has made base money far more useful than in the past, cryptocurrency alone can not meet the requirements of an economy. Open-Transactions fills in many of these gaps by providing a secure cryptographic foundation for representing smart contracts.


This article is part of a series describing the complementary relationship between Bitcoin and Open-Transactions as tools for creating a new digital economy. This is the second article, describing Open-Transaction. Other articles in the series are The Legacy Financial System, and Practical Applications of Open-Transactions.

In part 1 we established that financial instruments are contracts. In order to understand why Open-Transactions represents an improvement over existing contract systems, we first need to understand contracts. The best way to create this understanding is to build from the ground up.

Contract Theory in a Nutshell

Leo and Bob are neighbours and home owners. Leo owns a lawnmower and Bob does not, and so Bob (the borrower) asks Leo (the lender) if he can use Leo’s. Nothing special or complicated about this deal—it’s representative of the common interactions that humans have engaged in surely even before civilizations formed. Normally this type of deal would remain a purely verbal agreement, with no need to create any special representation of the agreement. In theory, it’s possible for any agreement, no matter how detailed, to remain purely verbal. We’ll see why nobody uses arbitrarily-complex verbal contracts in practise by looking at what happens when something goes wrong.

The only time Leo and Bob will become deeply concerned about the exact nature of their verbal agreement is when something happens that does not meet their expectations. The problem could start by Bob refusing to return the lawnmower. When Leo asks for the return of the mower and Bob refuses, he might give any number of reasons why will not do so. He could claim that Leo gave it to him a gift instead of a loan, for example. Or, he could say that Leo had actually abandoned it by throwing it in the trash. Bob could give these reasons to Leo, as well as to anyone to whom Leo tries to tell his side of the story. At this point Leo has no objective way to refute Bob’s claim.

Leo cares about this objective proof because, in most civilizations, he wants to resolve the dispute by appealing to third parties. These third parties might be a small claims court in modern developed nations, or the open-air þing from the Norse era. Whatever Leo decides to do in order to get his lawnmower (or equivalent compensation) back, he wants the support of his community in doing so. If he just takes it by force, then he’s in a position where Bob might claim to have been assaulted. No matter what type of contract enforcement exists in Leo’s society, in order to obtain recourse for a broken agreement Leo needs objective evidence in order to convince neutral third parties of his standing. This is why any but the most trivial contracts tend to be expressed in a tangible form.

Suppose Leo and Bob’s agreement was written down and signed instead of only verbal. Now Bob will have a lot more trouble claiming to have misunderstood the loan as a gift. In order to dispute the nature of the agreement, he needs to claim that his signature was forged, or perhaps he was forced to sign the contract under duress. Leo will have a much easier time convincing neutral third parties that his position is correct and Bob will have an uphill battle in order to propagate the opposite narrative. In order to create even less ambiguity, Leo and Bob could take their written agreement one step further and have it signed by a notary.

A notary is a neutral third party who is brought into the agreement at the beginning, before any potential dispute has occurred. The notary verifies the identity of all parties to answer claims of forged signatures, and observes the signing to check for obvious signs of duress. Since the notary gains income via their reputation as a neutral and trustworthy witness, they have an incentive to preserve their reputation and this creates an economic barrier that a dishonest party must overcome in order to suborn them.

These are the basic building blocks upon which contract representations are built. The agreement specified in some readable form to eliminate ambiguity regarding the nature of the agreement, signatures to demonstrate all parties agreed to the terms at the time of formation, and witnesses to provide additional certainty of accuracy. With this basic summary concluded, here are the key points to remember about contracts:

  • Contracts are agreements, not their representation. The contract described above was the agreement that Bob could borrow the lawnmower for a limited time and would return it to Leo. This existance of the contract does not require a tangible representation. Representations of contracts provide objective evidence of a contract, they are not the contract itself.
  • Contracts can not enforce themselves. An agreement is an intangible idea that can’t do anything, much less physically relocate a lawnmower. Even the representation of the contract, whether on paper or a software equivalent, lacks this capability.
  • Contracts are represented in tangible form mostly for the benefit of people who are not parties. While a formal written contract does have some value in helping each party understand the expcations of the others, the main reason for expressing contracts tangibly is to create objective evidence which third parties can be use to adjudicate potential disputes.

While it’s important to conceptually separate the contract-as-agreement from the contract-as-representation, the English language is not particularly well equipped to facilitate this separation because the same word is commonly used to refer to both. For ease of explanation, the rest of this article will use the common convention where “contract” refers to the tangible representation of the agreement in question.

Triple Entry Accounting

Financial contracts operate on the same fundamental principles as the contract of a lawnmower loan described above. A stock certificate is a representation of a company’s agreement to give a share of profits and decision-making authority to a shareholder – a contract. A bank account balance statement is a representation of a bank’s agreement with a depositor to redeem a certain amount of currency on demand – another contract. A check expresses an agreement between a depositor and a payee that the payee is entitled to a specified portion of the bank’s obligation to the depositor – also a contract. Financial contracts gain the same benefits of tangible representation as other contracts, and the tangible representations of these contracts are called financial instruments.

Triple entry accounting is a concept developed by a number of cryptographers. Triple entry account is a method of representing financial instruments in digital form, using cryptographic signatures. The “triple” portion of the name comes from how it implements a two-party contract: the instrument is signed by both parties involved, plus a witness. Another name for triple entry accounting is “triple signed receipts”.

Triple entry accounting is the cryptographic equivalent of having every contract notarized. Triple entry accounting is superior to other ways of creating financial instruments because cryptographic signatures can not be forged, and because the additional security of a notary can be provided at a low cost. Additionally, any system that implements triple entry accounting can also implement smart contracts – contracts which execute software to automate some or all of the terms.


Open-Transactions (OT) is a software library which implements the ideas of triple entry accounting, as well as Ricardian contracts and blinded cash in a single toolkit. Using OT, it’s possible to represent every existing type of financial instrument, as well as new ones that use smart contract functionality. To show how it works, let’s start with an example of a modern gold standard. Using OT, we’ll recreate the ancient practise of goldsmiths issuing promissory note to represent physical gold deposits.

Issuing Receipts

In legacy contract systems, identities are represented by a legal name, either the name of an individual or a business. In OT identities are persistent cryptographic pseudonyms, or nyms for short. Any entity that uses OT will control at least one nym, and all operations in OT reference nyms as the parties of contracts.

Ivan plays the role of our goldsmith. Before he can issue promissory notes, he must create a nym and an asset contract. Asset contracts serve two roles: they establish a unique ID which can be used to associate all future receipts to the asset type, and they describe the underlying asset which the receipts represent so that the holders of the receipts know what the issuer is promising them. In this case, the asset contract creates promissory notes for 14k gold with a 100 gram unit of account.

There are no special requirements to create or use an asset contract in OT. Any nym can create them, and any transaction server is free to process transactions based on those contracts.


After the transaction server has accepted the contract, Ivan prepares to conduct transactions by creating a receipt. The receipt stores the balance of a specific asset type associated with a particular nym, as well as any pending transactions. Receipts are valid if they are signed by the user and the transaction server and it is only strictly necessary to keep the most recent one (although users and transaction servers are free to maintain old receipts as well). Ivan’s initial receipt will show a balance of zero because it is the first time he is transacting using this asset type on this transaction server.

At this point, Ivan is ready to accept deposits and issue OT promissory notes in exchange for them. His first customer is Alice, who wants to deposit 1700 grams of gold.


Having accepted the 1700 gram deposit, Ivan creates an OT transaction which sends 17 units (the units are 100 grams) from himself to Alice. The transaction message consists of two parts:

  • The first part of the message is the transaction. It identifies the asset being sent, a previously-allocated transaction number, the sender, recipient, and amount and is signed by Ivan.
  • The second part of the message is an updated version of his receipt. The only change so far is that he indicates that transaction number 1 has been used and the transaction is in a pending state. He also signs this portion of the message.

The reason Ivan creates two individually-signed messages is so that he can preserve some privacy. As we’ll see shortly, Alice is going to see the transaction message exactly as Ivan broadcast it. If this message also included his balance information, then Alice would also see that. By keeping the receipt distinct from the transaction, Ivan can transact with other users without unnecessarily leaking financial information.


The transaction server checks Ivan’s message for validity, then signs both parts. It then sends a message to Alice containing the transaction (now with two signatures).

When Alice accepts the transfer, she signs the transaction and creates a receipt indicating her updated balance, and returns a copy of both to the transaction server. The transaction between Ivan and Alice is now complete because it has three signatures.

The transaction server acknowledges Alice’s new balance by signing her receipt.


The transaction server returns the competed transaction to Ivan, who then generates an updated receipt. The transaction number is removed from the list of open transaction numbers, and 17 units are deducted from his balance. This places his balance at -17. As the issuer of the assets in question, Ivan’s balance must be negative (or zero). The balance of anyone else who holds units of this type must be positive (or zero). At any given time, the sum of all balances for a given asset type must equal zero.

The transaction server acknowledges Ivans’s new balance by signing his receipt.

Transactions Between Users

Suppose Alice wishes to spend her gold promissory notes with Bob. Other than the fact that she does not need to create an asset contract like Ivan did, the sequence of steps is exactly the same as the process via which Ivan sent her the 17 units. Transactions are transactions as far as OT is concerned – the only difference between a user of an asset and the issuer of the asset is that issuer balances are negative and user balances are positive.

Redemption of the Underlying Asset

At some point in the future, someone who holds these units will decide they want physical gold instead of the promissory notes. The person redeeming the notes might be Alice, or Bob, or someone else. They could be somebody Ivan never met or interacted with in any way. Let’s call them Roberta. However, Ivan does know Roberta holds valid notes as long as her receipt is signed by the transaction server (notary).

The act of redeeming promissory notes would look like a sale. Roberta goes to Ivan’s store and purchases 500 grams of gold, using the promissory notes for payment. This is process by the transaction server just like any other transaction. Roberta’s balance will be reduced by 5 units and Ivan’s balance will increase by 5 units. Since Ivan is the issuer, an increase of his balance means it becomes less negative (lower absolute value). The represents his outstanding liabilities shrinking as he fulfils his redemption obligation.

As noted above, OT can not enforce Ivan’s obligation to redeem the promissory notes for gold. It’s not possible for software to leap out of Ivan’s computer, pick up the gold, and hand it to Roberta. What OT does do, however, is provide Roberta with nearly unimpeachable proof that Ivan has failed to perform on a valid contract, and she can use this as evidence in any appropriate dispute resolution system.

Additional OT Features

Other Instrument Types

The sequence above describes the most basic type of financial instrument and operation – the transfer of a promissory note. This is not the only way to transact in OT. OT users can create other transaction types, such as cashier’s checks and untraceable digital cash. OT can emulate any instrument that exists in the legacy financial system. The most exciting feature, however, is the ability to issue smart contracts. Smart contracts make financial transactions of arbitrary complexity available to anyone.


Besides simply using them to settle payment, users of promissory notes will want to exchange one type for another type. This is a service that can be provided by dedicated exchange businesses, however for low volume trading no separate exchange is required. Transaction servers can perform order matching on arbitrary currency pairs if traders utilize the certain financial instrument types Users can place a portion of their balance into instruments which represent market or limit orders, and the transaction server can match them appropriately. Because every order matching event involves public key cryptography, this kind of order book will never match the transaction volumes of a high-frequency trading engine, however it is suitable for basic exchange functionality.

Server Federation

What happens if a user on one transaction server wishes to trade with a user on another server? At the present time, there is no way for units to move between transaction servers.. Every receipt is specific to a nym-issuer-server combination, because there is no way for two transaction servers to verify that the other has not improperly inflated the liability totals without using block chain or equivalent technology.

Federation is a forthcoming feature, and the limitation above points to exactly how the problem of implementing it will be solved. Assets in OT can be federated if their asset contracts are tied to colored coins on a blockchain. Teaching OT to understand and work with colored coins can be implemented after voting pools.

Voting Pools

Cryptocurrencies are an exception to the general rule that OT can not enforce performance of contracts. Because they are pure software entities, it’s possible for a transaction server to manipulate them directly as well as manipulate representations of them. This is an important application for Bitcoin-fiat exchanges, as well as allowing transaction servers use blockchain features like colored coins. Voting pools are an arrangement of transaction servers which accomplish this merger between blockchain and OT.

While not a complete description of OT’s features, the above is sufficient to complete this series in the next article. Next we will see what concrete benefits OT brings to the table as a contract-processing system.

Diagrams in this article were provided by Jon Vaage.

(Originally published on Open Transactions News. Used with Permission.)