BLOCKCHAIN

The Blockchain module is Leaseora's Distributed Ledger Trust Layer. It allows selected documents and transactions from Insurance, Mortgage, Lease Management, WeBuild, Property Development, Compliance and the Document Hub to be anchored to a blockchain using a cryptographic document hash. The platform stores the resulting blockchain transaction hash, block number, registration status and timestamp on the relevant Leaseora record.

Leaseora Jul 30, 2026 59 min read 19 views

LEASEORA

BLOCKCHAIN

End-to-End User and Technical Operations Guide

Document Registration • Verification • Smart Contracts • Audit Trails • Insurance • Mortgages • Leases • Compliance • AI Insights

For real estate companies, corporate landlords, property managers, legal, compliance, mortgage, insurance, finance, security and operations teams

Version 1.0 | July 2026

Purpose of this guide

This guide explains how a real estate company uses Leaseora's Blockchain module as a distributed-ledger trust layer for critical real estate records. It covers document hashing and registration, verification results, blockchain transaction monitoring, mortgage smart contracts, on-chain payment evidence, immutable document audit trails, module-specific workflows, client verification, independent third-party verification, AI-assisted monitoring and SuperAdmin network configuration. It also provides a technical reference for the supplied models, controllers, services, events, listeners, fields and method contracts.

Document Control

Item	Details
Document title	Leaseora Blockchain Module User and Technical Operations Guide
Version	1.0
Date	July 2026
Primary audience	Real estate companies, corporate landlords, property managers, legal teams, compliance teams, mortgage teams, insurance teams, finance, IT, security and senior management.
Client audience	Private and corporate clients who receive, sign, verify or make payments against blockchain-protected records through Leaseora web or mobile services.
Technical coverage	BlockchainDocumentService, BlockchainController, blockchain models, module controllers, document fields, smart-contract methods, audit trail methods, event-driven registration, AI insights and SuperAdmin configuration.
Terminology	This guide uses Client in user-facing explanations. Backend class names and routes that use Tenant are preserved exactly in technical sections.

How to Use This Guide

· Business users should begin with Sections 1 to 6, then follow the numbered operational steps for the document type they manage.

· Legal and compliance teams should focus on registration evidence, canonical versions, verification outcomes, audit trails and independent verification.

· Mortgage and finance teams should study the smart-contract deployment, payment execution and reconciliation controls before using live transactions.

· IT and security teams should review network configuration, key custody, privacy, retries, monitoring and implementation details requiring confirmation.

· Product and engineering teams should preserve the supplied model, controller, service, method and field names when validating the live build.

Blockchain evidence has a defined boundary

Registration proves that a specific digital fingerprint existed on the configured blockchain at a recorded time. It does not by itself prove that the statements inside the document are true, that the signer had legal authority, or that the underlying transaction was lawful. Those questions still require business, legal, identity and compliance review.

1 Purpose, Scope and Terminology

Item	Description
Primary business purpose	Create tamper-evident evidence for high-value real estate documents and selected payment or access events.
Core operations	Register document hashes, monitor network confirmation, verify current content, display verification badges, retrieve audit trails, deploy mortgage smart contracts and record smart-contract payment executions.
Supported module contexts	Insurance policies and claim evidence, mortgage documents and legal contracts, signed lease documents, WeBuild and property-development legal documents, compliance documents and Document Hub files selected for registration.
Client experience	Clients can see verification status for shared documents and mortgage records through the web or mobile experience.
Independent verification	Where the configured blockchain is publicly inspectable, authorised third parties can review the transaction hash and block information without relying only on Leaseora.
Technical scope	BlockchainDocumentService, BlockchainTransaction, BlockchainDocument, source-document blockchain fields, module controllers, events, listeners, OpenAIService insights and SuperAdmin network management.

Key terminology

Term	Meaning
Document hash	A cryptographic fingerprint, described in the supplied design as SHA-256, calculated from the document content. A change to the content produces a different fingerprint.
blockchain_hash	The document's unique hash identifier stored for blockchain verification.
blockchain_tx_hash	The blockchain transaction identifier returned after registration or payment execution.
blockchain_block_number	The block in which the registration transaction was confirmed.
blockchain_status	The registration lifecycle state: null/not registered, pending, processing, confirmed or failed.
blockchain_registered_at	The timestamp at which the document registration was confirmed.
contract_address	The address of a deployed mortgage smart contract.
Canonical version	The authoritative document version the company intends to rely on, typically the fully reviewed and signed PDF.
Verification	The comparison of the current document hash with the blockchain-registered hash.
Audit trail	An immutable chronological record of document actions such as viewed, downloaded, signed, shared, modified or revoked.
Blockchain explorer	A network-specific interface that can display transaction, block and contract information where the configured network permits public inspection.

Do not confuse the hash with the document

The supplied architecture registers the document fingerprint and selected metadata, not the full lease, policy, identity document or claim evidence file. Staff should never copy sensitive raw document content into a public blockchain transaction.

2 Roles and Responsibilities

Role	Main responsibilities	Key controls
Corporate Landlord / Real Estate Company	Approves the use of blockchain protection, defines eligible document types and oversees costs, legal use and governance.	Must approve policies on canonical versions, network use, evidence retention and exception handling.
Document / Property Administrator	Uploads or generates records, chooses the correct property, client, lease or module context and monitors registration status.	Must verify file quality and metadata before registration; cannot treat pending as confirmed.
Legal / Authorised Signatory	Reviews and signs contracts, determines which signed version is authoritative and assesses verification evidence.	A draft hash should not be presented as the final signed contract.
Compliance Officer	Oversees compliance-document registration, event-driven processing and regulator evidence packs.	Confirms that personal data and restricted content are not exposed on-chain.
Mortgage Team	Registers mortgage documents, deploys approved smart contracts, monitors payment transaction hashes and exports evidence.	Contract deployment and payment reconciliation require approval and tested templates.
Insurance Team	Registers insurance policies and each claim-evidence file, monitors failures and verifies submitted evidence.	Each claim file must be matched to the correct array entry and claim record.
Finance Team	Reviews blockchain fees, smart-contract payment records and reconciliation with gateways, wallet, bank and accounting.	An on-chain payment signal does not replace settlement verification where the payment rail is off-chain.
IT / Security Team	Monitors network health, integrations, failed transactions, permissions and incident response.	Private keys, RPC credentials and deployment wallets must be protected.
Client / Tenant	Views, signs, downloads and verifies documents or mortgage payment history exposed to their account.	Must use the correct file/version when performing independent verification.
Leaseora SuperAdmin	Configures networks, RPC endpoints, chain IDs, gas strategy, batch schedules, templates, retry queues and platform monitoring.	Platform configuration does not replace landlord approval of a document or contract.

3 Complete Module Journey

Figure 1. Blockchain module end-to-end trust lifecycle

Phase	Business outcome	Primary records / services
1. Platform configuration	The SuperAdmin connects Leaseora to an approved blockchain network and configures registration, fee and contract controls.	SuperAdmin BlockchainController, network settings and smart-contract templates.
2. Document preparation	The landlord creates, uploads, generates or signs the correct document version.	InsurancePolicy, MortgageDocument, LeaseDocument, Document, legal and compliance records.
3. Registration	BlockchainDocumentService calculates or receives the hash and submits the registration transaction.	BlockchainDocumentService, BlockchainTransaction, BlockchainDocument.
4. Confirmation	The network confirms the transaction and the source record stores the hash, transaction hash, block number, status and timestamp.	Source-model blockchain fields.
5. Verification	Landlord, client or authorised third party checks whether the current content matches the registered fingerprint.	verifyDocument result and verification badge.
6. Smart-contract operation	An approved mortgage smart contract can be deployed and payment events recorded on-chain.	Mortgage.contract_address and MortgagePayment.blockchain_tx_hash.
7. Audit and intelligence	Access actions, transaction history, coverage gaps, failures and costs are monitored.	Audit trail methods, dashboard, exports and OpenAIService insights.

4 What the Blockchain Module Does and Does Not Do

Capability	What it does	What it does not automatically prove
Document registration	Anchors a cryptographic fingerprint and selected metadata to the configured blockchain.	That the content is factually correct, legally valid or created by an authorised party.
Document verification	Shows whether the current file matches the registered fingerprint.	Why a mismatch occurred or whether it was malicious.
Timestamp and block evidence	Provides transaction and block information for the registration event.	A legal filing date unless applicable law recognises it for that purpose.
Audit trail	Creates immutable evidence of logged access actions.	That an unlogged action never occurred outside Leaseora.
Smart-contract payment record	Records a mortgage payment execution signal on-chain and returns a transaction hash.	Bank or gateway settlement when the underlying money movement occurs outside the blockchain.
Independent verification	Allows a party to inspect public network data where supported.	That the party has selected the correct chain, contract, transaction or document version.
AI insight	Identifies patterns, coverage gaps and likely failure causes.	A final legal, security, financial or fraud decision.

Canonical version rule

Register the version the business intends to rely on. For a lease or development contract, the final fully signed PDF should normally be treated as canonical. A draft may be registered for internal history, but its badge and label must clearly state that it is not the final signed agreement.

5 Implementation Prerequisites and Governance

Business information and decisions to prepare

☐ Approved list of document categories eligible for blockchain registration.

☐ Rules distinguishing drafts, approved versions, signed versions and superseded versions.

