Skip to main content

merca.earth — Spatial Cadastre Protocol

Document status: This whitepaper is a high-level rationale document, not the canonical implementation specification. Normative protocol behavior is defined in the Yellowpaper. Economic, tax, and advanced lifecycle sections in this document include historical or exploratory material; where those passages describe design goals rather than live behavior, they are marked [Design intent — implementation may differ].

1. Introduction​

Land ownership systems depend on spatial integrity: parcels must not overlap, must belong to a jurisdiction, and must maintain consistent boundaries with neighboring plots.

Traditional cadastral systems enforce these constraints through centralized databases and administrative procedures. This creates inefficiencies, opacity, and persistent misalignment between spatial and legal data.

merca.earth proposes a protocol where geometric correctness of land ownership is enforced directly at the execution layer. Transactions that violate spatial rules are rejected by the protocol itself — invalid land geometry cannot be recorded on-chain.

The protocol embeds a spatial validation engine into the blockchain runtime, enabling deterministic enforcement of topological rules for all registered parcels.

2. Problem​

Existing land registries share three structural failures.

2.1 Spatial inconsistency​

Traditional databases allow overlapping parcels, gaps between parcels, and invalid topologies. These inconsistencies require manual correction by administrators.

2.2 Centralized authority​

Cadastral validation depends on a centralized authority, producing slow updates, opaque decision-making, and corruption risk.

2.3 Non-deterministic validation​

Most GIS systems use floating-point arithmetic and procedural validation pipelines. This makes deterministic distributed verification impossible — two nodes may reach different conclusions about the same geometry.

merca.earth solves these problems by embedding deterministic spatial validation directly into blockchain execution.

3. Protocol Overview​

merca.earth is an on-chain land cadastre protocol built on Sui. It enforces topological constraints on parcels during transaction execution — not after the fact.

The core guarantees:

  • Parcels may share boundaries but may not overlap in area.
  • A parcel may exist in unclaimed space, but where parent jurisdictions exist, it must be strictly contained within exactly one parent per level.
  • All parcels must have positive area.
  • Invalid spatial configurations cannot be recorded.

The implementation separates a deterministic spatial cadastre from a layered market system. The spatial core (mercatr) stores parcels in a shared quadtree index with explicit owner fields and runs the full collision pipeline on every registration. The market layer (mercatr_market) sits on top and adds pricing, forced buyouts, and tax distribution.

The market layer includes a cascading tax mechanism. [Design intent — implementation may differ] In the live Move implementation, hierarchy buckets accrue on hierarchy-bearing flows such as register, expand_unclaimed, acquire_slice, bump_price, drop_price, and mark or proposal revenue routed through the market; buy_full pays its seller, treasury, and hierarchy split immediately and does not itself close, collect, or withdraw deferred tax. When buckets are collected, the direct parent keeps 50 % of the accrued amount and the remaining live ancestors divide the remainder equally. Any caller may trigger collect_tax, and the withdrawn amount is transferred atomically to the current parent owner; uncollected buckets become sweepable to treasury only after their expiry epoch has passed.

The market also supports area mutations: expand into unclaimed territory, acquire a slice from a neighboring parcel, rebalance a boundary between two parcels you own, and merge owned parcels. Full semantics are normative in the Yellowpaper.

The canonical implementation targets Sui Move and SUI-denominated execution.

The current implementation details live in:

4. Engagement Surface​

The cadastre and the market answer one question: who owns what. They do not answer a separate question that determines whether anyone shows up — what can a visitor do before they own anything.

merca.earth answers that with paint: a public pixel canvas over the world map, available without a wallet. Anyone can leave a mark; the protocol does not record who. Paint is anonymous, off-chain, and free.

Paint inverts the usual order of operations on a property platform. Conventional onboarding requires a wallet, a payment, and a registration before any expression is possible — claim, then customize. Paint allows expression first and claim second: leave a mark, see whether it matters, register the land underneath if it does. When the parcel is registered, the paint inside the new boundary is absorbed into the parcel's visual layer; the public canvas hands those pixels over to the new owner.

