FOUNDATION 10 · REALTIME RELAY

Fast nearby messages, never persistent world authority

GuardianRegion PDAs advertise bounded realtime relay endpoints. Guardians can forward nearby movement, chat, equipment, and action hints, but they do not own land, index buildings, validate NCM3 payloads, or decide final Solana state. The game can lose its Guardian connection and still buy land contracts, register land, discover buildings from program-owned PDAs, and verify complete building hashes through RPC.

10 min read
Two NiceChunk villagers inspect a regional relay beside a public voxel path while the persistent world continues beyond it.

Key points

Guardian is a relay, not a database

Movement, chat, identity, equipment, and action packets improve responsiveness. Confirmed program accounts remain authoritative for terrain mutations, inventory, land, and buildings.

Buildings use direct on-chain discovery

The client reads FoundationChunk v3 indexes for the visible Chunk ring, resolves BuildSite v3 and BuildingManifest v3, then verifies BuildingShard bytes against the complete 32-byte SHA-256 hash.

A disconnected Guardian cannot block construction

Land purchase and registration depend on MarketUser, Building, Chunk, and player-session accounts. No Guardian account, endpoint, HTTP manifest, or WebSocket response appears in that transaction path.

PROGRAM-OWNED SERVICE STATE

Registry and Region accounts describe relay service only

The repository Guardian program defines a 160-byte GuardianRegistry and a 256-byte GuardianRegion V1 record. A Region stores signed region coordinates, inclusive Chunk bounds, owner, operator, GlobalConfig, endpoint host, port, TLS flag, stake, proof timing, penalty counters, and update slot. It contains no foundation ID, building revision, building count, or content hash.

Tags 0 through 2 initialize the registry and enroll regions. The configured NCK transfer goes to the Guardian treasury during registration. Tag 3 lets the stored operator submit a proof, tag 4 performs permissionless time-based settlement, and tag 5 lets the stored owner update the endpoint.

Some already-deployed environments may still expose an older 288-byte V2 Region layout and the game keeps a compatibility decoder for connecting to those relays. That compatibility is transport-only: neither the old layout nor Guardian availability participates in the new land and building discovery path.

Repository Region layout NCKGRG01 · V1 · 256 bytes

The source dispatcher accepts only tags 0-5.

Service cell 100 x 100 Chunks

It scopes relay discovery, not land ownership.

Building fields None

Foundation and NCM3 evidence stays in Chunk and Building program accounts.

UNTRUSTED REALTIME HINTS

WebSocket messages animate the present; Solana accounts settle the result

The Guardian protocol is useful for nearby player presence, movement, chat, equipment, names, and fast action feedback. These messages can be dropped, reordered, replayed, or unavailable without changing the authoritative account bytes.

A client may render temporary relay hints for responsiveness, but mining, placement, inventory, land registration, and building activation must converge on confirmed transaction results and fresh program-account reads.

If the WebSocket disconnects, the UI reports the lost Guardian connection. RPC-backed game actions remain available when their own required programs and accounts are reachable.

CHAIN-NATIVE SPATIAL INDEX

FoundationChunk replaces the former Guardian building-index concept

For each Chunk in the view distance plus preload margin, the client derives the FoundationChunk v3 PDA. Each valid record points to one immutable BuildSite v3 foundation. Duplicate foundation IDs are collapsed when a parcel spans several Chunks.

An active BuildSite supplies owner, geometry, active revision, and the complete active content hash. The client derives that revision's BuildingManifest v3 and ordered BuildingShard v2 PDAs, checks every owner and seed relationship, reconstructs the NCM3 payload, and compares its full SHA-256 value.

IndexedDB is only a performance cache. Cache entries are keyed by the on-chain identity and full hash, and cached NCM3 bytes are rehashed before reuse. A cache miss or mismatch falls back to PDA loading rather than Guardian data.

REGION AND AUTHORITY MATH

Region coordinates bound relay discovery; PDA ownership bounds trust

The region equation selects a service endpoint. It does not grant the selected process ownership of any world object.

Map a Chunk to one 100 x 100 service region

region(c) = floor(c / 100); minChunk = 100 x region; maxChunk = minChunk + 99

Applying the same floor rule independently to Chunk X and Z derives one deterministic GuardianRegion PDA for ordinary positive and negative world coordinates.

c
A signed Chunk coordinate.
region(c)
The signed service-region coordinate used in the GuardianRegion PDA seed.

Building acceptance contains no Guardian term

visibleBuilding = validFoundationChunk AND activeBuildSite AND activeManifest AND SHA256(shards) = manifestHash

A relay may announce that something happened, but only the Chunk and Building program accounts plus the complete payload hash can make a building enter the verified render and collision set.

manifestHash
The complete 32-byte SHA-256 commitment stored in BuildingManifest v3.
shards
The ordered BuildingShard v2 payload bytes addressed by foundation ID and revision.

Guardian exposes only tags 0 through 5

Rust programs/nicechunk_guardian/src/lib.rs
    match tag {
        0 => initialize_registry(program_id, accounts),
        1 => register_genesis_guardian(program_id, accounts, payload),
        2 => register_guardian(program_id, accounts, payload),
        3 => submit_guardian_proof(program_id, accounts, payload),
        4 => settle_guardian(program_id, accounts, payload),
        5 => update_guardian_endpoint(program_id, accounts, payload),
        _ => Err(NicechunkGuardianError::InvalidInstruction.into()),
    }

There is no land, building-summary, manifest, or inventory instruction. Tags above 5 are invalid.

Building discovery starts from visible Chunk indexes

JavaScript play/play-chain-foundations.js
    const chunks = chunksForCurrentView(center);
    lastScannedChunkCount = chunks.length;
    if (typeof module.loadFoundationsForChunks !== "function") {
      failures.push(new Error("FoundationChunk batch loader is unavailable."));
    } else {
      try {
        const loaded = await module.loadFoundationsForChunks(chunks);
        replaceVerifiedFoundations(nearbyFoundations, loaded);
        nearbyLoaded = true;
      } catch (error) {
        failures.push(error);
      }
    }

The visible Chunk ring determines which FoundationChunk PDAs to read. Guardian coverage and endpoint health are not inputs.

IMPLEMENTATION EVIDENCE

Where these claims come from

Each claim is intentionally scoped to a concrete implementation path. These references are for verification, not decoration.

programs/nicechunk_guardian/src/lib.rs

Defines Guardian tags 0-5 for registry initialization, enrollment, proof, settlement, and endpoint updates, with every higher tag rejected.

programs/nicechunk_guardian/src/state.rs

Defines the 160-byte Registry and 256-byte V1 Region service records without land or building metadata.

play/play-chain-foundations.js

Discovers nearby foundations from FoundationChunk PDAs across a bounded visible Chunk ring without Guardian coverage.

src/chain/nicechunkChain.js

Validates FoundationChunk, BuildSite, BuildingManifest, and BuildingShard ownership, seeds, revisions, and complete hashes.

play/play-chain-buildings.js

Rehashes cached NCM3 bytes and admits only buildings whose complete SHA-256 identity matches active on-chain land.