NICECHUNK PROTOCOL

01 · PROTOCOL THESIS

1. Protocol thesis

Persistent worlds face a three-way tension:

1. Players expect immediate interaction.
2. Shared state must be independently verifiable.
3. Storage, synchronization, and reconstruction costs must remain sustainable as the world expands.

NiceChunk resolves this tension by refusing to treat every byte as the same kind of truth. A frame can be fast, a relay message can be social, and a program transition can be final; confusing those properties is how a pleasant animation becomes an unpleasant audit.

Design principles

Reconstruct first. Public seeds, coordinates, rule commitments, and model bytes MUST produce repeatable results.

Settle narrowly. Each program validates one bounded transition and owns only the records in its domain.

Relay without authority. Guardian improves presence but cannot create ownership or replace program execution.

Compress continuously. Useful work receives rewards only when it proves and realizes a reduction in persistent state.

Conserve assets. No successful production action may silently discard a required input remainder, deterministic reward, item, liability, or refundable balance.

Fail closed. Unknown versions, arithmetic overflow, missing accounts, stale roots, incomplete proofs, ambiguous custody, or unavailable outputs reject the transition.

Make recovery ordinary. Public addresses, account lifecycles, close beneficiaries, and replay behavior are specified before the happy-path interface is designed.

02 · TRUTH LAYERS AND PROTOCOL ARCHITECTURE

2. Truth layers and protocol architecture

The browser, Chunk.js, Guardian, and Solana answer different questions. The browser asks what the player is doing now. Chunk.js asks what geometry follows from accepted inputs. Guardian asks which nearby activity should arrive quickly. Solana asks whether a shared transition is authorized and valid.

LOGIC MAP 01

2. Truth layers and protocol architecture

Solid paths carry authority or validated data. Dashed paths carry temporary messages. No layer inherits authority because it is faster or visually convincing.

2.1 Four truth layers

NiceChunk uses four deliberately separate truth layers:

1. Local intent covers input, camera, collision prediction, animation, drafts, and reversible feedback on one device.
2. Realtime observation covers Guardian messages that help nearby players share the present.
3. Durable state covers accepted Solana account bytes and atomic program transitions.
4. Deterministic reconstruction covers the geometry, materials, collision, and derived outputs that follow from durable inputs under pinned protocol roots.

LOGIC MAP 02

2.1 Four truth layers

A client MUST label or internally track which layer produced each datum. A Guardian block-removal hint, for example, MUST remain pending until the relevant Chunk account confirms it. A local mesh MUST NOT be treated as custody evidence. A transaction signature with unknown status MUST NOT be shown as either success or failure until its status and affected accounts are reconciled.

2.2 One root graph, many narrow programs

The Core GlobalConfig anchors one deployment. Domain registries commit the exact rules used by specialized programs. The aggregate ProtocolVersionRoot makes the accepted rule graph independently comparable without turning Core into an all-powerful mutable account.

LOGIC MAP 03

2.2 One root graph, many narrow programs

Every root uses SHA-256 over a domain tag and canonical binary encoding. Merkle collections sort leaves by typed identifier before hashing. Duplicate identifiers, unknown fields, noncanonical integers, and arithmetic overflow are invalid, not alternative encodings.

03 · GENESIS, REGISTRIES, AND DETERMINISTIC WORLD PROTOCOL

3. Genesis, registries, and deterministic world protocol

3.1 Network identity and sealed genesis

One NiceChunk deployment is identified by:

NetworkId = SHA256(
  "NCK/NETWORK/v2" ||
  solana_genesis_hash ||
  core_program_id ||
  global_config_pda
)

The sealed GlobalConfig commits the NCK mint, world identifier and 32-byte world seed; the Core and domain program identities; world bounds; fee-policy roots; and the first accepted registry roots. It has no ordinary update instruction. A replacement deployment has a different NetworkId, even if it reuses a name, logo, seed, or token symbol.

The canonical geometry profile is:

The Region span is committed redundantly so disagreement becomes detectable, not negotiable. GlobalConfig.guardian_region_size_chunks, GuardianRegistry.region_size_chunks, the Guardian program constant, the SDK derivation, Chunk.js discovery, and Guardian's building-region index MUST all equal 100. Activation, startup, or registration rejects any mismatch. A service radius and an AOI radius are separate operator limits and MUST NOT be mistaken for the chain assignment. Three numbers may describe nearby space; they do not get to describe three different worlds.

3.2 Versioned registries without retroactive reinterpretation

Mutable game rules live in domain registries. Each registry revision contains previous_root, revision, activation_slot, entry_count, and entries_root. An approved revision becomes usable only after its governance timelock and activation slot. Transactions name every mutable root that affects their result and reject stale or unknown roots.

RegistryRoot = SHA256(
  "NCK/REGISTRY/v2" || domain || revision || activation_slot ||
  previous_root || entries_root
)

ProtocolVersionRoot = MerkleRoot(sorted(domain || RegistryRoot))

An upgrade creates a new interpretation domain. Existing buildings, equipment, tasks, and receipts retain their pinned roots until an explicit migration validates the old and new semantics. Governance can open a new road; it cannot claim the old road was always somewhere else.

3.3 Integer world generation

NiceChunk divides the world into integer-addressed chunks. For untouched space, the world seed, terrain configuration, resource rules, and coordinates are sufficient to calculate the same base answer on compatible clients. The protocol does not need an account for every naturally generated block.

Player-created facts are layered over that base. A mined coordinate, protected foundation, building manifest, or governed rule changes reconstruction. Cost therefore follows meaningful change rather than theoretical world size.

LOGIC MAP 04

3.3 Integer world generation

The reconstruction rule is:

Visible world = generated base + validated deltas + verified NCM assets

G(NetworkId, WorldGenerationRoot, x, y, z) is a language-neutral integer algorithm. Signed world coordinates are canonical 32-bit integers; intermediate arithmetic uses checked signed or unsigned 64-bit integers as specified by each module. Division of negative X and Z uses Euclidean floor division, never language-default truncation toward zero. Floating point, host random generators, locale, wall-clock time, GPU state, and object iteration order are forbidden from consensus outputs.

The canonical query returns a typed BaseCell containing block ID, generated-structure ID and local member index, natural-water occupancy, resource source ID, and generation flags. A generated tree is one structure whose members are derived from its canonical anchor; it is not a fortunate pile of unrelated blocks.

chunk_x = floor_div(x, 16)
local_x = x - 16 * chunk_x             where 0 <= local_x < 16
chunk_z = floor_div(z, 16)
local_z = z - 16 * chunk_z             where 0 <= local_z < 16

BaseCell = G(WorldGenerationRoot, x, y, z)
CellNow  = ApplyVerifiedOverlays(BaseCell, ordered_delta_roots, active_assets)

World generation is sealed for this NetworkId. New terrain algorithms create a new world-generation domain or an explicitly bounded expansion zone; they do not alter previously addressable base coordinates. Resource, surface-decoration, and production registries may evolve, but each accepted action pins the exact revision it used.

3.4 Cross-runtime parity

The protocol publishes canonical binary test vectors for boundary coordinates, negative coordinates, biome transitions, water, generated structures, resource identity, and wide-range pseudorandom samples. Each vector contains the full input bytes and expected typed output bytes. Rust, Chunk.js, indexers, proof circuits, and independent clients MUST run the same vectors directly.

LOGIC MAP 05

3.4 Cross-runtime parity

Tests that separately recreate similar formulas are insufficient. The release gate executes each actual runtime and compares canonical bytes. Presentation-only lighting and pixel output remain outside world consensus.

04 · ACTION INTENT, SETTLEMENT, AND IDEMPOTENCY

4. Action intent, settlement, and idempotency

The client handles aiming, reach, collision, animation, and reversible feedback immediately. A supported shared action is then encoded as a bounded instruction containing integer coordinates and the exact accounts required by its program.

The program recalculates verifiable facts, checks signers, account ownership, PDA derivation, rules, and current state, and commits atomically. The client then reads affected records and reconstructs the result. Rejection returns the local pending state to its prior value.

LOGIC MAP 06

4. Action intent, settlement, and idempotency

Guardian can report that an action is happening. Only the owning Solana program can decide whether its durable state changed.

4.1 Canonical intent and one durable outcome

Every durable mutation carries a canonical ActionId:

ActionId = SHA256(
  "NCK/ACTION/v2" || NetworkId || owner || authority ||
  consumer_program || instruction_kind || session_epoch || action_nonce ||
  expected_state_roots || canonical_arguments
)

The owner or authorized session chooses a strictly increasing nonce inside its writable authorization record. The consuming program verifies the expected account revisions and roots, increments the nonce and action count, performs all writes, and emits or creates a typed receipt in the same transaction. Reusing an accepted ActionId returns the recorded outcome without applying value twice; reusing a nonce with different bytes is rejected.

LOGIC MAP 07

4.1 Canonical intent and one durable outcome

The browser MUST keep optimistic changes reversible until acceptance. It MUST preserve a known transaction signature, query the correct NetworkId, inspect meta.err, and reread affected accounts before retrying an unknown outcome. A retry uses the same ActionId when it is the same intended action; creating a new nonce to escape uncertainty is forbidden until reconciliation proves the first action absent or rejected.

4.2 Atomicity across programs

Cross-domain transitions use constrained cross-program invocations. Each adapter validates the caller program, signer PDA, expected old-state hash, new-state hash, policy roots, and exact target account. The transition and receipt are in one Solana transaction. If any invoked program fails, all program writes and transfers roll back; the network processing fee may still be charged.

For workflows too large for one transaction, staged accounts are invisible to canonical reconstruction until one activation record reaches FINALIZED. Partial uploads consume storage but do not create partial ownership or partial geometry. Abort and expiry rules name the signer allowed to close staging records and the beneficiary that receives their remaining lamports.

4.3 Four different payers and beneficiaries

Every instruction specification names:

• the transaction fee payer;
• the account storage payer;
• the asset owner or transition authority;
• the close or release beneficiary.

These roles may share a key, but they are never inferred from one another. Account creation records a CapitalPolicyId that defines close eligibility, minimum age, PoUW participation, refund routing, and any protocol share. Donated lamports do not enlarge a refund, miner reward, or liability unless the policy explicitly accepts and tracks them.

05 · SOLANA PROGRAM, PDA, AND ACCOUNT-LIFECYCLE ARCHITECTURE

5. Solana program, PDA, and account-lifecycle architecture

NiceChunk has no single all-powerful world account. Native Solana programs own separate record families:

• Core anchors immutable genesis configuration, the NCK mint identity, world geometry parameters, and committed rule hashes.
• Player owns profiles, appearance, equipment pointers, unique-name indexes, invites, and expiring session authority.
• Chunk verifies generated resources and owns broken-coordinate deltas, resource rules, surface rules, progress, and foundation chunk indexes.
• Backpack and Asset own inventory custody, material lots, unique items, overflow records, and custody nonces.
• Smelting owns recipe tables and production progress.
• Market owns listings and exact-item escrow state.
• Building owns build sites, foundations, manifests, shards, revisions, and protection data.
• Guardian owns regional endpoint discovery and operator commitments.
• Civilization owns citizenship, power accumulators, proposals, votes, tallies, timelocks, and execution receipts.
• Useful Work owns compression tasks, commitments, proofs, migrations, release lots, liabilities, and reward settlement.

LOGIC MAP 08

5. Solana program, PDA, and account-lifecycle architecture

Program ID is part of PDA derivation. Similar labels under different programs remain separate accounts.

5.1 PDA and account invariants

Every account family defines and enforces:

A public address that derives correctly but has the wrong owner, layout, network binding, or relationship is invalid. Programs MUST rederive every critical PDA themselves. Clients MUST validate owner and layout before decoding. Indexers accelerate discovery but never replace those checks.

5.2 Lifecycle and storage recovery

LOGIC MAP 09

5.2 Lifecycle and storage recovery

Every non-permanent account family MUST expose a bounded close or compaction path. A close drains only the balance permitted by its capital policy, zeroes data, and leaves a receipt or parent-state update sufficient to prevent replay. Permanent roots and append-only audit receipts declare that retention explicitly. Expiry alone never moves lamports; logout never revokes chain authority; a UI label never closes an account.

5.3 Cross-program invariant table

Each cross-program adapter publishes a machine-readable interface commitment containing account order, signer derivation, writable set, instruction schema hash, precondition root, postcondition root, and error map. A release cannot activate when either side's generated interface hash differs.

AdapterId = SHA256(
  "NCK/ADAPTER/v2" || caller_program || target_program ||
  instruction_schema_hash || account_schema_hash || invariant_root
)

No generic trusted-producer PDA may mint arbitrary record categories. Authority is scoped to one adapter, output type, recipe or action family, and policy revision.

06 · PLAYER IDENTITY, SESSIONS, NAMES, AND RECOVERY

6. Player identity, sessions, names, and recovery

A PlayerProfile is derived from an owner wallet and connects public identity to appearance, equipment references, progress checkpoints, and owned inventory paths. Assets remain in program-owned Backpack or equipment records rather than a browser save file.

For frequent actions, an owner may authorize an expiring PlayerSession. The session binds a temporary signer to:

• the owner;
• the owner's profile;
• the canonical GlobalConfig;
• an action permission mask;
• an expiry time.

Every consuming program repeats the relationship and permission checks. The temporary key can authorize only the NiceChunk actions accepted by those checks; it does not become the owner of the player's identity or inventory.

LOGIC MAP 10

6. Player identity, sessions, names, and recovery

6.1 Public identity and unique names

PlayerProfile = PDA(Player, ["player", GlobalConfig, owner]) is the durable root of one player. It stores public profile fields, progress references, authorization epoch, equipped item references, and the active Backpack pointer. Appearance data is a separate versioned asset so changing a model does not rewrite the identity root.

Names are normalized by a pinned Unicode profile, not by browser locale. The canonical form applies UTF-8 validation, NFKC normalization, Unicode case folding, allowed-script policy, whitespace collapse, and length bounds before hashing. Visually confusable or mixed-script names are rejected by the active NamePolicyRoot. The unique index is:

NameKey = SHA256("NCK/PLAYER-NAME/v2" || canonical_utf8_name)
NameIndex = PDA(Player, ["player-name", GlobalConfig, NameKey])

Changing a name atomically creates or claims the new index, updates Profile, and retires the old index into a cooling state before it may be claimed again. This prevents stale indexes and rapid impersonation. Public identity is discoverable; private contact information is never stored in these accounts.

Invites are owner-signed referrals, not ownership transfers or token entitlements. Each accepted invite records inviter, invited owner, campaign or rule root, slot, and uniqueness key. Spawn selection is deterministic from an accepted region and world root, but collision-safe placement is revalidated when the player enters the world.

6.2 Unfunded capability sessions

A session authority is an ephemeral signer whose public key is bound to a PlayerSession PDA. The protocol MUST NOT fund that signer with ordinary SOL or tokens. A transaction sponsor or the owner pays network fees and account rent directly. An unfunded session key can still sign messages, but compromise cannot spend a balance the protocol never placed there. One session carries at most 32 capability leaves and lasts no more than 86,400 seconds plus its policy-defined slot bound.

Each session stores status, owner, profile, authorization epoch, capability root, expiry slot and timestamp, maximum actions, consumed actions, next nonce, and optional per-domain limits. A capability leaf is:

CapabilityLeaf = SHA256(
  "NCK/CAPABILITY/v2" || consumer_program || instruction_kind ||
  account_scope_root || value_limit || rate_limit || policy_expiry
)

The consuming instruction receives the writable session, proves the applicable leaf, checks ACTIVE, owner and profile relationships, current authorization epoch, both expiry bounds, scope, count, nonce, value and rate limits, then invokes the Player program's constrained ConsumeCapability adapter. Player increments consumed_actions and next_nonce; the consumer applies the action in the same atomic transaction. A non-Player program never writes Player-owned session bytes directly. BREAK_BLOCK cannot authorize Backpack deletion, building uploads, market listings, or another action merely because a bit happened to be nearby.

LOGIC MAP 11

6.2 Unfunded capability sessions

The owner may revoke a session at any time or increment the Profile authorization epoch to invalidate all older sessions. Expired or revoked sessions may be closed after the dispute window; tracked rent returns to the capital-policy beneficiary. Revocation prevents later NiceChunk consumption. It cannot erase a signature already finalized before revocation.

6.3 Wallet, account, and data recovery

Self-custody means the protocol cannot reconstruct a lost private key. It can make everything else less dramatic. From NetworkId and an owner public key, a client can rederive Profile, active sessions, name index, equipped assets, Backpack directory, pending outputs, listings, buildings, governance records, and receipts through deterministic addresses and authenticated indexes.

A recovery flow MUST:

1. verify cluster and NetworkId;
2. identify which private authorities still sign without exposing secret bytes;
3. enumerate deterministic accounts and validate owner, layout, roots, revisions, and custody;
4. classify transaction outcomes from signatures and account reads;
5. revoke compromised sessions and rotate authorization epoch;
6. use only implemented transfer, cancel, claim, repair, or close paths;
7. simulate where practical, sign once, and verify the resulting state before retrying.

Browser caches are disposable indexes. They may improve startup, but no asset's only reconstruction bytes, custody fact, or durable nonce may exist solely in local storage.

6.4 Atomic character creation and appearance assets

Character creation joins several different facts without pretending they are one record. The owner wallet authorizes one transaction that creates the PlayerProfile, claims the normalized NameIndex, installs an initial PlayerAppearance revision, accepts an optional referral, and records a verified SpawnReceipt. If any mandatory component fails, none of them becomes active. A name availability preview and a locally rendered body are helpful previews; they reserve nothing.

PlayerAppearance is a public, versioned asset containing owner, profile, codec ID and version, exact payload hash, DependencyRoot, bounded dimensions, active revision, previous revision, and capital policy. NCM2 supplies compact static characters; NCM4 supplies registered bones and explicit actions. The Player program validates the envelope and commitment, while the registered verifier validates canonical bytes, dimensions, bone graph, action names, expansion limits, and cost vector before activation. Unknown codecs, cyclic bones, duplicate actions, missing required actions, noncanonical payloads, or a model outside the humanoid collision envelope reject.

The canonical collision capsule, eye height, reach origin, and occupied movement bounds come from CharacterPhysicsRoot, not from decorative hair, clothing, or animation. A very tall hat may win attention; it does not win extra mining reach. Chunk.js reconstructs appearance and equipment from the active revisions and falls back to the registered default character only for presentation when bytes are temporarily unavailable. A fallback never changes the stored appearance, hit volume, owner, or equipped ItemIds.

Appearance replacement is resumable but semantically atomic: bytes may be staged in bounded shards, yet only a fully verified revision changes the active pointer. Retired revisions follow their capital and archive policies. The owner may select a different valid appearance; no Guardian, indexer, cache, or marketplace thumbnail may rewrite it.

6.5 Referrals and deterministic spawn

A referral is an owner-accepted public relationship, not a bearer coupon hidden in a URL. The canonical invitation binds NetworkId, campaign root, inviter, optional target owner, allowed Region, expiry, and nonce. The invited owner signs acceptance. InviteReceipt = PDA(Player, ["invite", GlobalConfig, campaign, invited_owner]) enforces one accepted inviter per campaign and records no reward unless that campaign's pinned rule explicitly creates one. Editing ?ref= in a browser address proves only that someone can edit a browser address.

The first spawn is selected from the accepted invitation Region when permitted, otherwise from the genesis Region. It is not accepted from client-supplied XYZ coordinates. The Spawn program derives a deterministic candidate sequence:

SpawnSeed = SHA256(
  "NCK/SPAWN/v2" || NetworkId || owner || campaign_or_zero || region_x || region_z
)

candidate(i) = PermuteWithinRegion(SpawnSeed, i)       for 0 <= i < 256

For each candidate XZ column in order, the program or constrained World verifier recomputes canonical terrain and accepted deltas. The first candidate wins only when it has solid support, dry feet and head cells, two-block standing clearance, allowed world height, no active building collision, no protected exclusion, and a pathable neighbor under SpawnPolicyRoot. If no candidate passes, creation rejects with NoValidSpawn; it never stores an unverified browser guess. The accepted integer position, Region, world and delta roots, candidate index, and receipt hash enter the Profile and SpawnReceipt atomically.

LOGIC MAP 12

6.5 Referrals and deterministic spawn

Later movement is ordinary verified action state. Death and respawn use a separate RespawnPolicyRoot, checkpoint authority, cooldown, and receipt; they cannot silently reuse an invitation to teleport.

6.6 Wallet modes and secret handling

NiceChunk distinguishes an owner wallet, an unfunded session signer, a fee sponsor, and a public PlayerProfile. Connecting a wallet exposes an address and permits approval requests; it does not reveal the wallet's private key or approve a message, transaction, character, payment, or session by itself.

An external wallet or hardware signer is the preferred owner authority. An optional embedded owner wallet MUST NOT store plaintext or merely encoded secret-key bytes in cookies, URL state, localStorage, logs, analytics, crash reports, or service-worker caches. Its exportable backup container uses Argon2id with at least 64 MiB memory, three iterations and one lane to derive a key, then XChaCha20-Poly1305 with a fresh 128-bit salt, 192-bit nonce, versioned parameters, and origin || NetworkId || public_key as associated data. Implementations MAY raise these parameters; lowering them creates a new wallet-container version and an explicit warning. Plaintext key material exists only while unlocked in memory and is cleared on lock as far as the runtime permits.

A valid encrypted container protects data at rest; it cannot protect an unlocked key from malicious same-origin code, a compromised device, screen capture, coercion, or a user who loses both password and backup. The interface displays network, program, instruction class, value, destination, fee payer, and simulation result before owner approval. It never requests a seed phrase through an ordinary page form. Disconnecting removes a connection; it does not revoke finalized sessions, move assets, erase the chain, or magically back up a key.

LOGIC MAP 13

6.6 Wallet modes and secret handling

07 · RESOURCES, MATERIALS, PRODUCTION, AND EQUIPMENT

7. Resources, materials, production, and equipment

Resources begin as generated coordinates or governed surface objects. Mining verifies the source, records the world change, and places a concrete resource record into custody. Smelting consumes exact Backpack inputs against a recipe and produces materials with explicit volume and property fields. Forging turns allocated material mass into equipment reconstruction code. Building combines compatible materials, foundations, and NCM instructions into persistent structures.

LOGIC MAP 14

7. Resources, materials, production, and equipment

Production is a custody transformation. Valid inputs leave only when outputs fit or enter a bounded owner-controlled output record, and the entire transition succeeds.

7.1 Mining one canonical coordinate

Mining accepts an integer coordinate, expected base and current block identities, tool item, Backpack or output destination, rule roots, and action authorization. The Chunk program recomputes generation and overlays, verifies protection and duplicate-removal state, verifies the tool's custody and capability, decrements durable tool durability, creates the world delta, commits every deterministic output, and advances skill progress atomically.

The program does not pretend to replay the player's camera. Reach, swing contact, particles, and sound are local evidence. Durable acceptance proves only the exact program checks above.

roll = U64LE(SHA256(
  "NCK/DROP/v2" || NetworkId || WorldGenerationRoot ||
  DropRuleRoot || x || y || z || source_id || rule_salt
)[0..8]) mod 10,000

eligible(rule) = support_match && height_match && flags_match &&
                 rule.roll_start <= roll < rule.roll_end

The roll is coordinate-bound, not retry-bound. Changing a transaction nonce, wallet, RPC, or time cannot reroll the same natural source. Ordered rules define base output, decoration output, byproducts, and exploration bonus. Every accepted output is committed before XP advances.

7.2 Atomic single actions and semantically atomic extraction plans

Generated structures such as trees are reconstructed from their canonical anchor and membership function. Small multi-block actions of at most 64 affected cells execute in one transaction when account and compute limits permit.

Larger support collapses use a bounded ExtractionPlan. The submitted cells are lexicographically sorted and duplicate-free. The plan commits bounding box, canonical occupancy root, support-graph root, affected Chunk revision roots, output root, tool ItemId, owner, policy roots, and expiry. Direct verification supports at most 4,096 candidate cells and 1,024 removed cells; larger claims require a registered validity proof under the same public inputs.

LOGIC MAP 15

7.2 Atomic single actions and semantically atomic extraction plans

Staged Chunk records are ignored by canonical reconstruction until the single plan status becomes FINALIZED. Finalization makes all staged removals semantically visible together, applies durable tool cost once, activates outputs, and grants XP once. A partial upload is therefore recoverable storage, not a half-collapsed building site. Any changed baseline root invalidates finalization and permits cleanup.

After finalization, permissionless materialization batches copy staged coordinates into ordinary active Chunk deltas. Each staged entry has a materialized bitmap bit, so canonical reconstruction applies active deltas ∪ finalized unmaterialized entries exactly once during compaction. The plan and staging accounts may close only after every entry is materialized, every Chunk root matches, and the final plan receipt remains retained. Thus cleanup cannot make a finished collapse grow back.

Support is a protocol graph, not a client opinion. Vertices are occupied canonical cells in the bounded box; six-face adjacency defines edges; anchor predicates are pinned by PhysicsRoot. The removed component is exactly the unanchored connected component selected by the action. Clients may preview it, but the direct verifier or proof circuit decides it.

7.3 Backpack capacity and lossless overflow

A Backpack page is a fixed-capacity custody index containing at most 50 typed references or compact material-lot records. It MUST NOT authorize arbitrary removal through a mining capability. Dense UI ordering is not asset identity; moving an entry does not change ItemId, LotId, model commitment, material pattern seed, or provenance.

Before an action consumes inputs, the program computes final slot demand after merges, splits, removals, and outputs. If direct capacity is insufficient, deterministic outputs enter an owner-bound OutputReceipt with at most 16 entries. The receipt is created and funded in the same transaction and can later be claimed into any compatible owner Backpack. If neither direct custody nor a bounded receipt can be created, the whole action rejects: no block removal, no input consumption, no durability loss, and no XP.

LOGIC MAP 16

7.3 Backpack capacity and lossless overflow