☐ Named owners for Insurance, Mortgage, Lease, WeBuild, Development, Compliance and Document Hub records.

☐ Approved network and evidence policy supplied by Leaseora / SuperAdmin.

☐ Legal review of the intended evidential use in each operating jurisdiction.

☐ Privacy review confirming that only hashes and approved metadata are transmitted on-chain.

☐ Budget and approval process for network transaction fees.

☐ Retry, escalation and incident-response procedure for failed registrations.

☐ Smart-contract template approval, test evidence and change-control process.

☐ Payment reconciliation procedure linking gateway, wallet or bank records to smart-contract transaction hashes.

☐ Staff permissions for registration, verification, contract deployment, exports and audit access.

☐ Retention policy for original files, signed versions, hash evidence and exports.

Recommended implementation sequence

1. Confirm the configured blockchain network, supported document types and registration mode with Leaseora.

2. Select one low-volume document type for a controlled pilot, such as signed lease agreements or insurance policies.

3. Create a test document, calculate its hash through the normal workflow and register it.

4. Confirm the transaction reaches confirmed status and the record stores all expected metadata.

5. Download the same file and confirm verification returns verified.

6. Create a copy with one controlled change and confirm the result returns tampered rather than verified.

7. Test a missing or unregistered file and confirm not_found is handled clearly.

8. Test role permissions, client visibility, explorer links, exports and audit records.

9. For mortgage use, deploy and execute payments only against a test smart-contract template first.

10. Review transaction costs, monitoring, retry behaviour and evidence packages before expanding to live portfolios.

Never test destructive scenarios on production evidence

Tamper testing should use copies created for user acceptance testing. Do not alter a live signed agreement, insurance policy, title record or regulator submission merely to test the verification result.

6 Phase 1 - Blockchain Dashboard and Overview

Steps 1 and 2: open the trust layer, understand coverage and identify items requiring action.

STEP
1

Access the Blockchain Dashboard

Primary user: Corporate Landlord / Authorised Administrator / Legal / Compliance

Log in to Leaseora and navigate to Blockchain (/blockchain). BlockchainController@index loads the landlord-specific dashboard. The screen should aggregate blockchain activity across all modules that belong to the authenticated landlord, while platform-wide configuration remains under SuperAdmin control.

Dashboard area	What it shows	Operational use
Registered documents	Total number of blockchain-protected documents across Insurance, Mortgage, Leases, WeBuild, Development, Compliance and Document Hub.	Assess coverage and compare against the company registration policy.
Registration queue	Pending and processing transactions awaiting confirmation.	Identify delayed transactions and avoid duplicate resubmission.
Verification results	Verified records and alerts for tampered, failed or not-found results.	Prioritise legal, security or document-version review.
Smart contracts	Deployed mortgage contracts and current state information.	Confirm contract deployment, address and payment activity.
Transaction logs	Registration, verification, audit and contract transaction history.	Trace operational activity and prepare evidence exports.
Gas / fee summary	Network fee information associated with blockchain transactions.	Monitor budget and identify batch opportunities.
AI insights	Coverage gaps, unusual verification frequency, failure patterns and cost recommendations.	Use as decision support for investigation and optimisation.

Landlord dashboard versus platform network settings

The landlord dashboard monitors the company's records and transactions. Network selection, RPC endpoint, chain ID, deployment wallet and platform-wide contract templates are configured by SuperAdmin, not by ordinary landlord staff.

STEP
2

Review Dashboard Alerts and Transaction Detail

Primary user: Legal / Compliance / IT / Mortgage / Insurance Operations

Begin each review by filtering the transaction log by module, status, date range and document type. Open an individual transaction to compare the Leaseora record with its blockchain metadata. A complete confirmed registration should contain the source record reference, blockchain hash, transaction hash, block number, status and registration timestamp.

☐ Confirm the transaction belongs to the expected company and source module.

☐ Confirm the document title, type and internal ID match the source record.

☐ Confirm status is confirmed before presenting a Blockchain Verified badge.

☐ Confirm the transaction hash and block number are present.

☐ Open the source document and run verification when the evidence will be relied upon.

☐ Review failed transactions for an error reason and retry status.

☐ Escalate tampered results to Legal, Compliance and Security before replacing or deleting any evidence.

☐ Export the relevant transaction record when preparing an insurer, lender, regulator or dispute evidence pack.

7 Phase 2 - Core Blockchain Service and Registration Architecture

STEP
3

Understand BlockchainDocumentService

Primary user: IT / Product / Technical Operations / Authorised Module Administrators

BlockchainDocumentService is the central engine for all blockchain interactions in the supplied design. Module controllers should call the service rather than implementing network-specific encoding, hashing, verification or smart-contract operations independently. This keeps registration and verification behaviour consistent across Leaseora.

Method	Primary purpose	Core result
registerDocument($documentData)	Register a document hash and metadata on-chain.	blockchain_hash, blockchain_tx_hash and blockchain_block_number.
verifyDocument($documentHash, $documentContent = null)	Compare a supplied or newly calculated hash against the blockchain record.	verified, tampered or not_found.
createAuditTrail($transactionData)	Register a document action as an immutable audit event.	audit transaction hash.
getAuditTrail($transactionId)	Retrieve chronological, cryptographically verifiable audit entries.	Array of audit entries.
createMortgageSmartContract($mortgageData)	Deploy a mortgage payment contract using approved loan and party data.	contract_address.
executePayment($contractAddress, $paymentData)	Record a mortgage payment execution against a deployed contract.	payment transaction hash.

Document data submitted for registration

Data element	Purpose	Control
title	Human-readable document name used in Leaseora records and logs.	Use the approved record title; do not expose unnecessary personal data.
hash	SHA-256 fingerprint of the exact file content.	Calculate from the final file bytes; do not hash a different preview or source format.
type	Module or document classification such as insurance_policy or lease_document.	Use a controlled vocabulary for reporting and coverage analysis.
metadata	Approved contextual identifiers such as policy number, property ID or landlord ID.	Limit to non-sensitive information required for traceability.
source reference	Leaseora internal model and record ID linking on-chain evidence to the source record.	Confirm company ownership and permission before submission.

STEP
4

Register a Critical Document

Primary user: Authorised Document Administrator / Legal / Compliance

1. Open the final document in its source module and confirm the title, record link, file format and status.

2. Confirm the version is eligible for registration under the company policy.

3. Choose Register on Blockchain where the module provides a manual action, or complete the triggering action where registration is automatic.

4. Leaseora calculates or accepts the SHA-256 content hash and sets blockchain_status to pending.

5. BlockchainDocumentService submits the transaction to the configured network.

6. Monitor the transaction until the network confirms it or returns a failure.

7. On confirmation, verify that blockchain_hash, blockchain_tx_hash, blockchain_block_number and blockchain_registered_at are stored where the source model supports them.

8. Run verifyDocument against the stored file and confirm the user interface displays Verified.

9. Record any approval or evidence-pack reference required by the company procedure.

Registration should be idempotent

A retry or duplicate click should not create competing records for the same canonical file unless the product intentionally supports multiple registration events. Technical teams should confirm duplicate protection and idempotency in the live implementation.

STEP
5

Monitor Registration Status and Resolve Failures

Primary user: IT / Blockchain Operations / Module Administrator

Figure 2. Document registration and verification status flow

Status	Meaning	Required action
Not registered / null	No blockchain registration has been started for this record.	Register only when the document and policy require it.
Pending	The service accepted the request and submitted or queued the transaction.	Monitor; do not label the record confirmed.
Processing	The transaction is being prepared, broadcast or awaited by the network.	Check network health and queue age before retrying.
Confirmed	The transaction has been mined or otherwise finalised according to the configured network.	Store metadata, verify the file and display the confirmed badge.
Failed	The transaction could not be confirmed or the service returned an error.	Review error logs, correct the cause and use the approved retry path.

A failed registration does not alter the source document

The document can remain legally and operationally valid even when blockchain anchoring fails. The failure affects the extra blockchain evidence layer and must be handled without deleting or replacing the original business record.

8 Phase 3 - Insurance Policies and Claim Evidence

STEP
6

Register an Insurance Policy

Primary user: Insurance Administrator / Property Manager / Compliance

When a landlord creates or uploads an insurance policy through InsurancePolicyController@store, the supplied flow calls BlockchainDocumentService@registerDocument automatically. The policy uses a single set of blockchain fields because the policy record is associated with one principal policy document.

Policy field	Value stored	How staff use it
blockchain_hash	SHA-256 fingerprint of the policy PDF.	Verify the current policy file has not changed since registration.
blockchain_tx_hash	On-chain registration transaction.	Open or cite the network transaction where supported.
blockchain_block_number	Block containing the registration.	Provide block evidence and trace confirmation.
blockchain_status	pending, confirmed or failed.	Control badge display and exception handling.
blockchain_registered_at	ISO registration timestamp.	Record when the policy fingerprint was anchored.

1. Open the insurance policy record and confirm the policy number, property, insurer, coverage amount and document file.

2. Save or generate the final policy document through the normal insurance workflow.

3. Confirm the registration request enters pending status.

4. Monitor until the policy record shows confirmed and all returned metadata is populated.

5. Open the document detail page and run verification before presenting the policy to a lender, client or regulator.

6. If the policy is renewed or replaced, register the new policy file as a new canonical version rather than overwriting the historical evidence.

Renewal creates a new fingerprint

