Introducing Eterna Registry - a blockchain-based land registry and marketplace system

Introducing Eterna Registry: A Decentralized Land Registry on Nervos CKB

Hello Nervos Community!

About Me

I’m a land surveyor by profession, and I’ve been developing a growing interest in programming over the past few years. I’ve written Python scripts for geospatial data analysis, experimented with Solidity for smart contracts, and worked with C for lower-level programming. This project represents the intersection of my two worlds: land surveying and blockchain development.

I joined the Nervos ecosystem through an internship program, and Eterna Registry has been my main project - a way to apply blockchain technology to real problems I encounter in my daily work.


Why a Land Surveyor is Building This

In my line of work, I see the pain points of land registration firsthand:

  • Paper-based records that get lost, damaged, or disputed

  • Slow verification processes that delay property transactions for weeks

  • Fragmented databases where different offices hold different pieces of information

  • Boundary disputes that end up in court because there’s no single source of truth

These aren’t abstract problems - they’re daily frustrations for surveyors, notaries, real estate agents, and property owners. When I discovered CKB’s Cell model, I immediately saw how it could represent land parcels in a way that makes sense: each piece of land as a discrete, ownable cell with its own rules and metadata.

Eterna Registry is my attempt to build what I wish existed - a transparent, verifiable land registry where ownership is cryptographically secured and property data lives permanently on-chain.


Target Users

Given my background, the most realistic early adopters are professionals already working with land data:

| User Type | Pain Point | How Eterna Helps |

|-----------|------------|------------------|

| Government Land Agencies | Fragmented records, paper-based systems | Single source of truth, immutable history |

| Land Surveyors | Data verification, coordinate management | On-chain GPS data, shapefile import, area calculation |

| Notaries | Ownership verification, document authenticity | Cryptographic proof of ownership, transparent history |

| Real Estate Agents | Slow due diligence, title disputes | Instant verification, clear ownership chain |

| Architects | Site information scattered across sources | All land data in one verifiable location |

These professionals already understand the value of accurate land records - the blockchain aspect becomes a tool for solving problems they already have, not a solution looking for a problem.


The Vision: Why Blockchain for Land Registration?

Land ownership is foundational to economies worldwide, yet registration systems remain:

  • Fragmented - Records scattered across offices, databases, and paper files

  • Slow - Property transfers taking weeks through bureaucratic processes

  • Expensive - Lawyers, notaries, and government fees adding up

  • Vulnerable - Paper records lost, damaged, or fraudulently altered

For billions of people, proving land ownership is a nightmare. Disputes fill courts, and in many regions, there’s simply no reliable way to establish property rights.

Eterna Registry aims to change this by putting land titles on-chain as verifiable, tradeable NFTs with built-in marketplace functionality.


What Eterna Registry Does

At its core, Eterna Registry allows users to:

1. Register Land as NFTs

Enter comprehensive property details and mint them as Spore Protocol NFTs on CKB:

  • Ownership data: Full name, national ID, contact information, co-owners with percentage shares

  • Land details: Title number, parcel number, GPS coordinates (polygon boundaries), area with automatic calculation

  • Legal metadata: Registry authority, title deed number, registration date, zoning type

Each land gets a unique identifier (e.g., ETR-REG-20260115-A7B3C2) generated at registration.

2. Visualize Properties on Maps

Interactive satellite map visualization using Leaflet + OpenStreetMap:

  • Point locations with custom markers showing land IDs

  • Polygon boundaries for complex land shapes with automatic area/perimeter calculation

  • Multiple coordinate systems: WGS84 (GPS), UTM zones, Web Mercator, State Plane

  • Shapefile import for professional cadastral data

  • Fullscreen mode for detailed exploration

3. Trade Land on the Marketplace

Built-in peer-to-peer marketplace:

  • List for sale: Set your price in CKB, land is locked with a sale lock script

  • Browse listings: See all available lands with real-time blockchain scanning

  • Buy & Cancel: Currently in development - the transaction flows are being finalized


Why I Chose CKB

After evaluating several blockchains, CKB stood out for three fundamental reasons:

1. The Cell Model Maps Perfectly to Property Rights

On account-based chains, assets are database entries. On CKB, each asset is a cell - a discrete, ownable container with its own lock controlling who can spend it.

This mirrors real property law beautifully: you don’t own “5 units of land” in a global ledger. You own this specific parcel, with its own deed, its own boundaries, its own rules.