Output receipts do not expire into confiscation. One owner may have at most 32 open receipts; a transition that cannot merge, claim, or compact enough capacity rejects before changing value. To prevent unbounded state, receipts can be permissionlessly compacted into the owner's paged OverflowVault after a retention interval, preserving every output and LotId. Each deterministic vault page holds at most 64 records. The owner pays or explicitly accepts sponsored storage under the page's capital policy.

7.4 Physical material lots

NiceChunk materials are not colored cubes wearing different name tags. A MaterialDefinition commits density, state, shape family, hardness, toughness, elasticity, thermal limits, conductivity, corrosion, transparency, flammability, tool affinity, dye compatibility, texture/model recipe, and allowed production roles. Dimensions and shape belong to each item or component: plank, rod, beam, plate, brick, tile, pane, wire, pipe, fabric sheet, and voxel block are distinct forms.

Material quantity uses integer physical units:

• volume V in cubic millimetres (mm³, unsigned 64-bit);
• mass M in milligrams (mg, unsigned 64-bit);
• quality and purity in basis points;
• temperature in milli-kelvin;
• dimensions in millimetres;
• color in canonical linear RGB12 plus pigment and finish identifiers.

Density is a reduced rational density_num / density_den in mg/mm³:

M = floor(V * density_num / density_den)
V_from_mass = floor(M * density_den / density_num)

The lot also records which quantity was primary for its creation and one signed 128-bit density error:

DensityError = M * density_den - V * density_num

mass-primary:   V = floor(M * density_den / density_num)
                0 <= DensityError < density_num

volume-primary: M = floor(V * density_num / density_den)
                -density_den < DensityError <= 0

DensityError is accounting state, not a bonus particle that can be withdrawn. Each material and form definition supplies a maximum absolute density error for split pieces; a conversion or merge outside that tolerance rejects. Production receipts preserve separate recipe-denominator residues until they combine into a whole unit or enter an explicit loss class. No sequence of splitting, merging, unit conversion, or tiny batches may increase usable mass, usable volume, quality, or value.

All multiplication uses checked 128-bit intermediates. A MaterialLot stores LotId, material ID and revision, form, dimensions or form parameters, volume, mass, quality, purity, temperature class, color/finish, property commitment, and provenance root. Pattern seeds derive from immutable identity, not world position:

PatternSeed = first64(SHA256("NCK/MATERIAL-PATTERN/v2" || LotId || MaterialRoot))

Moving wood across a workbench therefore moves the wood; it does not ask the grain to improvise.

Split and merge conserve quantity. For a volume-selected split:

0 < V_a < V_parent
V_b = V_parent - V_a
M_a = floor(M_parent * V_a / V_parent)
M_b = M_parent - M_a

E_a = M_a * density_den - V_a * density_num
E_b = M_b * density_den - V_b * density_num

V_a + V_b = V_parent
M_a + M_b = M_parent
E_a + E_b = DensityError_parent

A mass-selected split uses the symmetric proportional-volume rule. Canonical child order determines which requested quantity is a; callers cannot choose a rounding direction after seeing outputs. Merge requires matching material revision, compatible form, purity band, color/finish policy, and custody owner, then sums V, M, and DensityError exactly. Weighted merge properties use rational accumulators stored in the output lot: the quotient is the displayed bps value and the numerator remainder is retained for the next merge. Repeated split and merge therefore cannot round quality upward.

LOGIC MAP 17

7.4 Physical material lots

7.5 Smelting and industrial recipes

Only a recipe whose PDA, revision, authority path, and hash appear under the active RecipeRoot may execute. Owning a structurally valid recipe account is not enough. A recipe declares exact input predicates, catalysts, fuel classes, heat curve, duration, theoretical products, byproducts, emissions, mass tolerance, quality rule, and enabled activation range.

For Smelting skill level L_s in [0, 10], recoverable material efficiency is:

SkillYieldBps(L_s) = min(6,000, 1,000 + 500 * L_s)

The default is 10%, each level adds 5 percentage points, and the cap is 60%. The interface MUST describe this as recoverable output efficiency, not as a lucky bonus. For one recipe output:

input_scale_bps = min(10,000, min_i floor(usable_input_i * 10,000 / required_input_i))
theoretical_mass = floor(template_mass * input_scale_bps / 10,000)
chemical_mass = floor(theoretical_mass * recipe_yield_bps / 10,000)
main_output_mass = floor(chemical_mass * SkillYieldBps(L_s) / 10,000)
main_output_volume = floor(main_output_mass * density_den / density_num)

required_input_i already includes the signed integer batch count. Inputs above the requirement remain in custody and cannot inflate that batch. No intermediate rounds upward. A zero main output is valid only when the recipe explicitly permits a failed batch; otherwise execution rejects before consuming inputs. Remaining mass is assigned exactly among slag, reusable offcut, gas/emission, evaporation, and bounded rounding residue:

M_inputs + M_added_reagents
  = M_main_outputs + M_solid_byproducts + M_gas + M_evaporation + M_rounding

M_rounding is less than the sum of recipe denominator quanta and is carried in the receipt; it cannot be harvested through batch splitting. Volume follows output mass and density, so a 10% recovery really produces a smaller piece of material rather than a full-size block with optimistic bookkeeping.

Required heat energy is integer and recipe-defined:

E_required_mJ = Σ floor(M_i * heat_capacity_i * delta_temperature_i / scale)
                + phase_change_mJ + process_loss_mJ
E_fuel_mJ     = Σ floor(fuel_mass_j * energy_density_j * furnace_efficiency_bps / 10,000)
accept_heat   = E_fuel_mJ >= E_required_mJ && peak_temperature within recipe band

Batch quality is the purity-weighted input quality adjusted by temperature accuracy, contamination, equipment condition, and skill, each with recipe-bounded coefficients. Every term and clamp is in the recipe registry. Inputs are partially consumed by exact mass or volume; unused remainders retain their LotId lineage and return to custody. Outputs, byproducts, XP, and the ProductionReceipt activate atomically or enter owner-bound output custody.

LOGIC MAP 18

7.5 Smelting and industrial recipes

7.6 Forging, NCF, and deterministic equipment stats

The forge edits bounded physical components. Each component references an exact material lot and carries form, dimensions, occupancy, transform, machining history, color surfaces, and structural role. NCF is a declarative reconstruction format; it is data, not imported executable code. The verifier caps payload bytes, components, grid cells, operations, holes, transforms, and reconstruction cost.

The forge computes required occupied volume and structural demand from canonical NCF bytes. Selected lots are consumed partially and exactly. Surplus remains in its original lot or a deterministic remainder lot; offcuts and machining waste become explicit byproducts. Dye volume affects only compatible surfaces and protective finish unless its material definition grants a structural role.

For component i, define material volume V_i, quality q_i in bps, toughness index t_i, current source durability fraction d_i in bps, and structural participation s_i in bps. The deterministic material capacity is:

weighted_capacity = Σ floor(V_i * q_i * t_i * d_i * s_i / 10^12)
geometry_bps      = clamp(contact_bps + continuity_bps - defect_bps, 1, 10,000)
skill_bps         = min(15,000, 10,000 + 500 * forging_level)
D_max             = min(recipe_durability_cap,
                        floor(weighted_capacity * geometry_bps * skill_bps / 10^8))

All indices and geometry terms come from pinned material, shape, and recipe registries. The forge accepts only when D_max meets the design's minimum structural demand. Item mass is the exact sum of incorporated component mass plus binders and finish. Reach, mining class, defense, heat tolerance, and other effects are derived from typed geometry and materials under an EquipmentStatRoot; a display number has no gameplay effect unless the consuming program reads and enforces it.

7.7 Unique item identity, custody, durability, and repair

Every forged result receives a unique Item PDA:

ItemId = SHA256(
  "NCK/ITEM/v2" || NetworkId || creator || forge_receipt || output_index
)
ItemPDA = PDA(AssetProgram, ["item", GlobalConfig, ItemId])

The Item stores type, creator, current owner, custody state and authority, custody nonce, NCF SHA-256 commitment, DependencyRoot, material-provenance root, immutable stat root, current and maximum durability, repair count, creation receipt, and capital policy. A 32-bit presentation hash is never sufficient for custody or model integrity.

Custody is one state machine, not a Backpack copy plus a hopeful pointer:

LOGIC MAP 19

7.7 Unique item identity, custody, durability, and repair

Typed equipment slots accept only compatible item classes. Every transition checks current state, owner, expected custody nonce, destination capacity, and Item PDA. There can be no duplicate authoritative references. Presentation caches may copy NCF bytes, but they must resolve the current Item and verify its commitment before claiming that the model represents the equipped asset.

Durability is durable state. An accepted mining, combat, building, or industrial action decrements durability_current in the same transaction as its effect:

wear = max(1, floor(action_wear * material_wear_bps * condition_bps / 10^8))
D_after = D_before - wear                 require D_before >= wear

Rejected and unknown actions do not locally restore a guessed chain value; the client rereads the Item. Repair consumes compatible material and energy. If r durability is restored, permanent fatigue is:

fatigue = floor(r * repair_fatigue_bps * max(1, repair_count) / 10,000)
D_max_after = max(recipe_floor, D_max_before - fatigue)
D_current_after = min(D_max_after, D_current_before + r)

The repair receipt names consumed lot quantities and resulting roots. Salvage destroys the Item only after creating every recoverable output and provenance link atomically.

7.8 Skills and enforceable progression

Each skill has a SkillDefinition under SkillRoot: level cap, cumulative XP thresholds, accepted receipt families, per-action XP rule, and machine-readable effect adapters. Programs update XP only from accepted actions and derive level as the greatest threshold not exceeding XP. Browser-derived reputation or decorative cards are presentation unless an active program explicitly consumes their committed value.

level(skill, xp) = max { L | 0 <= L <= L_cap and threshold[L] <= xp }
xp_after = min(U64_MAX, xp_before + accepted_xp)

All ten player skills use levels 0 through 10. SkillRoot stores the eleven explicit cumulative integer thresholds for each skill; programs consume those integers directly rather than reproducing a floating-point growth curve. An XP receipt names the action, skill, prior and next XP, threshold version, and consumer program. Duplicate ActionIds cannot grant duplicate XP. Policy updates apply prospectively; they do not retroactively relabel old receipts or reduce stored XP.

Exploration changes only the weight of a rule already eligible at that coordinate; it cannot create a resource or reroll a mined source. Swiftness changes movement, not mining reach, transaction priority, or world coordinates. Appraisal creates a signed identification receipt and controls ordinary interface disclosure, but material definitions and public account bytes remain public. It is gameplay knowledge, not cryptographic secrecy.

An owner above the Burden limit keeps custody of every item. Backpack rejects value-increasing additions and the movement consumer applies the registered overburden envelope, while removal, transfer out, salvage, and recovery remain possible. A registry revision cannot confiscate an inventory by lowering a number. Strength validates whether a typed item may perform a one-hand action; using two hands, a cart, crane, machine, or building installation follows its own explicit equipment class.

No XP is granted when required outputs are lost, an action remains staged, or a transaction fails. An effect cannot be advertised as enforced unless the specification names the consuming program, input account, formula, and failure behavior.

LOGIC MAP 20

7.8 Skills and enforceable progression

7.9 Vital state, combat, death, and respawn

PlayerProfile begins with 100 health, 100 energy, 100 stamina, mining power 1, build power 1, and defense 0. Those fields become gameplay facts only through registered action consumers. A derived PlayerStatRoot combines the pinned base-stat policy, active skills, equipped ItemIds, and current item durability; the program recomputes it rather than trusting a card assembled by the browser.

Energy pays bounded industrial or special actions. Stamina pays repeated physical work and movement bursts. Programs settle regeneration lazily from the prior settled slot and timestamp, using the smaller recovery permitted by both elapsed guards, then apply the new cost atomically. No transaction is required for every animation frame, and changing a device clock cannot refill a chain meter.

recovered = min(
  floor(elapsed_seconds_guarded * recovery_per_second),
  floor(elapsed_slots * recovery_per_slot)
)
meter_before_action = min(meter_max, meter_settled + recovered)
meter_after_action = meter_before_action - action_cost       require meter_before_action >= action_cost

Combat is valid only in a zone and relationship that permit it under CombatPolicyRoot; protected spawn, non-combat foundations, and non-consenting peaceful interactions reject. For one accepted hit:

attack = max(1, floor(base_attack * weapon_condition_bps * action_quality_bps / 10^8))
mitigation_bps = min(8,000, floor(defense_points * 10,000 / (defense_points + 1,000)))
damage = max(1, floor(attack * (10,000 - mitigation_bps) / 10,000))
health_after = max(0, health_before - damage)

The attack receipt decrements weapon and armor durability, consumes stamina or energy, applies health, and records attacker, defender, zone policy, stat roots, random-free hit class, and result atomically. Presentation can interpolate a swing; it cannot choose damage after seeing the outcome. More complex abilities use registered deterministic formulas and bounded inputs under the same receipt boundary.

At zero health the Profile enters INCAPACITATED. It cannot perform value-bearing actions other than authorized recovery, communication, and respawn. Items remain in their existing custody; death does not scatter assets, destroy NCK, or award a looter merely because a client rendered a dramatic fall. Respawn uses the verified checkpoint or deterministic spawn algorithm in Section 6.5, applies the policy cooldown and resource cost, restores the policy-defined health and meters, and writes a RespawnReceipt atomically. A Guardian message may announce the event, but cannot kill or revive anyone.