Any change to policy dates, limits, endorsements or wording changes the document hash. Keep the historical policy and its blockchain record, then register the renewed or amended policy as a separate version.

STEP
7

Register and Verify Insurance Claim Documents

Primary user: Insurance Claims Team / Compliance / Legal

InsuranceClaimsController@uploadDocuments registers each uploaded claim file separately. InsuranceClaim stores aligned JSON arrays for hashes, transaction hashes, block numbers and statuses. This allows a repair quote, photo, police report and other evidence to be verified independently within the same claim.

Array field	Purpose	Critical alignment control
blockchain_hashes[]	One document fingerprint for each uploaded claim file.	Index n must refer to the same file as index n in every related array.
blockchain_tx_hashes[]	One registration transaction per file.	Do not reorder without preserving the file mapping.
blockchain_block_numbers[]	Confirmation block per file.	Use together with the matching hash and transaction hash.
blockchain_statuses[]	Registration state per file.	A single failed item should not be mistaken for failure of the entire claim.

☐ Name each claim file clearly before upload.

☐ Upload only evidence linked to the correct InsuranceClaim record.

☐ Confirm each file produces its own array entry.

☐ Compare array counts with the number of uploaded documents.

☐ Verify high-value evidence before claim review or external submission.

☐ Escalate a tampered result without deleting the current or original file.

☐ Export a manifest showing file name, hash, transaction hash, status and block number when sharing a claim evidence package.

9 Phase 4 - Mortgage Documents and Smart Contracts

STEP
8

Register Mortgage Documents and Legal Contracts

Primary user: Mortgage Operations / Legal / Compliance

MortgageDocument records are registered when uploaded through the mortgage workflow. MortgageLegalDocumentController injects BlockchainDocumentService so generated and uploaded mortgage legal contracts can be registered and their access logged. The document record stores blockchain_hash, blockchain_tx_hash and blockchain_status.

Document category	Registration point	Additional control
Mortgage application document	After upload and approval under the mortgage document workflow.	Confirm it belongs to the correct applicant and application.
Mortgage offer	After the final offer has been approved and issued.	Do not confuse a preliminary illustration with the binding offer.
Mortgage agreement	After final terms and signatures are complete.	Register the signed canonical PDF.
Collateral / title evidence	After authorised upload and document review.	Use strict access permissions and verify before reliance.
Mortgage legal notice	After generation or approved upload.	Log access and preserve version history.

Document registration and smart-contract deployment are separate

Registering a mortgage agreement protects the document fingerprint. Deploying a mortgage smart contract creates executable on-chain logic and a contract_address. One does not automatically imply the other.

STEP
9

Verify and Export Mortgage Evidence

Primary user: Mortgage Operations / Client Support / Legal

1. Open the MortgageDocument record and select Verify Blockchain.

2. MortgageDocumentController@verifyBlockchain($id) loads the document and calls verifyDocument using the stored hash and, where supplied, the current content.

3. Review the result: verified, tampered or not_found.

4. For verified documents, confirm the badge displays registration metadata and the correct source record.

5. For tampered documents, freeze the evidence workflow and compare file versions before any corrective action.

6. For not_found, confirm the document was intended to be registered and that the correct network and record were queried.

7. Use exportZip to create a document package with a blockchain-status manifest.

8. Use exportPDF to produce a human-readable list with verification badges, or exportCSV to provide blockchain metadata for reconciliation or audit.

Export	Expected blockchain information	Use
ZIP	Original files plus manifest showing status and identifiers.	Evidence handoff or secure archive.
PDF	Document list and verification badges.	Management, lender, legal or regulator review.
CSV	Hash, transaction hash, status, record ID and related metadata.	Reconciliation, analytics or system import.

STEP
10

Deploy a Mortgage Smart Contract

Primary user: Authorised Mortgage Director / Legal / Technical Operations

When an approved mortgage is activated, BlockchainDocumentService@createMortgageSmartContract($mortgageData) can deploy an approved smart-contract template containing the supplied loan terms, parties, schedule and collateral reference. The returned contract_address is stored on the Mortgage record.

Input	Purpose	Pre-deployment validation
loan_amount	Principal encoded for the contract.	Must match the signed mortgage agreement.
interest_rate	Approved contractual interest rate.	Confirm units, fixed/variable treatment and precision.
term_months	Total contract term.	Must match the approved schedule.
monthly_payment	Expected periodic amount.	Reconcile with amortisation schedule and currency.
payment_schedule[]	Due dates and amounts.	Validate every entry and any final adjustment.
landlord_address	Landlord blockchain address.	Confirm address ownership and supported network.
tenant_address	Client blockchain address.	Confirm identity and address association.
collateral_property_id	Leaseora property reference.	Confirm the correct property and legal collateral record.

☐ The mortgage application and offer are approved.

☐ The signed mortgage agreement is final and blockchain-registered where required.

☐ The payment schedule reconciles with the agreement.

☐ Both blockchain addresses have been validated.

☐ The collateral property ID is correct.

☐ The approved and audited smart-contract template version is selected.

☐ The deployment wallet has sufficient approved funds for fees.

☐ Legal and technical approvals are recorded.

☐ The test deployment and payment execution have passed in the approved environment.

Figure 3. Mortgage smart contract lifecycle

STEP
11

Execute and Reconcile a Mortgage Payment

Primary user: Mortgage Finance / Client / Technical Operations

After the client pays through the configured gateway, wallet or bank-transfer workflow, BlockchainDocumentService@executePayment($contractAddress, $paymentData) records the payment event against the deployed smart contract. MortgagePayment.blockchain_tx_hash stores the returned transaction hash.

Payment data	Purpose	Control
amount	Installment amount submitted to the contract.	Must match the confirmed Leaseora payment amount and contract currency treatment.
date	Effective payment date.	Use the approved payment date and timezone convention.
reference	Leaseora or payment-rail reference.	Must be unique and traceable to the gateway, wallet or bank evidence.
contractAddress	Target mortgage smart contract.	Confirm it belongs to the correct Mortgage record.

1. Confirm the payment has reached the required verified or settled state in the payment rail.

2. Open the correct Mortgage and MortgagePayment record.

3. Confirm the contract_address and installment schedule entry.

4. Execute the payment through the approved service action.

5. Store the returned transaction hash on MortgagePayment.

6. Confirm the on-chain ledger reflects the payment event.

7. Reconcile the Leaseora payment, gateway/wallet/bank record, accounting entry and blockchain transaction.

8. Notify both parties according to the mortgage workflow.

9. At final payment, confirm whether the approved smart-contract template supports a fully-paid state and any encoded lien-release process.

Blockchain recording is not settlement verification

Where money moves through a gateway, wallet or bank transfer outside the blockchain, Finance must still verify settlement. The on-chain transaction is an additional payment-evidence record, not a substitute for reconciliation.

10 Phase 5 - Lease and AI-Generated Document Protection

STEP
12

Register the Final Signed Lease Document

Primary user: Lease Administrator / Legal / Authorised Signatory

LeaseDocumentService@triggerAIDocumentAnalysis($document, $lease) pairs AI document understanding with blockchain registration in the supplied design. LeaseDocument stores the blockchain fields alongside ai_extracted_data, ai_summary and ai_risk_score. AILeaseDocument is registered after electronic signing so the final signed file becomes the authoritative version.

Lease field	Purpose	Review requirement
ai_extracted_data	Structured data extracted from the lease.	Compare names, dates, amounts and clauses against the signed document.
ai_summary	AI-generated overview of the lease.	Use for navigation, not as a replacement for the contract.
ai_risk_score	AI-assisted risk indicator.	Requires human review and policy context.
blockchain_hash	Fingerprint of the exact lease PDF.	Register the final signed canonical version.
blockchain_tx_hash	On-chain registration evidence.	Retain with the lease and evidence exports.
blockchain_status	Registration lifecycle.	Do not show confirmed badge while pending or failed.
is_signed / signed_at	AILeaseDocument signing state and timestamp.	Confirm all required signatories are complete before final registration.

1. Generate or upload the lease document and complete AI analysis where enabled.

2. Review the extracted data, summary and risk score against the source document.

3. Complete all required electronic signatures.

4. Confirm is_signed is true and signed_at is populated.

5. Register the fully signed PDF as the canonical version.

6. Confirm blockchain status reaches confirmed.

7. Run verification and ensure the signed file matches the on-chain fingerprint.

8. Share the document with the client using the normal lease or Document Hub permissions.

9. Preserve earlier drafts and their labels without replacing the signed version.

STEP
13

Create an Immutable Lease Access Trail

Primary user: Lease Operations / Legal / Compliance

For critical lease actions, BlockchainDocumentService@createAuditTrail records the document hash, action, actor, timestamp, IP address and contextual metadata. Typical actions include viewed, downloaded, signed, shared, modified and revoked.

Action	When to log	Example metadata
created	When the canonical lease record or document is created.	lease_id, property_id, generated_by.
shared	When access is granted to the client or another authorised party.	share_id, recipient type, expiry.
viewed	When the protected document is opened.	user ID, user type, IP address.
downloaded	When the protected file is downloaded.	device/session reference.
signed	When a required signature is completed.	signature hash, signer role, signing order.
modified	When a new version replaces the working document.	previous hash, new hash, reason.
revoked	When access or a share is withdrawn.	revoked_by, reason, effective time.

Access log versus acknowledgment

