LandSight

The problem

A Nigerian buying land from abroad is making one of the largest purchases of their life against a title system they cannot inspect. The failure modes are well known to anyone who has tried: the same parcel sold twice by a family that never formally partitioned it; a Certificate of Occupancy that looks correct but does not correspond to anything in the state registry; a survey plan whose coordinates sit inside a government acquisition or a road setback; a "caretaker" selling land they do not own to someone who will never stand on it before paying.

None of this is exotic. It is the ordinary result of a registry system where the authoritative record is held by a state agency, is not queryable online in most states, and can only be checked in person by someone with standing to file a search. The diaspora buyer has money and no presence. The person with presence has no accountability to the buyer. That gap is the whole business.

The existing answer is to hire a lawyer or a surveyor privately. It works when you already know a trustworthy one. It fails silently when you do not, because the buyer has no way to distinguish a real registry search from a plausible PDF, and no recourse when the report turns out to be worthless. The money is gone and the verifier has no stake in the outcome.

LandSight attacks the second half of that. It does not try to replace the state registry. It makes the verification itself accountable: a named, accredited verifier, a report whose contents cannot be quietly revised after the fact, and payment that only moves when the work has been reviewed and approved.

What was built

Six deployed surfaces over one API:

• Buyer web app: submit a property for verification, track the job, receive the report and certificate.
• Verifier portal: accredited surveyors and lawyers pick up assigned jobs, file findings, upload evidence, and see their earnings.
• Admin console: verifier accreditation, job assignment and routing, report review and approval, payouts.
• Developer dashboard: API access for partners who want verification as a step inside their own flow.
• Public site and the Hedera service, a small Node process that holds the chain integration behind an internal HTTP boundary.

The end-to-end flow is deliberately linear. A buyer submits a property with its address, survey plan and any documents the seller has provided, and pays the verification fee through Flutterwave. The job is routed to an accredited verifier in that state. The verifier performs the physical inspection and the registry search, then files a structured report: title status, encumbrances, acquisition and setback exposure, ownership chain, and a risk level of Low, Medium, High or Critical. An admin reviews the report against the evidence attached to it.

On approval, three things happen. The report is hashed and the hash, risk level, verifier address and timestamp are written to PropertyVerificationRegistry on Hedera mainnet. A PDF certificate is generated that references that on-chain record. And PropertyPaymentEscrow releases the verifier's commission and the platform fee out of escrow in a single transaction.

The registry contract is intentionally small. It stores a bytes32 report hash, a risk enum, the verifier's address and a block timestamp, keyed by property ID, and it refuses a second registration for the same property and any caller who is not an accredited verifier. The report itself never touches the chain.

Technical decisions

Hedera rather than an EVM L2. The contracts were first deployed and exercised on Sepolia and Polygon Amoy. Both work, and both price transactions in a volatile gas token, which is a genuine problem when the unit economics of a verification job are fixed in naira and the margin is thin. Hedera prices transactions in USD terms with predictable fees, which makes a per-verification cost that can be reasoned about a year out. The second reason is Hedera Token Service: escrow settles in a token whose transfers are handled by a system contract rather than an ERC-20 implementation the platform has to write, audit and defend.

One chain for both certificates and payments. The early design had the attestation layer and the payment layer on different networks, on the theory that they were independent concerns. In practice it meant two key custody setups, two fee models, two sets of failure modes during a payout, and a reconciliation story nobody wanted to own. Consolidating onto Hedera after the testnet round cost some flexibility and removed an entire class of operational work.

Hash on chain, report off chain. A verification report contains the buyer's identity, the seller's identity, and a parcel's exact coordinates. Putting that on a public ledger would be a privacy failure dressed up as transparency. What goes on chain is the hash, the risk level and the verifier: enough for anyone holding a certificate to prove the report they were given is the report that was approved, and not enough to expose anybody. Cost is a side benefit; the privacy argument is the one that decides it.

Escrow holds the verifier's fee, never the buyer's purchase money. This is the decision with the most consequence and the least code. The escrow contract's entire surface is a release(jobId, verifier, verifierAmount, platformAmount) callable only by the owner, guarded against replay by a released mapping. It settles the fee for work performed. It has no path for holding, forwarding, or returning the money a buyer pays a seller for land. Custodying purchase funds would make LandSight a payments intermediary, with the licensing, capital and compliance obligations that implies, and it would put the platform in the middle of every disputed transaction. Escrowing the verifier's commission achieves the thing that actually matters, that the verifier is paid on approved work rather than on filing something, at a fraction of the regulatory surface.

Treasury keys in Google Cloud KMS, not in environment variables. The account that funds escrow and signs registry writes is the highest-value secret in the system. It lives in Cloud KMS with material in Secret Manager, with a key rotation path that was built and exercised rather than left as an intention. The Hedera service is the only component with access, and it is not internet-facing.

Outcome and evidence

LandSight launched in March 2026 and was covered by The Guardian Nigeria. The on-chain layer went to Hedera mainnet on 4 August 2026 after a testnet round on Hedera testnet on 2 August and earlier deployments to Sepolia and Polygon Amoy in July. All three mainnet contracts are listed at the end of this page and verifiable on HashScan.

The stack is Laravel 12 and MySQL for the API, with Passport for auth, Flutterwave for collections and DomPDF for certificate generation; React with Vite, TanStack Query and Zustand across the four front ends; Solidity and Foundry for the contracts; and a Node and Express service wrapping the Hedera SDK. Everything runs on Google Cloud behind Nginx, deployed from GitHub Actions.

I founded the company and wrote and shipped this system: the API, the contracts, the chain integration, the verifier and admin flows, and the deployment.

What is next

Direct integration with state registries, starting with Ogun OLARMS and Lagos e-GIS, so that the registry search step is a query rather than a physical visit. Bank and mortgage partnerships, where verification becomes a step inside an existing origination flow through the partner API. And extending the verifier network beyond Lagos and Ogun into the other states where diaspora buying is concentrated.