This produces two effects the cadastre alone cannot. First, it gives the map a discovery layer that exists before ownership: a coarser-zoom view shows where painting is currently happening, signalling interest in places no one has yet claimed. Second, it converts low-friction traces into a claim path — anyone who paints something worth keeping has a route to lock it in.

Paint runs alongside the protocol, not within it. It lives off-chain by design: lower latency, no gas, no transaction history, anonymity by default. The trust model is correspondingly weaker than the cadastre's — the team operates the canvas, content is not censorship-resistant, and the public canvas can be cleared during operations work. Ownership remains independent: the cadastre's guarantees do not depend on paint being available.

For the user-facing description see Paint; for the foundational concept see Key Concepts → Paint.

5. Documentation Map​

This whitepaper is a motivation and framing document only.

  • Yellowpaper — normative behavior, data structures, algorithms
  • How It Works — plain-language protocol walkthrough
  • Key Concepts — parcels, quadtree, buyouts, tax explained for new users

6. Protocol Summary​

The current protocol is a Sui-based on-chain cadastre with the following properties:

  • Fixed-point integer geometry — no floating-point, no rounding ambiguity
  • Strict positive-area, non-overlap enforcement at registration time
  • Shared quadtree-index storage with parcel owner fields
  • Capability-gated lifecycle operations (LifecycleCap, TransferCap)
  • Six hierarchy levels — Continent → Country → Region → City → District → Block — each a separate shared Index object
  • Optional market layer on top of the spatial core
  • Versioned market state: a shared Market wrapper stores mutable economic state in MarketInner through Versioned
  • Cascading, bucketed tax in Market V2 with anti-retro epoch guards, delete-after-collect, and permissionless expiry sweep

For all detailed semantics, see the canonical docs above.

7. Lifecycle​

[Design intent — implementation may differ] This section summarizes the current lifecycle at a high level. For entry-point semantics and edge cases, the Yellowpaper and Move source remain authoritative.

The current implementation supports:

  • Registration — geometry validated, overlap checked, parcel inserted into the Index atomically
  • Removal
  • Ownership transfer
  • Forced buyout — buyer pays the current buyout price (P=A×R×MP = A \times R \times M), and the market splits the payment 85% to the seller, 7% to treasury, and 8% to the hierarchy pool
  • Area mutations: expand_unclaimed, acquire_slice, rebalance_slice, merge_owned
  • Registration and expand_unclaimed route payment 92% to treasury and 8% to the hierarchy pool
  • acquire_slice routes payment with the 85/7/8 market split and reprices the receiver with an area-weighted blended premium from the receiver parcel and the captured donor area
  • Deferred tax accrual on hierarchy-bearing flows such as register, expand_unclaimed, acquire_slice, bump_price, and drop_price; buy_full does not accrue deferred tax
  • Atomic collection and withdrawal via collect_tax (permissionless — any caller, tax goes to owner)
  • Permissionless expiry cleanup via sweep_expired

Registration validates multipart parcel topology, minimum edge length, compactness, and non-overlap before inserting the parcel into the shared index.

Geometry-changing operations also interact with tax versioning. Expansion, rebalance, merge, and removal either close existing tax versions or sweep pending child-side tax state so that deferred tax accounting stays aligned with current geometry.

8. Historical Material​

Earlier protocol directions — ETH-native settlement, Harberger-style NFTs, advertising market research — have been moved to the archive.

The current Sui Move implementation supports full area mutations (expand_unclaimed, acquire_slice, rebalance_slice, merge_owned), forced buyouts, and a deferred market-tax lifecycle. Normative details are in the Yellowpaper.

9. Conclusion​

merca.earth treats geometry as a first-class blockchain invariant. No overlapping parcels can ever exist — the protocol prevents them at the transaction layer, not through administrative review.

The live Market V2 stack adds a cascading tax architecture with versioned tax buckets, delete-after-collect semantics, anti-retro epoch guards, owner-withdrawable balances, and permissionless expiry sweeps. All of this is specified normatively in the Yellowpaper → Abstract.

See also: Yellowpaper → Abstract · How It Works → Two Layers · Key Concepts → Parcel · Architecture → Module Dependency Graph · Vision

Last updated on