An audit entry proves that the system logged a view or action. A separate acknowledgment workflow may still be required to prove that the client explicitly confirmed reading or acceptance.

11 Phase 6 - WeBuild, Property Development, Compliance and Document Hub

STEP
14

Protect WeBuild and Property Development Legal Documents

Primary user: Property Development / WeBuild / Legal / Project Director

CorporateLandlordWeBuildController@generateContract can generate contract content with AI, convert it to PDF and register its hash. PropertyDevelopmentLegalDocument and PropertyDevelopmentDocument records support the development context. The fully signed version should be registered again as the canonical agreement after all signatures are complete.

1. Generate or upload the contract in the correct WeBuild or development project.

2. Review AI-generated clauses, parties, amounts, milestones and termination terms.

3. Create the initial PDF and, where policy requires, register it as a draft or approved pre-signature version.

4. Complete landlord, client, contractor or investor signatures in the approved order.

5. Generate the fully signed PDF and register its new hash as the canonical version.

6. Log each signature and material access action through createAuditTrail.

7. Run aiAnalyzeDocument where enabled and retain the analysis beside the document record.

8. Verify the final document before download, email or external submission.

A signature changes the file hash

Adding an electronic signature, certificate or final-page stamp changes the PDF bytes. The pre-signature and fully signed files therefore have different fingerprints. Register and label both only when the business requires both versions.

STEP
15

Register Compliance Documents Automatically

Primary user: Compliance Officer / Module Administrator

ComplianceDocumentUploaded fires whenever a compliance document is uploaded. RegisterComplianceDocumentOnBlockchain listens for the event, calls BlockchainDocumentService@registerDocument and stores the returned blockchain data on the ComplianceDocument record.

Event data	Purpose	Validation
document_id	Identifies the Leaseora Document record.	Confirm it belongs to the authenticated landlord and expected module.
document_type	Classifies the certificate, licence, audit report or other compliance file.	Use approved categories and registration rules.
landlord_id	Links the document to the owning landlord.	Required for data isolation and reporting.

☐ Confirm the compliance file is complete and approved before upload.

☐ Confirm the event is emitted once for the intended record.

☐ Confirm the listener creates or updates the correct blockchain registration.

☐ Monitor pending and failed states in the dashboard.

☐ Verify the file after confirmation.

☐ Include registration evidence in regulator or auditor exports where appropriate.

STEP
16

Register a Document Hub File on Demand

Primary user: Document Administrator / Legal / Compliance

Any critical file in the central Document Hub can be selected for blockchain registration where the feature is available. Suitable examples include title deeds, permits, compliance certificates, court orders, signed agreements and other high-value records. LandlordDocumentHubController@show($slug) displays the verification badge when blockchain metadata exists.

Before registration	During registration	After registration
Confirm title, module, property, lease, client, visibility and canonical version.	Submit through BlockchainDocumentService and monitor pending/processing.	Verify the current file and display badge only when confirmed.
Confirm the user has DocumentPolicy access to view and manage the file.	Avoid duplicate clicks while the transaction is pending.	Retain transaction hash, block number, timestamp and audit evidence.
Confirm the document is eligible under the company policy.	Do not expose raw personal document content in metadata.	Share with clients using normal Document Hub permissions; blockchain registration does not grant access.

12 Phase 7 - Verification by Landlords, Clients and Third Parties

STEP
17

Landlord Verifies a Registered Document

Primary user: Landlord / Legal / Compliance / Mortgage / Insurance

1. Open the document detail page in its source module.

2. Confirm blockchain_hash and blockchain_tx_hash are present and status is confirmed.

3. Select Verify Blockchain or the equivalent verification action.

4. The service calculates the current content hash when document content is supplied, or uses the supplied hash.

5. The service queries the configured blockchain record and compares the fingerprints.

6. Review the displayed result and registration metadata.

7. For verified, save or export the evidence if required.

8. For tampered, preserve both files, suspend reliance and investigate version history.

9. For not_found, confirm network, transaction, record mapping and registration history before retrying.

Result	Meaning	Business response
Verified	The current file fingerprint matches the registered on-chain fingerprint.	The document is unchanged since that registration event. Continue with the authorised workflow.
Tampered	The current file fingerprint differs from the registered fingerprint.	Treat as a version or integrity incident; preserve evidence and escalate.
Not Found	No matching blockchain record was located.	Check registration, network, identifiers and source record. Do not display a verified badge.

Tampered can mean version mismatch

A tampered result means the bytes do not match the registered version. It may indicate unauthorised alteration, a legitimate amendment, re-export, added signature, different scan or incorrect file selection. Investigation must determine the cause.

STEP
18

Client Verifies a Shared Document

Primary user: Client / Tenant

TenantDocumentPortalController@show($shareId) loads the shared document. When blockchain_hash is present, the system calls verifyDocument and displays the result inline. MortgageMobileController@mortgageDetail($id) and mobile document responses can expose blockchain_status so the app can show a lock icon and Blockchain Verified label when confirmed.

☐ The client is authenticated and the TenantDocumentShare is active.

☐ The correct property, lease or mortgage context is displayed.

☐ The document is the version intended for the client.

☐ The blockchain status is confirmed.

☐ The verification result is verified.

☐ Download permission is enforced independently of blockchain status.

☐ The client can view the transaction details permitted by the interface.

☐ Any tampered or not-found result is reported to the landlord rather than ignored.

STEP
19

Perform Independent Third-Party Verification

Primary user: Lender / Insurer / Regulator / Court / External Auditor

Where the configured network supports public inspection, an authorised party can review the blockchain_tx_hash independently. The party must use a compatible explorer or network interface, confirm the chain, inspect the transaction and compare the document fingerprint with the on-chain value.

1. Obtain the exact document file and its blockchain transaction hash from an authorised source.

2. Confirm the configured blockchain network and chain ID.

3. Open the transaction in a compatible network explorer.

4. Confirm the transaction timestamp, block number, contract or destination and stored fingerprint information.

5. Calculate the hash of the exact file using the approved algorithm and byte-preserving method.

6. Compare the independently calculated fingerprint with the on-chain value.

7. Record the verification date, tool, network, transaction and outcome in the evidence report.

8. Confirm the document identity and business context separately; a matching hash proves integrity, not factual truth.

Explorer examples are network-dependent

The supplied scenario mentions examples such as Etherscan and Polygonscan. The actual explorer depends on the blockchain network configured by Leaseora SuperAdmin. Do not assume Ethereum or Polygon unless the live configuration confirms it.

13 Phase 8 - Blockchain Audit Trails

STEP
20

Create and Retrieve a Document Audit Trail

Primary user: Legal / Compliance / Security / Authorised Module Staff

Figure 4. Immutable document audit trail

Audit field	Description	Operational control
document_id	Leaseora internal source-document ID.	Confirm the correct source record and company.
document_hash	Registered fingerprint of the document.	Tie the action to the correct canonical version.
action	viewed, downloaded, signed, shared, modified, revoked or other controlled action.	Use consistent action names for reporting.
user_id / user_type	Actor and role.	Resolve to an authenticated user or approved external identity.
ip_address	Network address associated with the action.	Protect and retain as security data under company policy.
timestamp	Exact UTC event time.	Display local time separately without changing the source timestamp.
metadata	Context such as lease activation, signature hash or share ID.	Avoid unnecessary personal or secret information.

Use createAuditTrail immediately after the protected action succeeds. Store the returned audit transaction hash in the related Leaseora event or audit record where the implementation supports it. Use getAuditTrail($transactionId) to retrieve the chronological chain when preparing a dispute, insurance, regulatory or fraud-investigation report.

Audit trail use cases

Use case	Evidence question answered	Supporting records
Lease dispute	When did the client view, sign or download the agreement?	Tenant share, signature record, audit transaction hashes and verified lease file.
Insurance claim	Who uploaded, viewed or modified each evidence item?	InsuranceClaim file mapping and per-document blockchain arrays.
Regulatory audit	How was a compliance document handled after upload?	Compliance event, listener registration, access entries and verification result.
Fraud investigation	Which user, IP and session interacted with the document?	Blockchain audit entries plus Leaseora security and session logs.
Mortgage payment dispute	Was a payment event executed against the correct contract?	Payment rail evidence, MortgagePayment record, contract address and transaction hash.

14 Phase 9 - Blockchain Analytics, Monitoring and AI Insights

STEP
21

Monitor Blockchain Transactions and Costs

Primary user: Management / Finance / IT / Compliance

Report / filter	Management question answered	Recommended response
Registrations by module	Which business areas use blockchain protection?	Compare with the approved coverage policy.
Pending queue age	How long have transactions waited for confirmation?	Review network health before retrying.
Confirmed versus failed	What is the success rate?	Investigate repeated failure categories.
Verification results	How often are documents verified, tampered or not found?	Prioritise integrity and mapping issues.
Gas / fee summary	What does registration and contract activity cost?	Review budget and batch strategies.
Smart contracts deployed	Which mortgages have on-chain contracts?	Confirm contract status and payment execution.
Transaction export	Can management or auditors trace every operation?	Export filtered CSV or PDF with approval.

Recommended review cadence

