Land and Immovable Property Ownership Registry
1
Content Definition of the project
4
Protocols and tools of the trade
4
Example for the use cases
4
Use Cases Use Case Country Registration Steps Use Case Citizen Registration Citizen Rita Steps Citizen Rita Summary Citizen Dominique Steps Citizen Dominique Summary Citizen Erik Steps Citizen Erik Summary Other relevant Citizen Use Cases Use Case Company / Organization Registration Use Case Notary Registration Implementation steps Use Case Immovable Property Registration Implementation steps Use Case Ownership Registration Implementation steps Use Case Verify an Account Use Case Transfer a Property: Change of Ownership Registration Implementation steps Preparation of the deal by a Notary Verification of citizens and parcel involved Ownership modification Registration of the Notary act as official document and proof of the deal Extra Information
5 5 5 7 7 7 12 13 13 18 18 18 19 19 20 20 20 20 20 23 24 26 26 27 27 27 28 28 28
Simplified flows Terminology Use Case: Register a Citizen Use Case: Register a Property Use Case: Register a Property Ownership
30 30 30 31 31 2
Use Case: Verify an Account Use Case: Transfer a Property
31 32
Private Pointer Accounts Bonuses
32 34
Future Work Atomic or linked transactions Identifiable Assets Creation of an Identifiable Asset Creating an Identifiable Asset Transferring an Identifiable Asset Parcel example Cosigners Weight for Multi-signature Accounts Multi-signature chaining
35 35 35 35 36 36 36 36 36
3
Definition of the project The goal of the project is to implement a Proof of Concept (POC) of an ownership register or cadastral system to prove the viability and usability of blockchain technology for such a system in real life situations. The system will be based on unique identifications and immutable registrations on the blockchain of: 1. Countries (Sovereign States) 2. Owners: a. Natural persons as citizens of a Country b. Organizations/Companies registered in a Country 3. Notaries: citizens with the legal authority to act as a Notary in a Country 4. Immovable properties located in a Country. The list of supported categories of immovable properties includes, but is not limited to: pieces of land, houses, other types of buildings and apartments. 5. Ownership
Protocols and tools of the trade For the development of this LANDSTEAD POC we will be using: ● The publicly available NEM blockchain network. ● The NEM Network Infrastructure Server REST API’s ● A customised LANDSTEAD wallet: ○ based on the open sourced NEM nano-wallet. ○ including the supported NEM Apostille notary service that enables unique identification of documents and registration of those documents on the blockchain. ○ focused on the Use Cases described in this project.
Example for the use cases ● ● ●
Country = Belgium. Belgium is realistic and probably suitable. Immovable property = parcel, small piece of land in Belgium, identified with a unique code Roles: ○ Civil servant = Garp ○ Citizens: Initial owner = Rita , new owners = Erik & Dominique ○ Notary
4
Use Cases Use Case Country Registration A Sovereign State (Country) that wants to use LANDSTEAD, identifies itself on the blockchain.
Steps ●
A civil servant (Garp) of the Country (Belgium) creates a random Private Key account NARZ5E-RMKNP4-UB46HF-CJE7FC-CNGOWP-IYHMA6-BELG
●
A backup of the wallet, the password used and the private key is made to guarantee any future access to the created Country Account.
●
An amount of XEM is transferred into the Country account to cover the expected transaction fees related to the Use Cases in this project.
●
Garp transferred an initial 5020 XEM into the Belgium account, see t ransaction
●
The Belgium account is used to create a namespace for the Country: “belgium”. The cost is 5000 XEM rental fee + 20 XEM transaction fee, see transaction
5
● ●
●
The Country account is used to create Assets for each role in the Use Cases (categories of owners, notaries, …) and for each type of property (parcel, house,...). Each Asset costs 520 XEM (500 XEM creation fee + 20 XEM transaction fees). These funds must be transferred to the account before the Assets can be created. Two Assets are planned (Garp transferred an additional 1100 XEM for this purpose): ○ belgium.citizen, see transaction
○
belgium.notary, see t ransaction
○
Another Option for the future = belgium.organization (this category can be used for all other types of owners, as long as they can be identified by a unique code: non-profit organizations, profit organizations such as companies and government instances)
6
○
belgium.parcel, see transaction
To transfer signing authority for the account to one or more legal representatives of the Country, and the Country account can be converted to a multi-signature account at any time. Adding or removing any signers on such a multi-signature country account is also supported. The initial amount transferred into the Country account could be chosen so that initial costs would be covered, let’s say, for example, 10.000 XEM = 35 USD, based on exchange rate on 24/12/2016.
Use Case Citizen Registration A Citizen of a Country is registered on the blockchain by the Country. This can be done one by one when needed, depending who owns an immovable property and whose ownership the Country wants to register on the blockchain. In this and other Uses Cases below we will use a few citizens in the examples: ● Garp, a Belgian civil servant, representing the Belgian Country. ● Rita, a Belgian citizen who owns a piece of land she is selling. ● Dominique and Erik, two Belgian citizens buying the parcel from Rita.
Citizen Rita Steps ●
The Country (Belgium) wants to register a Citizen (Rita), who owns a piece of land in the Country, on the blockchain. The Citizen can be identified by a National ID card or Pass. In Belgium, Rita has a Belgian eID card that contains the identification number of the National Register on the backside. The number 50.22.54-240.34 uniquely identifies Rita in Belgium. (picture and National Register number are provided for the sake of the example and are not to be published for privacy reasons) 7
●
The citizen (Rita) can have a Private Key Account or not. In this case we suppose Rita does not have a Private Key Account yet, so the Country can create one that can be used as long as Rita does not have an account of her own. ○ The civil servant (Garp) creates a Simple wallet for the Citizen (Rita). The wallet will contain the Private Key Account for the Citizen. The Wallet name can be chosen, but should uniquely identify the wallet in the Country as being the one of this citizen, f.e. 50.22.54-240.34
○
A backup is made of the citizen’s wallet file and of the password used for the wallet. This to guarantee any future access to the Citizen’s wallet.
○
The wallet is opened to read the created public Account number: NC4DCX-4PU7UF-L22ELK-ZPTL7G-WRN5XU-IAYV2W-RITA
8
○
●
The account’s Private Key should be retrieved and a backup is to be made, since this will allow to recreate a wallet containing the same account at any time needed in the future.
The civil servant (Garp) creates a Pointer Brainwallet (Alias) for the Citizen (Rita) ○ This is done with a Passphrase based on the unique personal code of the Citizen, the Countries namespace (belgium) and optionally the Asset identifying the category of the property owner (citizen). This results in the Passphrase “50.22.54-240.34@belgium” or “50.22.54-240.34@belgium:citizen”, which can also be used for the Wallet name as the Passphrase is not a secret in this case.
9
○
The file of the Wallet named 50.22.54-240.34@belgium:citizen can be saved together with the used password to facilitate easy access to the citizen pointer Brainwallet later. The Passphrase can be used to recreate the same Brainwallet again.
○
The Pointer Brainwallet contains the Pointer Account NCQL2B-6X2UJL-M5QINS-PHDSI3-3O3FVD-23L64V-ISQ3, see screenshot.
●
Optional, mainly needed for security: Convert Pointer Account in Brainwallet into Multisig with Country as only cosigner
●
To let this new Account point to the Private Key Citizen Account created before, the Country (Belgium) sends a Pointer Message to the Pointer Account: 50.22.54-240.34=NC4DCX-4PU7UF-L22ELK-ZPTL7G-WRN5XU-IAYV2W-RITA ○ The message could be encrypted or not, depending if the Country would evaluate that would have an additional value for privacy reasons. An encrypted message cannot be read on the public blockchain explorers, but everybody being able to 10
○
open the Account of the sender(Belgium) or the Account of the receiver (Pointer Account) would be able to decrypt the message and read it. To encrypt the message the receiving pointer account must have a public key, which is registered on the blockchain at the occasion of the first outgoing transaction. In this case we choose not to encrypt for simplicity. See the example of the next citizen below for the logic needed to encrypt the message. Send not-encrypted Pointer Message (+ fee = 5 XEM) 50.22.54-240.34=NC4DCX-4PU7UF-L22ELK-ZPTL7G-WRN5XU-IAYV2W-RITA ■ From: NARZ5E-RMKNP4-UB46HF-CJE7FC-CNGOWP-IYHMA6-BELG ■ To: NCQL2B-6X2UJL-M5QINS-PHDSI3-3O3FVD-23L64V-ISQ3 ■ In this example, we choose not to encrypt the message.
11
○
This results in a Pointer transaction in the receiving Brainwallet Pointer Account.
●
Confirm Rita’s Account to be of a Belgian Citizen by sending it a belgium:citizen Asset: ○ From: the Country Account (Belgium) ○ To: NC4DCX-4PU7UF-L22ELK-ZPTL7G-WRN5XU-IAYV2W-RITA ○ Asset transfer: 1 belgium:citizen The default nem:xem Asset can be removed, since none are transferred ○ Optional message (encrypted or not) with citizen ID: “50.22.54-240.34” ○ See transaction
Citizen Rita Summary The ‘Citizen Brainwallet Pointer Account’ has received a pointer message from the “belgium” account. The message points to the the actual Citizen Account. Based on the “belgium:citizen” Asset in the Account pointed to, it is confirmed the pointer message indeed points to an identified Belgian Citizen account.
12
Citizen Dominique Dominique already has a personal Private Key Account on the blockchain. So the logic to identify and register Dominique as official Belgian Citizen is slightly different as the Country does not have to create a new Citizen Account in this case.
Steps ●
The Country (Belgium) wants to confirm the identification of a Citizen (Dominique) on the blockchain by registering the Citizen’s existing Private Key Account. The Citizen must be identified to do that. As above, Dominique is identified by her Belgian eID card that contains the identification number of the National Register on the backside: 30.02.22-512.44 (The National Register number is provided for the sake of the example and is not to be published for privacy reasons, please)
●
The citizen (Dominique) in this case d oes have a Private Key Account: NALDDK-PPTJTF-7WRVWA-BBIJ7D-762OJN-L2LFK7-DOMI In this case the citizen is responsible for the wallet, the account, the backup of the wallet file and for a backup of the Account’s Private Key. In order to have this account confirmed to be the one of her as a Belgian Citizen, The Citizen (Dominique) has to provide the Account Number to the civil servant (garp).
●
The civil servant (Garp) creates a Pointer Brainwallet (Alias) for the Citizen (Dominique) ○ This has to be done with a Passphrase based on the unique personal code of the Citizen, the Countries namespace (belgium) and optionally the Asset identifying the category of the property owner (citizen). This results in a Pointer Wallet based on the Passphrase “30.02.22-512.44@belgium:citizen” which can be used as a Wallet Name as well, since the Passphrase is not a secret.
13
○
The file of the Wallet named 30.02.22-512.44@belgium:citizen can be saved together with the used password to facilitate easy access to the citizens pointer Brainwallet later. The Passphrase can be used to recreate the same Brainwallet again.
○
The Pointer Brainwallet contains the Pointer Account, see screenshot. NAPEC4-BMZYEB-JGTCR7-7GZALI-IPN464-WKSORQ-2XJ4
●
Optional, mainly needed for security: Convert Pointer Account in Brainwallet into Multisig with Country as only cosigner
●
To let this new Account point to the existing Private Key Citizen Account of the Citizen (Dominique), the Country (Belgium) sends a Pointer Message to the Pointer Account: 30.02.22-512.44=NALDDK-PPTJTF-7WRVWA-BBIJ7D-762OJN-L2LFK7-DOMI ○ The message could be encrypted or not, depending if the Country would evaluate that would have an additional value for privacy reasons. An encrypted message can not be read on public block explorers, but everybody being able to open the 14
○
Account of the sender(Belgium) or the Account of the receiver (Pointer Account) would be able to decrypt the message and read it. To encrypt the message the receiving pointer account must have a public key, which is registered on the blockchain at the occasion of the first outgoing transaction. So if, and only if, the Country would like to encrypt the message it should send some XEM (minimum 2) to the Pointer Account to allow the Pointer Account to send 1 XEM back in return: ■ Transfer 2 XEM (+ fee = 1 XEM) from Belgium to Pointer Account: NAPEC4-BMZYEB-JGTCR7-7GZALI-IPN464-WKSORQ-2XJ4 ■ Transfer 1 XEM (+ fee = 1 XEM) from Pointer Account to @belgium which is translated by the client into the issuing account of the namespace: NARZ5E-RMKNP4-UB46HF-CJE7FC-CNGOWP-IYHMA6-BELG Send Encrypted Pointer Message (+ fee = 9 XEM) 30.02.22-512.44=NALDDK-PPTJTF-7WRVWA-BBIJ7D-762OJN-L2LFK7-DOMI ■ From: NARZ5E-RMKNP4-UB46HF-CJE7FC-CNGOWP-IYHMA6-BELG ■ To: NAPEC4-BMZYEB-JGTCR7-7GZALI-IPN464-WKSORQ-2XJ4 ■ Optional: “Encrypt message” is activated in this case, see remark above.
15
○
This results in the following t ransaction with encrypted message
In the Wallet of the sender or the receiver, the wallet password can be provided to “Decode message”
●
Confirm Dominique’s Account to be of a Belgian Citizen by sending it a belgium:citizen Asset ○ From: the Country Account (Belgium) ○ To: NALDDK-PPTJTF-7WRVWA-BBIJ7D-762OJN-L2LFK7-DOMI ○ Asset transfer: 1 belgium:citizen The default nem:xem Asset can be removed, since none are transferred
16
○ ○
Optional message (encrypted or not) with citizen ID: “30.02.22-512.44” See transaction
17
Citizen Dominique Summary
Citizen Erik As with Dominique, Erik already has a personal Private Key Account on the blockchain. But in Erik’s case, a number of official documents are available and can therefore be linked to his Account using the available Apostille service. The documents can help to prove his identity, so the Country can use the documents during the identification and registration process which makes the identification case much stronger.
Steps ●
The Country (Belgium) wants to confirm the identification of a Citizen (Erik) on the blockchain by registering the Citizen’s existing Private Key Account. The Citizen must be identified to do that. As above he can be identified by his Belgian eID card that contains the identification number of the National Register on the backside: 62.24.05-232.61 (The National Register number is provided for the sake of the example and is not to be published for privacy reasons, please)
●
The Citizen (Erik) has his own Private Key Account, which is provided to the Civil Servant for the registration purposes: NCC5HB-H6QLNL-HUP4GK-E23MZ6-VCZU6V-WLZLNM-ERIK
●
The Civil Servant Registers the Citizens Account: ○ A Brainwallet Pointer Account is created with the Passphrase: 62.24.05-232.61@belgium:citizen ○ The Pointer Account is: NBVLX6-DNFPEK-HOZ3VQ-WXODNH-R6MCS7-542N6D-MPVN ○ Optional, mainly needed for security: Convert Pointer Account in Brainwallet into Multisig with Country as only cosigner ○ A Pointer message is sent to the Pointer Account: 62.24.05-232.61=NCC5HB-H6QLNL-HUP4GK-E23MZ6-VCZU6V-WLZLNM-ERIK 18
○
●
Send a citizen Asset (belgium:citizen) with an optional message (encrypted or not) with citizen ID: “62.24.05-232.61” to the Citizen’s Account NCC5HB-H6QLNL-HUP4GK-E23MZ6-VCZU6V-WLZLNM-ERIK
Additional Identification documents with Apostille, created with Erik’s account ○ Notarization of a Birth certificate, see Apostille transaction. Apostille creates an Account for the document and the transaction is a HEX message based on the hash of the document, sent to the Apostille Account: NAMBDT-VNX4C2-UQOD57-YYY4GQ-JDRBHZ-GBK5YL-QJZ7 ○ Notarization of an eID, see Apostille transaction. Apostille creates an Account for the document and the transaction is a HEX message based on the hash of the document, sent to the Apostille Account: NCK5A3-3OSMTT-U7DU64-QCTHOA-U66SNS-QJUTV6-47SB
Citizen Erik Summary
Other relevant Citizen Use Cases There are other Uses Cases regarding Citizen’s that are related to the Accounts described above. However, these additional Uses Cases are not relevant for this project. We mention them anyway for completeness or as an indication of possible future work: ● Birth: assignment of one’s unique National register number and creation of a Birth Certificate. We could Apostille a digital Birth Certificate and include it as a possibility? ● National pass or ID card: such document could be digitized and Apostilled as well ● Education Certificates or Diploma’s ● Drivers Licence ● International Travel Passport ● Marriage ● Military Service ● … (governments have all sorts of administrative requirements during a citizen’s lifetime ;-) ● Death
19
Use Case Company / Organization Registration A Company or Organization registered in a Country is identified on the blockchain by the Country. This can be done one by one when needed, depending who owns an immovable property and whose ownership the Country wants to register on the blockchain. See other Uses Cases below. This use case is very similar to the Citizen Use Case. The differences are: ● Identification with another code: VAT number, Company Number or similar ● Usage of another Asset “Organization” instead of “Citizen” ● Resulting in another pointer account Passphrase: CompNumber@belgium:organization ● The Organization Private Key Account would possibly be a Multisignature Account with multiple cosigners. For simplicity reasons (possible need of multisignature chain) we don’t include an example of this Use Case yet.
Use Case Notary Registration A Citizen of a country who is officially and legally authorised to act as a notary in the Country, is as such registered on the blockchain by the Country.
Implementation steps Same as Use Case Citizen, but with Asset “belgium:notary”. An example of a Notary Account has not yet been registered.
Use Case Immovable Property Registration An immovable property, such as a parcel (piece of land), a house, another type of building or an apartment is registered by the Country or by its cadastral services on the blockchain, based on a unique code or description identifying the property. The UAE's immovable property registration agency and cadastral or mapping agency use the same identification number for properties. We can assume this is the case in most countries. As example we use a Belgian piece of land (kadastraal perceel, see picture), a parcel 202 with unique ID “12452B0166/00J001”
Implementation steps The Country (Belgium) sends a Asset to a Property Account based on a Brainwallet seed using the unique code of the property, the namespace of the country and the Asset corresponding with
20
the property-type of the property. This results in the Passphrase id@country:property_type, in our example this would be 12452B0166/00J001@belgium:parcel ● Create a Brainwallet with the Passphrase 12452B0166/00J001@belgium:parcel
●
Save the wallet, f.e. with the 12452B0166/00J001@belgium:parcel
same
name
●
This results in a Wallet with Account NC7CJU-JTE7JB-EJMYFJ-ACBV7F-XIYBGD-DJZO7A-2NGZ
as
the
Passphrase:
21
Now, this is not a pointer Account (as was used for the citizen). This is the Account representing the property (12452B0166/00J001@belgium:parcel) itself. ●
Optional, mainly needed for security: Convert Pointer Account in Brainwallet into Multisig with Country as only cosigner
●
Belgium sends a belgium:parcel Asset to the Account. This to register that Belgium has confirmed this to be a Belgian parcel and a valid Belgian parcel identification number: ○ From: Belgium ○ To: NC7CJU-JTE7JB-EJMYFJ-ACBV7F-XIYBGD-DJZO7A-2NGZ ○ Asset transfer ■ Asset belgium:parcel ■ Amount: 1 ■ The nem:xem Asset can be removed since none are sent. ○ The message could contain the identification code of the parcel for clarity: 12452B0166/00J001
See transaction
22
●
A extract from the cadastral system could be requested from the Belgian cadastral services. The document will confirm parcel 12452B0166/00J001 is indeed the identification of the parcel located at that specific geographical location together with other information about the parcel, such as its surface for example. This document can be registered on the blockchain: ○ From : NC7CJU-JTE7JB-EJMYFJ-ACBV7F-XIYBGD-DJZO7A-2NGZ ○ Register the file of the parcel cadaster extract with Apostille. ○ Backup the returned zip file containing the notary file and the Apostille certificate together with the original document.
Note: In the case the property is the subject of transaction, a trade or a deal, a Notary would need to verify the property registration and its cadastral correctness. If the property would not be registered on the blockchain yet, a message could be sent by the Notary to Belgium as a request to register the property. Belgium can verify if such request comes from a registered Notary (the requesting account needs to have received a Asset belgium:notary) and Belgium can then register the Property and add the cadastral document accordingly.
Use Case Ownership Registration The relation between one or more owners of a property and the property itself is registered on the blockchain by the Country, by its cadastral services or by a registered Notary. Registration of ownership is one Use Case (this one). When a property is sold, there is a deal and a trade with a change in ownership and the Notary document attesting that trade to be valid and legal is a different Use Case related to the same Asset. That other Use Case is therefore separately documented below on purpose. This to keep it simple and clear, so risks of misunderstandings about what could possibly mean what are reduced. So in our example we have a Citizen (Rita) and a Property (parcel 12452B0166/00J001) 23
Implementation steps Convert the Asset Account representing the immovable property into a multisignature Account with the owner(s) as cosigner(s): ● Transfer the needed costs for the Multi-signature conversion (22 XEM) into the Account representing the Asset (NC7CJU-JTE7JB-EJMYFJ-ACBV7F-XIYBGD-DJZO7A-2NGZ), since that account will be charged for the fees and not the initiator of the transaction, nor the cosigner(s). ● Any cosigners account must have a public key on the blockchain and must therefore have minimum one (confirmed) outgoing transaction. Belgium can transfer 2 XEM into the cosigners account NC4DCX-4PU7UF-L22ELK-ZPTL7G-WRN5XU-IAYV2W-RITA or could have transferred 2 XEM in the same transaction where the 1 belgium:citizen Asset was transferred. ● Following needs to be changed if Country has already converted the property to multisig, see optional step in previous Use case. Convert the Account into a Multisignature Account so it becomes a transferable asset: ○ Account: NC7CJU-JTE7JB-EJMYFJ-ACBV7F-XIYBGD-DJZO7A-2NGZ To convert a regular account into a multisignature account, the private key of the account has to be provided, so you have to make sure you have that information available in a secure way! ○
1 Cosigner: NC4DCX-4PU7UF-L22ELK-ZPTL7G-WRN5XU-IAYV2W-RITA
○
This results in the following multisig conversion:
24
25
●
So after the ownership registration we have this situation:
●
Added value with Apostille: ○ If an electronic copy of the Notary act is available, the document can be Apostilled using one of the accounts involved (Notary, Owner, Property). This will result in an outgoing message from the account creating the Apostille to the Account Apostille creates for the document. ○ In the case a cadastral document describing the property is available, this document can be registered with Apostille as well. In this case the it seems most appropriate the Asset Account will be used, since the document confirms the identification and will contain additional information about the property.So the Property or Asset Account (NC7CJU-JTE7JB-EJMYFJ-ACBV7F-XIYBGD-DJZO7A-2NGZ) will have an outgoing transaction to the Account Apostille creates for the cadaster document.
Use Case Verify an Account 1.
2.
Citizen logs in to [C] and accesses ‘Verify account’ Citizen can see in his balance he has received 1 country:citizen Asset from the Country, confirming the country has validated his IDc Citizen can see in his balance he has received 1 or more country:parcel Assets from the Country, confirming the country has validated him/her as owner of the properties. Additional info about the Properties can be provided based on: 2.1. the IDp mentioned in the same message from the Country in which the country:parcel Asset was received 2.2. the multisig accounts (can be more than one for rich people ;-) of which [C] is cosigner: [P] in this example 2.3. Any optional Apostille Accounts created for Property documents. These can be found as outgoing messages from [P] (See Use case Register a Property)
Use Case Transfer a Property: Change of Ownership Registration The registration on the blockchain of the property ownership can be changed into a new ownership registration by a Notary registered in the Country: the owner(s) being cosigner(s) of the transferrable asset multisig account will be changed into the new owners(s) becoming the new cosigner(s) of the multisig asset account. 26
It is crucial to make the distinction and understand the difference between : ● An Apostille account resulting from a Notary Document or Act created by the Notary at the occasion of the change of ownership. The document and the Account that represents it, could be controlled by the Notaries (could be more than one), the selling parties (could be more than one) and the buying parties (could be more than one). They should probably all be co-signers of the document. The Notary can Apostille an electronic copy of the Notary act from his Account. This will result in an outgoing message from the Notary Account to the Apostille Account of the Notary Act. ●
the Multisignature Account representing the Asset itself (NC7CJU-JTE7JB-EJMYFJ-ACBV7F-XIYBGD-DJZO7A-2NGZ represents the property 12452B0166/00J001@belgium:parcel) which can be used to Apostille a cadaster document containing all relevant information about the property.
Implementation steps In the example the Belgian parcel 12452B0166/00J001, owned by Rita, is sold to Dominique and Erik.
Preparation of the deal by a Notary To allow a Notary to prepare all administrative duties and verifications: ● The Notary has to collect identification information of the parties and of the property involved: ○ Previous owner National Number, giving Access to the Pointer Account ○ New owners National Numbers, giving Access to the Pointer Accounts ○ Property Identification: cadastral number or code of the parcel, identifying it in the Country, and giving access to the Property Account ● Rita adds the Notary as cosigner of the Property (parcel) Account, in a multisignature modification transaction. The Notary can be seen in this case as a provider of an escrow service. And to be able to provide this service, the Notary needs (at least temporarily) control of the asset.
Verification of citizens and parcel involved The Notary can check: ● Rita is a registered Belgian citizen, identified by her National Number and the pointer message pointing to her account NC4DCX-4PU7UF-L22ELK-ZPTL7G-WRN5XU-IAYV2W-RITA, that contains one belgium:citizen Asset ● The account representing the asset is indeed a registered parcel by the Belgian Country, based on the one belgium:parcel Asset received in the asset account NC7CJU-JTE7JB-EJMYFJ-ACBV7F-XIYBGD-DJZO7A-2NGZ ● Rita is indeed owner (cosigner) of the Asset account ● Dominique is a registered Belgian citizen, identified by ○ National Number 27
●
○ Pointer Account based on the Passphrase NationalNumber@belgium:citizen ○ The Pointer message in the Pointer Account points to the Private Citizen Account ○ The Private Account has received a belgium:citizen Asset from Belgium Erik is a registered Belgian citizen, identified by ○ National Number ○ Pointer Account based on the Passphrase NationalNumber@belgium:citizen ○ The Pointer message in the Pointer Account points to the Private Citizen Account ○ The Private Account has received a belgium:citizen Asset from Belgium ○ Birth certificate ○ eID
Ownership modification The notary, now a cosigner of the Asset Account NC7CJU-JTE7JB-EJMYFJ-ACBV7F-XIYBGD-DJZO7A-2NGZ, can initiate a multisignature modification to allow the change of ownership be registered on the blockchain ● remove himself as cosigner if this is specifically asked by the owner(s). ○ Keeping the Notary as cosigner can have benefits for the owners for later changes to the property. ○ As an alternative, f.e. the Notary of the previous owner(s) can be removed, while the Notary of the new owner(s) could be added. ● remove Rita’s Private Account as cosigner being the previous owner ● add Dominique’s Private Account as cosigner being one of the new owner(s) ● add Erik’s Private Account as cosigner being one of the new owner(s) ● If there is a new or changed cadastral extract describing the property, the document can be Apostilled by the Notary using the account of the property.
Registration of the Notary act as official document and proof of the deal The document produced by the Notary as a Notary Act is Apostilled as well. This can be done from the Account of the Notary, as it is his responsibility. A message can be sent to the Property Accounts of the involved parties pointing to the Apostille Account of the Notary Act. Or the Apostille Account could be converted into a Multisig Account itself with the involved parties as cosigner’s: ● Notaries (could be more than one) ● The selling parties (could be more than one) ● The buying parties (could be more than one)
Extra Information This registration of the change of ownership will often be executed after the Notary has verified that any other relevant legal conditions for the transaction are met. For example: if a necessary loan has been approved by a financial institution, the needed funds are available and the related payment of the transaction can be executed. For this LANDSTEAD POC we will not implement blockchain alternatives for these verifications or payments.
28
In our opinion however, once a Country has taken the needed regulatory steps to make blockchain payments an alternative legal tender in the Country, such additional functionalities could be added. In such case the payment could be executed by the Notary, together with the change of ownership, in the same atomic transaction on the blockchain. Technically it is possible (catapult release), it will only require some legal changes supported by the Notaries to make it viable.
29
Simplified flows Terminology BW - Brain wallet MS - Multi Signature IDc - Citizen Identification Number or Code IDp - Property Identification Number or Code [G] - Government's account (Private Key) [C] - Citizen's account (Private Key, in other examples NAAAAA), must have received a country:citizen Asset with IDc as message [PC] - Pointer to Citizen and brainwallet from IDc@atlantis:citizen (in other examples NPOINT1) [P] - Property Account and brainwallet from IDp@atlantis:parcel (in other examples NPOINT2, although it is not needed to use it as a pointer account with a pointer message). Must have received a country:parcel Asset (representing the Property Type) with IDp as message [N] - Notary Account (one that has received a country:notary Asset) Tokens • atlantis:citizen • atlantis:notary • atlantis:parcel • atlantis.register:citizen • atlantis.register:notary • atlantis.register:parcel • atlantis.revoke:citizen • atlantis.revoke:notary • atlantis.revoke:parcel
Use Case: Register a Citizen 0. User creates [C] on it's own and submits his account [C] for validation and registration 0. Gov. creates [G] and all the Assets Civil Servant continues registration use case 1. Civil Servant logs in to [G], and accesses 'Validate an account'. 2. A form with 2 fields is presented: the IDc of the citizen and the Citizen’s Account number [C]. 2.1 Civil Servant inputs ID Firstname Lastname@country:citizen (We could use Firstname and Lastname so nobody else can guess upfront what the account numbers will be, and because the date of birth is already integrated in the ID. At least that’s the case in Belgium) 2.2 [PC] BW gets created 2.3 [PC] is set to be a MS acct from [G] 2.4 [G] inputs account number of [C] to send message (ID=C) to [PC] 30
2.5 [G] creates and sends atlantis.register:citizen to [PC] 2.6 [G] sends atlantis:citizen to [C]
Use Case: Register a Property 1. 2.
3.
4.
Civil Servant logs in to [G] and accesses ‘Register a Property’ A form is presented with the following fields 2.1. Selection of Property Type: (drop down, for the moment ‘parcel’ is the only one for Atlantis) 2.2. IDp, identification code of the property: Civil Servant enters the following information 3.1. he selects Property Type ‘Parcel’ 3.2. he enters the Parcel identification as IDp 3.3. he confirms with Send 3.3.1. [P] gets created from IDp@country:parcel 3.3.2. [G] sends message together with 1 country:parcel Asset to [P] 3.3.3. Convert [P] into MS with cosigner [G] for protection Optional: When cadastral documents are available they can be Apostilled using [P]
Use Case: Register a Property Ownership Once the Civil Servant has proof of ownership, based on existing cadastral services or existing paper Notary Acts, the magic can happen ;-) 1. Civil Servant logs in to [G] and accesses ‘Register property ownership’ 2. Form is presented with fields for 2.1. Type of owner (must be a country Asset, default citizen) 2.2. IDc 2.3. Property type (must be a country Asset, default parcel) 2.4. IDp 3. After providing the info and confirmation, the following steps are performed 3.1. [P] is determined based on IDp@country:parcel, Asset presence of country:parcel is checked in [P]. 3.2. [PC] is determined based on IDc@country:citizen 3.3. In [PC], Incoming messages from [G] are read to find the last message starting with “=” 3.4. If that last message has an account after the “=”, that is the actual Account of the Citizen: |C] 3.5. Asset presence of country:citizen is checked in [C] 3.6. [P] is converted to multisig with 1 cosigner: [C] This represents the Citizen’s ownership of the property!
Use Case: Verify an Account 3.
Citizen logs in to [C] and accesses ‘Verify account’ Citizen can see in his balance he has received 1 country:citizen Asset from the Country, 31
4.
confirming the country has validated his IDc Citizen can see in his balance he has received 1 or more country:parcel Assets from the Country, confirming the country has validated him/her as owner of the properties. Additional info about the Properties can be provided based on: 4.1. the IDp mentioned in the same message from the Country in which the country:parcel Asset was received 4.2. the multisig accounts (can be more than one for rich people ;-) of which [C] is cosigner: [P] in this example 4.3. Any optional Apostille Accounts created for Property documents. These can be found as outgoing messages from [P] (See Use case Register a Property)
Use Case: Transfer a Property 1.
2.
Citizen gives a Notary Access to the property: 1.1. Citizen logs into [C] and Accesses ‘Give Notary access to property’ 1.2. form with a field for the Account number of the Notary [N] 1.3. Citizen confirms Account [N] is added as cosigner to the property account [P], with only 1 signature needed. Notary logs into [N] 2.1. ...
Private Pointer Accounts Pointing accounts can be open and public to all or encrypted and hidden. The open way has been discussed above. To make it encrypted take the citizens private key and hash it with a known algorithm we aren’t using yet. Let’s say in this case MD5 instead of the SHA series most people use. That will produce a new key that only the citizen can know. We take the first or last x characters of that key. So lets say the MD5 hash of the citizen’s key is “be8bec133a7d30e6b59e4b8f34736362a6c94294334b816e76d549d70ab6277c237bba5095136 bb38833d7aa504ed7ae9f151c876d23d9fa9ae6a22ee01” so I take the first 10 characters. This “be8bec133a” this code become the salt. So instead of a pointer account being made with the passphrase “NationalNumber@belgium:citizen”, it would instead be made with “NationalNumber-salt@belgium:citizen”. So our previous example in this document which was “50.22.54-240.346@belgium:citizen”, would now be “50.22.54-240.34-be8bec133a@belgium:citizen”. The account address in the message would also get salted too with the same salt. In our previous our account being pointed to was NC4DCX-4PU7UF-L22ELK-ZPTL7G-WRN5XU-IAYV2W-RITA but if I add the salt to it, like this 32
“NC4DCX-4PU7UF-L22ELK-ZPTL7G-WRN5XU-IAYV2W-RITA-be8bec133a” and now hash that with MD5, I get "9e696964c315167a9b6006f3cbeb992d” which can be left as the message in the pointer account. Rita can now give her National ID number, NEM address and salt to anybody and they can verify through this protocol that the Belgium government has certified her account as real. Pointing account could also have a link to an encrypted PDF in it. With the PDF encrypted again with the salt. anybody verifying her could click that link in the pointing account, download the pdf, unzip it with the above salt and then see a basic driver’s license info about her including her picture, date of birth, age, address, and all that. All this might sound complicated, but it would as simple as her waiving a QR formatted with the address, ID number, and salt combined in it and somebody else scanning it. All the rest is automated. All the citizen would need to know is her master pass phrase to restore her account on any phone.
33
Bonuses Thanks to the capabilities of this project and its concepts, using proper account management and apostille, we can easily add other registry systems based on anyone or anything with an ID, Serial Number or equivalent: - Birth certificate - Car certificates - Company register - ... Other technologies could be used to improve user friendliness, for example Transfer of properties via NFC or Qr Codes. Resources http://www.id.gov.ae/en/id-card/id-card-benefits.aspx http://www.id.gov.ae/en/id-card/faq.aspx https://www.property24.com/property101/buyers-guide/property-transfer-[infographic]/16659 https://www.property24.com/property101/buyers-guide/registering-a-home-in-your-name/15311 http://www.dubailand.gov.ae/ http://www.dubailand.gov.ae/English/Real%20Estate%20Services/Sale%20Services.pdf http://www.dubailand.gov.ae/English/Real%20Estate%20Services/Survey%20Services.pdf https://e-justice.europa.eu/content_land_registers_in_member_states-109-en.do
34
Future Work Based on the experience of this project, some potential improvements were identified that are technically not yet possible with the 0.6.82 Beta version of NEM. The following are therefore some suggestions for additional capabilities to be considered to implement in future versions of NEM.
Atomic or linked transactions In some Use Cases it makes sense to link two or more transactions together, f.e. in the Change Ownership Use Case described above. Maybe catapult will provide this possibility, to be confirmed. If not, we should describe it in more detail.
Identifiable Assets In this project an asset, such as a parcel (piece of land), was identified with a Brainwallet Account created with a unique Passphrase (12452B0166/00J001@belgium:parcel). Using this method, an asset is represented with an account. While NEM provides Assets to represent assets, until now Assets can only be used to represent fungible assets. Although using accounts to represent identifiable not-fungible assets is a creative solution based on the current (0.6.82) technical capabilities of the NEM blockchain to, it can also be considered as: ● a workaround, around the lack of support for identifiable not-fungible assets ● an inappropriate usage of accounts Support for Identifiable Assets could provide a better solution to this need in some cases. A big part of the Business Logic to work with these Asset ID’s could be implemented client side, while additional server load could probably be limited to validation of transactions.
Creation of an Identifiable Asset When a Asset is created, the issuer could determine if he wants to create a regular fungible Asset (these are the the existing 0.6.82 Assets) or an Identifiable not-fungible Asset. This choice could be presented to the user as a Yes/No checkbox, analog to the Transferable, Mutable Supply and Requires Levy checkboxes.
35
In the case of an Identifiable Asset, the Divisibility should always be 0, since Identifiable Assets can only be sent, one by one, uniquely identified by their ID (Serial Number, Chassis Number of a car, …)
Creating an Identifiable Asset An issuer of an Identifiable Asset can register the creation of an asset by transferring 1 (one) Asset to an account of the owner of the asset. The Amount of the transfer should always be 1 (one). The transfer has an additional and mandatory field ID (Serial Number, Chassis Number, …) that has to be provided by the issuer. The transaction should only be accepted if the ID can be confirmed to be unique within that specific namespace:asset or namespace.sub-namespace:asset domain.
Transferring an Identifiable Asset The Amount of the transfer should always be 1 (one). The sender should choose the ID from a list, presented as a drop down, with the list constructed based on the ID’s of the same Asset that the account received and did not send back out again yet.
Parcel example belgium:parcel with ID12452B0166/00J001 ● can be created by Belgium, the same as it was created in the example ● can be transferred directly to Rita’s account (no more need to create a Brainwallet for the parcel and converting it to a multisig account with Rita’s account as cosigner)
Cosigners Weight for Multi-signature Accounts In order to support the following situation of ownership after the heritage (grandfather), a property (house), would be split in four parts for four siblings. Two of them are deceased themselves, one having two children, the other three. This would be the situation: ● ¼ ● ¼ 36
● ¼, split in two: 2 x 1/8 ● ¼, split in three: 3 x 1/12 The Ownership of the House could be represented by converting the Asset Account into a 7/7 multi-signature account having all 7 persons as cosigners. However, until now, there is no possibility to register the weight of their individual ownership. Creating a specific Asset for the shares in this property seems overkill, no?
Multi-signature chaining In the example of a company with multiple shareholders and a board of directors, one can imagine that the account of the company would be a multisignature account with multiple co-signers. A contract of the company registered with Apostille would be converted into a Multi-signature account itself, with the company being the Owner of the contract. Today this is not possible.
37
