NiceChunk Civilization Codex

Codex Entry

Start with the promise, then inspect the proof.

The civilization page is a deep technical document. Use one of the reader tracks, then follow every claim down to the matching hash, PDA, validator, receipt, or rejection reason.

Civilization loop in one view A player action becomes public proof, public proof becomes civic power, and only validated rules can write future config PDAs.

Trust Ladder

A civilization rule should climb six public proofs before it becomes law.

This is the shortest way to judge NiceChunk civilization: a player reads a promise, a reviewer checks the proof object, and the contract rejects the rule if any rung is missing.

Six-rung trust ladder Every rule must move from readable intent to frozen identity, accountable power, deterministic validation, narrow execution, and public receipt.

Term Decoder

The same words should be readable as player promises and technical evidence.

Civilization becomes easier to trust when every important word has two meanings on the page: a plain explanation for players and a concrete proof object for reviewers.

Plain word to proof object map A reader can move from simple language to the exact account, hash, snapshot, validator, or event that proves it.

Plain Model

Civilization is the rule engine above the playable world.

A new player can read it as a public rule book. A technical reviewer can read it as a bounded state machine: hashed proposals, snapshot signatures, validator gates, and config PDA writes.

From player action to world law Every important step leaves a public object or public hash.

Reader Path

A player should know how to judge a rule before signing it.

The civilization page must work as a rule-reading interface, not only a technical manifesto. Every proposal should answer simple player questions and expose the exact evidence experts need to verify the same answer.

From plain question to verifiable proof The same rule should be understandable as a player story and auditable as deterministic state.

Rule Author Workbench

A good civilization system helps ordinary players write safe rules without hiding the machine truth.

The authoring flow should start from a plain player idea, force it through known templates, preview impact, generate a hash-bound machine patch, dry-run the validator, and only then freeze a rule book for signatures.

Idea-to-signable-rule pipeline Players write in plain language, but every published rule must end as a frozen, hash-bound, validator-tested object.

Beginner-to-Auditor Journey

A newcomer should see one continuous path from playing the world to trusting a rule.

The civilization page should not start from abstract governance. It should show how ordinary actions become public evidence, how evidence becomes civilization power, and how that power can approve only bounded, inspectable changes.

New player trust journey A simple player story and the technical proof chain should describe the same world state.

Implementation Boundary

Credibility starts with saying what is live, what is designed, and what is not claimed.

This page is a technical product direction for the civilization system. It separates the current public UI model from the future on-chain governance contract so reviewers can judge feasibility without guessing.

Two Layers of Law

A world constitution and an evolving civilization layer.

Natural Law protects the world from arbitrary authority. Civilization Law lets players evolve production, construction, craft, and society without turning governance into capital voting.

Rule Classifier

The first question is what the rule can touch, not who wants it.

NiceChunk should classify every proposal before signatures count. Future-only configuration can use Civilization Law; old assets, world invariants, supply rules, or privileged paths require Natural Law or immediate rejection.

Rule classification decision tree Classification happens before voting so popularity cannot bypass asset safety or world invariants.

Conservation Ledger

A credible economy must prove where every new output came from.

Resource rules, recipes, forging, smelting, and civic rewards should all pass the same economic invariant: outputs must be backed by generated origin, consumed inputs, versioned transformation, and public receipts.

Resource conservation proof loop A rule can change production only when every output can be traced back to origin, input burn, recipe version, and audit balance.

World-level consensus

Natural Law is not a normal vote.

A Natural Law change must face stronger prompts, stricter validators, longer cooling, and broader challenge windows because it can affect the deepest fairness assumptions of the world.

Civilization Power

Power comes from real participation, not wallet count or raw NCK balance.

The future contract should weight citizens by world participation while limiting abuse through maturity, caps, active windows, decay, and anomaly penalties.

Civilization power is a filtered participation snapshot Participation adds signal; anti-abuse filters reduce noise before voting power is frozen.

Power Snapshot Integrity

Civilization power should be computed like an audit trail, not estimated like a leaderboard.

A credible vote needs a frozen, replayable power snapshot. The system should accept only receipt-backed participation, apply eligibility gates, normalize categories, cap concentration, freeze the epoch, and let anyone recount signatures from public accounts.

Receipt-to-snapshot integrity pipeline Participation becomes voting weight only after receipt checks, normalization, caps, epoch freeze, and public recountability.

Citizen Integrity

Anti-Sybil power comes from public evidence, not private identity.

NiceChunk should not prove humanity by collecting passports or private profiles. It should limit fake power by using public game receipts, maturity windows, category caps, decay, anomaly flags, and challengeable snapshots that any auditor can inspect.

From raw activity to challengeable citizen power Public receipts are filtered, capped, decayed, frozen, and then opened to challenge before they can decide a rule.