Frequency	Review
Daily	Failed registrations, pending queue age, tampered alerts, payment execution failures and network-health warnings.
Weekly	Registration coverage by module, missing canonical versions, retry queue and smart-contract payment reconciliation.
Monthly	Fee trends, success rate, audit-log completeness, AI insights, staff activity and evidence exports.
Quarterly	Network strategy, smart-contract template versions, privacy controls, permissions, legal recognition and disaster-recovery testing.
Before external submission	Verify the exact document and assemble transaction, block, audit and source-record evidence.
After an incident	Preserve files and logs, revoke access if necessary, investigate, document resolution and retest controls.

STEP
22

Use AI Blockchain Insights

Primary user: Management / IT / Legal / Finance

OpenAIService can analyse blockchain usage patterns and produce decision-support insights. AI should receive only approved data and should not be treated as the final authority on document authenticity, network security, legal admissibility or fraud.

AI feature	Purpose	Required human review
Registration coverage analysis	Identifies document types or modules with low registration coverage.	Confirm whether the gap is intentional under policy.
Verification frequency insight	Highlights documents verified unusually often.	Determine whether this indicates dispute risk, high use or a benign process.
Failed-registration pattern analysis	Groups likely causes such as network, format or size issues.	Review technical logs and reproduce before changing configuration.
Smart-contract performance analysis	Examines execution success and payment timing.	Reconcile against actual MortgagePayment and settlement records.
Cost optimisation recommendations	Suggests batching or timing strategies.	Assess operational delay, network risk and evidence requirements before adoption.
Document AI + blockchain pairing	Extracts lease data and registers the document in one workflow.	Verify AI fields and the final canonical file separately.

AI does not change verification outcomes

The cryptographic comparison determines verified, tampered or not_found. AI may explain patterns or prioritise investigation, but it should not override the underlying hash result.

15 Phase 10 - SuperAdmin Blockchain Configuration

STEP
23

Configure the Blockchain Network

Primary user: Leaseora SuperAdmin / Platform Security / Blockchain Engineering

SuperAdmin\Core\BlockchainController@index manages platform-wide blockchain configuration. The supplied design supports selecting Ethereum, Polygon, Solana or a private enterprise blockchain, but the live deployment must confirm which networks and implementation adapters are actually available.

Configuration	Purpose	Control
Network selection	Chooses the blockchain used for registration and contracts.	Use an approved, supported and legally reviewed network.
RPC endpoint URL	Connects Leaseora to the blockchain node or provider.	Restrict credentials, use TLS and monitor availability.
Chain ID	Prevents transactions from being sent to the wrong network.	Validate against the selected network and environment.
Gas price strategy	Controls transaction-fee and confirmation-speed preference.	Use approved fast, average or slow policy based on urgency.
Deployment wallet address	Sends registration and contract-deployment transactions.	Monitor balance and restrict permissions.
Private key	Authorises blockchain transactions.	Encrypt, isolate, rotate and never expose to landlord users or logs.

Private-key custody is a critical control

A compromised deployment key could authorise unauthorised transactions. The supplied scenario says the private key is encrypted; the live implementation should also confirm access control, storage technology, rotation, backup and incident response.

STEP
24

Configure Registration, Batching and Retry Rules

Primary user: Leaseora SuperAdmin / Platform Operations

Setting	Options described in the scenario	Operational decision
Auto-registration	Register all eligible documents automatically or use on-demand registration.	Balance coverage against document readiness and transaction cost.
Minimum document size threshold	Threshold used by the registration policy.	Confirm whether it is a real production rule and how small files are handled.
Excluded document types	Document categories omitted from automatic registration.	Document the reason and ensure staff understand the gap.
Batch registration schedule	Hourly or daily batches of pending registrations.	Consider evidence urgency and confirmation delay.
Failed-transaction retry queue	Queue for retrying failed transactions.	Use backoff, duplicate protection and escalation thresholds.
Alert thresholds	Failure rate or queue age that triggers an alert.	Route to platform operations and security.

STEP
25

Manage Smart-Contract Templates and Platform Monitoring

Primary user: Leaseora SuperAdmin / Legal / Security / Engineering

☐ Use only pre-approved mortgage smart-contract templates.

☐ Complete code review and security auditing before production deployment.

☐ Assign a version identifier to every template.

☐ Prevent an existing mortgage contract from silently changing to a new template version.

☐ Test deployment, payment, final-payment and failure paths.

☐ Monitor block time, throughput, fee levels and RPC availability.

☐ Monitor failed deployments and payment executions.

☐ Maintain an emergency pause or incident process where supported by the contract design.

☐ Retain template source, audit reports, deployment parameters and contract addresses.

☐ Communicate platform incidents to affected landlords and clients according to policy.

16 Security, Privacy and Key-Management Controls

Control area	Required practice	Why it matters
Hash-only anchoring	Register fingerprints and minimal approved metadata rather than raw documents.	Reduces exposure of personal, legal and financial content.
Canonical file storage	Retain the exact registered file in secure Leaseora storage.	Verification is impossible if the original bytes cannot be reproduced.
Least privilege	Restrict registration, contract deployment, verification exports and audit access by role.	Prevents misuse and protects evidence.
Private-key protection	Encrypt and isolate transaction-signing keys.	Key compromise can authorise fraudulent blockchain transactions.
Network separation	Separate test and production endpoints, chain IDs and wallets.	Prevents test activity entering production evidence.
Logging and redaction	Log technical identifiers but avoid secrets and unnecessary personal data.	Supports investigation without increasing data exposure.
Session and access security	Use Leaseora security controls, 2FA and session revocation for privileged users.	Protects high-impact blockchain actions.
Backup and recovery	Back up source files, record mappings, configuration and evidence exports.	The chain alone does not store the full business document.
Incident preservation	Do not delete or overwrite files, hashes or logs during an investigation.	Preserves chain of custody and legal evidence.

Privacy review before registration

☐ The metadata contains no raw identity document, bank account, address or confidential clause unless explicitly approved and suitable for the configured network.

☐ The document hash is linked internally to the correct authorised source record.

☐ The public explorer view, if any, has been reviewed for information exposure.

☐ Retention and deletion policies explain that a public blockchain transaction may be immutable even if the off-chain file is later deleted under lawful process.

☐ Client notices and contracts describe the use of blockchain evidence where required.

☐ Third-party verification instructions avoid exposing internal IDs or access tokens.

17 Status Lifecycles and Record Relationships

Record	Key blockchain states / fields	Operational meaning
Source document	blockchain_status: null, pending, processing, confirmed, failed.	Tracks the document-registration lifecycle.
Verification result	verified, tampered, not_found.	Compares current content with on-chain evidence.
InsurancePolicy	Single hash, transaction, block, status and timestamp.	One primary policy document per record.
InsuranceClaim	Arrays of hashes, transactions, blocks and statuses.	Independent evidence per uploaded claim document.
Mortgage	contract_address.	Deployed mortgage smart contract.
MortgagePayment	blockchain_tx_hash.	On-chain payment execution evidence.
AILeaseDocument	is_signed, signed_at plus hash fields.	Final signed AI-generated lease registration.
BlockchainTransaction	Registration, verification, audit, deployment or payment operation.	Platform transaction history and monitoring.
BlockchainDocument	Index linking Leaseora document IDs to blockchain records.	Central lookup and verification mapping.

Record relationship principles

· Source model -> BlockchainDocument: The business record remains in its module while the blockchain index links it to on-chain evidence.

· Source document -> BlockchainTransaction: A document may have registration, verification and audit transactions over time.

· Mortgage -> Smart contract: One Mortgage stores the deployed contract_address used by its payment records.

· MortgagePayment -> Blockchain transaction: Each executed installment stores its own transaction hash.

· InsuranceClaim -> Evidence arrays: Every uploaded file must retain a stable mapping across all blockchain arrays.

· Document version -> Hash: Each materially different file has its own fingerprint and should not silently inherit another version's badge.

18 Event, Controller and Communication Matrix

Trigger / action	System handler	Result
Insurance policy created	InsurancePolicyController@store -> BlockchainDocumentService@registerDocument	Policy blockchain fields populated after confirmation.
Insurance claim evidence uploaded	InsuranceClaimsController@uploadDocuments -> registerDocument per file	Hash, transaction, block and status arrays appended.
Mortgage document uploaded	MortgageDocument workflow -> registerDocument	MortgageDocument blockchain fields stored.
Mortgage verification requested	MortgageDocumentController@verifyBlockchain($id)	verified, tampered or not_found returned.
Mortgage legal document accessed	MortgageLegalDocumentController -> createAuditTrail	Immutable access event created.
Mortgage activated	createMortgageSmartContract($mortgageData)	contract_address stored.
Mortgage installment recorded	executePayment($contractAddress, $paymentData)	MortgagePayment.blockchain_tx_hash stored.
Lease AI analysis completed	LeaseDocumentService@triggerAIDocumentAnalysis	AI fields and blockchain registration populated.
AI lease fully signed	AILeaseDocument signing workflow -> registerDocument	Final signed version registered.
WeBuild contract generated / signed	CorporateLandlordWeBuildController@generateContract	Draft/final contract hash registered as configured.
Compliance document uploaded	ComplianceDocumentUploaded -> RegisterComplianceDocumentOnBlockchain	Automatic compliance registration.
Document Hub manual registration	LandlordDocumentHubController -> registerDocument	General Document blockchain fields populated.
Protected document action	createAuditTrail($transactionData)	Audit transaction hash created.

19 Staff Permissions and Segregation of Duties

