A distributed ledger provides for decentralized consensus on a set of cryptographically verified data. However, in and of itself, such a ledger does nothing to ensure that nodes in its network have the same computational state derived from these data. The part of the consensus system that determines the shared state is called the transaction logic. As Richard Gendal Brown explains in his article entitled How to explain the value of replicated, shared ledgers from first principles:
“When smart contracts are incorporated with distributed ledgers not only is there the benefit of consistent data such as holdings across all participants, but consistent contractual language around those holdings as well.”
Relatively primitive consensus systems, such as Bitcoin and Bitcoin-derived altcoins, were designed primarily to be transfers of value in digital currencies, and their transaction logic implements a token system. A token system is a scheme for transferring balances in a digital asset from one party to another. In Bitcoin, this token system is extended by a programming language, Script, but this language suffers from two serious limitations:
It is not Turing complete.
It has no notion of state. (All contracts resolve to either True or False.)
The consequences of these design decisions are that the maximum complexity of the transaction logic of the network in question is limited to recording of balances in digital assets, along with some simple multi-signature authentication.
By contrast, it is possible to build on top of a ledger a virtual machine for the execution of a Turing complete language and the preservation of state. Then the transaction logic may be arbitrarily complex (by the properties of Turing complete languages). The presence of such a virtual machine allows for the creation of smart contracts: self-executing and self-enforcing, cryptographically authenticated multi-party agreements. Again, from Richard Gendal Brown:
“This opens up the intriguing possibility of “smart contracts”: a world where derivatives counterparties agree that a shared piece of code represents the agreement they have made with each other and they execute it on the shared, replicated ledger.”
A token system can only record balances in digital tokens: quantities may be associated with identities, but that’s it. By contrast, a full smart contract system has the capability of implementing any software routine at all, including all of those of mere token systems. This opens up the possibility of representing financial securities and instruments directly on the distributed ledger without reference to central databases and all of their disadvantages.
In short, here’s how the two systems compare:
Applying this to finance
In the context of modeling financial instruments on a distributed ledger, token-based systems allow one to model quantities but not the actual mechanics of the financial instruments themselves. For instance, let’s look at a bond: For a specific bond issuance, it has a total quantity, which is distributed during a primary market allocation process and changes as the bond trades in the secondary market. It also has “functionality” such as corporate actions (making a coupon payment, puts, calls, conversions, etc), and the actual logic behind the issuance, primary market allocation, secondary market trading workflows.
With token-based systems, all of the logic beyond the bond quantities themselves must be implemented outside of the distributed ledger. This means that, with the above example of bonds, one could model simple ownership (i.e. “the owner of address 1234 owns 1000 of the IBM’s 5 ⅜ of 22 bonds”), but essentially nothing more than that. All of the rest of the bond’s functionality must be implemented within a traditional web/database architecture. Contrast this with smart contract-based technologies, where not only the quantities may be modeled on the distributed ledger, but also all of the logic and workflows themselves, in computer code that all authorized participants may examine and agree on.