When I create a land NFT, it becomes a cell that the owner truly possesses and controls - not an entry in someone else’s smart contract.

2. Custom Lock Scripts Enable Custom Rules

This is where CKB really shines. I needed specific ownership and trading rules:

  • Only the verified owner can transfer their land

  • Sales must validate payment before releasing the NFT

  • Cancelled listings return to the original owner

On most chains, this requires complex smart contract logic. On CKB, I encode these rules directly into lock scripts - the mechanism that controls when cells can be spent.

I developed two custom lock scripts:

Land Ownership Lock (32-byte args):


[owner_lock_hash: 32 bytes]

  • Controls who owns a land NFT

  • Args contain Blake2b hash of owner’s lock script

  • Validates owner signature for any transfer

  • Enables registry-wide discovery (query all lands by code hash)

Sale Lock (64-byte args):


[owner_lock_hash: 32 bytes][price: 8 bytes LE][nonce: 24 bytes]

  • Enables marketplace listings

  • Two unlock conditions:

  • Owner retrieval: Seller can cancel anytime

  • Successful sale: Buyer pays correct amount, NFT transfers automatically

3. Spore Protocol for On-Chain NFTs

I’m using the Spore Protocol for land NFTs because:

  • Data lives on-chain - Not just a URL pointing elsewhere

  • Rich metadata support - Stores all property details in the cell

  • Molecule encoding - Structured data format for reliable parsing

  • Proven standard - Well-tested protocol with active development

Important note on discovery: Eterna Registry does NOT use Spore’s type script for discovery. Instead, I query by custom lock script code hash - this enables registry-wide land discovery and marketplace scanning with a single indexed query. All lands share the same Land Ownership Lock code hash (with different args per owner), making discovery O(log n) efficient.


Key Design Decisions

Building Eterna Registry taught me a lot. Here are the architectural choices that shaped the DApp:

Custom Locks Over Default Wallet Locks

Initially, I minted land NFTs directly to users’ JoyID wallet locks. This worked, but had problems:

  • Lands were scattered across different lock scripts (each wallet has its own)

  • No way to query “all lands in the registry” efficiently

Solution: Create a dedicated Land Ownership Lock. All registry lands use the same code hash with different args (the owner’s lock hash). Now I can:

  • Query ALL registry lands with a single indexer call

  • Verify ownership without knowing the specific wallet

  • Build governance features (multi-sig, delegation) in the future

Targeted Scanning Over Full Blockchain Queries

Early versions scanned the entire blockchain to find lands and listings. This was painfully slow and didn’t scale.

Solution: By deploying lock scripts with known code hashes, I query the CKB Indexer directly:

Result: Marketplace loads in under 5 seconds regardless of blockchain size.

Lock Hash Caching for Performance

Calculating lock hashes requires Blake2b hashing with proper Molecule serialization - not expensive, but wasteful to repeat.

Solution: I built a UserLockHashDatabase service that:

  • Caches lock hashes in localStorage

  • Provides bidirectional lookup (address ↔ lock hash)

  • Separates testnet/mainnet data

  • Resolves seller addresses for display

JavaScript Lock Scripts via CKB-JS-VM

Rather than writing lock scripts in C or Rust, I used TypeScript compiled to JavaScript running on CKB-JS-VM.

Why this approach:

  • Faster development iteration

  • Familiar language for web developers

  • Sufficient for initial version (security-critical features can be rewritten in Rust later)

  • Great tooling with OffCKB

Free Maps with Leaflet + OpenStreetMap

Originally I integrated Google Maps, but the API costs would be prohibitive at scale.

Solution: Leaflet with OpenStreetMap provides:

  • Free satellite imagery (via various tile providers)

  • No API keys required

  • Full-featured: markers, polygons, popups, fullscreen

  • Coordinate system conversion (UTM, Web Mercator, State Plane)

  • Shapefile import for cadastral data

  • Area and perimeter auto-calculation using Turf.js


Current Status

What’s Working (Testnet)

  • Land Registration: Full metadata entry, GPS coordinates (point/polygon), Spore NFT minting

  • Map Visualization: Satellite view, polygon boundaries, auto-zoom, fullscreen

  • Marketplace Listing: List lands for sale with custom sale lock script

  • Marketplace Browsing: Scan and display all active listings via lock script queries

  • Custom Lock Scripts: Both deployed to testnet

  • Wallet Integration: JoyID authentication with balance display

  • Network Switching: Testnet/mainnet toggle with automatic configuration