08 · NCM VERIFIABLE ASSETS, FOUNDATIONS, AND BUILDINGS

8. NCM verifiable assets, foundations, and buildings

NCM is the NiceChunk family of compact model representations. It describes occupied geometry, material references, dimensions, transforms, and, where required, rig or action data. Material identifiers are interpreted through a versioned dependency set; the number alone is not a permanent definition of texture, transparency, collision, or shape.

• NCM3 provides bounded structural verification for shared buildings.
• NCM4 adds bones and explicit actions for character reconstruction.
• NCF1 carries compact forged-equipment reconstruction data.

A building payload is data, not executable imported code. The protocol validates its format and bounds, hashes the exact canonical bytes, divides larger payloads into deterministic shards, and activates a manifest only after every required shard is present.

LOGIC MAP 21

8. NCM verifiable assets, foundations, and buildings

The manifest proves which bytes define the asset. The registered dependency root proves which material, shape, collision, and runtime semantics give those bytes meaning. Chunk.js deterministically reconstructs canonical geometry and collision under that dependency version.

Determinism is scoped to protocol outputs. Compatible implementations must agree on canonical occupied cells, material semantics, transforms, and collision. Pixel output can still vary with texture resolution, accessibility settings, lighting quality, browser, GPU, and other presentation choices that are not committed as consensus state. NiceChunk therefore claims protocol-equivalent reconstruction, not pixel-identical screenshots.

8.1 Format families and strict routing

NCM prefixes route to separate bounded decoders. NCM2 represents compact static avatars; NCM4 represents rigged avatars with explicit bones and actions; NCM3 represents buildings; NCF represents forged equipment. A larger number is not permission to decode one family as another. Every stored model includes codec ID, codec version, payload hash, DependencyRoot, canonical dimensions, and a deterministic resource-cost commitment.

Decoders reject noncanonical Base64URL, noncanonical varints, trailing bytes, unknown opcodes, out-of-bounds transforms, unknown materials, arithmetic overflow, excess expansion, and cost-meter saturation. Chain validation limits and Chunk.js reconstruction limits MUST be identical for consensus dimensions. A payload that the program accepts but the canonical client cannot safely reconstruct is a protocol failure, not a user preference.

NCM2_LEGACY_V1 is a compatibility profile for sealed genesis characters and explicitly grandfathered appearances. Its raw payload is at most 1,532 bytes, with at most 64 palette colors and 512 bounded cuboids inside a 256 × 256 × 256 authoring grid. It carries no trusted rig or action semantics. New user-authored appearance revisions use NCM4_CHARACTER_V1; a legacy NCM2 asset migrates only through a verified revision, never because a client silently relabeled its prefix.

NCM4_CHARACTER_V1 uses a 1,532-byte raw payload, 30 ticks per second, rotations quantized in steps of π / 128, at most 64 palette entries, 512 cuboids, 16 visibility groups, 20 fixed acyclic humanoid bones, 20 action clips, 256 keyframes per clip, and 256 keyframe rotations in total across the payload. The CharacterActionRoot assigns the canonical action IDs idle, walk, run, jump, fall, land, mine, build, use, attack, defend, hurt, celebrate, sit, sleep, swim, greet, trade, forge, and smelt. idle, walk, run, jump, fall, mine, build, and use are required; the others may fall back to their registered base-action mapping. Action fallback changes animation only, never action authority, reach, speed, collision, or item effects.

8.2 Foundation rights and material-backed activation

A foundation is an XZ rectangle with surface Y, owner, access policy, active revision, and per-Chunk index entries. Overlap checks use Euclidean Chunk coverage and protect the exact configured excavation and construction volume. The foundation does not assert that a local preview was level; creation verifies canonical terrain, fluid, clearance, overlap, and any civilization zoning rule under pinned roots.

Every NCM3 revision expands into a canonical bill of materials before activation. One design voxel is a cube with a 1,000 mm edge and gross volume 1,000,000,000 mm³. Shape and form definitions provide a fill_bps for non-solid parts such as roof tiles, panes, beams, stairs, and hollow pipes. Hidden-face removal affects rendering cost, not physical material volume.

RequiredVolume(material_id, form_id) =
  Σ floor(1,000,000,000 * shape_fill_bps / 10,000)
    after canonical overwrite and shape rules

BillOfMaterialsRoot = MerkleRoot(sorted(
  material_id || material_revision || form_id || required_volume || structural_role
))

The builder escrows exact compatible lots. Each contribution proves owner authorization, material revision, form compatibility, quality floor, volume, and provenance. Activation consumes exactly the required quantities, creates deterministic remainder lots, and binds MaterialCommitmentRoot to the building. Doors, furniture, machines, and other detachable objects are separate installable assets unless the NCM revision explicitly consumes them; a building generator MUST NOT quietly install a door on the owner's behalf.

LOGIC MAP 22

8.2 Foundation rights and material-backed activation

8.3 Resumable revisions and semantic activation

Building uploads use deterministic manifests and bounded shard PDAs. Writes are sequential and idempotent. Finalization verifies every shard address and length, full SHA-256 payload hash, canonical NCM3 syntax, expansion and unique-voxel budgets, rotated footprint, world height, foundation revision, dependency roots, bill of materials, and contribution escrow.

Only one active revision affects reconstruction and collision. A staged revision is inspectable but invisible. Replacing a building activates the new revision and retires the old revision atomically; shared material may be credited only through an explicit transformation receipt. If activation fails, the previous building remains active.

Cancellation closes only staged records after verifying owner or governance authority, full expected shard list, and capital policy. Demolition is a separate transition that deactivates collision, creates salvage outputs according to material condition and demolition method, updates foundation indexes, retires payload accounts, and records close beneficiaries. It never deletes history merely because the mesh disappeared.

8.4 Discovery, reconstruction, and cache safety

Guardian and indexers may publish regional building summaries. A client treats them as discovery hints, then derives BuildSite, active manifest, every shard, and dependencies; validates owners, layouts, revisions, full hashes, roots, and foundation geometry; and only then gives bytes to Chunk.js.

LOGIC MAP 23

8.4 Discovery, reconstruction, and cache safety

Cache identity includes NetworkId, BuildSite, active revision, payload hash, DependencyRoot, placement, and renderer ABI. Position, camera, or load order cannot alter procedural material patterns. Cache eviction removes derived buffers, never source custody or reconstruction bytes.

09 · PROOF OF USEFUL WORK: MINING THAT MAKES THE WORLD LIGHTER

9. Proof of Useful Work: mining that makes the world lighter

Every meaningful action can leave a permanent mark. Excavating terrain, building a fortress, and forging equipment all create state that must be stored, synchronized, transmitted, and reconstructed.

Each action may add only a small record. At world scale, millions of actions accumulate. Players collectively fund rent-exempt balances for program accounts, persistent geometry grows, and later clients inherit the delivery and reconstruction cost.

NiceChunk's Proof of Useful Work, or PoUW, turns that burden into an application-layer optimization market. It does not replace, extend, or secure Solana consensus. Miners compete to discover a shorter NCM representation for accepted terrain, buildings, or equipment while preserving exactly the same protocol-defined state under the same pinned dependencies.

9.1 Target identity and semantic equivalence

Every optimization task is pinned to one network, owning program, immutable baseline, semantic dependency set, reconstruction-cost policy, and reward-settlement policy:

NetworkId = SHA256(
  "NCK/NETWORK/v1" || EncodeNetwork(
    solana_genesis_hash, core_program_id, global_config_PDA
  )
)

DependencyRoot = SHA256(
  "NCK/DEPENDENCIES/v1" || EncodeDependencies(
    material_registry_id, material_registry_hash,
    shape_registry_id, shape_registry_hash,
    physics_schema_id, physics_schema_hash,
    runtime_abi_id, runtime_abi_hash
  )
)

ReconstructionPolicyRoot = SHA256(
  "NCK/RECONSTRUCTION_POLICY/v1" || EncodeReconstructionPolicy(
    meter_id, meter_hash, cost_vector_schema_hash,
    absolute_limits, relative_regression_caps,
    minimum_layout_byte_delta
  )
)

RewardSettlementPolicyRoot = SHA256(
  "NCK/REWARD_SETTLEMENT_POLICY/v1" || EncodeRewardSettlementPolicy(
    reward_mint, route_allowlist_root,
    oracle_id, oracle_hash, quote_freshness_slots,
    max_slippage_bps, minimum_output_rule_hash,
    settlement_bucket_count, bucket_cap_allocation_root,
    reservation_epoch_cap, execution_epoch_cap,
    fallback_mode
  )
)

TaskId = SHA256(
  "NCK/POUW/TASK/v3" || EncodeTask(
    NetworkId, world_id, owning_program_id, asset_class,
    asset_PDA, active_revision, active_encoding_hash,
    codec_id, codec_version, verifier_id, DependencyRoot,
    ReconstructionPolicyRoot, RewardSettlementPolicyRoot,
    capital_policy_id
  )
)

The Solana genesis hash prevents cross-cluster replay. The Core program and GlobalConfig PDA distinguish deployments that share a cluster. The asset's owning program is part of the task because identical PDA seed bytes under different programs identify different accounts. NetworkId is never accepted as a caller-defined label: task creation compares it with the network domain compiled into or stored by the verified program deployment. Runtime configuration, an RPC URL, a token symbol, or a website label can help discover these values but cannot replace that check.

The verifier decodes an encoding under the version named by the task and produces a typed canonical state. For NCM3 buildings, later commands overwrite earlier commands. The canonical state serialization contains the domain tag, three little-endian u16 dimensions, a little-endian u32 occupied-voxel count, and final (x, y, z, material_id) tuples sorted lexicographically by (y, z, x). Every tuple field is a little-endian u16. DependencyRoot fixes what each accepted material ID and shape operation means. Site identity, owner, world position, rotation, collision policy, and protection relationships form a separate versioned protected-state commitment.

All commitment inputs use a registered binary schema with fixed-width or length-prefixed fields. The || symbol below means schema-defined byte concatenation, not ambiguous concatenation of display strings.

Other asset classes use their own typed state and dependency schema. NCM4 equivalence includes bones and action definitions; forged equipment includes its geometry, attachment, collision, and durability identity. A proof is valid only under the verifier and dependency root registered for that asset class.

SemanticRoot_v(bytes) = SHA256(
  domain_v || DependencyRoot || CanonicalState_v(Decode_v(bytes))
)

Equivalent_v(old, candidate) :=
  SemanticRoot_v(old) = SemanticRoot_v(candidate)
  AND DependencyRoot_before = DependencyRoot_after
  AND ProtectedRoot_before = ProtectedRoot_after

Changing any dependency hash creates a new interpretation domain; bytes from different dependency roots are never declared equivalent by equality of voxel tuples alone. Changing a meter, cost schema, regression cap, reward route, oracle guard, or fallback creates a new policy root and therefore a new task domain. The roots are commitments to deterministic comparison and settlement, not permission to skip either. The accepted proof path either executes the bounded verifier directly or verifies a protocol-approved validity proof produced against that exact verifier. A shorter string, a matching screenshot, or a client-calculated hash alone proves nothing.

LOGIC MAP 24

9.1 Target identity and semantic equivalence

9.2 Submission, replay, and front-running defenses

A miner first commits to SHA256("NCK/POUW/COMMIT/v1" || EncodeCommit(TaskId, candidate_hash, miner, salt)). After the minimum reveal delay and before expiry, only that miner can reveal the bound candidate and salt. This prevents an observer from copying a revealed encoding and redirecting its reward. EncodeTask and EncodeCommit are registered canonical binary schemas; implementations never hash ambiguous display strings.

The task is optimistic: owners can continue using or revising their assets while miners search. Finalization repeats the active revision and encoding-hash checks. An owner revision makes an older task stale; a stale candidate cannot migrate state or earn a reward. The protocol also rejects an already-consumed commitment, a candidate hash already rewarded for that task, and any candidate no smaller than the active representation.

Invalid submissions consume verifier resources. A governed proof bond covers bounded verification and cleanup. Valid submissions recover the refundable portion; invalid or abandoned submissions can pay their measured protocol cost. Per-asset queues, per-miner limits, expiry, and minimum savings prevent cheap candidate spam from becoming a state-growth attack.

LOGIC MAP 25

9.2 Submission, replay, and front-running defenses

9.3 Storage capital, consent, and release rights

A transaction fee, a transfer to a gameplay signer, and lamports placed in a program-owned account are different economic events. The storage payer funds the account, the game asset owner controls the rights granted by the asset program, and the program owns the account data. None of those roles alone implies a general right to withdraw the account's lamports.

PoUW therefore never infers a release right from a wallet address or from who happens to own the related building. An account class is eligible only when its creation-time state or inherited GlobalConfig commits to a versioned CapitalPolicyId. That policy identifies the eligible account class, release beneficiary, reward-share ceiling, minimum age, cumulative accounting rules, and payer disclosure. The policy ID is pinned by TaskId and ProtectedRoot; a miner cannot change it.

