Smart Contracts, Property Management, and Blockchain


Property ownership is seen as providing economic security and social status in most societies. It is thus incumbent on every society to provide a legally secure process for property purchase and management. The processes enabling property purchase are an embedded part of the society via its history and culture, and are thus different country by country. In the case of populous countries like India, this process will even be different from state to state. Bringing uniformity to this process with a concomitant introduction of a single source (digitised) documentation of a property is no small matter. There are many hurdles on the way to achieving a solution to this problem.

Blockchain as a solution has been waiting in the wings for a problem, but in the case of property management, the solution and the problem are an excellent fit. Of course there is a caveat, property management is neither an easy problem nor blockchain an easy solution. It is a long haul from problem analysis, to proof-of-concept, to prototype, and finally to production. This particular problem impacts an entire society, and thus involves legal and many government bodies. Transparency and good governance will only achieved with their cooperation, input, and involvement.

  • A smart contract represents a Digital Autonomous Organisation (DAO). In the specific case we are considering a DAO can be mapped to a (or a group of) property registration office(s). But, more than that the smart contract represents the process of property purchase represented as a state machine. As such its design can be easily compromised by deficient understanding of the process behind property purchase.
  • From a technical perspective a smart contract is an executable piece of code. It looks very similar to a class definition. Below is a a very rudimentary example, only for the purpose of illustrating some of its features.
contract Flatowners {
Flatowner[] public flatowners;
struct Flatowner {
bytes32 firstName;
bytes32 lastName;
uint aadhar;

function addFlatowner(bytes32 _firstName, bytes32 _lastName, uint _aadhar) returns (bool success) {

Flatowner memory newFlatowner;
newFlatowner.firstName = _firstName;
newFlatowner.lastName = _lastName;
newFlatowner.aadhar = _aadhar;
return true;

function getFlatowners() constant returns (bytes32[], bytes32[], uint[]) {

uint length = flatowners.length;
bytes32[] memory firstNames = new bytes32[](length);
bytes32[] memory lastNames = new bytes32[](length);
uint[] memory aadhars = new uint[](length);

for (uint i = 0; i < flatowners.length; i++) {
Flatowner memory currentFlatowner;
currentFlatowner = flatowners[i];
firstNames[i] = currentFlatowner.firstName;
lastNames[i] = currentFlatowner.lastName;
aadhars[i] = currentFlatowner.aadhar;

return (firstNames, lastNames, aadhars);
  • All methods that change the state of the underlying contract will expend gas. This is the cost associated with the method execution. How this can be monetised is a issue that needs resolution.

Among the many other issues that need to be resolved before embarking on this are the following,

  • Much of the initial thinking for this was based on Ethereum and their implementation of smart contract using solidity. Ethereums vision would suggest that they wish to rule the world, fencing your blockchain from the rest of the Ethereum network may be necessary.
  • Who bears the compute cost? If the execution model is one of public and private partnership, the answer may be obvious, for a purely public enterprise the compute cost impact has to be evaluated. This is the equivalent of the bitcoin miner.
  • There has to be a guaranteed benefit to the public. No multiple sales of the same property, that is, all property sales have to be through this system. The system should provide a list of all prior owners of a property. The system will be the single source of all documentation regarding any property.
  • There has to be the same legal empowerment of the digital documents as there is with the current physical documents of a property.


These are some early thoughts following preliminary discussions focused solely on the Indian property market. There are many more challenges of varying degrees of difficulty that have to be addressed. The scale of the task for implementation is extremely onerous, considering the government bodies that have to use and manage the system for the public. But, for all the negatives the longterm benefits of smart document and blockchain are unquestionable.

Posted in Uncategorized | Tagged , , | Leave a comment

A Process by any other name…

…would still confuse as much.

  (with apologies to Shakespeare)


    The average person see a process as they would see a forest, essentially without the details of the trees. The fact that a process is only a moniker, for a collection of activities is completely lost in this perspective. This is unfortunate, since these activities are like the trees of the forest, that give the process its shape and structure. They help to explain how the organisation does its business, or attains its business goals. It is particularly important that process designers pay heed to this fact. A good process design is dependent upon knowing the inner workings of the target organisation.

   An organisations interest in a process is only incidental, its real interest is in certain events that the process generates. Event-driven organisation have their processes fired  off when a trigger event happens.

   For example, a claim request from a policy holder will trigger the Insurers claim process.

   The activities of the claim process will generate many events, not all of them are of business value to the Insurer. Many of the events generated by the activities are useful for the correct execution of the process. Some of them are trigger events for financial processes of the Insurer, for example, a claim payment to the insured. It is obvious from this that an inside-out view is more important than a simple outside view of the process.

   Process, beside being a moniker, should properly be used as bench marks. A claim for the insured is the most stressful time, and delays at this stage are one of the best example of bad customer service. Processes are useful for comparing cross company practices and performance. But, for any individual Insurer, it is always the latency of each activity that sums to the performance of the process as a whole.

   As mentioned in another article, it is important to differentiate the language of the technologist from that of the business user. The technologists language is driven by the need to standardise computer design tools and execution engines for processes. These standardisation make it easier for the technologists to compare vendor tools and machine performance. These standardisation eases the job of the technologists for implementation of business process for machine execution, and also communications with other technologist. A business process common language for machines and technologists. It is undeniable that there is a need for such a common language for technologists and machines. There is also need for a standardisation effort to provide industry wide vendor comparison. But, there is no need for the business user, or the business process designer to learn or communicate in this, what is after all a foreign language to him.

   It is suggested that the visualisation of the process as boxes and arrows provides a sense of the flow, while presumably the attached XML document provides the details. This is perhaps true for a technologist, but not for a business user. It is really unfortunate that the word “flow” has ever entered the lexicon of process language. It is the consequence of our need to believe that automation (with digitisation) will reduce all process latency to Planck time. We want to believeThat the earth is flat, at least, in the economic sense. The need to make everything uniform and reproducible in the millions leads us to use all avenues to ensure it is so. It would have been far better to use  “follow” instead “flow”, an activity follows another activity, instead of an activity flowing into another activity.

   These tools (that help to draw the boxes and arrows) are meant for interactive use, which also suggests that the business user must be well adept at using it to navigate the process.

   The business user community already has a language, the language of the organisation at which he is very adept. He has the knowledge to deduce which collection of activities organisation-demo-example-1complete a process of interest to the organisation. He also has the language of business events, the organisational analytics that they give rise to. The only thing lacking is an ontology that brings all this together for him to be able to design processes. 

    The ontology must have a small set of symbols, a small amount of grammar, but it must enable a very large and rich set processes. This is not unlike chess, a few pieces, a small set of valid moves, but generating an infinite variety of games. Of course, there is always place for some small syntactic sugar for the handling of business rules and such additions.

   The motivation for the business user/analyst is to own and design the process with the optimum use of the organisation structure. The only thing that constraints his design are the limits of his understanding, and the boundaries of the organisation structure. But, a technologist is also constrained by the tools, the standards, and his far more limited knowledge of the organisation structure.

Posted in business analysis, DEMO, process design, process improvement | Leave a comment