Role	Typical access	Control point
Document Administrator	View source records, submit eligible documents, monitor status.	Cannot deploy mortgage contracts or change platform network settings.
Legal Officer	Review canonical versions, verification and audit evidence.	Cannot approve its own technical exceptions without independent review.
Compliance Officer	Manage compliance registration, exports and regulator evidence.	Cannot expose restricted metadata or delete incident evidence.
Mortgage Officer	Register mortgage records and prepare deployment data.	Contract deployment and schedule changes require approval.
Finance Officer	Reconcile payment execution and transaction fees.	Cannot treat unverified off-chain payment as settled.
Insurance Officer	Manage policy and claim-document blockchain records.	Must preserve array-to-file mapping.
IT / Security	Monitor failures, access, endpoints and incidents.	Should not alter business documents or legal terms.
Director / Approver	Approves policies, high-risk exceptions, smart contracts and budgets.	Reviews audit and management reports.
Client Support	Explains badge and verification status to clients.	Cannot override verification results or expose internal secrets.
SuperAdmin	Configures network, keys, templates, batches and platform monitoring.	Platform access should use strongest authentication and audited change control.

Minimum permission controls

· Use individual accounts and strong authentication for all privileged users.

· Require approval for production smart-contract deployment and network changes.

· Restrict private keys and RPC credentials to platform infrastructure.

· Require a reason for manual retries, evidence replacement and badge override attempts.

· Review exports because they may contain transaction identifiers and sensitive source-record metadata.

· Revoke access immediately when a staff role or employment ends.

· Review all privileged actions in Leaseora security and blockchain audit logs.

20 Dashboards, Reports and Management Review

Dashboard / report	Management questions answered
Registration coverage	How many eligible documents are protected, and where are the gaps?
Pending queue	Which records are waiting, for how long and on which network?
Failure report	What failed, why, how often and whether retry succeeded?
Verification report	Which documents were verified, tampered or not found?
Smart-contract register	Which mortgages have deployed contracts and which template version was used?
Payment transaction report	Which installments have on-chain transaction hashes and reconcile to settlement?
Fee report	What registration and execution costs were incurred by module and period?
Audit trail report	Who accessed, signed, shared, modified or revoked protected records?
AI insight report	What coverage, dispute-risk, failure or cost patterns require human review?

21 Worked Example - Insurance Policy and Claim Evidence

Scenario

HarbourGate Properties insures HarbourGate Court. The policy PDF is registered when created. Months later, storm damage occurs and the company uploads photographs, a repair quotation and a police report to the related InsuranceClaim.

Stage	What happens	Evidence retained
1. Policy creation	InsurancePolicyController@store saves the policy and calls registerDocument.	Policy file and source record.
2. Hashing	SHA-256 fingerprint is calculated from the policy PDF.	blockchain_hash.
3. Confirmation	The transaction is mined and the policy reaches confirmed.	transaction hash, block number and timestamp.
4. Verification	The policy detail page verifies the current file.	Verified result and badge.
5. Claim upload	Three claim files are uploaded.	InsuranceClaim document list.
6. Per-file registration	Each file creates its own hash, transaction, block and status array entry.	Aligned JSON arrays.
7. Claim review	The insurer or legal team verifies each file independently.	Per-file verification results.
8. Evidence export	The company exports a package with a manifest.	Files, hashes, transactions, blocks and statuses.

Control outcome

· The policy can be shown to be unchanged since registration.

· Every claim-evidence file has an individual fingerprint rather than one combined claim hash.

· A failed registration on one photograph does not invalidate the other evidence entries.

· The exported manifest preserves the file-to-array mapping for independent review.

22 Worked Example - Mortgage Smart Contract and Monthly Payment

Scenario

A client accepts a mortgage offer for a property with a loan amount of 250,000, an interest rate of 3.5% and a 360-month schedule. The mortgage is activated and an approved smart contract is deployed.

Stage	What happens	Control
1. Agreement	Final mortgage agreement is signed and blockchain-registered.	Verify the canonical PDF.
2. Deployment data	Loan terms, addresses, schedule and collateral property ID are prepared.	Reconcile with the signed agreement.
3. Smart contract	createMortgageSmartContract deploys the approved template.	Store contract_address and template version.
4. Payment due	The first installment appears in MortgageAmortizationSchedule.	Confirm amount, date and reference.
5. Settlement	The client pays through the approved rail.	Verify gateway, wallet or bank settlement.
6. On-chain execution	executePayment records the payment against the contract.	Store MortgagePayment.blockchain_tx_hash.
7. Reconciliation	Finance matches four records.	Leaseora payment, payment rail, accounting entry and blockchain transaction.
8. Independent review	Both parties inspect the contract and payment transaction.	Contract address and transaction hash.

Final payment behaviour depends on the template

The supplied lifecycle states that the smart contract may mark the mortgage fully paid and release a lien if that logic is encoded. The live contract template, legal process and property registry integration must confirm whether this is actually implemented.

23 Worked Example - Lease Access Dispute

Scenario

A client disputes whether they received and signed a lease. The landlord must produce a complete integrity and access evidence package without relying on a single screenshot.

Evidence item	Question answered
Verified final signed lease file	Is the produced PDF identical to the registered canonical version?
blockchain_tx_hash and block number	When and where was the fingerprint registered?
TenantDocumentShare record	Was the document shared with the correct client?
Audit entry: viewed	When was it opened, by which user and from which IP?
Audit entry: signed	When was the signature action recorded and what signature metadata was linked?
Signature verification record	Was the electronic signature valid under the platform workflow?
Audit entry: downloaded	Was the file downloaded after signing?
Leaseora access and security logs	Do the session and device records support the audit events?

The legal team should export the evidence chronologically, explain the relationship between off-chain source records and on-chain fingerprints, and avoid claiming that the blockchain alone proves informed consent or legal validity.

24 Real Estate Company Onboarding Checklist

Policy and governance

☐ Blockchain use policy approved by management and legal.

☐ Eligible document types and canonical-version rules defined.

☐ Privacy and metadata restrictions approved.

☐ Smart-contract authority and approval matrix defined.

☐ Transaction-fee budget and approval process established.

☐ Incident, retry and evidence-preservation procedures documented.

☐ Third-party verification instructions reviewed.

Data and module preparation

☐ Insurance policy and claim document naming standards agreed.

☐ Mortgage documents, addresses, schedules and collateral references reconciled.

☐ Lease and development signature workflows defined.

☐ Compliance event registration tested.

☐ Document Hub high-value categories identified.

☐ Historical documents selected for migration or left unregistered according to policy.

☐ Source files retained in byte-preserving storage.

Technical and security setup

☐ Production and test networks confirmed.

☐ RPC endpoint, chain ID, explorer and provider access tested.

☐ Deployment wallet and encrypted key custody approved.

☐ Fee strategy, batching, retries and alert thresholds configured.

☐ Smart-contract templates reviewed, tested and versioned.

☐ Role permissions and privileged authentication tested.

☐ Exports, backups, audit logs and monitoring validated.

25 User Acceptance Testing and Go-Live Validation

Test area	Test case	Expected result
Dashboard	Open landlord blockchain dashboard with test records.	Only the landlord's transactions and KPIs appear.
Registration	Register an approved test document.	Status progresses to confirmed and all metadata is stored.
Same-file verification	Verify the original file.	Result is verified.
Changed-file verification	Verify a controlled modified copy.	Result is tampered.
Missing record	Verify an unregistered file.	Result is not_found with clear guidance.
Duplicate submission	Repeat a registration request.	No unintended duplicate evidence or charge.
Insurance policy	Create and register a policy.	Single blockchain field set populated.
Claim evidence	Upload multiple claim files.	Aligned arrays contain one entry per file.
Mortgage document	Run verifyBlockchain and exports.	Badge and manifests show correct metadata.
Smart-contract deployment	Deploy approved test contract.	Correct contract_address stored.
Payment execution	Execute a test installment.	MortgagePayment transaction hash stored and reconciled.
Lease document	Register final signed lease after AI analysis.	AI fields and confirmed blockchain fields are present.
Compliance event	Upload a compliance file.	Listener registers it automatically once.
Audit trail	View, download and sign a test document.	Chronological audit entries are retrievable.
Client portal	Open shared protected document as client.	Correct inline verification label shown.
Independent verification	Inspect transaction on the configured network interface.	Hash and block evidence match.
Permissions	Test each staff role.	No unauthorised registration, deployment or export.
Failure / retry	Simulate approved test failure.	Error logged, retry controlled and no duplicate.
Monitoring	Review fees, failures and AI insight.	Dashboard reconciles with test transactions.

Go-live gate

Do not use production blockchain badges, mortgage smart contracts or external evidence packs until registration, verification, failure handling, client display, independent verification, reconciliation, permissions, privacy and monitoring have passed user acceptance testing.

26 Common Issues and Troubleshooting

