Blockchain Database for Improved Recording of Property Deeds

The method of registering a property deed currently requires the use of a centralized database. These database systems are usually overseen by one administrator, the Registry, which does not allow for transparency for others involved in the process and leaves data prone to accidental or fraudulent changes. The manual mechanisms in place for deed recording lack efficiency and transparency, leading to costly legal and financial difficulties for all stakeholders. The attorneys responsible for submitting deeds are not required to follow a standard submission process, ultimately requiring the registry office to redundantly re-enter information. Many of these issues can be improved with a blockchain database to streamline future transactions and improve the security of information.

We worked closely with a local registry of deeds in the greater Boston area, the Suffolk County registry, to fully understand the current manual process and to collect the data we needed to develop our blockchain prototype model. The deed registry process in Suffolk County has undergone significant changes to keep pace with rise in population. This presents an opportunity to modernize the current system through blockchain technology. All parties involved in the deed recording process are stakeholders in this endeavor, which include but are not limited to grantors, grantees, government registry employees, lawyers, and third-party e-document companies. The successful implementation of blockchain in an industry like real estate can ultimately benefit other registries, both in Massachusetts and beyond. A successful application may encourage other registries to consider adopting a more technologically advanced approach to their current systems.

To encapsulate the efforts made to create a proof-of-concept prototype, the name Genistreet was selected to represent the final product name. The name is derived from parts “Geni” and “Street.” “Geni” comes from Genesis Block, which is the first block of a blockchain upon which additional blocks are added. It is the first instance of every block in the blockchain, and every succeeding block can be traced back to it. “Street” represents the real estate component of the product and is synonymous with “block” in the context of urban planning.

For nearly 300 years since the Registry was founded, the deed recording system remained unchanged. Until 1970, property deeds were only organized by names and did not contain parcel ID numbers or traces to municipalities. Street addresses first appeared in the Registry in 1970. The turn of the twenty-first century brought drastic changes to the recording system. In 2005, the majority of Massachusetts counties, including Suffolk, switched to the Avenue computer system and became the primary source of entry for real estate records. This system is still being used as of 2023 [1].

Originally, deed searches were completed in person at the Registry office. However, modern storage techniques have allowed the digitization of these public records. Online access to property deeds varies across each county of each state; some make their whole database searchable by attributes, some list property addresses and names outright, and others require a subscription or small payment for access. A real estate boom in the 1950s made it difficult for deed writers to maintain pace, which rendered the Palmer Method unsustainable. Hand-written deeds were quickly replaced with typed deeds, allowing for the surge in property sales and the decline of Palmer-educated students. With this change, however, there was an increase in error rates. Hand-written deeds offered a level of standardization that was not as apparent in typed books. Registers noticed a decline in accuracy post-1950 [1].

While the paper system was more accurate than the typed books and electronic system, a return to this system is unlikely. The demand for current property deeds and the increase of technological advancements present significant challenges for returning to this method. Furthermore, the style of bookbinding used to create physical deeds has been phased out, making it nearly impossible to continue to produce physical books. Prior to the turn of the twenty-first century, there were roughly seven or eight bookbinders in greater Boston with the skills necessary. As of 2010, only one remains [1].

There is no current standardization for the quantity and type of relevant information required for deed processing. Information submitted is determined at the attorney's discretion. For thoroughness, this issue often results in larger documents than necessary and can dilute crucial information. In addition to costly errors, the current system does not safeguard against deed fraud. Deed fraud manifests in multiple ways, and it can occur when someone takes title to a property through identity theft and forgery on a deed. Currently, registries look for three key attributes when documenting a property deed: (1) proper formatting, (2) a signature, and (3) a notarization. It is not the Registry's responsibility to detect fraudulent signatures or question the legitimacy of deeds; this becomes problematic when it is also the Registry's function to give property deeds legal protection. The final step to establish Certainty of Title to the grantee is completely vulnerable to passing fraudulent deeds through the system. This paper develops a modern electronic-based registry process based on the blockchain concept. The paper presents a prototype proof of concept. Blockchain solves all the above problems. It is more accurate, records are immutable, and thus can be altered or forged. The remainder of the paper presents the model and the prototype in more detail.

Blockchain is an emerging technology that is reshaping various types of transactions in different industries. When blockchain is applied to database systems, it manifests as a collection of blocks containing data. These blocks link to one another and create a distributed ledger or database. It is a peer-to-peer, decentralized network that eliminates the need for intermediary services or third parties to make decisions about recording information in the database [2]. The fundamentals of blockchain technology are rooted in cryptography, distributed computing, and game theory. Entities that are transacted like works, properties, capital, or goods can be recorded in a blockchain [3]. Block permanence in the database requires the use of time stamps and hash codes. Transaction validation is performed by many participants instead of just one, which creates a peer-to-peer network. If a user's updates are not validated by others, the network rejects this update [3].

