A public voxel world should be inspectable before it asks for trust.

Why It Matters

NiceChunk is not asking users to believe a black box.

The project value comes from making a playable voxel world whose important rules can be inspected, repeated, and gradually moved into verifiable on-chain systems.

Verification Model

Trust is built from public inputs and repeatable checks.

NiceChunk should be reviewed as a layered verification system: deterministic generation, explicit state commitments, wallet-signed transitions, and visible boundaries where off-chain systems still participate.

Evidence Map

What a reviewer can inspect today.

This page points reviewers to concrete surfaces instead of vague promises: source modules, contract pages, generation demos, and stated limitations.

Independent Review Package

A serious protocol should make due diligence portable.

Auditors, investors, and engineers should be able to collect a compact review package: source paths, deployment manifests, account layouts, replay fixtures, failure cases, and disclosure notes.

Reviewer Packet Blueprint

The next audit step is a versioned packet, not another pitch document.

This blueprint defines what NiceChunk should publish for independent review: the exact source snapshot, deployment data, account decoders, generation fixtures, adversarial tests, and maturity disclosures tied to a release.

Source & Artifact Map

A reviewer should be able to move from claim to source path.

This map indexes the current code and data surfaces that support NiceChunk's trust story. It is not a formal audit, but it reduces ambiguity for engineers who want to inspect the system directly.

Protocol Registry

The trust surface is a set of programs, accounts, seeds, and invariants.

This registry makes the current Solana surface easier to inspect. It lists the program domains, PDA seeds, account magic bytes, versioned account sizes, and the questions a reviewer should ask before treating the system as economically reliable.

Deployment Evidence Ledger

Program IDs are only the first layer of deployment trust.

A serious review compares website registry values against source paths, SDK constants, on-chain owners, account layouts, deployment slots, and future binary hashes. This ledger separates what is visible today from what still needs a signed release manifest.

Account Decoder Evidence

Public account state should be readable without trusting the UI.

NiceChunk account data is most credible when reviewers can decode raw bytes, verify magic and version, check owner and PDA assumptions, then compare the decoded state against the website and wallet transaction history.

Audit Methodology

A fair on-chain game should be reviewed like a reproducible system, not a pitch deck.

NiceChunk's review standard is intentionally concrete: identify public inputs, replay deterministic functions, inspect authority, test failure cases, and separate implemented contract behavior from design intent.

Audit Scope Matrix

The review surface must be explicit before any security claim is meaningful.

NiceChunk separates contract correctness, deterministic generation, economy settlement, client disclosure, and operational availability. Each surface needs its own evidence and its own exclusions.

Threat Model

Trust improves when the project states what can go wrong.

NiceChunk should be evaluated against concrete adversaries: dishonest clients, stale generated data, duplicated resources, unavailable regions, misleading UI claims, and settlement mismatches.

Protocol Invariants

The protocol should be judged by invariants that survive UI changes.

An invariant is a rule that should remain true across clients, languages, UI redesigns, and future market features. These are the checks NiceChunk should keep visible as the system matures.

Verification Recipes

Reviewers should be able to reproduce the claim, not just read it.

These recipes turn the trust model into concrete review work: collect public inputs, run a replay or account decode, compare expected state, and document any mismatch as an implementation or disclosure issue.

Adversarial Test Matrix

A fair game economy is proven by the failures it refuses to accept.

Happy paths show that a feature works. Adversarial paths show whether the economy resists duplication, unauthorized mutation, stale state, wrong custody, and misleading UI confirmation.

Formal Fairness Model

The world should be evaluated as a deterministic state transition system.

For a public on-chain game, fairness is not a slogan. It is a set of observable inputs, deterministic functions, authenticated transitions, and explicit assumptions that can be challenged by reviewers.

Verification Notation

The core game loop can be described as public inputs plus constrained transitions.

This notation is intentionally readable rather than academic theater. It gives auditors a shared vocabulary for generation, mining, backpack custody, market settlement, and guardian availability without pretending every planned proof is already complete.

State Lifecycle

A mined block should carry its history from seed to wallet-owned inventory.

NiceChunk's resource design is strongest when reviewers can follow one block across generation, mining validation, backpack storage, and future settlement without relying on a hidden inventory server.

State Commitment Model

Not every voxel needs to be stored, but every economic claim needs a public anchor.

NiceChunk's storage model should be reviewed by separating canonical account state, deterministic recomputation, client cache, and planned proof surfaces. This makes the protocol cheaper without hiding what matters.

Data Availability & RPC Assumptions

A public game still depends on how quickly players can read public state.

Reviewers should distinguish canonical Solana account state from RPC access, browser cache, guardian relay, and generated local data. Availability failures should degrade clearly instead of changing economic truth.

Economic Integrity

The game economy should expose custody, currency, and settlement assumptions.

NiceChunk's economic layer is easiest to trust when NCK parameters, marketplace state, backpack ownership, guardian staking, and unfinished settlement assumptions are visible instead of hidden behind UI copy.

Reviewer Routes

Three clean paths through the project.

A serious reviewer should not have to guess where to start. These routes connect the project thesis to specific pages and the evidence each page is meant to provide.

Claims Ledger

Every serious claim needs a status, evidence, and boundary.

This ledger is written for reviewers who need to separate implemented systems from design intent. It keeps the project honest while showing why the technical direction matters.

Proof Maturity Timeline

A trust claim should mature from visible design to reproducible proof.

NiceChunk treats public trust as a staged engineering target. The timeline below separates what is visible today from the evidence required before a feature should be considered protocol-grade.

Upgrade & Governance Posture

Rule changes must become visible before they become political.

The system is still evolving, so the honest question is not whether governance is finished today. The question is how rule versions, program upgrades, policy constants, and future voting paths will be disclosed and constrained.

Trust Boundaries

Clear boundaries are more credible than maximal claims.

NiceChunk should be judged by what is implemented, what is verifiable, and what is still planned. The website must avoid claiming full decentralization before every critical system is decentralized.

Risk Register

A credible protocol names the risks it has not eliminated yet.

The project is stronger when unfinished trust assumptions are visible. This register frames current technical risks, why they matter, and what evidence should reduce them over time.

Open Review Questions

The strongest version of NiceChunk is the one that invites hard questions early.

These questions are not marketing objections. They are the engineering and economic questions that should remain visible until the project has stronger evidence, production deployments, and independent review.

Review Checklist

A practical path for independent review.

A high-trust Web3 game should give reviewers a route through the code, rules, demos, and limitations without forcing them to reverse-engineer the whole website.

For Reviewers

Different reviewers need different proof.