The NiceChunk PoUW policy designates a dedicated PoUW treasury as the beneficiary of eligible surplus. Funding an eligible active account pays for durable protocol storage; it is not a promise that the original payer can later reclaim the same lamports. The transaction builder exposes that policy before funding, and the on-chain task remains independently tied to it afterward.

This rule is not retroactive. An account created under a payer-refund path, with no PoUW capital policy, or before the policy became active cannot be swept into PoUW merely because equivalent bytes are found. It must retain its existing close rules or enter through an explicitly authorized opt-in migration. Pending building uploads are not eligible active assets: cancellation continues to return their manifest and shard lamports to the authorized cancellation recipient.

LOGIC MAP 26

9.3 Storage capital, consent, and release rights

9.4 Value conservation and anti-self-dealing

Banning an owner from mining its own asset would be cosmetic: the same party could use another wallet. NiceChunk instead makes self-dealing uneconomic at the accounting layer.

• A baseline must be active for a governed minimum age, have no pending revision, and use canonical bounded syntax before it can enter the task queue.
• Each asset records its first eligible baseline, cumulative bytes released, cumulative eligible rent, prior receipts, and cooldown. Later proofs receive credit only for new savings below the current active layout.
• The lifetime rent ceiling is calculated once from eligible storage capital and the minimum retained protocol layout. Splitting one improvement across many receipts cannot raise that ceiling.
• The reward share is strictly below 100%, and there is no fixed completion bonus. Verification, migration, and treasury costs reduce value before the percentage is applied.
• Proof bonds, slashed bonds, donated lamports, unrelated treasury balances, token appreciation, and bytes already credited are never labeled storage savings.
• The same compact encoding may earn on different assets only when each migration independently closes or shrinks real account bytes. It cannot earn twice for the same task or released capital lot.

LifetimeRentCeiling = max(
  0,
  rent_min(first_eligible_layout) - rent_min(minimum_retained_layout)
)

sum(EligibleRent for asset receipts) <= LifetimeRentCeiling
0 <= reward_share_bps < 10,000

An owner and miner may still cooperate, but cooperation cannot manufacture eligible value. Deliberately funding a bloated account moves the attacker's SOL into program-controlled storage; compression can return only a strict, cost-adjusted fraction of that measured value as purchased NCK. Sybil wallets do not change the inequality.

9.5 Atomic migration and actual lamport release

Large candidates can be staged in pending accounts, but staging never changes the active pointer. Finalization is one atomic state transition: it rechecks the task, activates the candidate, preserves the asset and owner relationships, closes obsolete shards, transfers eligible surplus lamports, and writes a migration receipt. If any step fails, the old representation remains active.

Solana account resizing requires explicit accounting. Shrinking an account with realloc does not by itself send excess lamports anywhere. The owning program must shrink and transfer the surplus, or close obsolete program-owned accounts and transfer their lamports to the designated PoUW treasury.

Let r(d) be the current rent-exempt minimum for a program account with d data bytes. The settlement records:

B_before  = sum of active manifest, header and shard data lengths before migration
B_after   = sum of active manifest, header and shard data lengths after migration
DeltaB    = B_before - B_after

RentDelta = max(0, sum r(d_before) - sum r(d_after))
Released  = lamports actually transferred from shrunk or closed baseline accounts
EligibleRent = min(RentDelta, Released)

The min prevents donated excess lamports from being presented as compression value. New manifests, headers, shards, receipts, and claim records are included in B_after; temporary staging accounts must be closed before settlement or charged as migration overhead. A task is useful only when DeltaB and EligibleRent exceed governed minimums.

9.6 Net value and NCK reward settlement

Gross rent release is not the same as net value. The settlement ledger deducts only costs actually paid from the PoUW release or treasury. A miner's transaction fees and external search expense remain the miner's risk and are not added to the reward basis. Verification, migration, account creation, treasury execution, and safety reserves are deducted before a reward budget exists:

NetValue = max(
  0,
  EligibleRent - VerifyCost - MigrationCost - TreasuryCostReserve - SafetyReserve
)

RewardSOLBudget = min(
  reward_share_bps * NetValue / 10,000,
  per_asset_cap,
  reservation_epoch_cap_remaining
)

ReservedRewardSOL = lamports actually transferred to receipt escrow
ReservedRewardSOL = RewardSOLBudget

MinerRewardNCK = NCK actually acquired with RewardSOLBudget after swap costs

Slashed proof bonds first cover their own bounded verification and cleanup. They are not EligibleRent, do not enlarge NetValue, and cannot create a PoUW reward.

Released SOL enters a dedicated PoUW accounting path. Finalization atomically sends the fixed RewardSOLBudget into receipt-specific settlement escrow and routes only the unreserved remainder to available treasury balance. NCK acquisition uses the task-pinned route allowlist, oracle, quote freshness, maximum slippage, minimum-output rule, and execution cap. Purchased NCK enters the reward vault and is assigned to the same receipt.

If the oracle is unavailable, liquidity is insufficient, or the minimum output is not met, the swap pauses. The asset remains safely compressed and the fixed SOL budget remains isolated for that receipt; ordinary treasury spending cannot consume it. The protocol creates no unbacked or uncapped NCK liability. Reward value is based on NCK actually acquired, not an optimistic quote.

9.7 Reward reservation and idempotent settlement

Asset migration and reward delivery have different liveness. NiceChunk joins them at one solvency boundary: a migration is finalized only when the candidate becomes active, the old layout is retired, the release lot and receipt are written, and the calculated SOL reward budget reaches receipt-specific escrow in the same transaction. A failure in any one of those writes rolls back the migration.

ReleaseLotId = SHA256(
  "NCK/POUW/RELEASE_LOT/v1" || EncodeReleaseLot(
    TaskId, migration_receipt_PDA, affected_account_set_root,
    before_lamports, after_lamports, ReservedRewardSOL
  )
)

SpendableEscrowSOL(receipt) = max(
  0, escrow_lamports - rent_min(escrow_data_len)
)

EscrowedRewardSOL(receipt) = receipt.ReservedRewardSOL
SpendableEscrowSOL(receipt) >= EscrowedRewardSOL(receipt)

OutstandingRewardSOL = sum(
  EscrowedRewardSOL(receipt) for every receipt in RESERVED or SOL_CLAIMABLE state
)

OutstandingRewardNCK = sum(
  assigned_nck for every receipt in FUNDED state
)

TreasuryAvailableSOL excludes OutstandingRewardSOL
for every bucket b:
  RewardVaultBalanceNCK[b] >= OutstandingRewardNCK[b]

SettlementBucketId = LE64(
  first_8_bytes(SHA256("NCK/POUW/SETTLEMENT_BUCKET/v1" || TaskId))
) mod settlement_bucket_count

These sums are audit identities, not instructions to scan every receipt during one transaction. Extra lamports donated to an escrow do not enlarge its receipt-recorded reward principal or the miner's claim. Program-owned SettlementLiability PDAs and NCK reward vaults are deterministically sharded by TaskId; each bucket maintains aggregate RESERVED SOL, FUNDED NCK, and reservation and execution epoch counters for its receipts. The reward policy pins the bucket count and per-bucket cap allocation, and registration requires the bucket caps to sum to no more than the global reservation and execution caps. Migration, swap, and claim lock one bucket with the affected receipt and escrow or bucket vault accounts and update all balances and counters atomically. This avoids one globally writable ledger or token-vault account without multiplying the global authorization. Indexers can independently recompute each bucket and the global sums from receipts and reject a published ledger snapshot that does not reconcile.

RESERVED -> FUNDED:
  OutstandingRewardSOL' = OutstandingRewardSOL - ReservedRewardSOL
  OutstandingRewardNCK' = OutstandingRewardNCK + AssignedRewardNCK

FUNDED -> CLAIMED:
  OutstandingRewardNCK' = OutstandingRewardNCK - AssignedRewardNCK

RESERVED -> SOL_CLAIMABLE:
  OutstandingRewardSOL' = OutstandingRewardSOL

SOL_CLAIMABLE -> CLAIMED_SOL:
  OutstandingRewardSOL' = OutstandingRewardSOL - ReservedRewardSOL

The receipt uses a one-way state machine:

• RESERVED means the useful migration is complete and its exact SOL reward budget, excluding the escrow account's own rent reserve, is physically isolated, but NCK has not yet been acquired.
• FUNDED means one guarded exact-input swap succeeded and the receipt records the actual NCK vault balance delta assigned to the miner. That assigned balance remains unavailable to every other receipt or treasury action. A failed quote, route, cap, or minimum-output check leaves the receipt RESERVED and spends nothing.
• CLAIMED means the assigned NCK was transferred and the receipt was marked consumed atomically. A bad destination account leaves it FUNDED; replay cannot transfer twice.
• SOL_CLAIMABLE means the public settlement deadline passed under a policy that permits fallback, no swap consumed the principal, and the miner may claim exactly the isolated SOL principal instead of NCK.
• CLAIMED_SOL means that fallback principal was transferred once and the receipt was consumed atomically.

State never moves backward. A successful settlement attempt consumes the RESERVED state, so another executor cannot spend the same release lot. A successful claim consumes FUNDED or SOL_CLAIMABLE, so another transaction cannot claim the same allocation.

The default public policy is NCK_PREFERRED_SOL_FALLBACK_V1. It attempts guarded NCK acquisition permissionlessly for at least 2,592,000 seconds and 6,480,000 slots after migration. Once both thresholds pass, anyone may mark the receipt SOL_CLAIMABLE; only the recorded miner may claim. Before that deadline, the miner may sign one extension that adds exactly another 2,592,000 seconds and 6,480,000 slots. No second extension is valid. The task page discloses the exact NCK routes, original deadline, maximum extended deadline, fallback asset, and principal before commitment. A separately registered NCK_ONLY_RESERVED policy may omit fallback, but its interface MUST state that settlement can remain unavailable indefinitely. No policy may confiscate an unclaimed principal, redirect it to treasury, or change mint or fallback after TaskId exists.

LOGIC MAP 27

9.7 Reward reservation and idempotent settlement

9.8 Verification backends and proof statement

Every task names one entry in the verifier registry. An entry commits to the asset class, codec, semantic-schema, dependency-schema and cost-vector-schema hashes, accepted DependencyRoot, accepted ReconstructionPolicyRoot, bounds, verification mode, activation window, and either the direct verifier program hash or the validity-proof verification-key hash.

An activated registry entry is append-only and semantically immutable. A pause can reject new tasks or finalizations under that entry, but cannot edit its codec, dependencies, limits, key, or interpretation. Replacing any committed field requires a new identifier and version domain.

Two backends are accepted under the same semantic specification:

1. Direct verification executes the bounded decoder and semantic-root calculation in the owning program or an approved verifier program.
2. Validity-proof verification checks a succinct proof generated against the registered circuit or program. The proof is not trusted because a service produced it; the on-chain verifier checks it against pinned public inputs and a registered verification key.

ProofPublicInputs = {
  TaskId,
  VerifierId,
  DependencyRoot,
  ReconstructionPolicyRoot,
  ActiveEncodingHash,
  CandidateEncodingHash,
  SemanticRoot,
  ProtectedRoot,
  ActiveCostVector,
  CandidateCostVector
}

ProofStatement :=
  bounded_decode_v(active_bytes)   = SemanticRoot
  AND bounded_decode_v(candidate)  = SemanticRoot
  AND Meter_v(active_bytes) = ActiveCostVector.decode
  AND Meter_v(candidate) = CandidateCostVector.decode
  AND DecodeCostPolicyPass(
        ReconstructionPolicyRoot,
        ActiveCostVector.decode,
        CandidateCostVector.decode
      )
  AND all registered format and expansion limits hold

The proof meters decoder-owned dimensions. The owning program independently derives account addresses, hashes the actual candidate bytes, rechecks TaskId and ProtectedRoot, supplies and verifies the layout-owned dimensions, calculates pre- and post-migration layouts, and performs the atomic state transition. Neither the proof nor the meter decides ownership, release rights, rent release, or reward. Both backends must pass the same published semantic and metering vectors. If a verifier or key is paused, expired, or unsupported, the protocol rejects new finalizations instead of falling back to an administrator signature.

LOGIC MAP 28

9.8 Verification backends and proof statement

9.9 Deterministic resource accounting and anti-externalization

Fewer stored bytes do not automatically mean cheaper reconstruction. A short sequence of heavily overlapping cuboids can perform far more intermediate voxel writes than a longer direct encoding. A candidate can also move burden into more active accounts, dependency lookups, or working memory. PoUW rejects that cost transfer instead of labeling every byte reduction useful.

Each verifier version defines an integer-only deterministic meter. It does not use wall-clock time, browser frame rate, GPU timing, network latency, or a miner-provided benchmark. Those measurements vary by device and cannot be consensus inputs. The registered meter produces a cost vector such as:

LayoutCostVector(layout) = (
  layout_data_bytes,
  layout_account_count
)

DecodeCostVector_v(bytes) = Meter_v(bytes) = (
  command_count,
  expansion_ops,
  peak_working_units,
  dependency_reads
)

CostVector_v(bytes, layout) = (
  LayoutCostVector(layout),
  DecodeCostVector_v(bytes)
)