In Progress

  • Purchase Flow: Buying lands with ownership transfer - transaction building being refined

  • Cancel Listing: Returning lands to owner - unlock conditions being debugged

  • Full Payment Validation: Sale lock currently simplified, full validation coming

Technical Stack

| Layer | Technology |

|-------|------------|

| Frontend | React 18 + TypeScript + Vite |

| Styling | Tailwind CSS + Lucide Icons |

| Blockchain | CKB (Nervos Network) |

| NFT Protocol | Spore Protocol |

| Wallet | JoyID via @ckb-ccc/joy-id |

| Maps | Leaflet + OpenStreetMap + Turf.js |

| Lock Scripts | TypeScript → CKB-JS-VM |

| Deployment | Vercel |

What’s Next

  1. Mainnet Deployment - Deploy lock scripts to mainnet after purchase/cancel flows are stable

  2. Multi-signature Support - For disputed properties or institutional ownership

  3. Mobile App - React Native version for field registration

  4. Official Integrations - Working toward recognition by land registry authorities


Lessons Learned Building on CKB

A few insights for anyone considering CKB development:

1. The Cell model requires a mental shift

Coming from Ethereum/Solidity, I kept thinking in terms of contracts holding state. On CKB, state lives in cells, and scripts just validate state transitions. Once this clicked, the elegance became clear - but it took time.

2. Lock scripts are powerful but unforgiving

Your lock script defines who can spend a cell. If you deploy a buggy lock, assets could be locked forever. I tested extensively on testnet before deploying anything.

3. data1 vs type hash matters

For lock scripts that need to execute (not just exist on outputs), use data1 hash type. Type IDs work for outputs but fail for inputs during verification. This cost me debugging time.

4. The tooling has improved dramatically

OffCKB, CKB-JS-VM, the Spore SDK, and CKB-CCC made development much smoother than I expected.

5. The community is genuinely helpful

Every time I got stuck, someone on Discord or Nervos Talk helped me through it. This community support made the difference.


I’d Love Your Feedback

The DApp is live on CKB testnet at https://ckb-registry.vercel.app/ - please try it out!

As a land surveyor learning blockchain development, I’m still early in my journey and would genuinely appreciate the community’s input:

Technical feedback:

  • Are there better CKB patterns for what I’m trying to achieve?

  • How would you improve the lock script architecture?

  • Any suggestions for the purchase/cancel flows I’m currently debugging?

Product feedback:

  • Is the user experience intuitive enough?

  • What features are missing that would make this actually useful?

General thoughts:

  • What would you do differently if you were building this?

Please don’t hesitate to point out issues, suggest improvements, or ask questions. I’m here to learn, and honest feedback - even critical feedback - is exactly what I need to make this better.

I’m also interested in connecting with anyone working on similar problems - whether in land registration, geospatial blockchain applications, or real-world asset tokenization.


Closing Thoughts

This project started as an internship assignment but has grown into something I genuinely believe could help solve real problems in my field. Property rights matter - they’re the foundation of economic security for families and communities worldwide.

CKB’s Cell model is uniquely suited for representing property ownership, and I’m excited to keep building. The core infrastructure works, the marketplace flows are being refined, and I’m learning something new every day.

Thanks for reading - and thanks to the Nervos community for being so welcoming to newcomers like me.


Links:


Built on CKB with Spore Protocol, JoyID, and a land surveyor’s perspective.

9 Likes

This test website looks good to me, and I fully agree that blockchain has a role to play in the Real-World Asset (RWA) sector. My main concern is the regulatory hurdle. Getting local government departments to recognize and use this platform will be a huge challenge, so good luck.

1 Like

Really solid work here.

You can tell this comes from someone dealing with actual land data and not just theory. My father is a land surveyor, so I’ve seen firsthand how messy boundaries, updates and ownership transitions can get. Mapping parcels to discrete CKB cells with programmable rules feels surprisingly natural once you think about it in that context.

On your question about architecture : Keeping parcel state minimal on-chain and pushing heavier metadata off-chain (with hashes anchored in cells) sounds like the right direction long term. Land registries need permanence and clarity, but also flexibility for updates and corrections.

This kind of project makes the “cells as owned state” model click in a very concrete way. Really interesting direction.

And as JackyLHH mentioned, real-world adoption will probably be the toughest challenge. But projects like this can start as parallel infrastructure for surveyors, notaries, or private registries before becoming official systems. If it proves useful in practice and reduces disputes or administrative friction, institutions tend to follow over time.

1 Like