There are a few main differences between blockchain databases and relational databases. Relational databases fall under a centralized system. In a centralized system, a central administrator has authority over the database's content and has the power to modify or delete data entries. In contrast, blockchain databases are usually decentralized systems, where new entries that are added to the end of the ledger cannot be edited or deleted by anyone in the network. This makes blockchain databases more resistant to censorship, provide immutability to users, and do not depend on a third party for asset security [4,5]. Table 1 

While the immutability of blockchain databases may be its most prominent feature, blockchain still provides many other benefits. If a user wants to modify an existing transaction, a new transaction must be made and the previous block must be referenced, which provides traceability. This provides confidence and security that sensitive information, like certificates or property records, cannot be tampered with once recorded [4]. Blockchain also provides a degree of transparency among users since data are published on a common platform which can be viewed in real time [3].

Blockchain depends heavily on the hashing and block concept for security. Hash codes are the most defining component of a blockchain system. A hash code is a cryptographic attribute that is embedded within a block and defines its security [6]. Hash codes are unique identifiers for each block and are typically a 32–62 hexadecimal character string. To generate a code under these specifications, a Secure Hashing Algorithm (SHA) is required at the discretion of the coding language used to build the backend code. These codes are then used to retrieve and identify the block it is associated with.

The genesis block is the cornerstone of “building” a blockchain. It is the first block in the chain and provides the standardized outline for the attributes that will be contained throughout the system [6,7]. In a traditional blockchain system, a transaction will be validated by six confirmations to fully integrate into the chain [6]. Many of these iterative steps occur within the computer science (CS) principle of consensus protocols. This principle is also known as a peer-to-peer network [6,8]. The first step in validation is checking if the respective parties have the authority and sufficient balance to initiate the transaction. This is followed by a double spending check, ensuring that two separate parties are not trying to obtain a single input. After, the transaction is brought to the attention of the peer-to-peer network and the block gets verified. Once the peers successfully validate the block, it will be added to the chain as a new block. The final steps of validation include all peer's local ledgers being updated, and the hash code compliance with the adjacent blocks [6].

The functionality of nodes is rooted in the principles of validation, particularly the consensus protocol [8]. The term “node” is the technical term to describe a block throughout the entire validation stage before it is officially considered a block [6]. It is an important distinction because they are not imposed by any of the linking functions. A node is only considered a block once it is communally validated and the order of the chain is agreed upon [6,7].

Blockchain deed registration would offer a streamlined recording process where it is nearly impossible to misplace a deed. Blockchain accelerates the filing process and allows for automatic updates to the registration process as soon as the parties involved agree on the terms of their contract. This would accelerate the time between signing the preliminary sales agreement and the final deed of sale [9].

Every transaction on the blockchain is traceable, timestamped, and indisputable [3]. Once an accurate title enters the blockchain, the chain of titles updates in real time and each transaction is continuously protected [2,10]. After the deed information is entered, any attempt to delete or edit the entry will be rejected by the subsequent block [2]. The registration entry is uploaded almost instantly, and all involved parties are granted access to it simultaneously. When a property is sold, all relevant documentation can be transferred to the new owner through the blockchain. Owners can instantly access their property's information dating back to the original deed. A property's structural or ownership changes can be added to a blockchain registration even if it is not being sold. During ownership changes, blockchain allows for more options than a singular owner. Since the property is represented as a digital token, it can be divided between parties which enables fractional ownership of a building or piece of land [3]. Tokenization is the process of turning a person's equitable interest in a property into a digital representation or token. Once tokenized, real estate can be sold, traded, or liquidated. Tokenization allows for a quicker, more secure transaction without the need for a third-party escrow [11]. Access to the deed can also be tokenized [12].

The process of a blockchain real estate exchange follows a series of steps. A seller accepts an offer on their house and requests the payment over the blockchain. The seller's request is facilitated by the nodes, which process this request using predetermined algorithms. Once the nodes have verified this request, then the exchange will commence. This verification may differ from transactions because it is determined by each party involved in the exchange. Since any registration occurring on the blockchain will be permanent, the transaction only occurs once and can still be witnessed by an escrow company. Once uploaded, the blockchain ledger is updated with a new block of data that forms an additional chain, which cannot be altered [11].

After the process of uploading registration, the sequence of ownership can be accessed on the public index. A purchaser can check the public record to ensure the seller is the last recorded owner. The property history does not contain any missing information, and no one has laid claim to the property since the last sale. This history is referred to as the “Chain of Title” and provides transparency for ownership [10]. Any attempt at fraud or incorrect documentation will be visible in the Chain of Title.