CostPolicyPass(policy, active, candidate) :=
  for every protected dimension i:
    candidate[i] <= policy.absolute_limit[i]
    AND candidate[i] <= active[i] + policy.relative_regression_cap[i]
  AND active.layout_data_bytes - candidate.layout_data_bytes
      >= policy.minimum_layout_byte_delta

For NCM3, expansion_ops counts deterministic voxel-write attempts, including writes later overwritten by another command. peak_working_units follows the registered verifier machine rather than a JavaScript engine's heap layout. Layout bytes and active account count come from the actual pre- and post-migration account sets and are rechecked by the owning program.

Every meter field uses a registered fixed width and checked integer arithmetic. Overflow, counter saturation, a missing dimension, or an unknown dimension identifier fails closed; it cannot be interpreted as a small cost.

A policy may permit a small, explicit regression in one dimension when the byte saving is material, but it cannot silently inherit a new meter or unlimited trade-off. The policy root is fixed by TaskId, proof inputs, verifier registration, and the migration receipt. Rewards remain based on eligible rent actually released after costs; claimed latency or bandwidth improvements never inflate the reward basis.

LOGIC MAP 29

9.9 Deterministic resource accounting and anti-externalization

9.10 Two useful-computation markets

NiceChunk uses computation at two different boundaries. Proof of Frontier searches for a valid compact seed for an eligible world-frontier target. Proof of Useful Work revisits already accepted geometric state and removes avoidable bytes. Neither is Solana consensus, and neither authorizes an in-world resource reward by itself.

9.11 Economic flywheel

LOGIC MAP 30

9.11 Economic flywheel

The reward source is not inflationary busywork. It is bounded by value actually unlocked after the protocol preserves the same asset. Computation lowers storage requirements, reduces network traffic, improves reconstruction, and extends the sustainable life of the world.

Every shorter NCM code is a road made faster for the next traveler, a fortress made cheaper to preserve for its builder, and a piece of equipment made easier to carry across the network.

10 · GUARDIAN REALTIME SERVICE NETWORK

10. Guardian realtime service network

Guardian is a non-custodial regional relay network. It helps nearby players share movement, chat, equipment presentation, action cues, and verified discovery hints with low latency. It does not settle terrain, move assets, cast governance votes, sign for players, or become authoritative by being quick.

10.1 One canonical Region grid

For signed Chunk coordinate c, the canonical Region span is:

R = GlobalConfig.guardian_region_size_chunks
  = GuardianRegistry.region_size_chunks
  = GuardianProgram.REGION_SIZE_CHUNKS
  = 100

region(c) = floor_div(c, R)
min_chunk(r) = r * R
max_chunk(r) = r * R + R - 1

Applying the formula independently to X and Z gives one inclusive 100 × 100 Chunk rectangle. Region (0, 0) covers Chunk coordinates 0..99 on both axes; Region (-1, -1) covers -100..-1. Euclidean floor division is mandatory, so negative coordinates do not fall into a different Region merely because a programming language truncates division toward zero.

Region arithmetic uses checked signed 64-bit intermediates and rejects results outside signed 32-bit Chunk coordinates; it never saturates two distinct extreme inputs into the same bounds. GuardianRegion = PDA(Guardian, ["guardian-region", GlobalConfig, i32le(region_x), i32le(region_z)]) is the only registry record for that cell. Clients derive the player's Region and a bounded neighbor set directly; aggregate counters are informational and cannot replace account enumeration.

The registered Region, node service window, and per-event area of interest are deliberately different:

LOGIC MAP 31

10.1 One canonical Region grid

With service radius S = 100, the default configured runtime square is 201 × 201 Chunks and contains (2S + 1)^2 = 40,401 Chunk positions around its center. This operational window does not enlarge the registered 100 × 100 Region or make extra coverage chain-discoverable. With AOI radius A = 7, one movement, chat, equipment, or action cue covers a 15 × 15 Chunk square and fans out to at most (2A + 1)^2 = 225 local Chunk topics before connection, rate, and payload filters. The larger window answers “may this node serve here?”; the smaller window answers “who nearby needs this event?”

10.2 Registration, stake, and operator lifecycle

Registration escrows 100,000 NCK in a Region-specific stake vault. It does not transfer the principal into general treasury custody. The Region stores operator, payout authority, endpoint commitment, TLS mode, service protocol version, capacity, status, stake principal, slash total, service epoch, and policy root. Adjacent expansion requires at least one active cardinal neighbor except the unique genesis Region authorized by the genesis receipt.

LOGIC MAP 32

10.2 Registration, stake, and operator lifecycle

The operator may rotate its service key through a wallet-authorized challenge. Governance may recover an operator only through the normal proposal and timelock path. Withdrawal returns remaining principal to the recorded payout authority after the exit and dispute windows. Slashed NCK is routed by GuardianPolicyRoot between challenger reimbursement, affected-region service rewards, and protocol treasury; no executor chooses recipients ad hoc.

10.3 Authenticated relay sessions

Connection uses a server nonce, client nonce, Region, protocol version, expiration, and wallet public key. The client signs the domain-separated challenge with the owner or an active relay-only session capability. The server verifies the signature, network, Region service bounds, expiry, and replay cache before accepting frames.

RelayChallenge = SHA256(
  "NCK/GUARDIAN-HELLO/v2" || NetworkId || region_pda || endpoint_commitment ||
  wallet || client_nonce || server_nonce || expires_at
)

The authenticated wallet establishes presentation identity for that connection. It still does not authorize a Backpack, item, building, payment, or world mutation. Every frame carries session ID, monotonic sequence, message kind, spatial scope, and bounded payload. The relay applies per-kind size, frequency, fanout, and area-of-interest limits. Out-of-order, duplicate, malformed, over-rate, or out-of-region frames are dropped.

LOGIC MAP 33

10.3 Authenticated relay sessions

10.4 Service proofs, rewards, and slashing

Service time is divided into policy-sized slot epochs. A prior finalized slot hash selects unpredictable challenge slots and bonded challenger assignments after the operator has committed its endpoint and service key. Each assignment creates an on-chain ServiceChallenge with nonce and response deadline. The endpoint service key signs the nonce and TLS certificate commitment; either the challenger or operator may submit the complete signed transcript. This prevents a dishonest challenger from hiding a successful response. A missing response becomes objective only when the challenge account exists, its request was validly opened, its deadline passes, and no valid endpoint response commitment was submitted. Latency remains a quorum observation rather than an impossible cryptographic claim about the speed of the internet.

Challenge weight is assigned, not self-reported. A challenger escrows a policy bond and registers a payout authority, funding-source commitment, service endpoint prefix commitment, network ASN attestation, and operator-affiliation declaration. The chain derives ChallengerGroupId from those correlated fields under GuardianPolicyRoot. One group contributes at most one unit of availability weight per Region and challenge window; shared payout authority, initial bond source, IPv4 /24, IPv6 /48, ASN, operator authority, or disclosed controller collapses candidates into the same group. An epoch needs at least three selected groups across at least two ASNs before it can earn availability rewards. Selection weight is min(isqrt(bond_base_units), challenger_weight_cap) and is capped again per group. These rules raise the cost of manufactured agreement; they do not claim that wallets or rented networks make Sybil identities disappear.

Challenge eligibility and slash evidence are deliberately different. Correlation or insufficient independent samples can reduce a reward score to zero, but cannot by itself slash an operator. A slash requires the signed contradiction, invalid commitment, forged receipt, or expired on-chain nonresponse described below. Challenger bonds are slashed for fabricated transcripts, contradictory attestations, or repeated failure to perform assigned requests; ordinary network disagreement is recorded without inventing guilt.

LOGIC MAP 34

10.4 Service proofs, rewards, and slashing

For epoch e:

availability_bps = floor(10,000 * successful_weight / assigned_weight)
latency_bps      = weighted policy score over successful samples
integrity_bps    = 10,000 unless a valid equivocation or invalid-data proof exists
service_bps      = min(availability_bps, latency_bps, integrity_bps)

guardian_reward = floor(
  epoch_guardian_pool * region_demand_weight * service_bps /
  Σ(active_region_demand_weight * service_bps)
)

region_demand_weight is 1 + isqrt(capped_authenticated_wallet_minutes + capped_region_fee_units). Wallet minutes count at most one concurrent session per owner, and both inputs have policy caps. The denominator and every numerator are committed in sharded epoch settlement records. If it is zero, the epoch pays no reward. Unassigned rounding remains in the pool. Rewards require a minimum independent sample weight and availability floor. Client receipts alone are not trusted uptime votes; they supplement protocol-selected challenges and are capped per owner and network cluster.

Objective slash proofs cover contradictory signed endpoint claims, forged service receipts, invalid regional commitments, and provable challenge nonresponse. Ordinary transient failure first degrades rewards. A severe accepted proof slashes min(remaining_stake, floor(100,000 NCK * 3,000 / 10,000)); repeated failures can remove the Region. Every slash has a bond, evidence hash, challenge window, and appeal result. This gives enforcement due process without asking the outage to write its own performance review.

10.5 Discovery remains a hint

Regional indexes commit full SHA-256 Merkle roots, algorithm version, revision, record count, and validity interval. Each building leaf contains full BuildSite and manifest commitments. Clients verify Merkle inclusion and then verify the actual Building PDAs and full payload hash. A Region outage removes convenience, not world ownership; direct PDA reconstruction and authenticated caches remain valid.

11 · NCK ECONOMY, TREASURY, MARKET, AND FRONTIER WORK

11. NCK economy, treasury, market, and frontier work

11.1 NCK identity and fixed supply ceiling

NCK is the native utility asset of the NiceChunk economy. Genesis accepts:

• symbol: NCK;
• issuance and permanent supply ceiling: 1,000,000,000 NCK;
• decimals: 6;
• continuing mint authority: none;
• freeze authority: none.

S_cap = 1,000,000,000 * 10^6 base units
0 <= S(t) <= S_cap

No continuing mint authority prevents supply from rising above genesis issuance. Holders may burn tokens, so observed supply can fall below the ceiling. NCK identity is established by NetworkId, exact mint address, legacy SPL Token program owner, decimals, initialized state, authority options, and supply bound, never by ticker text alone.

11.2 Genesis distribution and treasury custody

The immutable GenesisDistributionRoot commits every initial allocation leaf, claim class, amount, claim window, and destination rule. Its canonical GenesisManifest publishes the exact NCK mint, Token Program, predecessor NetworkId, predecessor snapshot slot and blockhash, eligibility query, sorted leaf file hash, leaf count, aggregate amount, distribution vault, treasury vault, claim start and end, and Merkle construction rule. The manifest bytes remain content-addressed and independently reproducible before the distribution root is sealed.

An early-player leaf exists exactly once for each unique owner that had a valid PlayerProfile and at least one accepted gameplay receipt on the named predecessor network at or before the snapshot slot. Records created after the snapshot, malformed profiles, receipts from another network, and duplicate owner entries are rejected. This rule does not claim one wallet equals one human; it makes the historical eligibility boundary public and reproducible instead of asking a spreadsheet to look trustworthy.

The distribution enforces:

• one free 100 NCK claim for each eligible early-player leaf;
• 0 NCK reserved for the development team as a genesis or team allocation;
• every NCK not assigned to an eligible early-player leaf placed directly in protocol treasury custody;
• no public, private, strategic, team, or whitelist token sale inside genesis distribution.

A_early    = 100 NCK * number_of_valid_early_player_leaves
A_treasury = S_genesis - A_early

A_early + A_treasury = S_genesis = S_cap

EarlyLeaf = SHA256(
  "NCK/EARLY-PLAYER/v2" || NetworkId || predecessor_network_id ||
  snapshot_slot || owner || profile_pda || first_accepted_receipt_hash ||
  100_000_000
)

The early-player claim window lasts exactly 365 days from its manifest start timestamp and must also pass its paired slot guards. Each claim proves the leaf and transfers exactly 100,000,000 base units to the leaf owner or that owner's signed destination; ClaimReceipt = PDA(Distribution, ["claim", GenesisDistributionRoot, owner]) prevents replay. Before opening claims, the distribution vault balance must equal A_early, the treasury receipt must prove A_treasury, and their sum must equal the authority-free mint supply. A mismatch prevents activation.

Unclaimed balances remain in the distribution vault until the immutable deadline, then a permissionless instruction moves them to the protocol treasury and closes only empty claim-page state under its capital policy. They never move to an operator or team wallet. Developers may earn NCK under the same public player, miner, Guardian, market, grant, or governance rules as everyone else; zero reserved allocation is not a ban on honest work.

LOGIC MAP 35

11.2 Genesis distribution and treasury custody

11.3 Utility and source-separated treasury accounting

NCK is used for Guardian stake, market settlement, civilization bonds and deposits, protocol services, useful-work rewards, grants, and player-to-player exchange. Holding NCK does not replace a program-specific signature, item custody check, session capability, or vote eligibility rule.

Treasury assets are partitioned into source-specific vaults and liabilities. Ordinary protocol revenue, Guardian stake, slash proceeds, market fees, grants, distribution balances, PoUW release lots, and operator rewards cannot be netted together by a convenient dashboard. Every movement names source, policy, destination, authorization receipt, and liability effect.