Issue	Likely cause	Recommended action
Registration remains pending	Network congestion, provider delay, fee strategy or queue processing.	Check transaction hash, queue age and network health; do not resubmit blindly.
Registration failed	RPC error, rejected transaction, insufficient deployment-wallet balance, format or service error.	Review error logs, correct the cause and use approved retry.
No transaction hash	Request may not have been broadcast or response was not stored.	Check service logs and source-record update; preserve idempotency.
Verified badge missing	Status is not confirmed, fields are incomplete or UI mapping failed.	Confirm source fields and verification result.
Verification returns tampered	Different bytes, wrong version, re-export, added signature or alteration.	Preserve files, compare versions and escalate.
Verification returns not_found	Wrong network, missing registration, incorrect hash or record mapping.	Confirm chain, transaction, source record and hash.
Claim arrays have different lengths	Partial update or incorrect append logic.	Freeze claim evidence, reconcile each file and repair mapping under audit.
Explorer link fails	Wrong network explorer, malformed transaction hash or private network.	Use the configured network interface and chain information.
Contract deployment fails	Invalid data, unaudited template, wallet fee balance or network issue.	Review validation, template version, funds and logs.
Payment tx hash missing	executePayment failed or MortgagePayment was not updated.	Reconcile payment and retry only through approved process.
On-chain payment differs from settlement	Wrong amount/reference or off-chain settlement issue.	Suspend reconciliation and investigate all four records.
Audit trail has gaps	Action did not call createAuditTrail or service failed.	Review controller path and off-chain access logs; do not fabricate entries.
AI insight seems incorrect	Incomplete data or pattern inference.	Review source transactions and ignore unsupported recommendation.
Fees are unexpectedly high	Network conditions, gas strategy or many individual transactions.	Review platform settings and approved batching options.
Client sees wrong status	Stale API response, wrong share or incorrect record mapping.	Refresh, verify source document and inspect TenantDocumentShare relation.

Support information to include

Provide the company, module, source record ID, document title, blockchain status, transaction hash, network, date/time, user, action attempted, expected result, actual result and a screenshot with secrets and unnecessary personal data removed.

27 Frequently Asked Questions

Does Leaseora store the full document on the blockchain?

The supplied architecture registers a hash and approved metadata. The full document remains in Leaseora storage.

What does Blockchain Verified mean?

The current file fingerprint matches the fingerprint registered on the configured blockchain.

Does verification prove the document is legally valid?

No. It proves integrity relative to the registration event, not legal authority, truth or enforceability.

Can a document be changed after registration?

The off-chain file can change, but the new file will have a different hash and will not verify against the old registration.

Should a draft lease be registered?

Only if company policy requires draft history. The final fully signed PDF should be clearly registered as the canonical version.

Why can a legitimate file return tampered?

It may be a different export, amended version, added-signature version, scan or incorrect file selection.

Can clients verify documents?

Yes, where the document is shared and the portal or mobile response exposes the blockchain status.

Can a regulator verify without Leaseora?

Where the network supports independent inspection, the party can inspect the transaction and compare the file hash.

Are insurance claim files registered together?

Each uploaded claim file is registered separately and stored in aligned JSON arrays.

What is a mortgage contract_address?

It is the address returned when an approved mortgage smart contract is deployed.

Does executePayment move money?

The supplied design records payment execution against the smart contract. Off-chain rails still require settlement verification.

Can the blockchain release a property lien automatically?

Only if the approved smart-contract template and legal/registry integrations implement that behaviour.

What happens when registration fails?

The source document remains; the registration enters failed status and follows the approved investigation and retry path.

Can AI override a tampered result?

No. AI may support investigation, but the cryptographic comparison determines the verification outcome.

Who configures the network and private key?

Leaseora SuperAdmin manages platform-wide network configuration. Ordinary landlord users should not access the private key.

28 Quick Reference - 25 Operational Steps

1. Access the Blockchain dashboard.

2. Review coverage, queue, alerts, fees and smart contracts.

3. Understand BlockchainDocumentService methods.

4. Register an approved critical document.

5. Monitor pending, processing, confirmed and failed status.

6. Register and verify an insurance policy.

7. Register each insurance claim-evidence file.

8. Register mortgage documents and legal contracts.

9. Verify and export mortgage blockchain evidence.

10. Deploy an approved mortgage smart contract.

11. Execute and reconcile mortgage payment events.

12. Register the final signed lease document.

13. Create an immutable lease access trail.

14. Protect WeBuild and development legal documents.

15. Use automatic compliance-document registration.

16. Register high-value Document Hub files on demand.

17. Verify a registered document as landlord.

18. Allow a client to view the verification status.

19. Perform independent third-party verification.

20. Create and retrieve the full audit trail.

21. Monitor transaction activity and costs.

22. Review AI blockchain insights.

23. Configure the platform blockchain network.

24. Configure batching, exclusions, retries and alerts.

25. Manage smart-contract templates and platform monitoring.

29 Technical Reference - Core Models and Records

Model / record	Purpose	Principal blockchain data
BlockchainTransaction	Platform-wide transaction log for registrations, verifications, audit trails, deployments and payment executions.	Operation type, status, network identifiers, transaction data and fees.
BlockchainDocument	Index linking Leaseora source documents to on-chain registrations.	Source model/ID, document hash, transaction hash, block and status.
InsurancePolicy	Insurance policy with one principal blockchain-registered document.	blockchain_hash, blockchain_tx_hash, blockchain_block_number, blockchain_status, blockchain_registered_at.
InsuranceClaim	Claim containing multiple independently registered evidence files.	blockchain_hashes[], blockchain_tx_hashes[], blockchain_block_numbers[], blockchain_statuses[].
MortgageDocument	Mortgage application or supporting document.	blockchain_hash, blockchain_tx_hash, blockchain_status.
MortgageLegalDocument	Mortgage legal contract with verification and access audit trail.	Hash, transaction, status and audit references.
Mortgage	Core mortgage record.	contract_address for deployed smart contract.
MortgagePayment	Individual mortgage installment.	blockchain_tx_hash returned by executePayment.
LeaseDocument	Lease document paired with AI understanding and blockchain registration.	blockchain fields plus ai_extracted_data, ai_summary, ai_risk_score.
AILeaseDocument	AI-generated lease, notice or addendum.	is_signed, signed_at and final registration fields.
PropertyDevelopmentLegalDocument	WeBuild or development legal contract.	Blockchain hash, transaction and status.
Document	Central Document Hub record.	Hash, transaction, block, status and registered timestamp where supported.
ComplianceDocument	Compliance file registered by event listener.	Returned blockchain fields on source record.

30 Technical Reference - Controllers, Services, Events and Listeners

System	Responsibility
BlockchainDocumentService	Register and verify documents, create and retrieve audit trails, deploy mortgage smart contracts and execute payments.
BlockchainController	Landlord blockchain dashboard, transaction log, verification history, filters and exports.
SuperAdmin\Core\BlockchainController	Network configuration, registration policies, contract templates, platform monitoring and batch management.
InsurancePolicyController	Creates policies and triggers document registration.
InsuranceClaimsController	Uploads claim files and registers each document independently.
MortgageDocumentController	Mortgage document management and verifyBlockchain($id), ZIP/PDF/CSV exports.
MortgageLegalDocumentController	Registers mortgage legal documents and creates access audit trails.
MortgagePaymentController	Processes mortgage payments and participates in activation/payment flows.
LeaseDocumentService	AI document analysis, lease intelligence and post-analysis blockchain registration.
CorporateLandlordWeBuildController	AI contract generation, document analysis and blockchain registration for WeBuild.
PropertyDevelopmentDocumentController	Development project document management.
LandlordDocumentHubController	Optional manual blockchain registration and badge display for central documents.
TenantDocumentPortalController	Client shared-document view and inline blockchain verification.
MortgageMobileController	Mobile mortgage detail including blockchain status.
ComplianceDocumentUploaded	Event emitted when a compliance document is uploaded.
RegisterComplianceDocumentOnBlockchain	Listener that calls registerDocument and updates the compliance record.
OpenAIService	Coverage, verification-frequency, failure-pattern, smart-contract and cost insights.

31 Technical Reference - BlockchainDocumentService Methods

Method	Parameters	Returns	Purpose
registerDocument	$documentData: title, hash, type, metadata	blockchain_hash, blockchain_tx_hash, blockchain_block_number	Register a document fingerprint on-chain.
verifyDocument	$documentHash, $documentContent = null	verified / tampered / not_found	Verify current document integrity.
createAuditTrail	$transactionData: document, actor, action, timestamp, IP, metadata	audit_tx_hash	Create immutable access or modification evidence.
getAuditTrail	$transactionId	Chronological audit entries	Retrieve the complete document audit history.
createMortgageSmartContract	$mortgageData: terms, parties, schedule, collateral	contract_address	Deploy an approved mortgage payment smart contract.
executePayment	$contractAddress, $paymentData: amount, date, reference	transaction_hash	Record a payment execution against the contract.

Expected service behaviour

· Validate mandatory data and source-record ownership before submission.

· Calculate the same hash deterministically for the same file bytes.

· Use the configured network, chain and transaction-signing mechanism.

· Return or persist errors without discarding the source document.

· Prevent unintended duplicate transactions during retries.

· Update source records only with values returned for the correct transaction.

· Keep private keys and provider secrets out of application responses and logs.

· Produce auditable, network-specific transaction identifiers.

32 Technical Reference - Blockchain Fields by Model

Model	Single-value fields	Array fields / special fields
InsurancePolicy	blockchain_hash; blockchain_tx_hash; blockchain_block_number; blockchain_status; blockchain_registered_at	-
InsuranceClaim	-	blockchain_hashes[]; blockchain_tx_hashes[]; blockchain_block_numbers[]; blockchain_statuses[]
MortgageDocument	blockchain_hash; blockchain_tx_hash; blockchain_status	-
MortgageLegalDocument	blockchain_hash; blockchain_tx_hash; blockchain_status	Audit-trail references as implemented
LeaseDocument	blockchain_hash; blockchain_tx_hash; blockchain_status	ai_extracted_data; ai_summary; ai_risk_score
AILeaseDocument	hash fields plus is_signed; signed_at	-
PropertyDevelopmentLegalDocument	blockchain_hash; blockchain_tx_hash; blockchain_status	-
Document (CDMS)	blockchain_hash; blockchain_tx_hash; blockchain_block_number; blockchain_status; blockchain_registered_at	-
MortgagePayment	blockchain_tx_hash	-
Mortgage	contract_address	-

