Why We Chose Sui: Object Model, Shared Objects, and Sub-Second Finality for a Spatial Protocol
A spatial cadastre — a protocol where territory claims on a map must never overlap — imposes requirements that most blockchains weren't designed for. It needs atomic read-check-write in a single transaction. It needs concurrent writes to shared state without serialization. It needs sub-second finality for a real-time map. And it needs programmable authorization that works without the owner's signature. We evaluated EVM chains, Solana, and Sui. Here's what we found.
The overlap check and the insertion must happen in the same atomic operation. If they're separate — even by a single block — a race condition exists between them. (We walked through the full two-user scenario in our previous post on SAT collision detection.)
EVM chains can compose calls via multicall contracts, but it requires deploying a custom aggregator and reasoning carefully about reentrancy. Sui's Programmable Transaction Blocks make multi-step atomic composition a first-class primitive: validate geometry → run collision check → insert parcel → emit event, all in one indivisible block. If any step fails, everything reverts. No custom wrapper needed. The atomicity guarantee isn't something you build — it's something you get.
This matters more than it sounds. The spatial guarantee — that no two parcels ever overlap — is only as strong as the atomicity of the operation that enforces it. A protocol that checks off-chain and inserts on-chain has no guarantee at all. A protocol that checks and inserts in separate transactions has a window. PTBs close that window at the protocol level.
Thousands of users register parcels on the same spatial index simultaneously. That index is one shared object.
On EVM chains, concurrent writes to the same contract state queue up in the mempool — one transaction per block slot wins, the rest retry. On Solana, transactions that touch the same account are serialized before execution — account-lock contention creates a bottleneck when demand is high. Both approaches work, but they impose a ceiling on throughput that a global map protocol will eventually hit.
Sui's shared objects handle concurrent access differently. Multiple transactions can touch the same shared object in the same block; the consensus layer handles ordering without serializing execution. The protocol doesn't have to shard the index or route users to different objects to avoid contention.
Here's the Index struct — the single shared object that every parcel registration writes to. cells maps spatial regions to parcel IDs, polygons stores the geometry, and authorized_caps gates which contracts can register:
/// The shared quadtree index. One per deployment.
/// Each polygon is stored in exactly one cell at its natural depth.
public struct Index has key, store {
id: object::UID,
/// Maps depth-prefixed Morton keys to polygon IDs stored at that cell.
cells: Table<u64, vector<ID>>,
/// Maps polygon IDs to Polygon objects.
polygons: Table<ID, Polygon>,
/// Size of the finest-level cell in coordinate units.
cell_size: u64,
/// Maximum quadtree depth (finest level). World covers 2^max_depth cells.
max_depth: u8,
/// Total registered parcels.
count: u64,
config: Config,
authorized_caps: VecSet<ID>,
}
One object. Every registration on the entire map touches it. The protocol's correctness depends on concurrent writes to this object being ordered safely — not serialized away. The authorized_caps field is worth noting: it's not a simple owner check. It's a registry of capability object IDs that the index trusts. Any contract that holds a registered capability can write to the index. Any contract that doesn't is rejected, regardless of who deployed it.
When a user draws a parcel and presses register, the confirmation should appear on the map in under a second. Not "pending." Not a spinner. Done.
Ethereum L1 finalizes in roughly 12 seconds per slot. Optimistic rollups add their own latency on top — and introduce a withdrawal delay that makes the UX feel like a form you submit and wait on. Sui reaches finality in under 500 milliseconds.
For a protocol where users draw territory, contest claims, and respond to buyouts in real time, this isn't a performance optimization. It's the difference between a live map and a bulletin board. A 12-second confirmation loop means users can't see whether their claim landed before someone else's. A sub-second loop means the map updates as fast as the user acts. The UX requirement drove the finality requirement, and the finality requirement drove the chain choice.
Every parcel on merca.earth is always for sale. The owner cannot refuse a valid buyout. On EVM, enforcing this requires the owner to pre-authorize transfers — an approval transaction that reverts the guarantee back to trust. If the owner doesn't approve, the forced sale can't execute. The protocol's unconditional guarantee becomes conditional on owner cooperation.
On Sui, the protocol mints a TransferCap capability object at deploy time and hands it to the market contract. When a valid payment arrives, the market calls force_transfer using that cap. No owner signature. No pre-approval. The owner's cooperation is structurally irrelevant.
The key is &load_inner(market).transfer_cap — the market contract holds the capability as an object field and passes it directly to execute a forced ownership change:
// Force transfer ownership to buyer
index::force_transfer(
&load_inner(market).transfer_cap,
index,
polygon_id,
buyer,
);
This is a design pattern enabled by Sui's object model: authorization lives in an object, not in an address mapping. The capability can be revoked, reassigned, or scoped without changing the contract's logic. EVM could approximate this with escrow contracts, but the pattern is less composable — the escrow itself becomes a trust surface, and the owner's ability to withdraw approval before a sale lands reintroduces the cooperation problem.
The capability model also separates concerns cleanly. The spatial index doesn't know anything about pricing. The market contract doesn't need admin access to the index. The TransferCap is the only bridge between them — a narrow, auditable interface that does exactly one thing.
These aren't preferences or bets on ecosystem growth. They're structural requirements. A spatial cadastre that serializes concurrent writes can't scale to a global map. One that separates check from insert can't be trustless. One that finalizes in 12 seconds can't be a live map. One that requires owner approval can't enforce unconditional forced sales.
The choice of chain determines what the protocol can guarantee unconditionally. Sui doesn't make merca.earth better. It makes merca.earth possible.