ABSTRACT
A world that can grow without storing every untouched block
NiceChunk is a persistent voxel-world protocol built around a simple division of labor: deterministic software reconstructs what can be computed, while Solana stores what must be owned, changed, governed, or independently verified.
A conventional online world asks one operator to hold the map, the inventory, the rules, and the history. Putting that entire workload on-chain would replace one bottleneck with another. NiceChunk instead derives untouched terrain from public world inputs, records player-created deltas in program-owned accounts, and uses NCM codes to describe reusable geometry compactly. Guardian nodes carry nearby realtime activity without becoming the authority for assets or settlement.
The result is a shared world that remains responsive at the edge and verifiable at its durable boundaries. Players create persistent state; miners search for shorter NCM representations that preserve the same typed state under the same dependency root; successful Proof of Useful Work reduces the storage burden without exporting reconstruction cost and converts measured efficiency into NCK rewards.
Compatible clients can calculate the same untouched landscape. The chain anchors current ownership and accepted changes, while receipts commit transition history. Realtime nodes help players see one another. Useful-work miners reduce the bytes needed to reconstruct current state within a pinned cost policy.
A short vocabulary
- Canonical state
- The one protocol-accepted meaning of an asset or world record at a specific revision.
- Chunk.js
- The registered runtime that reconstructs protocol geometry, material semantics, and collision.
- NCM
- Bounded model data interpreted by a registered codec, never imported executable code.
- PDA
- A Solana account address derived from public seeds and its owning program.
- NetworkId
- A commitment to one Solana genesis hash, Core program, and GlobalConfig PDA.
- DependencyRoot
- A commitment to the material, shape, physics, and runtime semantics required to interpret an asset.
- ReconstructionPolicyRoot
- A commitment to deterministic cost meters, absolute ceilings, and permitted relative regressions.
- RewardSettlementPolicyRoot
- A commitment to reward mint, treasury routes, oracle guards, liability-shard scheme, caps, and fallback behavior before mining begins.
- Observation context
- The source, cluster, slot, blockhash, commitment, and time behind an account read.
- Storage payer
- The signer that funds a program account without receiving wallet-like control over its lamports.
- Capital policy
- The creation-time rule for PoUW eligibility and the beneficiary of eligible storage surplus.
- Guardian
- A regional realtime relay that improves presence without creating ownership.
- Mining
- Resource extraction, frontier proof, and compression proof are separate actions with separate authority.
01 · PROTOCOL THESIS
Compute the common world. Settle the uncommon change.
Persistent worlds face a three-way tension. Players expect immediate interaction, shared state must be independently checkable, and the cost of storing an expanding universe must remain bounded. NiceChunk resolves this tension by refusing to treat every byte as the same kind of truth.
Reconstruct first
Public seeds, coordinates, rules, and model bytes produce repeatable results.
Settle narrowly
Each program validates one bounded state transition and owns its records.
Relay without authority
Guardian carries low-latency presence while chain programs remain authoritative.
Compress continuously
Useful work pays for provable reductions in persistent geometric state.
02 · ARCHITECTURE
Four systems cooperate without pretending to be one
The browser, Chunk.js, Guardian, and Solana answer different questions. The browser asks what the player is doing now. Chunk.js asks what visible geometry follows from accepted inputs. Guardian asks which nearby activity should arrive quickly. Solana programs ask whether a specific shared transition is authorized and valid.
The NiceChunk trust and data map
03 · DETERMINISTIC WORLD
A coordinate is a question, not a stored cube
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 therefore does not need an account for every naturally generated block.
Player-created facts are layered over that answer. A mined coordinate, a protected foundation, a building manifest, or a governed rule changes what the client should reconstruct. The base world and its deltas remain separate, making the cost of state proportional to meaningful change rather than theoretical world size.
Deterministic reconstruction with validated deltas
04 · ACTION SETTLEMENT
Fast feedback and durable truth travel on different paths
A player should not wait for a block time before a tool moves. The client therefore handles aiming, reach, collision, animation, and reversible feedback immediately. A supported shared action is then expressed as a bounded instruction containing integer coordinates and the accounts required by its program.
The program recalculates the facts it can verify, checks signatures and PDA ownership, applies all writes atomically, and rejects the whole instruction when a required check fails. The client reads the affected records again and reconstructs the result. Guardian may tell nearby players that an action is happening, but that message is never promoted into settlement evidence.
One action, two latency paths, one durable outcome
05 · SOLANA PROGRAM ARCHITECTURE
There is no single all-powerful world account
NiceChunk is divided into native Solana programs with narrow responsibilities. Each program owns predictable PDA families and validates only the state transitions in its domain. A profile cannot rewrite terrain. A Guardian endpoint cannot transfer an item. A rendering result cannot authorize a marketplace sale.
Program ownership and account domains
06 · IDENTITY, SESSIONS, AND CUSTODY
The owner key defines authority; session keys bound routine play
A player profile 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 inside a browser save file.
For frequent actions, the owner can authorize an expiring PlayerSession. The session record binds a temporary signer to the owner, a GlobalConfig, an action mask, and an expiry. Consuming programs repeat those checks. This reduces repeated wallet prompts without turning the temporary key into the owner of the player's identity.
07 · RESOURCE AND PRODUCTION ECONOMY
Resources move through verifiable transformations
World resources begin as generated coordinates or governed surface objects. Mining verifies that 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, quality, grade, and durability fields. Forging uses those materials to create compact equipment recipes; building consumes compatible materials and NCM instructions to create persistent structures.
The resource loop and its verification gates
08 · NCM VERIFIABLE ASSETS
Geometry becomes a compact, deterministic instruction set
NCM is NiceChunk's 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 applies bounded structural validation for shared buildings. NCM4 extends character reconstruction with explicit bones and actions. NCF1 carries compact forged-equipment reconstruction data.
A building is not uploaded as executable code. Its bounded payload is validated, hashed, divided into deterministic shards, and activated through a manifest only when every required byte is present. A compatible client derives the manifest, reads the shards, verifies their commitments and dependency root, and asks the registered Chunk.js runtime to build canonical geometry, material semantics, and collision from the payload.
NCM publication and independent reconstruction
Determinism is scoped to protocol outputs. Compatible implementations agree on occupied cells, material semantics, transforms, and collision. Texture resolution, accessibility settings, lighting quality, browser, and GPU can still change pixel output when those presentation choices are not committed as consensus state. NiceChunk therefore claims protocol-equivalent reconstruction, not pixel-identical screenshots.
09 · PROOF OF USEFUL WORK
Mining that makes the world lighter
Player creation expands the canonical world. Proof of Useful Work turns computation into a continuous counterforce: miners discover shorter NCM programs that reconstruct exactly the same accepted geometry under the same pinned dependencies.
NiceChunk's useful-work market is an application-layer optimization protocol. It does not replace, extend, or secure Solana consensus. A miner selects eligible NCM state and searches for a shorter encoding that preserves exactly the same protocol-defined meaning under the registered dependency root.
9.1 Target identity and semantic equivalence
Every task binds the network, world, owning program, asset class, asset PDA, active revision, active encoding hash, codec, verifier registry entry, semantic dependency root, reconstruction-cost policy, reward-settlement policy, and creation-time capital policy. The verifier decodes both representations into one typed canonical state. For NCM3, later commands overwrite earlier commands. The canonical serialization contains its domain tag, three little-endian u16 dimensions, a u32 occupied count, and final (x, y, z, material_id) u16 tuples sorted by (y, z, x). DependencyRoot fixes what accepted material IDs and shape operations mean. Owner, position, rotation, collision policy, protection relationships, and capital policy form a separate versioned commitment that compression cannot change.
Every commitment uses a registered binary schema with fixed-width or length-prefixed fields. The || notation below means schema-defined byte concatenation, not ambiguous concatenation of display strings.
NetworkId = SHA256("NCK/NETWORK/v1" || EncodeNetwork(solana_genesis_hash, core_program_id, global_config_PDA))
DependencyRoot = SHA256("NCK/DEPENDENCIES/v1" || EncodeDependencies(material_registry_id+hash, shape_registry_id+hash, physics_schema_id+hash, runtime_abi_id+hash))
ReconstructionPolicyRoot = SHA256("NCK/RECONSTRUCTION_POLICY/v1" || EncodeReconstructionPolicy(meter_id+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+hash, quote_freshness, max_slippage, minimum_output_rule, settlement_bucket_count, bucket_cap_allocation_root, reservation_caps, execution_caps, fallback_mode))
TaskId = SHA256("NCK/POUW/TASK/v3" || EncodeTask(NetworkId, world_id, owning_program_id, asset_class, asset_PDA, revision, encoding_hash, codec_id, codec_version, verifier_id, DependencyRoot, ReconstructionPolicyRoot, RewardSettlementPolicyRoot, capital_policy_id))
SemanticRootv(b) = SHA256(domainv || DependencyRoot || CanonicalStatev(Decodev(b)))
Equivalent := same SemanticRoot AND same DependencyRoot AND same ProtectedRoot
The Solana genesis hash prevents cross-cluster replay. Core and GlobalConfig distinguish deployments on one cluster, while the owning program distinguishes identical PDA seed bytes in separate account domains. NetworkId is never caller-defined: task creation compares it with the network domain compiled into or stored by the verified deployment. Runtime configuration, an RPC URL, a token symbol, or a website label can discover these identities but cannot replace on-chain checks.
NCM4 and forged equipment use their own typed state and dependency schema, including the protected rig, action, attachment, collision, and durability fields relevant to those assets. A changed dependency hash creates a new interpretation domain, while a changed meter or regression cap creates a new reconstruction-policy and task domain. A changed mint, route, oracle, cap, or fallback creates a new reward-policy and task domain. Equality of voxel tuples across different roots is not equivalence. The roots commit to deterministic comparison; they do not permit a client-calculated hash or matching screenshot to replace the registered verifier.
Compression proof, equivalence, and migration
9.2 Submission, replay, and front-running defenses
A miner first commits to SHA256("NCK/POUW/COMMIT/v1" || EncodeCommit(TaskId, candidate_hash, miner, salt)). EncodeCommit is a registered canonical binary schema. After the minimum reveal delay and before expiry, only that miner can reveal the bound candidate. Finalization repeats the active revision and encoding-hash checks. An owner can keep using or revising an asset while search continues, but a revision change makes the old task stale and unable to migrate or earn a reward.
Commit-reveal, concurrent edits, and one reward receipt
The protocol rejects consumed commitments, duplicate candidate hashes, and candidates no smaller than the active representation. A governed proof bond covers bounded verification and cleanup. Per-asset queues, per-miner limits, expiry, and minimum savings stop cheap candidate spam from becoming a new state-growth attack.
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 asset owner receives program-defined game rights, and the program owns the account data. None of those roles alone creates a general withdrawal right.
PoUW never guesses a release right from a wallet address. An account class is eligible only when its creation-time state or inherited GlobalConfig commits to a versioned CapitalPolicyId. The policy fixes the eligible account class, release beneficiary, reward ceiling, minimum age, cumulative accounting, and payer disclosure. It is pinned by TaskId and ProtectedRoot, so a miner cannot change it.
Funding, asset rights, and storage-surplus routing
The NiceChunk policy sends eligible surplus to a dedicated PoUW treasury. Funding an eligible active account pays for durable protocol storage; it is not a promise that the original payer can reclaim the same lamports. This is not retroactive. Accounts with a payer-refund path or no PoUW policy retain that lifecycle unless an explicitly authorized opt-in migration succeeds. Pending building uploads remain outside PoUW, and cancellation keeps its existing recipient.
9.4 Value conservation and anti-self-dealing
Banning an owner from mining its own asset would be cosmetic because another wallet can be used. NiceChunk makes self-dealing uneconomic in the value ledger instead. Baselines must be active for a minimum age, have no pending revision, and use bounded canonical syntax. Every asset carries its first eligible layout, cumulative released bytes and rent, prior receipts, and cooldown.
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 · fixed proof bonus = 0
Splitting one improvement across many receipts cannot increase the lifetime ceiling. Proof bonds, donated lamports, unrelated treasury balances, token appreciation, and bytes already credited are never storage savings. The same compact encoding can earn on different assets only when each migration independently releases real bytes; it cannot earn twice for one task or capital lot. Sybil wallets do not change these rules.
9.5 Atomic migration and actual lamport release
Candidate shards may be staged, but staging never changes the active pointer. Finalization atomically rechecks the task, activates the candidate, preserves owner and asset relationships, closes obsolete shards, transfers eligible surplus lamports, and writes a receipt. If any step fails, the old representation stays active.
Shrinking a Solana account with realloc does not automatically release
excess lamports. The owning program must transfer the post-shrink surplus, or close
obsolete program-owned accounts and transfer their balances to the PoUW treasury.
DeltaB = sum(data_len before) - sum(data_len after)
RentDelta = max(0, sum rent_min(before) - sum rent_min(after))
EligibleRent = min(RentDelta, lamports actually released)
The calculation includes manifests, headers, shards, receipts, and claim records. Temporary accounts must be closed or counted as overhead. Taking the minimum prevents donated excess lamports from being misreported as compression value.
9.6 Net value and NCK reward settlement
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 = RewardSOLBudget
MinerRewardNCK = NCK actually acquired with RewardSOLBudget after swap costs
The 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 do not increase the reward basis. Slashed proof bonds first cover their own verification and cleanup; they are not EligibleRent and cannot generate 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 that receipt.
If the oracle is unavailable, liquidity is insufficient, or minimum output is not met, the swap pauses. The compressed asset remains active and the fixed SOL budget remains isolated; ordinary treasury spending cannot consume it. The protocol creates no unbacked or uncapped NCK liability. Reward value follows 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: migration finalizes only when the candidate becomes active, the old layout is retired, a unique release lot and receipt are written, and the calculated SOL reward budget reaches receipt-specific escrow in the same transaction. 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 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 in one transaction. 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. The reward policy pins the bucket count and cap allocation, and bucket caps must sum to no more than the global caps. Migration, swap, and claim lock one bucket with the affected receipt and escrow or bucket-vault accounts and update them atomically. This avoids one global writable ledger or token-vault bottleneck without multiplying authorization. Indexers can independently reconcile every bucket from receipts. Extra lamports donated to an escrow never enlarge its receipt-recorded reward principal or the miner's claim.
RESERVED → FUNDED: OutstandingRewardSOL' = OutstandingRewardSOL - ReservedRewardSOL
RESERVED → FUNDED: OutstandingRewardNCK' = OutstandingRewardNCK + AssignedRewardNCK
FUNDED → CLAIMED: OutstandingRewardNCK' = OutstandingRewardNCK - AssignedRewardNCK
The receipt moves only forward. RESERVED means migration is complete and its exact SOL budget, excluding the escrow account's own rent reserve, is isolated. FUNDED means one guarded exact-input swap succeeded and the receipt records the actual NCK vault delta assigned to the miner; that amount is unavailable to every other receipt or treasury action. CLAIMED means that NCK was transferred and the receipt was consumed in the same transaction. Failed guards spend nothing and leave RESERVED; a bad claim destination leaves FUNDED.
State never moves backward. Successful settlement consumes RESERVED, and successful
claim consumes FUNDED, so concurrent executors cannot spend or transfer the same value
twice. The current NCK_ONLY_RESERVED fallback keeps SOL isolated until an
allowed NCK acquisition succeeds, potentially indefinitely if every pinned route remains
unavailable. Any future expiry, SOL fallback, alternate mint, or confiscation rule
requires a new RewardSettlementPolicyRoot and cannot be introduced after miners have
committed work.
Atomic solvency boundary and one-way reward settlement
9.8 Verification backends and proof statement
Every task names a verifier-registry entry committing to the asset class, codec, semantic-schema, dependency-schema, and cost-vector-schema hashes, accepted DependencyRoot, accepted ReconstructionPolicyRoot, bounds, mode, activation window, and either a direct verifier program hash or a validity-proof verification-key hash. Direct mode executes the bounded decoder on-chain. Validity-proof mode accepts an untrusted prover's output only after the registered on-chain verifier checks it against pinned public inputs.
Once activated, a registry entry is append-only and semantically immutable. A pause may reject new tasks or finalizations under that entry, but changing its codec, dependencies, limits, key, or interpretation requires a new identifier and version domain.
PublicInputs = TaskId · VerifierId · DependencyRoot · ReconstructionPolicyRoot · ActiveEncodingHash · CandidateEncodingHash · SemanticRoot · ProtectedRoot · ActiveCostVector · CandidateCostVector
bounded_decode(active) = bounded_decode(candidate) = SemanticRoot
Meter(active) = ActiveCostVector.decode · Meter(candidate) = CandidateCostVector.decode
DecodeCostPolicyPass(ReconstructionPolicyRoot, ActiveCostVector.decode, CandidateCostVector.decode)
all registered format and expansion limits must hold
Two proof backends, one semantic and cost statement
The proof meters decoder-owned dimensions but never decides ownership, release rights, rent, or reward. The owning program derives addresses, hashes actual bytes, rechecks TaskId, DependencyRoot, ReconstructionPolicyRoot, RewardSettlementPolicyRoot, and ProtectedRoot, verifies both account layouts and their cost-vector fields, and performs the migration. Both modes pass the same semantic and metering vectors. A paused, expired, or unsupported verifier causes rejection, not fallback to an administrator signature.
9.9 Deterministic resource accounting and anti-externalization
Fewer stored bytes do not automatically mean cheaper reconstruction. A short sequence of overlapping cuboids can perform more intermediate voxel writes than a longer direct encoding, while extra accounts, dependency reads, or working memory can move cost from storage into every future reconstruction. PoUW rejects that transfer.
Each verifier version uses an integer-only deterministic meter. Wall-clock time, browser frame rate, GPU timing, network latency, and miner-provided benchmarks vary by device and are never consensus inputs. The owning program measures real layout fields; the registered verifier meters decode fields.
LayoutCostVector = (layout_data_bytes, layout_account_count)
DecodeCostVector = Meter(bytes) = (command_count, expansion_ops, peak_working_units, dependency_reads)
CostVector = (LayoutCostVector, DecodeCostVector)
for every protected i: candidate[i] ≤ absolute_limit[i] AND candidate[i] ≤ active[i] + relative_regression_cap[i]
active.layout_data_bytes - candidate.layout_data_bytes ≥ minimum_layout_byte_delta
For NCM3, expansion operations include writes later overwritten by another command. Working units follow the registered verifier machine, not a JavaScript heap layout. Every field uses a registered fixed width and checked arithmetic; overflow, saturation, or an unknown dimension fails closed. A policy can allow a small disclosed trade-off, but changing its meter or caps creates a new task domain. Rewards still follow eligible rent actually released; claimed latency or bandwidth improvements cannot enlarge them.
Useful compression cannot export reconstruction cost
9.10 Two useful-computation markets
Proof of Frontier proves an eligible world-frontier target. Proof of Useful Work revisits accepted state and removes avoidable bytes. Neither is Solana consensus, and neither authorizes an in-world resource reward by itself.
9.11 Economic flywheel
The useful-work economic flywheel
The reconstructed state remains the same under one pinned dependency set.
Net allocated bytes fall after proof and migration costs are counted.
Compression never changes the asset owner or grants the miner custody.
Rewards follow completed state reduction, not an off-chain estimate.
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 NETWORK
Regional presence without a hidden world authority
Guardian regions are discoverable through deterministic on-chain records. A client derives the regions around its position, reads active endpoints, verifies their bounded metadata, and attempts a low-latency connection. The relay coalesces nearby movement, chat, equipment presentation, action cues, and building announcements within a region.
Guardian messages are intentionally ephemeral. Sequence checks, spatial bounds, rate limits, and message schemas protect the relay, but persistent assets still require the relevant Solana program. A client can lose a Guardian connection and continue to reconstruct the canonical world from public inputs and on-chain records.
An active Region PDA proves registry acceptance, not endpoint reachability, current TLS control, or honest operation. Reachability requires a live handshake. A wallet identifier inside a relay frame is only a claimed presentation identity unless the session verifies a wallet-signed challenge; neither form can authorize custody or durable state.
Regional discovery, realtime relay, and settlement boundary
11 · NCK ECONOMY AND MARKET
NCK coordinates access, settlement, and useful work
NCK is the native utility asset of the NiceChunk economy. The genesis configuration accepts six decimals and a genesis issuance ceiling of one billion NCK. The mint has no continuing mint authority and no freeze authority, making the non-inflationary boundary directly inspectable rather than dependent on an administrative promise. Holder burns can reduce observed supply below that ceiling.
S_cap = 1,000,000,000 × 10^6 base units
0 <= S(t) <= S_cap
The symbol NCK does not establish token identity. An independent client verifies the NetworkId, GlobalConfig mint address, legacy SPL Token program owner, six decimals, initialized state, disabled authority options, and current supply at or below the cap.
NCK connects economic activity that originates inside the world: protocol access, Guardian participation, marketplace settlement, civilization coordination, and Proof of Useful Work rewards. The marketplace escrows exact item records rather than a visual category label. Purchase and delivery occur atomically in NCK or SOL, with fees and destinations validated by the relevant program accounts.
A non-inflationary ceiling does not mean fixed market value, guaranteed liquidity, or guaranteed rewards. Protocol revenue and PoUW rent release remain separate accounting sources. Ordinary fees follow their configured destinations; PoUW can reward only a migration receipt backed by its own eligible net value. Treasury balances, token price changes, and unrelated deposits cannot be counted as a miner's byte savings.
NiceChunk does not treat token ownership as ownership of every world state transition. Program-specific authorization, item custody, session scope, and rule lifecycle remain separate checks.
12 · CIVILIZATION RULES
World rules become addressable records with an execution trail
Civilization governance separates a proposal's text and target from signatures, power snapshots, tallies, execution, and the target program's resulting state. This matters because a passed vote is not itself proof that a resource table or recipe changed. The target adapter must accept the patch atomically, and an ExecutionReceipt binds the completed rule to that applied transition.
Rule lifecycle with verifiable execution
A parameter update cannot silently reinterpret an old proof. Codec and verifier changes create a new versioned task domain, and active records continue under their pinned version until an explicit migration succeeds.
13 · SECURITY MODEL
Trust is reduced by making every boundary explicit
NiceChunk assumes that a client can be modified, a relay message can be misleading, an RPC provider can return stale, fabricated, incomplete, or censored data, imported model bytes can be malformed, an upgrade authority can be compromised, and economic inputs can be manipulated. Security does not depend on hiding those possibilities. It depends on deciding which component may make each claim and requiring the owning program or deterministic verifier to repeat the relevant check.
Threats terminate at different verification boundaries
NCM decoders enforce limits before allocation and during expansion. Payload length, dimensions, command count, operation budget, output count, and recursion depth where applicable stop a very short input from forcing unbounded memory or compute. PoUW also compares candidate and active cost vectors under the pinned reconstruction policy; remaining below a high absolute maximum is not enough.
Wrong deploymentNetworkId, program IDs, exact PDA derivation, and account owners prevent cross-cluster interpretation.
Upgradeable programLoader, ProgramData, byte hash, and upgrade authority define code provenance separately from account immutability.
Copied or stale proofTaskId, commit-reveal, expiry, uniqueness, and final baseline checks permit at most one miner-bound receipt.
Equivalent-looking modelTyped semantic, dependency, and protected-state roots are checked under the pinned verifier.
Short but expensive modelDeterministic cost vectors, absolute ceilings, and relative regression caps prevent undisclosed reconstruction-cost transfer.
RPC observationNetwork, source, slot, blockhash, commitment, and account checks scope the claim; ordinary JSON-RPC is not a consensus proof.
Historical availabilityActive bytes preserve current reconstruction; receipts preserve transition commitments; exact replay additionally requires old payload bytes.
Manipulated swapRoute allowlist, TWAP bound, slippage, minimum output, and epoch caps produce a bounded trade or no trade.
Replayed or unfunded rewardA unique release lot, receipt escrow, one-way settlement states, and atomic claims permit one fully backed budget and at most one transfer.
Hash assumptionCommitments rely on collision and preimage resistance; a replacement hash uses a new domain and verifier version.
13.1 Dependency-bound equivalence
A material ID is a reference into a registry, not its complete definition. The same integer can produce different collision, transparency, texture-layer, or shape behavior if a client silently changes that registry. PoUW therefore compares both encodings under one pinned DependencyRoot. A changed material, shape, physics, or runtime ABI hash creates a new semantic domain and requires explicit migration.
Dependency-bound equivalence separates protocol state from pixels
13.2 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 requested commitment reports the fork confidence claimed by that operator; neither proves the bytes were honestly returned. High-assurance consumers use independently operated validating infrastructure or verify against separately obtained ledger state. Multiple providers can expose disagreement, but matching providers do not become consensus merely by agreeing.
Every published observation therefore names its genesis hash, slot, blockhash where available, commitment, 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.
Observation confidence and historical availability are separate claims
PoUW may close an obsolete encoding only after an equivalent candidate is active, so current-state reconstruction remains available. A migration receipt preserves old and new commitments, but replaying the exact retired encoding requires separately retained content-addressed bytes. A hash-only receipt is never relabeled as full historical availability.
14 · SCALABILITY
Scale follows from storing differences and optimizing them
The protocol decomposes growth across four resources. Deterministic generation avoids storage for untouched terrain. PDA families isolate writes and allow clients to request only relevant records. Guardian regions localize realtime traffic. NCM compresses geometric assets, while Proof of Useful Work revisits existing state and reduces its future cost.
This architecture does not claim that persistent state is free. It makes the source of each cost visible, avoids paying for computable emptiness, and creates a mechanism that rewards measurable reductions in the state players collectively carry.
15 · RISK AND CONTROL FRAMEWORK
Decentralized does not mean risk-free
NiceChunk treats technical, operational, governance, and market failure as explicit protocol risks. Controls reduce the probability or impact of failure; they do not make failure impossible.
Emergency controls can pause submissions, migrations, swaps, or claims independently. A pause cannot transfer an asset, rewrite its semantic root, or make Guardian data authoritative. Recovery identifies the affected version and leaves an execution receipt.
16 · TECHNICAL REFERENCE
Public limits make independent verification practical
The bounded NCM3 building profile gives every publisher, verifier, miner, and client the same envelope. Initial publication and PoUW candidate verification use the same interpretation; a format is not accepted merely because one browser can render it.
16.1 NCM3 building limits
16.2 Version, deployment, and upgrade invariants
New rules create a new domain; old bytes keep their meaning
Every durable account has an owning program, magic or discriminator, layout version, and deterministic address relationship. Every PoUW task also pins its network, owning program, codec, verifier, dependency root, reconstruction-policy root, and reward-settlement-policy root. Semantic, metering, or reward-policy upgrades open a new versioned domain and require explicit migration; they do not reinterpret accepted bytes, cost rules, or reward rights 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 authority exists, it remains a trust assumption. A governance receipt proves control of upgrades only when the loader path actually enforces that relationship.
A matching deployed byte hash identifies one observed executable; it does not prove that published source reproduces it. A reproducible-build claim also publishes the source commit, dependency locks, compiler and Solana toolchain versions, build flags, environment assumptions, and artifact-hashing rule, then obtains the same byte hash from an independent build.
16.3 Independent verification checklist
- Declare the trust mode: independently operated validator, explicitly trusted provider, or named multi-provider comparison.
- Obtain genesis hash, slot, blockhash where available, commitment, and observation time from that source.
- Compute NetworkId and verify the Core program, GlobalConfig address, owner, magic, layout, and sealed fields.
- Check the Building program loader, ProgramData, deployed byte hash, and upgrade-authority state.
- Derive the BuildSite PDA from the verified GlobalConfig and foundation identity.
- Check account owner, magic, version, site owner, active revision, and bounds.
- Derive the active manifest and every expected shard PDA.
- Check shard order, lengths, completion state, and the manifest payload hash.
- Resolve and hash the codec, material, shape, physics, and runtime dependencies into the expected DependencyRoot.
- Resolve the registered deterministic meter and limits into the expected ReconstructionPolicyRoot.
- Resolve reward mint, route, oracle, settlement-bucket scheme, cap allocation, and fallback commitments into the expected RewardSettlementPolicyRoot.
- Validate NCM3 limits, reconstruct canonical state, check the cost vector, and apply rotation and offsets only from validated fields.
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.4 Deployment identity and feature evidence
A public label such as “active,” “verified,” or “on-chain” helps discovery but is not proof by itself. A third party scopes a protocol claim only after observation context, network identity, program provenance, account provenance, and feature-policy identity all agree.
Five evidence families bound one defensible protocol claim
Finality-sensitive consumers repeat the account read at their required commitment and through their declared trust mode before treating the result as settled. Any executable upgrade changes code provenance and requires the program branch to be repeated.
16.5 Time-scoped evidence snapshots
An evidence publisher can make one observation reproducible without pretending that a hash authenticates its source. ObservationId commits NetworkId, slot, an optional blockhash, commitment, observation time, account-set root, program-provenance root, and feature-registry root.
ObservationId = SHA256("NCK/OBSERVATION/v1" || EncodeObservation(NetworkId, slot, blockhash_option, commitment, observed_at, account_set_root, program_provenance_root, feature_registry_root))
The evidence bundle includes exact account bytes or content-addressed objects, full addresses, data lengths, owners, source endpoints or validator method, schema versions, hashing rules, and unavailable records. ObservationId makes alteration detectable; it does not turn an untrusted observation into consensus truth. Strength comes from reproducing it against the disclosed ledger trust mode.
16.6 Primary specifications
17 · CONCLUSION
The world grows because players create. It lasts because the protocol can refine.
NiceChunk combines a deterministic world, program-owned state, compact geometric assets, regional realtime relays, and useful computation into one persistent civilization substrate.
Players do not need to trust a hidden map server to know what untouched terrain should be. Builders can publish structures that compatible clients independently reconstruct under pinned dependencies. Owners can recover active public records from deterministic addresses. Markets can move exact asset records atomically. Civilization rules can leave hash-linked execution trails. As active geometry accumulates, miners can earn by reducing the bytes required to reconstruct it without changing its protocol meaning or exporting undisclosed reconstruction cost. Each accepted reward is tied to one release lot, one isolated budget, and at most one claim. Historical replay remains an explicit retention claim, not an assumption hidden in a hash.
Computation serves the world when efficiency creates measurable value and every accepted proof leaves the shared universe easier to carry.