Threat Model

A civilization system is credible only if it explains how bad rules fail.

Governance is dangerous when voting can bypass physics, ownership, or transparency. NiceChunk civilization rules should treat every proposal as untrusted until hashes, snapshots, validators, challenge windows, and PDA scopes prove otherwise.

Threat-to-defense map Every dangerous path should meet a visible defense before it can become state.

Challenge Desk

A player needs a public way to stop a suspicious rule before it executes.

Trust is stronger when disagreement has a procedure. A challenge path should show the review window, evidence hash, execution pause, named rejection reason, and final public outcome.

Challenge-to-resolution path A bad rule should move from suspicion to evidence, paused execution, public resolution, and a replayable lesson.

Rule Case Walkthrough

A Bronze Age rule shows how civilization becomes executable code.

This example is written as the coding target for the future civilization program: one player-readable rule, one machine patch, one signature path, one validator result, and one public PDA write.

Bronze Age rule execution map The same proposal moves from player story to machine patch to audited on-chain state.

Rule Impact Simulator

Before signing, a player should see the rule's personal, world, and technical impact.

A trustworthy civilization interface should simulate a proposal before it becomes power: what changes for my backpack, what changes for future production, which PDAs are read, which hashes must match, and why the validator accepts or rejects the patch.

Rule impact simulation path The same dry run should explain player impact, PDA reads, validator gates, and the final sign-or-reject decision.

Before You Sign

A signature should feel like a public commitment, not a blind button press.

The signing screen should prove that the player is signing the same rule text, same machine patch, same frozen power snapshot, same risk summary, and one clear side: agree, reject, or abstain.

Signature safety chain A signature becomes trustworthy when the wallet action, risk acknowledgement, PDA write, and public recount all bind to the same rule identity.

Decision Split

Reject, abstain, and challenge are different tools, not the same kind of no.

A trustworthy governance screen must teach players the difference between support, opposition, silence, and evidence-based blocking. Each action should write a different public meaning while sharing the same rule identity.

Four-way decision routing A player chooses a side for threshold math, but only a challenge with evidence pauses execution.

Civic Power Ledger

Civilization power should come from provable play, not a transferable vote token.

NiceChunk's civilization layer can turn discovery, backpack ownership, forging, settlement work, and audit challenges into a public citizen snapshot. A player sees why their voice counts; an auditor sees the receipts, caps, decay, and replay path behind that power.

Action-to-civic-power pipeline Civilization power is assembled from receipts, normalized into a snapshot, then used only for bounded rule signatures.

Lifecycle

A rule book moves from writing to execution without project-side permission.

Rule Book Structure

Human-readable intent and machine-executable patch stay bound by hashes.

The UI stores mock data locally today. Later these fields can map directly to rule_book_pda, rule_signature_pda, and rule_registry_pda account layouts.

Rule Packet Anatomy

A trustworthy rule is a packet of evidence, not a paragraph of intent.

The future contract should treat every proposal as a sealed evidence packet: readable text for players, machine patch for validators, declared accounts for auditors, frozen power for threshold math, and a receipt path for replay.

Rule packet evidence envelope Each field answers one trust question before signatures, validator dry-runs, and PDA writes can count.

Technical Flow

The contract executes a verified patch, not a vague social instruction.

The human rule explains the intent. The machine patch states exactly which config PDA fields change. The validator rejects unsafe patches before a registry write can happen.

Hash-bound execution path Readers can compare text_hash and patch_hash before signing.

RuleValidator Spec

A civilization rule must pass deterministic gates before it can touch a config PDA.

The validator is the difference between meaningful governance and dangerous voting. It turns a social proposal into a constrained state transition: parse, classify, prove safety, require the correct threshold, then write a narrow result.

RuleValidator gate sequence Unsafe proposals fail before signatures can become executable state changes.

Execution Proof

A rule becomes credible only when its signatures, accounts, and failure paths are inspectable.

This is the bridge between a readable proposal and a trustworthy state change: frozen power snapshots, signature PDAs, deterministic account reads, validator rejection reasons, and a narrow registry write.

Permissionless execution transaction Any caller can execute, but only if the transaction proves the same rule, same snapshot, same hashes, and same expected account state.

Execution Receipt Ledger

After execution, the rule should leave a receipt that players can replay forever.

A trustworthy civilization system does not stop at a green success message. It should publish before-and-after hashes, written PDA addresses, event payloads, rejection reasons, indexer confirmations, and later supersession or challenge references.

Execution receipt accountability chain Success and failure both produce public evidence, so the website, indexer, and skeptical reader can replay the same outcome.

Public Transparency Console

Players should be able to inspect civilization truth without trusting the website.