The general protocol fee is 50 bps (0.50%) and applies only to two primary protocol purchases: one Starter Pack at 0.1 SOL per owner and one non-transferable Genesis Pass at 1 SOL per owner, with at most 10,000 Genesis Passes. The Starter Pack delivers the exact item and material bundle committed by StarterPackRoot through owner-bound output custody. The Genesis Pass is an access and provenance credential; it contains no NCK allocation, profit right, revenue share, or promise of market value. Each purchase atomically collects price + floor(price * 50 / 10,000), creates one owner-bound PurchaseReceipt, and creates every promised output or rejects without payment.

The 50 bps fee does not apply to account rent, Solana transaction fees, player-to-player transfers, resource mining, smelting, forging, building activation, session creation, Guardian stake, Guardian rewards, governance votes, PoUW release lots, early-player claims, or marketplace trades. Marketplace settlement uses only its explicit schedule below. A new charged service requires a new FeePolicyRoot, governance timelock, exact base asset, payer, rounding, refund, route, and activation range; a client cannot add a “small convenience fee” because the button looked lonely.

For protocol SOL revenue subject to the genesis route, including primary purchase price and its separately recorded protocol-fee component:

liquidity_share    = floor(revenue * 5,000 / 10,000)
reward_share       = floor(revenue * 3,000 / 10,000)
engineering_share  = revenue - liquidity_share - reward_share

The resulting shares are 50%, 30%, and the exact 20% remainder. engineering_share funds audited protocol engineering and operations through civilization-approved budgets; it is not a token allocation or unrestricted private entitlement. Related-party recipients disclose controlling wallets and abstain from the relevant vote. Unspent grant balances return to their source vault when the grant closes.

PoUW release escrows remain governed exclusively by their pinned reward policy. They cannot fund operations, liquidity, or unrelated rewards. NCK volatility, a large treasury balance, or an enthusiastic social post does not create a miner liability.

11.4 Atomic marketplace

A listing escrows an exact ItemId, MaterialLot quantity, blueprint, or other registered asset. It stores seller, source custody nonce, asset commitment, quantity, accepted payment mint, base-unit price, fee policy, expiry, destination constraints, and status. Display names and thumbnails are discovery metadata, not settlement identity.

LOGIC MAP 36

11.4 Atomic marketplace

SOL and NCK decimal text is converted to unsigned base units before signing. For price p:

market_fee   = floor(p * 100 / 10,000)   # 1.00%
guardian_fee = floor(p * 10  / 10,000)   # 0.10% on every market settlement
seller_net   = p - market_fee - guardian_fee

The buyer pays exactly p; fees are deducted from settlement proceeds. A zero rounded fee remains zero. Checked 128-bit intermediates reject overflow. Guardian fees route to the named Region's epoch pool only when its Region and service epoch are valid; otherwise that component routes to the general Guardian pool, never to an arbitrary endpoint wallet. Omitting a Region changes routing, not the fee amount.

Purchase verifies buyer differs from seller, payment accounts and mint, listing state and expiry, exact asset commitment, seller authority at listing creation, current escrow custody, buyer destination compatibility and capacity, fee vaults, and expected nonces. Payment, ownership, custody, listing status, output receipts, and rent release are atomic. Sold listings expose a close path; permanent rent leakage is not a market feature.

11.5 Proof of Frontier: short code for the world's edge

Proof of Frontier is a useful-computation market distinct from in-world resource mining and PoUW compression. It coordinates eligible expansion by asking miners to encode the canonical boundary of unlocked Chunks as a short, valid Shape Seed. The output is useful: clients and programs can reconstruct the same frontier from fewer bytes.

The canonical frontier is the sorted set of directed edges separating unlocked and locked Chunk cells. Its target is:

FrontierRoot = MerkleRoot(sorted(canonical_directed_frontier_edges))

FrontierTaskId = SHA256(
  "NCK/FRONTIER-TASK/v2" || NetworkId || epoch || FrontierRoot ||
  codec_root || max_seed_bytes || reward_policy_root
)

Registered encodings include canonical RAW_EDGES, PATH_RLE, RECT, and bounded UNION. Decoding MUST reproduce the exact sorted edge set and root, stay within operation and memory limits, consume all bytes, and re-encode to the identical canonical seed. The proof is short enough, not a claim of mathematical global optimality:

valid(seed) = canonical(seed)
              && Decode(seed) = target_frontier_edges
              && byte_length(seed) <= max_seed_bytes
              && deterministic_cost(seed) <= frontier_cost_limit

LOGIC MAP 37

11.5 Proof of Frontier: short code for the world's edge

Commit-reveal binds the solution to the miner before public bytes are exposed. The first finalized valid reveal wins; duplicate solutions receive no second reward. The expansion claim names one locked Chunk cardinally adjacent to the accepted frontier, verifies it remains eligible, and consumes the receipt exactly once.

Difficulty retargets max_seed_bytes over fixed windows toward a 60-second median solve interval using bounded integer steps. If no solution arrives for ten target intervals, the limit relaxes monotonically. It can never exceed the canonical RAW encoding length, at which point every finite frontier is solvable. Faster blocks tighten by at most 3% of raw length per window; stalled windows relax by at most 5%.

The reward adds a bounded compression premium to the policy base reward:

savings_bps = floor((raw_seed_bytes - accepted_seed_bytes) * 10,000 /
                    max(1, raw_seed_bytes))
reward_bps  = 10,000 + min(10,000, savings_bps)
frontier_reward = min(epoch_pool_remaining,
                      floor(base_frontier_reward * reward_bps / 10,000))

The premium is at most 2×, and the first valid reveal consumes one epoch reward. Frontier rewards come from a capped Frontier vault and epoch policy, not new minting and not PoUW release escrows.

12 · CIVILIZATION MEMBERSHIP, GOVERNANCE, AND EXECUTION

12. Civilization membership, governance, and execution

Civilization is an on-chain coordination system for membership, civic power, proposals, voting, budgets, zoning, registries, and protocol adapters. A proposal is not a law, a tally is not execution, and a caller does not get to improve democracy by leaving inconvenient vote accounts out of the transaction.

12.1 Citizenship and deterministic civic power

Each civilization has a Charter root, membership policy, treasury, bounded territory references, and governance policy. A Citizen PDA binds one owner to admission receipt, join slot, status, stake if required, contribution accumulator, delegation target, and power revision. One owner has at most one active Citizen record per civilization.

Raw power uses public integer inputs:

stake_whole_nck = floor(civic_stake_base_units / 10^6)

raw_power = 1,000
            + 100 * isqrt(stake_whole_nck)
            + 10  * isqrt(verified_contribution_points)

power_cap = 100,000
citizen_power = min(raw_power, power_cap)

The base recognizes citizenship, square roots reduce purchase and farming dominance, and power_cap limits one record. Contribution points enter only through named accepted receipt adapters, decay by charter epochs where specified, and cannot be self-attested. Civic stake remains escrowed and withdrawable after exit rules; it is not payment for power. Sybil resistance is bounded by transparent admission and caps, not falsely declared solved by arithmetic.

Delegation is optional, one-hop, and frozen at snapshot. A citizen cannot delegate to itself, through a cycle, or after snapshot. The recipient may receive at most 100,000 delegated power in one snapshot; excess remains undelegated to its original owners. The original owner cannot vote delegated units.

12.2 Complete snapshots and cumulative voting

A proposal pins a PowerSnapshot containing civilization, snapshot slot, citizen count, total eligible power P, accumulator root, governance policy, and expiry. Citizen leaves derive from the maintained on-chain power accumulator. Any member can prove inclusion or exclusion error during the snapshot challenge window; a successful challenge corrects the accumulator before voting opens.

Each citizen has one VoteReceipt = PDA(Civilization, ["vote", proposal, citizen]). A vote is YES, NO, ABSTAIN, or CHALLENGE. The proposal owns cumulative totals (Y, N, A, C) and cast_power. During the amendment phase, casting or changing a vote verifies the snapshot leaf, subtracts the previous choice when present, adds the new choice, increments the vote nonce, and updates totals atomically. At ballot_lock_slot, all cast choices become immutable; uncast citizens may still cast once through the final voting deadline. Finalization reads accumulator totals, not a caller-selected account list.

LOGIC MAP 38

12.2 Complete snapshots and cumulative voting

For ordinary proposals:

quorum_bps = 2,000            # 20% of eligible power
approval_bps = 6,000          # 60% of YES + NO
challenge_bps = 1,500         # 15% of all eligible power

cast = Y + N + A + C          require cast <= P
quorum_met = cast >= ceil(P * quorum_bps / 10,000)
approval_met = Y + N > 0
               && Y * 10,000 >= approval_bps * (Y + N)
challenge_met = C >= ceil(P * challenge_bps / 10,000)

pass = quorum_met && approval_met && !challenge_met

Constitutional changes, treasury authority, program upgrades, verifier registration, and emergency-control policy use 40% quorum, 67% approval, and a 10% challenge threshold. Arithmetic uses checked 128-bit intermediates and ceiling division where stated. Abstain counts toward quorum but not approval. Challenge counts toward participation and independently blocks the proposal once its threshold is reached.

12.3 Deadlines, irreversible early outcomes, and timelocks

Every proposal has fixed snapshot, voting start, ballot lock, voting end, execution-not-before, and expiry slots plus timestamp guards. The lock begins 12 hours before the voting deadline for both ordinary and constitutional classes. Before that lock, no outcome is mathematically irreversible because existing voters may change their choice. It cannot finalize merely because a friendly caller likes the votes seen so far.

Let R = P - cast be all uncast power. Early pass is allowed only when the result cannot be reversed even if every remaining unit votes against it or challenges:

early_pass = now >= ballot_lock_slot
             && quorum_met
             && Y * 10,000 >= approval_bps * (Y + N + R)
             && C + R < ceil(P * challenge_bps / 10,000)

After ballot lock, early defeat is allowed only when the immutable challenge total already meets threshold or even assigning all R to YES cannot satisfy approval:

early_defeat = now >= ballot_lock_slot
               && (C >= ceil(P * challenge_bps / 10,000)
                   || (Y + R) * 10,000 < approval_bps * (Y + N + R))

Otherwise finalization waits for the voting deadline. Ordinary passed proposals wait at least 48 hours; constitutional proposals wait at least 7 days. Both slot and timestamp thresholds must pass. Public execution is permissionless after timelock and before expiry.

12.4 Compare-and-swap execution

The proposal commits target program, target PDA, instruction adapter, exact expected old-state hash, patch hash, resulting expected state hash, account-set root, and value limits. The target program independently validates all fields and policy roots, performs the update, and creates the Civilization ExecutionReceipt through constrained CPI in the same transaction.

execute_allowed = proposal.status == TIMELOCKED
                  && now >= execute_not_before
                  && now < expires_at
                  && Hash(target_before) == expected_old_hash
                  && Hash(canonical_patch) == patch_hash
                  && adapter_id == committed_adapter_id
                  && resulting_hash == expected_new_hash

Any mismatch rejects without marking the proposal executed. This compare-and-swap rule prevents an old approved patch from overwriting newer state. The receipt binds proposal, tally root, before and after hashes, target, executor, slot, and transfers. A passed tally without that target-state and receipt relationship is an approved suggestion, not an applied law.

12.5 Emergency pause without emergency ownership

A threshold emergency council may pause only named high-risk entry points for at most 72 hours: new PoUW tasks, migrations, treasury swaps, Guardian registration, market listings, or governance execution. It cannot move player assets, change balances, alter roots, cast votes, upgrade programs, or extend its own pause. Every signer and reason hash is public. Civilization governance may ratify a replacement policy through the constitutional path; absent ratification, the pause expires automatically.

13 · SECURITY, DATA AVAILABILITY, AND RECOVERY MODEL

13. Security, data availability, and recovery model

NiceChunk assumes modified clients, malicious relays, stale or dishonest RPC providers, malformed models, compromised browser storage, colluding miners, manipulated markets, governance capture attempts, unavailable archives, program defects, and active upgrade authorities. Security comes from giving each component the smallest claim it can safely make, then verifying that claim where value moves.

13.1 Authority and threat boundaries

Cryptographic commitments rely on collision and preimage resistance of registered hash functions. SHA-256 is the default commitment hash. A hash upgrade creates a new domain; it never reinterprets an old 32-byte value under a new algorithm.

13.2 Dependency-bound equivalence

A material ID is a registry reference, not a complete physical definition. The same integer could become glass, granite, or an extremely confusing hat if clients silently chose their own tables. PoUW and asset reconstruction therefore pin DependencyRoot over material, shape, physics, codec, runtime ABI, and meter definitions.

LOGIC MAP 39

13.2 Dependency-bound equivalence

Canonical geometry, material behavior, transforms, collision, occupied bounds, and deterministic cost must agree. Pixel identity is not required because presentation quality and hardware differ.

13.3 Observation, finality, and data availability

A standard Solana JSON-RPC account response is not a cryptographic proof of consensus state. TLS authenticates the endpoint operator, and a requested commitment reports the fork confidence claimed by that operator; neither proves that the bytes were honestly returned. High-assurance consumers use their own validating infrastructure or verify against independently obtained ledger state. Comparing multiple independent providers can expose disagreement and reduce a single-provider dependency, but matching providers do not become a consensus proof merely by agreeing.

