Using smart contracts to manage real-world contracts

This post originally appeared on ZeMing M. Gao’s website, and we republished with permission from the author. Read the full piece here.

Using smart contracts on a blockchain to manage certain aspects of regular contracts such as status (validity, termination, etc.) monitoring, renewing, or rolling has broad business applications.

Note that it is not to use a smart contract to replace a regular contract. Doing such would be impractical in many cases. By “regular contract,” I mean real business contracts in a legal sense. These can be vastly more complex than the so-called smart contracts. Not only that, many terms and contingencies of the real business contract require human supervision and intervention and cannot, and should not, be replaced by completely automated “smart contracts” (which really is a misnomer because they are dumb, not smart).

But smart contracts on blockchain can be used to manage these off-chain real contracts far more efficiently and effectively than the current method. And this is the future.

For example, the current contract management regime involves much costly uncertainty and human involvement just to maintain a clear and mutually accepted (non-disputed) status of a contract. Simple tokenization on blockchain may partially solve this problem but is too rigid because it does not allow the off-chain real contract to be renewed, rolled on, or modified without losing continuity.

“Losing continuity” means every change would result in a new smart contract, creating complexity and obstacles in management.

An nChain invention uses an on-chain UTXO to represent the state of an off-chain contract, and subkeys to manage the renewing or rolling of the contract within the same thread that can be automatically managed without losing control or privacy.

The significance of this is easily overlooked. It allows businesses to form and execute contracts the way they would like to and not be forced to change their business practice, but at the same time, it provides an added advantage of blockchain smart contract management over actual business contracts.

Not being able to do so is one of the major reasons why businesses have not adopted blockchain. This is because, for most businesses, blockchain seems like an invasion that threatens them to change how they do their business rather than an alliance that improves their existing business.

By the way, in the blockchain space, no company understands this intricate relationship between smart contracts and real contracts better than Tokenized.com does, and no company has done more in related development than them. And they are often misunderstood for they are not focusing completely on on-chain activities.

Also, nChain has been granted a European patent (link below) on this subject. This doesn’t quite cover all blockchain-enforced smart contracting but is nevertheless very foundational and broad.

In relation to the Smart Business Paradigm

This is related to something I call the “smart-business paradigm,” in which all kinds of business relationships, structures, organizations, assets, contracts, transactions, and records, how they are created, managed, and serviced, would start to move to a public blockchain, implemented with tokenization, smart contracts, and software contracts (see my definition below), and potentially also AI.

I had previously put my thoughts in this article: The Smart-Business Paradigm. (Note: in that article, I used a “smart-phone” analogy for “smart business.” I didn’t mean that a smartphone is analogous to a “smart contract.” But I do think there is an analogy between the two from a systematic viewpoint. The “smart-business” integrates multiple components such as tokenization, smart contracts, and software contracts, like how a smartphone integrates various technologies and components.)

With that background, I’ve compared several different tokenization protocols on BSV blockchain, to find out the potentials of each.

Especially worthy of attention are STAS protocol and Tokenized protocol, which are quite different in their designs and philosophies.

I support both protocols because each has its advantages.

In the most simplistic terms: STAS is on-chain tokenization and on-chain verification. For an asset whose existence and legal validity do not depend so much on an existing company (such as an issuer), and one would like to take advantage of blockchain physicality and permanency, STAS is an obvious choice. Not that others don’t work, but STAS is simply better for this type of assets. STAS protocol is also ideal for micro-businesses that can be programmed using an automatic smart contract that requires no manual interaction and intervention once set up. Also, in principle, at least, almost all token types (including those planned by Tokenized) can be implemented on-chain, specifically with STAS protocol.

In contrast, Tokenized is off-chain tokenization and on-chain verification. For assets that rely on a high level of flexibility involving existing business models and multiparty off-chain management (such as issuer, authorized agents, etc.), the Tokenized model has an advantage. Again, it’s not that other protocols would not work, but Tokenized has invested years of work in developing such a platform to take care of both on-chain and off-chain business integration and interaction.

Then there is also sCrypt, which is much broader because it is not merely a tokenization protocol but a smart contract platform. It has the potential to do everything well in the long term, even though it initially does not allocate its resources for deep off-chain development.

The issue is not just the tokenization and the smart contract part alone but also the general aspects of contracting in the real business world. These general contract aspects may never be made into smart contracts.

The limitation is not about coding ability but about the human reality.

I use the word “contracting” as a comprehensive short-term for everything I mentioned above (i.e., all kinds of business relationships, structures, organizations, assets, contracts, transactions, and records, how they are created, managed, and serviced).

This general aspect of contracting may either stay with the traditional way (extremely inefficient) or be reformed using a purposeful software framework integrated with tokenization, smart contracts, software contracts, and AI.

The above second alternative stands as an opportunity.

By “software contracts,” I mean contracts that are machine-readable/manageable but *not* machine executable (in contrast to smart contracts, which are both machine-readable and machine-executable. In other words, software contracts are smarter than paper contracts but cannot be quite classified as smart contracts as they are less automated.

The Ricardian contract is an example of such a “software contract.”

I believe the software contracts as defined above cannot be completely placed on-chain, but rather need an off-chain software framework. The transaction confirmations may still be on-chain, but the actual creation, management, and enforcement (including oracles) don’t seem to be suited for an on-chain implementation.

So, in relation to STAS, one question I have is, if tokenization and smart contracts are done using STAS on-chain, would the system be *compatible* with an off-chain software framework for converting all aspects of the traditional contracts to software contracts? (This includes all aspects of agreements, commercial records, messages, business relations, agent relations etc.)

Note my question is about “compatibility” rather than replacement, which I already assume is not possible with any protocol.

From a purely technical viewpoint, I don’t see why it would not be compatible. But what I worry about is the actual business reality. For example, what if you have an industry in which certain assets are required to be handled by a designated entity using a private database? If this were the case, they might require data-based tokens (despite the disadvantages of such tokens). Transaction verifications may still be on-chain, but the other aspects of the business must be handled off-chain, leaving the software contract the only automation opportunity for this part.

The fact that in the above scenario, the system would rely on off-chain servers and databases is a problem when looked at from the smart contract viewpoint. But it probably will remain a part of reality for a long time.

Meanwhile, according to how broadly one defines the “smart-business paradigm,” it may eventually involve triple-entry accounting and shared ledger (components of a ledger shared by many companies). But these may belong to an even higher level type of implementation which will be adopted by companies in a later stage, with the exception of certain industries that consider the benefit of triple entry accounting and auditing and compliance a high priority.

I’m not arguing one way or another. I just think that we are looking at different kinds of business opportunities and weighing their relative expediency given the limited resources.

Watch: sCrypt makes smart contracts possible on the BSV blockchain