On the opposite end of the transition, blockchain can be a useful alternative to bypass the limits on international transfers enforced in some countries. The current system imposes additional transaction hurdles for international buyers if they are paying in a different currency than the seller [9]. A transaction over blockchain would eliminate this extra step.

The most common issue blockchain would resolve is concerns relating to land ownership. Without the ability to trace all historical documents, some individuals may not have the proper documentation to secure legal ownership of their property. This is especially common when selling an older property. Older properties are more likely to not be registered or have registration information in an existing relational database because it has been lost or destroyed. In this situation, the registration requires professional surveyors and conveyancing professionals [3]. Paper deeds are high-risk targets for natural disasters. If a deed is destroyed in a fire or similarly destructive disaster, there is no longer a formal record of land ownership, and it will be at the discretion of a state attorney to redeclare ownership. Although deed information is transferred from paper to a relational database, this database is not an official documentation of ownership [3].

We needed a data set to develop our blockchain model for the registry of deeds. Thus, we obtained actual real data from the Suffolk County Registry. The Registry's records are stored in a public relational database. It was clear that it would not be possible to get the necessary data straight from the Registry's website [10]. As a solution, we contacted the IT which eventually provided all the records from 1973 until February 2022 in the form of seven Excel Comma Separated Values Files (.csv). These files contained more than 10 million records. Only data from 2016 until February 2022 were used to develop our blockchain model discussed in this research. The resulting data set amounted to 16,516 records.

The selected data set includes many types of transactions, like assignments, mortgages, and tax liens. The data were filtered to show only property deed records. Table 2 shows the attributes of the data set. Appendix  A shows the first 10ten records of the data set.

Data visualizations were made to better understand the large data set that was obtained. This led to insights about any irregularities that may not have been immediately visible when looking at thousands of records. The visualizations focused on “town_code” and “consideration”. Figure 1 displays a pie chart of all 16,516 records based on their values of “Town_code.” This chart includes three irregular titles, “Search All Towns,” “NONE,” and “Multiple Towns.” These three values only appear in data 29 times and do not add value; therefore, these records were removed. Figure 2 shows a pie chart with the distributions of the remaining records by “Town_code.” It is more succinct, and one can draw the understanding that most land transactions in Suffolk County between 2016 and 2022 took place in Boston while the remaining 21% of the deed transactions took place in other towns.

To visualize the considerations for the years included together, values had to be adjusted for inflation.

Based on the month and year of the transaction, the consideration was multiplied by the inflation rate for that month, which was taken from the US Inflation Rate Calculator [13]. Figure 3 shows a histogram with the adjusted considerations. The chart shows that the average consideration for a transaction is between 450,000 and 650,000. There is a strong left skew to values within 400,000 of that range. The left tail extends to 11 million in the data but all values over three million are in an overflow bin.

Genistreet's model creation comprises three main parts: the backend code that creates the blockchain, the frontend that establishes the user interface, and their connection to complete the product. Instead of writing the blockchain initialization code from scratch, an open-source base code was used [14]. The source code provided the outline for defining what a block is, creating a blockchain with hash codes, and validating the blockchain. All the source code was modified to fit Genistreet's goals. Many of the callable functions were developed from scratch. The full backend code can be found in the GitHub². The backend was built from 12 unique functions. We refer the reader to the GitHub link.

Every time a user accessed the blockchain from the frontend, they were returned the full blockchain. This was possible because the code ran every time and the full blockchain was created. This process created new hash codes for each block every time. To maintain the integrity of the blockchain, all the original hash codes were saved in a .txt file and were re-appended to the full blockchain. The blockchain was validated before any functions would execute in the blockchain. This process took very little time and did not interrupt the user's experience with the blockchain. The “Save_hashcodes” and “Return_hashcodes” functions enabled this process.

Validating the blockchain was a two-step process within the “Validate_blockchain” function. The first step ensured the genesis block hash code was correct and that the correct hash codes were appended. The second step inspected the entire blockchain and checked if the hash code on each block matched the previous hash code on the next block. If any blocks are modified, the validate function returns a warning to the user and reports which block created an error.

The Registry serves as a public search database. To enable a similar functionality, a query function was created in Genistreet. This is more complicated in a blockchain because it is not possible to iterate over the object “Block” as a string is typically searched. To solve this problem, the function turns all the blocks in the blockchain into strings and iterates over each string to check if the search term is in that string. Figure 4 shows the layout of the blockchain model. It also shows the deed transaction variables used in the model as well as the content of any block within the chain. Table 3 shows the attributes of a block: five system-defined attributes and eight user input attributes. Figure 5 visualizes the process of adding a new record (block) to the blockchain. Figure 6 shows the flowchart for searching a record.