33 Technical Reference - Module Registration and Verification Paths

Functional area	Controller / service path
Insurance policy registration	InsurancePolicyController@store -> BlockchainDocumentService@registerDocument -> InsurancePolicy blockchain fields.
Insurance claim evidence	InsuranceClaimsController@uploadDocuments -> registerDocument per file -> InsuranceClaim arrays.
Mortgage document verification	MortgageDocumentController@verifyBlockchain($id) -> verifyDocument(hash, content).
Mortgage legal audit	MortgageLegalDocumentController -> createAuditTrail on access.
Mortgage contract deployment	Mortgage activation -> createMortgageSmartContract($mortgageData) -> Mortgage.contract_address.
Mortgage payment execution	Payment flow -> executePayment(contract_address, paymentData) -> MortgagePayment.blockchain_tx_hash.
Lease analysis and registration	LeaseDocumentService@triggerAIDocumentAnalysis -> AI fields -> registerDocument.
AI lease final registration	Electronic signing complete -> registerDocument(final signed PDF).
WeBuild contract	CorporateLandlordWeBuildController@generateContract -> PDF -> registerDocument; signatures -> re-register canonical version.
WeBuild AI analysis	CorporateLandlordWeBuildController@aiAnalyzeDocument -> analysis stored beside blockchain record.
Compliance automatic flow	ComplianceDocumentUploaded -> RegisterComplianceDocumentOnBlockchain -> registerDocument.
Document Hub manual flow	LandlordDocumentHubController document action -> registerDocument -> badge in show($slug).
Client verification	TenantDocumentPortalController@show($shareId) -> verifyDocument -> inline result.
Mobile verification	Document/mortgage API response includes blockchain_status and confirmed badge indicator.

34 Technical Reference - AI-Powered Blockchain Features

AI feature	Service / trigger	Purpose
Registration coverage analysis	OpenAIService	Identify document categories lacking blockchain protection.
Verification-frequency insight	OpenAIService	Flag unusually frequent verification that may indicate dispute or operational risk.
Failed-registration analysis	OpenAIService plus transaction/error logs	Identify patterns involving network, file, queue or configuration.
Smart-contract performance	OpenAIService plus mortgage transactions	Analyse deployment and payment-execution success and timing.
Cost optimisation	OpenAIService plus fee records	Recommend batching or timing strategies subject to approval.
Lease document intelligence	LeaseDocumentService@triggerAIDocumentAnalysis	Extract fields, summarise, score risk and register the same document.
WeBuild document analysis	CorporateLandlordWeBuildController@aiAnalyzeDocument	Analyse contract content beside the blockchain record.

35 Blockchain Evidence Pack and Independent Verification Checklist

Minimum evidence pack

☐ Exact source document file used for verification.

☐ Leaseora source-record ID, module and document title.

☐ Document hash and hashing algorithm.

☐ Blockchain network and chain ID.

☐ blockchain_tx_hash and blockchain_block_number.

☐ blockchain_registered_at timestamp.

☐ Current blockchain_status and verification result.

☐ Explorer or network-interface evidence where available.

☐ Relevant audit trail entries and audit transaction hashes.

☐ Version history and explanation of canonical status.

☐ For mortgages: contract_address, template version and payment transaction hashes.

☐ For claim evidence: manifest preserving file-to-array index mapping.

☐ Name, role, date and method used by the person preparing the evidence.

Evidence statement template

Suggested factual wording

The attached file produced the same SHA-256 fingerprint as the fingerprint registered in blockchain transaction [transaction hash] at block [block number] on [timestamp] on the configured [network] chain. The verification therefore indicates that this file is unchanged relative to that registration event. This statement does not independently determine the truth, authority or legal validity of the document's contents.

36 Implementation Details Requiring Confirmation

The supplied scenario defines the intended architecture and method contracts but does not fully specify every production implementation detail. Product, engineering, legal, security and operations teams should confirm the following before formal training or go-live:

Area	Details to confirm
Network availability	Which of Ethereum, Polygon, Solana or enterprise networks are actually implemented and supported.
Finality policy	How many confirmations or what network condition changes pending/processing to confirmed.
Hashing implementation	Exact SHA-256 calculation method, treatment of streams, PDFs, images and generated files.
Metadata schema	Exact fields submitted on-chain and privacy restrictions for each module.
Duplicate protection	Idempotency key, retry behaviour and treatment of multiple registrations for one version.
Error handling	Full status enumeration, retry schedule, dead-letter queue and staff notification.
Fee accounting	Who pays fees, currency conversion, budgeting, markup and landlord reporting.
Key custody	Encryption, HSM/KMS use, rotation, backup, access and compromise response.
Explorer links	Network-specific URL construction and support for private networks.
Contract platform	Smart-contract language, deployment process, upgrade policy, audit reports and emergency controls.
Payment semantics	Whether executePayment only records an event or also transfers on-chain value.
Fully-paid / lien release	Whether and how the approved template implements final state and registry/legal actions.
Audit trail persistence	Where audit transaction hashes are stored and which actions are guaranteed to call the service.
Client API schema	Exact blockchain fields and verification objects returned by web and mobile endpoints.
Historical migration	Whether existing documents can be batch-registered and how canonical versions are selected.
Data protection	Legal basis, notices, retention and deletion implications in each operating jurisdiction.

Confirm against the live build

This guide preserves the supplied class, method, field and lifecycle names. Where the production interface or code uses additional statuses, validation rules, networks or security controls, the product and technical teams should update training materials before release.

LEASEORA

BLOCKCHAIN

A distributed-ledger trust layer for documents, contracts, payments and immutable audit evidence.

Support and onboarding

For corporate onboarding, staff training or operational support, contact Leaseora at support@leaseora.com.

leaseora.com

Was this article helpful?

Your feedback helps us improve our documentation.

Back to Knowledge Base More in BLOCKCHAIN

Article Info

Category BLOCKCHAIN

Reading Time 59 min

Published Jul 30, 2026

Tweet Share

🤝

Need more help?

Our support team is available to assist you.

Contact Support

BLOCKCHAIN

Document Control

How to Use This Guide

1 Purpose, Scope and Terminology

Key terminology

2 Roles and Responsibilities

3 Complete Module Journey

4 What the Blockchain Module Does and Does Not Do

5 Implementation Prerequisites and Governance

Business information and decisions to prepare

Recommended implementation sequence

6 Phase 1 - Blockchain Dashboard and Overview

7 Phase 2 - Core Blockchain Service and Registration Architecture

Document data submitted for registration

8 Phase 3 - Insurance Policies and Claim Evidence

9 Phase 4 - Mortgage Documents and Smart Contracts

10 Phase 5 - Lease and AI-Generated Document Protection

11 Phase 6 - WeBuild, Property Development, Compliance and Document Hub

12 Phase 7 - Verification by Landlords, Clients and Third Parties

13 Phase 8 - Blockchain Audit Trails

Audit trail use cases

14 Phase 9 - Blockchain Analytics, Monitoring and AI Insights

Recommended review cadence

15 Phase 10 - SuperAdmin Blockchain Configuration

16 Security, Privacy and Key-Management Controls

Privacy review before registration

17 Status Lifecycles and Record Relationships

Record relationship principles

18 Event, Controller and Communication Matrix

19 Staff Permissions and Segregation of Duties

Minimum permission controls

20 Dashboards, Reports and Management Review

21 Worked Example - Insurance Policy and Claim Evidence

Control outcome

22 Worked Example - Mortgage Smart Contract and Monthly Payment

23 Worked Example - Lease Access Dispute

24 Real Estate Company Onboarding Checklist

Policy and governance

Data and module preparation

Technical and security setup

25 User Acceptance Testing and Go-Live Validation

26 Common Issues and Troubleshooting

27 Frequently Asked Questions

Does Leaseora store the full document on the blockchain?

What does Blockchain Verified mean?

Does verification prove the document is legally valid?

Can a document be changed after registration?

Should a draft lease be registered?

Why can a legitimate file return tampered?

Can clients verify documents?

Can a regulator verify without Leaseora?

Are insurance claim files registered together?

What is a mortgage contract_address?

Does executePayment move money?

Can the blockchain release a property lien automatically?

What happens when registration fails?

Can AI override a tampered result?

Who configures the network and private key?

28 Quick Reference - 25 Operational Steps

29 Technical Reference - Core Models and Records

30 Technical Reference - Controllers, Services, Events and Listeners

31 Technical Reference - BlockchainDocumentService Methods

Expected service behaviour

32 Technical Reference - Blockchain Fields by Model

33 Technical Reference - Module Registration and Verification Paths

34 Technical Reference - AI-Powered Blockchain Features

35 Blockchain Evidence Pack and Independent Verification Checklist

Minimum evidence pack

Evidence statement template

36 Implementation Details Requiring Confirmation

Support and onboarding

Was this article helpful?

Table of Contents

Article Info

Share

Need more help?