Every published observation therefore names its genesis hash, slot, blockhash where available, commitment, RPC method, source, observation time, full account address, owner, data length, and data hash. finalized reduces rollback risk relative to weaker commitments; it does not authenticate a malicious provider. A later observation can supersede an earlier one, especially after a program upgrade or account transition.

Data integrity and data availability are also different claims:

• Current-state recoverability requires every active manifest, shard, registry, and rule dependency needed for reconstruction to remain available.
• Transition auditability requires receipts that bind old and new roots, affected accounts, slot, transaction, byte accounting, and value accounting.
• Historical replay additionally requires the superseded payload bytes. A content hash proves integrity when those bytes are found; it cannot recreate missing bytes.

PoUW may close an obsolete encoding only after the equivalent candidate is active, so current-state reconstruction remains available. The migration receipt preserves the old and new commitments, but replaying the exact retired encoding requires a separately retained content-addressed archive. The protocol never relabels a hash-only receipt as full historical availability.

Historical payloads use content-addressed archives under an ArchivePolicyRoot. An AvailabilityCertificate commits payload hash, byte length, erasure-code parameters, provider set and independence groups, retention start and end, prepaid service principal, provider bonds, challenge schedule, replacement window, and status. Historical replay may be labeled available only while enough bonded providers answer unpredictable shard challenges to reconstruct the bytes. When that threshold fails, the honest label is integrity commitment only.

Retiring active bytes through PoUW prepays at least 365 days and 78,840,000 slots of historical retention under ARCHIVE_365_V1; both guards must pass before the obligation ends. The archive cost is included in MigrationCost before NetValue and therefore cannot be paid from the miner's already reserved reward principal. Providers receive epoch payments only after the epoch's selected shard challenges pass. Prepaid future epochs and posted bonds remain source-separated liabilities, not treasury revenue.

required_shards >= data_shards
successful_independent_provider_groups >= archive_group_threshold

ArchiveAvailable(epoch) =
  reconstructable_shards(epoch)
  && successful_independent_provider_groups >= archive_group_threshold
  && now <= retention_end

ArchiveProviderPayment(epoch) =
  floor(epoch_service_principal * accepted_service_weight /
        max(1, total_accepted_service_weight))

An unavailable or corrupt provider loses the failed epoch payment and may be slashed only through an objective challenge. The policy spends slashed bond first on replacement storage and challenger cost. During a 30-day replacement window, the certificate is DEGRADED and the interface names the missing threshold; if reconstruction remains impossible, it becomes LAPSED, stops availability claims, and returns any refundable unused service principal to its recorded beneficiary. Governance may renew retention before expiry but cannot rewrite a lapsed interval as available or use one provider under several names to satisfy independence. Once mandatory retention ends, anyone may continue hosting the bytes, yet the protocol claims only integrity commitment unless a new funded certificate is active.

LOGIC MAP 40

13.3 Observation, finality, and data availability

Important properties follow:

• An animation does not prove a transaction.
• A Guardian message does not prove ownership.
• An active Guardian registry record does not prove endpoint liveness or wallet control.
• A valid NCM payload does not prove who owns it.
• A matching semantic hash does not excuse the registered verifier from enforcing the dependency root, format, and expansion bounds.
• A successful program instruction proves only the transition and accounts it validates.
• An immutable configuration account does not prove that its owning program is non-upgradeable.
• A deployed program-byte hash proves which bytes were observed, not that published source reproduces them; reproducibility requires the source commit, toolchain, build recipe, and a matching independent build.
• A normal JSON-RPC response is an operator-provided observation, not a cryptographic proof of Solana consensus.
• A content hash proves the integrity of available bytes, not their continued availability.
• Proof of Useful Work never grants the miner custody of the optimized asset.
• Cryptographic commitments rely on the collision and preimage resistance of the registered hash function; verifier upgrades use a new domain and version.

13.4 Program upgrades and reproducible builds

Configuration immutability and executable immutability are separate. An independent verifier checks loader owner, ProgramData address, deployed byte hash, and upgrade-authority option. Governance controls an upgrade only when the loader authority is a constrained governance PDA and the executed proposal names the exact artifact hash.

A reproducible release publishes source commit, dependency locks, compiler and Solana toolchain versions, build container digest, features, flags, environment assumptions, artifact normalization, and hashing rule. At least two independent builders produce the same deployable byte hash before an upgrade exits timelock. If an upgrade authority remains, it remains a disclosed trust assumption.

13.5 Emergency recovery invariants

Emergency controls are domain-specific and fail closed. They may stop new risk; they may not rewrite accepted history, seize custody, bypass vote totals, enlarge supply, redirect isolated reward budgets, or make relay data durable. Recovery creates a versioned remediation proposal and receipt, preserves affected account commitments, and offers deterministic claim or migration paths.

The following invariants hold even during recovery:

NCK_supply <= S_cap
genesis early-player allocation + treasury allocation = exact genesis supply
one owner creation -> one active Profile, NameIndex, Appearance and verified SpawnReceipt
one ItemId -> exactly one non-consumed custody state
accepted output mass + explicit losses = consumed input mass + added reagent mass
one ActionId -> at most one value-bearing effect
one ReleaseLotId -> at most one reward principal and one NCK-or-SOL claim
finalized vote totals = sum of unique snapshot-scoped VoteReceipts
active building -> complete payload + dependencies + material commitment available
Guardian message -> never sufficient for durable ownership or custody
prepaid archive principal -> unavailable to treasury until service or refund settles

14 · SCALABILITY AND PERFORMANCE MODEL

14. Scalability and performance model

NiceChunk scales by assigning different work to the layer that can perform it without weakening authority.

14.1 Partitioning and contention

World mutation partitions by Chunk PDA; inventory by owner Backpack page; materials by lot; buildings by BuildSite and manifest; markets by listing; Guardian settlement by Region and epoch; governance votes by VoteReceipt plus deterministically sharded tally accumulators; PoUW liabilities by policy shard. Global roots are read-only in ordinary play.

Shard selection is deterministic from the primary identity hash, so a caller cannot select a less-contended shard with different accounting. Shard caps sum to no more than their global cap. Cross-shard settlement proves aggregate roots without requiring one globally writable account on every action.

14.2 Reconstruction budgets

Chunk.js performs canonical world and asset reconstruction. Workers decode, expand, bake deterministic lighting inputs, build greedy meshes, and return transferable packed buffers. Visible-face meshing, frustum culling, distance budgets, texture arrays, instancing, and bounded LRU caches reduce frame cost without changing canonical collision or occupied cells.

Each asset publishes a deterministic cost vector:

Cost = (
  persistent_bytes,
  account_count,
  decode_commands,
  expanded_writes,
  unique_cells,
  working_memory_units,
  dependency_reads
)

Protocol limits apply before allocation and during expansion. Device wall-clock time, FPS, GPU model, and network latency are benchmark metadata, not consensus values. Releases include desktop and mobile benchmark envelopes with device, browser, viewport, scene, trace window, and source revision.

14.3 State compaction without semantic loss

Receipts are retained at the granularity required for replay protection, ownership, liabilities, and audit. Repetitive records may be checkpointed into Merkle accumulators only after a challenge window and only when claimants retain proof paths or can regenerate them from available data. Compaction never merges unrelated liabilities or removes the bytes needed to claim an asset.

This architecture does not claim storage or compute is free. It makes costs attributable, prevents computable emptiness from becoming permanent state, and rewards reductions that can be measured without making someone else's client pay an undisclosed bill.

15 · RISK AND CONTROL FRAMEWORK

15. Risk and control framework

No persistent on-chain world is risk-free. “Decentralized” is an architecture property, not insect repellent.

16 · TECHNICAL PROTOCOL PROFILE AND CONFORMANCE

16. Technical protocol profile and conformance

16.1 Canonical limits

Limits are part of format or policy roots. Raising one changes account, verifier, proof, memory, and client assumptions and therefore requires a new versioned domain. Chain and Chunk.js limits for canonical dimensions MUST agree exactly.

16.2 Canonical serialization rules

Unless a format says otherwise:

• integers are fixed-width little-endian and range-checked;
• variable integers use the shortest unsigned LEB128 encoding and reject redundant groups;
• strings are length-prefixed UTF-8 under their named normalization profile;
• lists are length-prefixed and ordered by their schema, or explicitly sorted by canonical key;
• optional values begin with 0 or 1; no other tag is valid;
• public keys are 32 raw bytes;
• hashes are 32 raw SHA-256 bytes;
• arithmetic uses checked fixed-width integers and stated floor or ceiling rules;
• unknown enum values, duplicate map keys, trailing bytes, and overflow reject.

Every domain publishes golden bytes, hashes, and rejected vectors. SDKs are generated from the schema and compare interface commitments in CI.

16.3 Version, deployment, and upgrade invariants

LOGIC MAP 41

16.3 Version, deployment, and upgrade invariants

Every durable account has an owning program, magic or discriminator, layout version, and deterministic address relationship. Every PoUW task additionally pins its network, owning program, codec, verifier, dependency root, reconstruction-policy root, and reward-settlement-policy root. Semantic, metering, or reward-policy upgrades publish new hashes and evidence, activate a new version, and migrate assets or open tasks explicitly; they do not change the meaning, cost rules, or reward rights of already accepted tasks in place.

Configuration immutability and executable-code immutability are separate claims. An external verifier checks the Solana loader owner, ProgramData relationship, current upgrade-authority option, and deployed program-byte hash. If an upgrade authority exists, compromise or unilateral use of that authority remains a trust assumption even when GlobalConfig itself has no update instruction. A governance vote or registry receipt proves control of the loader only when the actual upgrade path enforces that relationship.

A matching deployed byte hash identifies one observed executable. It does not prove source correspondence. A reproducible-build claim additionally publishes the source commit, dependency locks, compiler and Solana toolchain versions, build flags, environment assumptions, and canonical artifact-hashing rule, then obtains the same deployed byte hash from an independent build.

16.4 Whole-system conformance matrix

An implementation is conforming only when each durable transition defines and tests all columns:

“The UI prevents it” is not a valid answer in the Authority column.

16.5 Independent verification checklist

An independent client or indexer begins every verification by:

1. declaring the trust mode: independently operated validator, named trusted provider, or named provider comparison;
2. obtaining genesis hash, slot, blockhash where available, commitment, and observation time;
3. computing NetworkId and checking Core, GlobalConfig address, owner, layout, and sealed fields;
4. verifying NCK mint owner, decimals, supply ceiling, and absent mint and freeze authorities;
5. resolving ProtocolVersionRoot and every domain root required by the claim;
6. inspecting each involved program's loader, ProgramData, deployed byte hash, upgrade authority, source commit, and reproducible-build evidence;
7. deriving every critical PDA and checking owner, layout, network binding, status, authority, revision, nonce, custody, and capital policy;
8. recomputing canonical action, asset, material, tally, proof, or settlement roots from exact bytes;
9. checking every source, destination, escrow, output, receipt, liability, and close-beneficiary relationship; and
10. reconciling transaction status, meta.err, fee, transfers, and post-state at the required commitment.

A durable building additionally requires foundation geometry, contribution escrow, bill of materials, manifest and ordered shard checks, payload hash, codec limits, DependencyRoot, placement, cost vector, and active revision.

A PoUW migration adds nine checks: the TaskId names the prior active bytes; the task, verifier and proof use the same DependencyRoot; the task, proof and receipt use the same ReconstructionPolicyRoot; the task and receipt use the same RewardSettlementPolicyRoot; the capital policy permits PoUW and remains protected; old and candidate semantic roots match under the pinned verifier; the candidate cost vector passes absolute and relative limits; cumulative credit remains below the asset's lifetime ceiling; and the release lot, escrow, byte, and lamport accounting match the accounts closed or resized.

16.6 Deployment identity and feature evidence

A public label such as “active,” “verified,” or “on-chain” is a discovery aid, not proof by itself. A third party can scope a protocol claim only after five evidence families agree: observation context, network identity, program provenance, account provenance, and feature-policy identity.

LOGIC MAP 42

16.6 Deployment identity and feature evidence

This check does not declare an entire application trustworthy. It establishes the maximum defensible statement about one observed deployment and one state transition. Finality-sensitive consumers repeat the account read at their required commitment and through their declared trust mode before treating the result as settled.

16.7 Time-scoped evidence snapshots

An evidence publisher can make one observation reproducible without pretending that a hash authenticates its source:

ObservationId = SHA256(
  "NCK/OBSERVATION/v2" || EncodeObservation(
    NetworkId, slot, blockhash_option, commitment, observed_at,
    account_set_root, program_provenance_root, feature_registry_root
  )
)

The evidence bundle includes the exact account bytes or content-addressed objects, full addresses, data lengths, owners, source endpoints or validator method, schema versions, hashing rules, and any errors or unavailable records. ObservationId makes alteration detectable; it does not turn an untrusted observation into consensus truth. Verification strength comes from reproducing the observation against the disclosed ledger trust mode.

16.8 Primary specifications

• NiceChunk technical field guide
• Program interfaces and account domains
• Proof of Frontier
• NCM DNA compression laboratory
• Canonical English whitepaper source
• Solana program-derived addresses
• Solana accounts and rent
• Solana commitment status
• Solana getAccountInfo