Open-Transactions supports a range of financial instruments such as account transfer, cheques and vouchers (aka "cashier's cheques" or "banker's cheques"), in addition to cash.

These instruments are all analogous to the same financial instruments that we all use at normal banks today. Everyone already has an intuitive understanding of these financial instruments, because we use them regularly in our normal daily lives.

Markets, Basket Currencies, and Smart Contracts

Open-Transactions also implements higher-level, contract-based transactions such as payment plans and markets with trades.

The markets on Open-Transactions support market orders, limit orders, fill-or-kill orders, day orders, stop orders, and stop limits, just like trading on a real market.

Basket currencies are also supported, as well as payment plans (recurring payments.)

Client-side scripting: !/usr/bin/env ot The entire (mostly) high and low level OT API is available within your scripts.

Triple Signed Receipts

All of this is accomplished in such a way that all parties are able to prove, at all times, which transactions have cleared and which instruments are authorized, without having to store their entire transaction history, but instead by merely keeping the last signed receipt.

Without the special mechanism that makes this possible, all parties would otherwise be forced to store all receipts forever.

Nyms and Asset Types have consistent IDs across all OT servers, since the ID is formed by hashing the relevant contract or public key.

OT servers do not store user assets. Rather, cryptocurrencies are stored in voting pools so the server can't steal them.

In every way, the user is in control, not the server—even when you're using servers you do not trust. These characteristics generate a federated network architecture—similar to the internet, and it has the same virtues as the internet—openness, decentralization, resilience, censorship-resistance, and user control.

The community behind OT is strongly committed to developing systems that give users full control over their own assets and information.

It's like PGP FOR MONEY. The idea is to have many cash algorithms, not just Lucre. I’d like to add Chaum’s version, Brands’ version, etc. So that, just like PGP, the software should support as many of the top algorithms as possible, and make it easy to swap them out when necessary.

User accounts are pseudonymous. A user account is a public key. (This is like PKTP by Andrew McMeikan.) You can open as many user accounts as you want. Full anonymity is possible only for "cash-only" transactions (where users only perform token exchanges, and do not open accounts), whereas pseudonymity means that transactions can be linked to the key that signed them. (While the real life identity of the owner is hidden, continuity of reputation becomes possible.) See full-color diagrams linked above.

Any user can issue new digital currencies and digital asset types, by uploading the new currency contract to the server. (This functionality is comparable to Ricardo by Ian Grigg.)

Users can open asset accounts of any type. You can have as many as you want, associated with each user account. (See Loom by Patrick Chkoreff.)

Triple Signed Receipts / No Account History. On OT, entities are able to conduct transactions, verify instruments, and provably agree on current holdings via signed receipts, all without the need to store any transaction history. An asset account on OT is not according to the traditional sense of the word (an account normally being thought of as, "a list of transactions, with a balance, used in double-entry bookkeeping.") While the word "account" makes things easy to understand, an asset account on OT exists only in the mind of the account holder himself. He simply asks the server to agree with him that it exists, and to provide him with a signed receipt to that effect. In the user interface, OT is able to mimic the account metaphor, making usage intuitive, even though no actual account exists, or need be stored on either side, other than the signed receipt itself! (See Bill St. Clair's excellent Truledger for an example of this concept.)

Open Transactions also features markets. Any two asset types can be traded against each other. The markets are full-featured and include limit orders, stop orders, fill-or-kill, day orders (date ranges), and stop limits.

Open Transactions also supports basket currencies. Users can define their own, and the server handles the process of exchanging in and out of basket accounts. Baskets are treated by the software like any other asset type, (you can open accounts, transfer funds, withdraw cash, write cheques, and even trade basket currencies on markets.)

Client-side scripting: The entire OT API is now available for use in OTscripts on the client side. Just remember to put this at the top of the file:

#!/usr/local/bin/ot --script

Open Transactions also supports payment plans. Users can sign contracts with each other, and the server will carry out the terms and implement the payment plan. (A future goal is to issue new asset types based on revenue from payment plans--so they can also be traded on markets.)

Contracts, in general, are very important to Open Transactions; they are the building block of the entire library. Open Transactions uses a Ricardian-style contract, and all the various instruments, data files, and messages resemble PGP-signed XML files. All objects serialize to a string.

The philosophy of the software is based around separation of powers (issuers and transaction servers being separate entities) as well as the distribution of risk. For example, Asset accounts can be distributed across multiple servers, and asset types can be distributed across multiple issuers (via baskets.) Read about the Auditing protocol.

Potential future instruments include: Real Bills, dividend-paying stocks (the same mechanism can be used as interest paying bonds) and collateralized debt obligations. (OT supports payment plans, so it would be easy to group tranches of OT's payment plans to pay into a single reserve account, as backing for a new stock offering that could be traded on OT markets.) This is similar to how basket currencies are implemented. Stocks/Bonds would pay shareholders by dropping a cheque into your stock account's inbox. These features aren't available yet, but they are easy to add given the existing OT infrastructure.

All communications are secured with OpenSSL. All messages are also signed and encrypted. All transactions require signatures from relevant parties including the server.

Open Transactions is open-source, written in C++, object-oriented, and includes Native APIs for Java, Ruby, Python, PHP, Perl, C, D, C++, Objective-C, C#, Tcl, and LISP. (Also supporting JRuby, Jython, Scala, Clojure, Groovy, and any other language that works on the JVM.)

STORAGE... The library itself is storage neutral, and could be utilized across a variety of different storage systems. All objects serialize to a string, and it is very easy to add support for new storage methods. (Currently OT uses the filesystem with key/value pairs.) Adding a new storage method is as easy as subclassing OTDB::Storage and overriding a few methods. Use any DB you want.

Messaging... The library itself is transfer-protocol neutral, and can be utilized across a variety of different transfer protocols. The default implementation uses the ZeroMQ library for transport. Transport is implemented as a callback function, so it's very easy (a few dozen lines of code) to swap in some other system, if you wish.

OT currently supports MsgPack and protobuf for data packing, though new packers can be added by subclassing OTDB::Packer.

The intention is for this software to be integrated as many places as possible... Games, digital cash wallets, distributed data stores, secure voip apps, anonymous bit torrent networks, mixnets, remailers, nym servers, etc. There are many other potential uses.