The future PDA browser should decode the same public accounts that the contract reads: rules, signatures, citizen snapshots, module registries, config PDAs, challenges, and execution events.

Public evidence browser map Every claim on the civilization page should point to a decoded account, event, or rejection reason.

Independent Verification Path

A third party should be able to prove or reject every civilization claim without asking NiceChunk.

The page should teach a skeptical reader how to move from a website claim to decoded PDA ownership, recomputed hashes, signature recounts, validator dry-runs, and final event receipts.

Claim-to-proof verification path A public claim becomes trustworthy only when another reader can independently recompute the same proof chain.

Versioned Evolution

Civilization advances by creating a public version chain, not by erasing old rules.

A credible world needs historical continuity. When a new rule replaces an old one, the registry should preserve old hashes, effective epochs, supersession links, and asset compatibility notes.

Rule version chain A module can advance to a new config without making previous assets or audit trails disappear.

Citizen Role Matrix

Civilization roles should describe public duties, not private authority.

A player can become an explorer, miner, forger, builder, guardian, or auditor through public receipts. Roles explain how a citizen helps the world and which proof object backs that contribution; they should never become hidden admin permissions.

Citizen role-to-proof matrix A role is credible only when it maps to public work, public receipts, public duties, and replayable power inputs.

Civilization Setting Blueprint

The civilization system should become a playable society engine, not only a voting page.

Future coding should treat civilization as the public layer that connects eras, citizens, settlements, production, knowledge, and rule execution. Each design object needs a readable player promise and a decoded PDA anchor.

Civilization gameplay-to-PDA map The page defines the future coding model: player actions create public state, public state unlocks eras, and rules change only bounded config.

Civic Works Loop

Settlements make civilization playable by turning shared work into public state.

A civilization system needs more than rule signatures. It needs cooperative projects where players contribute materials, guardians prove coverage, rules authorize effects, and every benefit can be traced back to public accounts.

Settlement public works loop Materials, citizens, guardians, and rules form one inspectable loop before a settlement receives a benefit.

Codex Build Spec

This page is also the implementation brief for the future civilization program.

Future coding work should implement the smallest trustworthy loop first: publish a hash-bound rule book, sign with frozen civilization power, validate a bounded patch, execute it without a privileged wallet, and expose every PDA in the browser.

MVP Contract Slice

The first civilization contract should be small enough to audit and useful enough to prove the model.

The safest first release is not the whole society engine. It is one narrow loop: publish a frozen rule, sign with snapshot power, finalize a public tally, optionally challenge, execute a bounded config write, then browse every account and event.

First deployable civilization loop A small contract slice proves public authorship, frozen signatures, deterministic rejection, permissionless execution, and decoded PDA transparency.

Feasibility Budget

A civilization contract is believable only if it says what stays small on-chain.

The page should not ask readers to trust a giant on-chain social system. The feasible design stores short hashes, account pointers, snapshots, tallies, and events on-chain; large readable explanations and browser views stay off-chain but are always checked against public hashes.

Civilization state budget map The contract keeps the proof-critical bytes small, while clients and indexers make the same public state readable.

Implementation Trace

Every instruction should leave a replayable audit trail.

The future civilization program should be easy to reconstruct from public data: which instruction was called, which PDA changed, which hash was checked, which event was emitted, and why a rule was accepted or rejected.

Instruction-to-event audit trail A reviewer should be able to replay the same rule from published hash to final config write.

Current Contract Surface

Civilization has to bind to real PDA surfaces, not only ideas.

NiceChunk already exposes concrete account families for world config, resource drops, backpacks, recipes, guardians, and market state. Civilization should govern versioned configuration surfaces around these modules, while preserving old asset safety.

Civilization-to-PDA binding map Future rules should write narrow config PDAs that existing programs can read or that migration validators can safely apply.

Open Contract PDA Browser

Target Modules

Civilization changes the configuration layer, not core code by text command.

Natural Law Examples

Rules that protect the world itself.

Civilization Law Examples

Rules that let civilization advance.

Execution Model

Automatic execution means permissionless execution, not a server changing code.

Once threshold, cooling, and challenge conditions are satisfied, any player can call execute_rule. The contract checks only on-chain state and writes the approved configuration into PDA registries.

Mock Rule Books

Local data today, chain accounts tomorrow.

These examples are intentionally structured like future on-chain data so wallet signing, PDA reads, and execute_rule flows can replace the mock layer later.

Future Contract Direction

The civilization program should mutate rule configuration PDAs through validators.

Core gameplay contracts should stay fixed where possible and read active configuration PDAs. Civilization consensus changes configuration, not ownership by fiat.

Old asset protection principle

Civilization Law should affect newly generated resources, equipment, and block rules by default. Retroactive effects on existing player assets require Natural Law consensus, stronger prompts, and 90% world-level agreement.