We have utilized the standard html and CSS concepts to create the frontend of our blockchain model. The CSS files define all the metadata styles, spacing, colors, and other esthetic features. html and CSS provide complete flexibility in designing the html webpages. When uploaded to a server with backend blockchain code connections, users are able to interact with the blockchain. All frontend code can be found on GitHub³. Table 4 lists all the webpages that were defined for Genistreet before html and CSS programming began.

The transitional pages on the Genistreet website originated from the open-source contributor Nexmoe [15]. Adaptations to this baseline code included changing the default content, hexadecimal color codes, and appended structural html features. Predefined styles included the format for lists, tables, and articles. The additions enhanced the visually appealing elements of user interface (UI) design and personalized the template for Genistreet's visual needs, such as using a softer font. Figure 7 shows the resulting homepage of Genistreet's website. Figure 8 shows the webpage to search for a record.

The html and CSS to submit a deed were developed differently than the other pages. Open-source code from Hanwen Zhang's GitHub page helped build the html form [16]. The CSS code that styled the form was altered to make the colors fit the gold/black theme of Genistreet's branding. The html was changed to accommodate the different sections and data needed. Figure 9 shows a section of the form. To standardize the templates in the directory, a convergence of the CSS styles of both the main.css and nexmoe.css was required. For version backups, multiple iterations of the nexmoe.css file were made to accommodate the “Register a Deed” template. The nexmoe.css iterations can be found nested in the Styles directory of the “Genistreet” branch in the GitHub repository [15].

The backend code was written in python and the frontend code was written in html and CSS. The html webpages were accessed within python code for a fully functionable, interactable blockchain. User input through the html form was stored as variables in the python code so the functions to add blocks and query the database work properly. Following the submission of the form in Fig. 9 the user is returned to the confirmation page, Fig. 10, that their information has been added to the blockchain. This confirmation page relays back to the user the variables they entered and the attributes being stored in the blockchain. Figure 11 is representative of the queried results being pulled from the blockchain. Exemplifying that the recently submitted deed can then be queried from its addition to the blockchain.

****The individual measurements selected for determining success of the blockchain model are the following:

1. Throughput: The current system allows for 350–700 deeds per day. The Genistreet solution can uphold the current demand, while also allowing for increased capability if this number were to increase.

2. Touches per Deed: The current system requires three different people to handle each deed, the person entering it into the system, the person verifying that it was entered, and the person completing the second verification. The proposed solution would only require two touches, the person submitting and the person doing an immediate quality check.

3. Cycle Time: Since the solution transfers the deed entry to the user, the registry is no longer required for input. The cycle time per deed would be eliminated completely.

4. Labor Time: By eliminating cycle time and maintaining throughput capacity, the Genistreet solution would save 8 labor hours per day; based on the cycle time per 500 deeds (average of 350–700).

The final product for Genistreet can be summarized by the deliverables shown in Table 5.

While Genistreet embodies the essential elements of a blockchain repository, additional technical elements need to be added for it to be a stand-alone, functioning blockchain. These elements include model scaling, enhancing cryptographic capabilities, and additional methods for a thorough validation [17], more specifically:

• Changing the filtered data inputs to encompass the entirety of the registry's data

• Adding concurrent blockchains linked by property ownership last names

• Adding cryptographic, hash code linking through the implementation of a Merkle Tree and Merkle Tree Root

• Adding nonce and proof-of-work (PoW) functionalities to allow for peer-to-peer validation

• Adding an optical character recognition (OCR) element, that relies on machine learning, to validate entries on input

• Adding a monetary component for users to submit the associated fees with their transaction

• Hosting the frontend on a public server

Despite the changes and attempts made by registries of deeds throughout the United States to modernize systems to accommodate for the increasing property transactions and technological advancements, there is still an opportunity to update the current deed recording further. Standardizing the data input process would create a more secure and streamlined system, reduce the burden of recording disjointed property deeds from Registry personnel, and increase overall throughput. To address these issues, a new model has been proposed through the application of blockchain technology. Extensive research was done on the current deed recording process at the Registry, blockchain fundamentals, and the synthesis of these two fields. Backend and frontend development delivered a functional online prototype, Genistreet. Genistreet is a strong primary iteration with the potential to evolve into a more robust system. In future with Genistreet iterations, the backend can be developed to use nonce and proof-of-work (PoW) functionalities to allow for peer-to-peer validation. This may involve using a blockchain hosting service such as Azure.

There are no conflicts of interest. This article does not include research in which human participants were involved. Informed consent not applicable.

This article does not include any research in which animal participants were involved.

The authors attest that all data for this study are included in the paper.