nicechunk

Every block becomes history. Every byte becomes value. NiceChunk is an on-chain voxel world powered by NCM compression and Proof of Useful Work on Solana.

[nicechunk @nicechunk]

What if the computation spent “mining” in an on-chain game did not disappear into meaningless hashes, but returned as a smaller, cleaner and more durable world?

That is the idea behind the Proof of Useful Work protocol we are developing for NiceChunk.

A persistent on-chain world has an unusual problem: success creates weight. Every block mined, wall constructed, building expanded and object forged produces new state that must remain available, reproducible and independently verifiable long after the original player has left.

For us, these are not merely database records. Every removed block is evidence that someone explored that land. Every building is time and intention given physical form. Every forged tool carries materials, geometry and decisions that belong to its creator. The world becomes heavier precisely because it becomes more alive.

The easy answer would be to move most of this history into a private database, centralized asset server or trusted indexing layer. Our goal is harder: preserve the canonical state of the world through Solana account data without allowing the continuing growth of that state to quietly destroy scalability.

NiceChunk PoUW is being designed as an application-level state optimization protocol. It does not replace Solana Proof of Stake. PoUW miners are not Solana validators, and their computation does not provide consensus or finality for the network. Solana continues to perform those roles. The purpose of NiceChunk PoUW is narrower, but genuinely useful: search for more efficient representations of NiceChunk’s existing game state.

The work is not “guess random numbers until a hash has enough zeros.”

The work is: find a smaller deterministic program that reconstructs a piece of terrain, a player-built structure or a forged object exactly, then submit a result that any independent verifier can reproduce and check.

The architecture deliberately separates two very different jobs.

Search may be expensive, probabilistic and massively parallel. Miners can explore millions of possible programs, mutations, structural decompositions and residual corrections. Verification, however, must remain deterministic, bounded and reproducible. Miners spend the large computational budget; the protocol only needs to verify the candidate they finally submit.

Everything begins with canonical semantics.

Before the protocol can decide whether something has been compressed correctly, it must define one exact interpretation of every coordinate, material, property and update rule. Terrain may be represented as a canonical sorted and deduplicated set of world-state changes. Buildings are interpreted as their final voxel coordinates and materials. Forged objects must include their complete geometry, materials, grip or anchor information and any immutable physical properties that form part of the object’s identity.

These three forms of state have different structures and may use different compression profiles, but they all obey the same law:

The representation may change. The meaning must not.

Each object is therefore committed through a cryptographic semanticRoot calculated from its canonical decoded state. The semantic root answers the question: “What is this object?”

It does not answer: “How is this object currently encoded?”

The encoded bytes have a separate encodingHash. Two different programs may reconstruct exactly the same house:

semanticRoot(A) = semanticRoot(B)

while:

encodingHash(A) ≠ encodingHash(B)

This separation is essential. A building must not become a new asset merely because a miner discovered a shorter way to describe it. Its ownership, history and canonical identity remain unchanged. Only its representation improves.

A candidate encoding contains two complementary parts:

CANDIDATE = BOUNDED VOXEL PROGRAM + EXACT RESIDUAL PATCH

The program captures regular structure. The residual patch records every exception required to reconstruct the target without a missing voxel, an additional voxel or an incorrect material.

A house, for example, might be expressed as a foundation BOX, perimeter WALL, doorway CUT, repeated windows, mirrored roof sections and a small patch containing its unique details. Terrain may use boxes, runs or bitmaps to describe mined regions, followed by precise restoration or deletion entries for irregular boundaries. A forged object may combine solids, cuts, axial profiles, symmetry and run-length encoding with a residual that preserves every final detail.

The residual is what makes useful search practical. A candidate program does not need to discover the entire object perfectly in a single mutation. It can first capture the large-scale structure, while the patch adds missing voxels, removes excess voxels and corrects materials. As the structural program improves, the residual becomes smaller. The combined representation only wins when the complete, exact result becomes smaller than the current encoding.

The deterministic voxel VM may provide general operations such as BOX, RUN, WALL, EXTRUDE, REPEAT, MIRROR, CUT, SET, CLEAR and PAINT. However, its instruction library must be fixed, public and versioned before a mining task begins.

We cannot inspect a castle and then add an instruction called GENERATE_THIS_CASTLE. That would merely hide the asset inside the decoder and call it compression. General reusable rules are compression. Asset-specific shortcuts are not.

The VM must also remain safe enough to verify under strict resource limits: no floating-point ambiguity, arbitrary code execution, recursion, unbounded loops or uncontrolled expansion. Every instruction must have deterministic behavior, a defined resource cost and hard limits on input size, command count, memory, voxel writes, patch entries and decoding work. Unknown instructions, integer overflow, truncated data, trailing garbage and non-canonical encodings must be rejected.

The verifier never trusts statistics supplied by a miner. It independently decodes the candidate, reconstructs its canonical semantics, recalculates its cryptographic commitments, measures its actual byte size and decoding work, and compares the result against the original task.

Visual similarity is irrelevant. “Almost identical” is invalid.

A candidate may replace the incumbent only when all required conditions are satisfied:

semanticRoot(candidate) = semanticRoot(target)

mismatchCount = 0

candidateStoredBytes < incumbentStoredBytes

candidateDecodeUnits ≤ protocolLimit

Semantic equality comes first. Storage improvement comes second.

A shorter program must not be allowed to hide pathological computation. An encoding that occupies very few bytes but requires an unreasonable amount of time, memory or expansion to decode is not a useful optimization. This is why every candidate must remain below a published decoding budget. Decode cost may also be used to rank candidates of equal size, but an encoding should not be presented as a storage improvement unless it actually stores fewer bytes.

PoUW does not need to prove that a candidate is the shortest possible representation in the universe. Such a claim would generally be impractical and unnecessary. The protocol only needs to prove something objective and independently reproducible:

“This encoding preserves exactly the same semantics and is strictly smaller than the current accepted encoding.”

This is where genetic programming becomes useful.

The miner should not randomly mutate compressed bytes. It evolves legal, strongly typed program structures: adjusting dimensions, combining adjacent regions, discovering repetition, testing symmetry, changing scan directions, extracting reusable substructures and reducing the size of the exact residual.

One candidate may replace a literal sequence of windows with REPEAT. Another may discover that two wings of a building can be represented with MIRROR. Another may merge many neighboring boxes into a larger volume. Another may express thousands of voxels as a single extrusion followed by a small patch.

Compute becomes structured exploration.

Genetic programming does not need to work alone. A practical miner can combine deterministic baselines, greedy decomposition, beam search, grammar-guided mutation, island-model evolution, local program rewrites, e-graph simplification and SIMD or GPU-assisted comparison. Different search implementations may compete freely, because no miner is trusted to define correctness. The verifier defines truth.

This produces the asymmetry that useful work requires: discovering a better representation may require millions of failed attempts, while checking the successful candidate remains deterministic and bounded.

We must also be honest about the word “useful.” Not every CPU cycle automatically creates value. Most candidates will fail. Some assets may already have highly efficient encodings, and a miner may complete a search without finding any improvement.

The durable value appears only when an independently verified candidate preserves exactly the same state while reducing its accepted storage cost.

Miners do not decide what exists in NiceChunk. They cannot create resources, improve item attributes, rewrite ownership, alter player history or change the canonical world. They only propose a more efficient expression for semantics that have already been committed.

The world remains fixed. Its language becomes shorter.

If a future reward mechanism is activated, rewards must be based on verified and realized improvements—not claimed effort, electricity consumed or unverifiable benchmark scores. Account replacement, allocation changes, bonds, cooldowns, competing submissions and reward calculations must all be explicitly specified, tested and audited before economic activation.

For NiceChunk, the long-term meaning is profound. Terrain modifications, player-built settlements and forged objects could be progressively re-encoded whenever someone discovers a genuinely better representation, without deleting anything players created and without changing the canonical identity of their work.

The more civilization grows, the larger the search space for useful structural patterns becomes. Repeated walls, roads, districts, towers, tools and terrain modifications are not merely additional storage pressure; they become opportunities for the network’s miners to discover a more compact language for the world.

For fully on-chain games on Solana, the broader value is not “free storage.” Compression does not automatically refund rent-exempt capital. It does not automatically increase Solana TPS. It does not make every component of a game fully on-chain, and it does not secure Solana itself.

Its value is more precise: when account layouts safely adopt a smaller verified encoding, fewer stored bytes can reduce future allocation requirements and decrease the amount of data that clients must fetch, cache, transmit and synchronize. The exact benefit must be measured from real account layouts and real replacement rules—not assumed from a compression percentage alone.

NiceChunk already has domain-specific foundations through NCM, NCF and NCM-DNA research. The unified semantic-root protocol, exact residual system, bounded verifier, cost model, CLI and browser miners, adversarial test vectors and future Solana reward path are still being developed. We will not blur the difference between research, implementation, auditing and mainnet activation.

This is the standard we are setting for ourselves:

Public code. Versioned rules. Canonical semantics. Deterministic execution. Golden test vectors. Adversarial testing. Reproducible benchmarks. Independent verification before rewards.

A persistent world should not be forced to forget its history in order to survive its own growth.

Useful work should leave something behind.

In NiceChunk, we want it to leave the world lighter—without erasing a single block, object, building or memory created by its players.

Fewer bytes. Not fewer stories.

#NiceChunk #Solana #ProofOfUsefulWork #PoUW #FullyOnChainGaming #OnchainGaming

[nicechunk @nicechunk]

A sincere update regarding the migration of NiceChunk’s on-chain Backpack Program.

While refactoring NiceChunk’s underlying architecture, we discovered that the original Backpack contract had far more room for optimization than we had expected.

This was not something that could be solved with a small patch.

To properly implement these optimizations—and to preserve enough flexibility for the future Civilization System, community-governed upgrades, and long-term protocol expansion—we had to redesign the entire Backpack architecture.

After careful consideration, we removed the legacy Backpack contract and closed its corresponding Backpack PDA accounts.

All recoverable SOL previously locked as rent in those PDAs has already been returned to the respective players’ wallets.

Most importantly, the resources stored in the old Backpacks have not been abandoned.

When an affected player creates a new Backpack under the upgraded contract, our migration program will automatically copy their existing resources into the new Backpack.

What you collected still belongs to you.

You will not need to gather those resources again or begin from nothing. Only the on-chain structure holding them is changing.

However, we understand that this migration still creates additional work for our players.

You connected your wallet, created your Backpack, entered the world, gathered resources, and trusted the rules we deployed on-chain. Now, because of an architectural decision made by the development team, you are being asked to create that Backpack again.

Even if the process only takes a short time, it is still an inconvenience that should not have belonged to the player.

For that, we sincerely apologize.

We did not make this decision lightly.

NiceChunk’s future Civilization System is not intended to be just another gameplay feature. It will be the mechanism through which this world can eventually evolve beyond the permanent control of its original developers.

Future rules, extensions, and contract upgrades must have enough architectural space to be proposed, verified, approved, and ultimately driven by the civilization that emerges inside this world.

If we continued building on the limitations of the legacy Backpack contract, we would be preserving short-term convenience at the cost of the world’s long-term freedom.

The problem would not disappear. It would only become more difficult, more expensive, and more disruptive to solve later.

So we chose to endure this migration now, while the world is still young and its foundations can still be rebuilt responsibly.

But technical necessity does not erase the value of your time.

Decentralization is not an excuse for inconvenience, and architectural progress does not remove our responsibility to the players who trusted us during this early stage.

To express our apology, every player affected by this migration will receive one additional item forged by us.

These compensation items will not all be identical.

Some players may receive practical tools. Others may receive small decorative objects. Their types, attributes, and quality may vary.

There is an important reason for this:

Even the NiceChunk development team cannot arbitrarily create equipment.

We do not have an administrator command that can summon unlimited tools. We cannot secretly duplicate rare equipment or generate thousands of perfect compensation items from nothing.

Every item used for this compensation genuinely exists inside the world.

Some were forged by members of the development team. Others were voluntarily donated by community contributors and early players. Every one of them came from real resources, real crafting, and real participation under the same rules that apply to everyone else.

In a traditional game, the development team could simply generate a standardized reward and distribute an identical copy to every player.

That would certainly be easier.

But if we allowed ourselves to break the laws of NiceChunk whenever it became convenient—even for the purpose of apologizing—then the fairness we speak about would be nothing more than a slogan.

A fair world cannot depend on developers merely promising not to abuse unlimited power.

A truly fair world must be designed so that such power does not exist.

That means even our apology must obey the laws of the world.

One player may receive a powerful tool. Another may receive a simple object with little practical value. Someone else may receive a small decoration forged and donated by a person they have never met.

These gifts may not be identical in rarity or function, but every one of them is real.

Each item contains the materials, time, effort, and goodwill of an actual participant in this world.

And somehow, these imperfect gifts feel more meaningful than anything we could have created through an administrator command.

NiceChunk is gradually becoming more than contracts, algorithms, terrain, resources, and PDAs.

It is beginning to contain memories.

It contains mistakes and repairs, tools forged by one person and passed to another, resources gathered through real exploration, and small acts of generosity between people who are helping build a world that does not fully exist yet.

It is becoming a little strange, a little imperfect, and unexpectedly lovable.

We cannot promise that building something this ambitious will never require another difficult decision.

But we can promise that we will not hide those decisions from you.

We will explain what changed, protect what belongs to players, return what can be returned, acknowledge the inconvenience we create, and remain bound by the same rules we ask everyone else to follow.

The development team should never stand above this world.

We are only its earliest builders—and eventually, when the Civilization System assumes control, we should become ordinary participants in the civilization we helped begin.

To everyone who entered NiceChunk while its foundations were still being laid: thank you.

Thank you for testing unfinished systems, discovering problems, reporting bugs, enduring migrations, gathering resources, forging equipment, donating items, and treating this small on-chain world as something worth caring about.

Your patience is not something we take for granted.

This world is becoming more complete because you were willing to enter it before it was complete.

Sincerity is everything we can give.

Thank you for your patience, your trust, and your understanding. 🤍
#NiceChunk #Solana #SolanaGaming #FullyOnchainGame #OnchainGaming #AutonomousWorlds #Web3Gaming #BlockchainGaming #BuildInPublic #Decentralization

[nicechunk @nicechunk]

Proof of Useful Work: Mining That Makes the World Lighter

In our game, every meaningful action leaves a permanent mark.

When a player excavates a mountain, reshapes the terrain, constructs a fortress, or forges a piece of equipment, the result is not merely rendered on a local client. It becomes part of the game’s canonical on-chain state—a shared world whose history, ownership, and geometry can be independently verified.

At its core, much of this state is geometric data: terrain structures, building components, equipment models, spatial relationships, and the transformations created by players.

Each individual interaction may require only a small amount of storage. But at scale, millions of actions accumulate. Players collectively fund the rent-exempt balances required by PDAs, the global state continues to expand, and more data must be stored, synchronized, transmitted, and reconstructed across the network.

This is where our Proof of Useful Work begins.

Instead of asking miners to spend computational power searching for arbitrary hashes, the protocol assigns them a task that directly improves the game: discovering shorter and more efficient NCM representations for existing terrain, buildings, and equipment.

Miners compete to produce valid compression proofs—demonstrating that a shorter NCM code can deterministically reconstruct the same geometric state without sacrificing integrity, ownership, or verifiability.

The result is not theoretical efficiency.

A successful proof reduces the number of bytes required on-chain. Smaller accounts can reduce the rent-exempt capital locked inside PDAs. Less state means lower synchronization and transmission overhead. More compact geometry can also accelerate model delivery, reconstruction, and rendering for players around the world.

When storage is compressed, excess SOL previously committed to maintaining that state can be released. Under the protocol’s economic design, this value is automatically routed through the treasury to acquire NCK, which is then distributed to the miners who produced the useful compression.

The cycle is simple:

Players create the world.
Their actions generate persistent state.
Miners optimize that state.
The protocol releases previously locked capital.
The treasury converts that efficiency into NCK rewards.
And the entire game becomes lighter, faster, and more scalable.
This transforms mining from an external security expense into an internal engine of continuous optimization.
Computational power is no longer consumed only to prove that electricity was spent. It is used to reduce the collective burden carried by every player—to lower storage requirements, decrease network traffic, improve rendering performance, and extend the sustainable life of the world itself.
Every shorter NCM code is more than a technical achievement.
It is a road made faster for the next traveler.
A fortress made cheaper to preserve for its builder.
A piece of equipment made easier to transmit across the network.
A fragment of history protected without forcing future players to carry unnecessary weight.
The game world grows because players create.

It remains sustainable because miners refine.

That is our vision for Proof of Useful Work: a system in which computation serves the world, efficiency creates measurable value, and miners are rewarded not for producing meaningless hashes—but for making the shared universe better for everyone who lives within it.

[nicechunk @nicechunk]

Over the past ten-plus days, our team has been working around the clock to complete one of the most important technical upgrades in the history of the game: migrating the original game codebase into our new chunk.js architecture.

Today, we’re proud to share that the migration is now more than 90% complete.

What initially appeared to be a straightforward transition quickly became a far deeper and more complex undertaking than we had anticipated. As we moved forward, we discovered that many of the game’s core systems were tightly connected to the original architecture. This meant that we were not simply moving code from one place to another—we were rebuilding, restructuring, and rethinking a significant part of the game from the ground up.

Throughout this process, we refactored most of the underlying systems, resolved legacy compatibility issues, rebuilt key logic, improved the way different modules communicate with each other, and conducted repeated rounds of debugging and testing to ensure that the new structure remains stable, efficient, and scalable.

There were many difficult moments along the way.

Some issues required hours of investigation before we could even identify the real cause. Others forced us to revisit systems that had been running quietly in the background for a long time. Every time one problem was solved, another layer of complexity would appear. But step by step, module by module, and test by test, the team continued moving forward.

What matters most is that we solved these challenges one by one.

This upgrade is not only about cleaning up old code. It is about building a stronger technical foundation for everything that comes next. A more modular architecture will allow us to develop new features faster, improve performance more effectively, reduce technical risk, and maintain the game with far greater flexibility in the long term.

In other words, this is not just a migration. It is a major step toward the next stage of the game.

We want to sincerely thank every engineer who has spent countless hours rebuilding, testing, reviewing, and fixing the system—often late into the night. Your persistence, patience, and attention to detail made this progress possible.

We also want to thank all of the testers and players who participated in the process, reported issues, shared feedback, and helped us verify each new build. Your support has been an essential part of this upgrade. Every bug report, every test session, and every piece of feedback helped us move closer to a more stable and polished experience.

More than 90% of the work is now complete, but we are not treating the remaining portion lightly. The final stage often requires the greatest level of care, especially when it comes to stability, compatibility, and the overall player experience. We will continue to test, optimize, and refine the system until we are confident that the transition is ready.

The past ten days have been exhausting, intense, and challenging—but they have also reminded us why we started building this game in the first place.

Great products are not created by avoiding difficult problems. They are created by facing those problems, solving them together, and continuing to move forward even when the path becomes more complicated than expected.

We are incredibly proud of what the team has accomplished so far, and even more excited about what this new foundation will make possible.

Thank you for your patience, your trust, and your continued support.

We are almost there.

Beyond the technical progress itself, there is something equally important that we want to make clear.

The engineers, testers, and players who have contributed to this process are not participating because of hidden incentives, special treatment, or the promise of additional privileges. Their motivation comes from something much simpler and much more meaningful: a genuine love for the game, a belief in what NiceChunk can become, and a shared desire to build something worth being proud of.

This kind of participation means a great deal to us.

Many people have given their time, energy, experience, and patience without expecting to stand above anyone else. They joined late-night testing sessions, investigated difficult technical issues, reproduced bugs repeatedly, reviewed new builds, and provided honest feedback—not because participation would give them a higher status, but because they care deeply about the future of NiceChunk.

That spirit is at the heart of everything we are building.

NiceChunk is founded on an uncompromising principle of fairness. Developers and players stand on equal ground. There is no privileged class within the community, and contributing to development does not grant anyone additional authority, exclusive resources, preferential access, in-game advantages, or special influence over the experience of others.

Contribution is not a shortcut to privilege.

Being involved in development does not place someone above the community. It creates a greater responsibility to serve the community.

For us, fairness cannot exist only as a slogan. It must be reflected in the way the project is designed, the way decisions are made, the way resources are distributed, and the way every player is treated. The people who write the code, the people who test the builds, and the people who enter the game for the first time must all exist within the same fair environment and follow the same fundamental rules.

No one should receive an unfair advantage simply because they are closer to the development process.

No one should have greater rights simply because they contributed earlier.

And no one should be treated as less important simply because they are “only” a player.

In NiceChunk, there is no such thing as “only a player.”

Players are not outsiders looking into a product built behind closed doors. They are part of the world itself. Their experiences, discoveries, feedback, criticism, and creativity are just as important to the long-term direction of the game as the code written by engineers.

The development team may be responsible for building the systems, but that does not make the team the owner of everyone else’s experience. Our responsibility is to create and protect a fair foundation—one where every participant can compete, create, explore, and grow under the same rules.

This is also why we are especially grateful to everyone who has contributed during this migration.

Your work was not driven by the expectation of special rewards. It was driven by trust, passion, and a shared belief that NiceChunk deserves a stronger foundation. That kind of support cannot be measured only in hours worked, bugs reported, or modules completed. It represents a culture—a culture in which people contribute not to gain power over others, but to create something better for everyone.

That is the community we want NiceChunk to become.

A community where contribution is respected, but never converted into unfair authority.

A community where developers are accountable to players, rather than placed above them.

A community where effort creates responsibility, not privilege.

And most importantly, a community where fairness applies equally to everyone.

To every engineer, tester, and player who has taken part in this process: thank you.

Thank you not only for helping us rebuild the game, but for proving that people can come together around a shared vision without demanding special status in return.

NiceChunk is being built by people who love it.

But it is being built for everyone.
#NiceChunk #GameDev #BuildInPublic #CommunityDriven #FairPlay #PlayersFirst #Web3Gaming #BuiltTogether

[nicechunk @nicechunk]

A new engine era for NiceChunk.

We are replacing our heavily optimized three.js renderer with chunk.js — a WebGL2 engine built from the ground up specifically for NiceChunk.

NiceChunk is not a generic 3D scene. It is a fully on-chain verifiable voxel world, where the visual algorithm must stay aligned with Solana-verifiable contract logic.

That is why we decided to remove every unnecessary abstraction layer and rebuild the engine around one goal:

maximum voxel rendering performance + deterministic on-chain verifiability.

Before this, even after pushing three.js to its limits, a chunk radius of 6 could only stay around 60 FPS — and movement still caused frame drops.

With chunk.js, we are now running a 20-chunk radius at stable 60 FPS, even under 5x high-speed movement.

In our extreme internal benchmark, this represents up to a 400x performance improvement.

Beyond performance, the new renderer also gives us cleaner colors, a more unified terrain style, and a stronger game-like visual identity. The world finally feels closer to the comic-like voxel universe we imagined.

We are now migrating the full game rendering pipeline to chunk.js, including terrain, resources, materials, avatars, items, and every visual element that must remain compatible with our on-chain verification model.

This is a massive engineering effort, but seeing a smoother world, a wider render distance, and a more beautiful NiceChunk makes it worth it.

Huge thanks to the engineers helping with optimization and to the players testing every build with us.

chunk.js will be open-sourced under the MIT license on GitHub.

We hope it can become a useful foundation for future fully on-chain games, verifiable games, and blockchain-native voxel worlds.

NiceChunk is not just building a game.

We are building an engine layer for verifiable worlds.

#NiceChunk #Solana #Web3Gaming #OnChainGaming #GameEngine #VoxelGame #WebGL2 #OpenSource #MIT #FullyOnChain

[nicechunk @nicechunk]

From Three.js to a NiceChunk-native engine.

NiceChunk originally started with Three.js for compatibility.

After countless iterations and rendering optimizations, we finally reached a visual style we genuinely love. The world already feels alive to us. Sometimes we even just stand on the beach, watch the sunset, and enjoy the world we built.

But after real testing and deeper technical review, we had to face a hard truth:

NiceChunk is not a general-purpose 3D game.

It is a deterministic voxel world designed around Solana-verifiable resources, chunk states, player modifications, provenance, and low-cost on-chain validation.

Three.js helped us get here, but its general-purpose scene graph, abstraction layers, and flexible 3D pipeline are now becoming a ceiling. They add logic we do not need, limit voxel-specific optimization, and make it harder to align the rendering engine with compact, verifiable PDA-based world state.

So we made a painful decision:

We are leaving behind the current Three.js foundation and rebuilding from the ground up.

The new NiceChunk engine will be a purpose-built blockchain voxel engine, designed specifically for deterministic chunks, extreme voxel rendering efficiency, compact state representation, resource verification, and fully on-chain-auditable world changes.

It will not be a universal 3D engine.

It will intentionally remove many features that voxel games do not need.

But for NiceChunk, that is exactly the point.

Less abstraction.
More determinism.
Lower verification cost.
Higher voxel performance.
A world engine built for on-chain games from the ground up.

We love the world we already created.
Now we have to rebuild it stronger.
#NiceChunk #Solana #Web3Gaming #OnchainGaming #VoxelEngine #GameFi #FullyOnchain

[nicechunk @nicechunk]

NiceChunk has no unified “default character” concept.

No fixed hero model.
No studio-issued skins.
No centralized asset database.

Every player can own a fully free character identity: voxel skin, body model, equipment style, and future visual evolution — all generated, modified, and verified as player-owned game state.

This is powered by **NCM — NiceChunk Model**, our compact 3D asset encoding format built for on-chain voxel assets.

Instead of storing character models as external GLB/VOX files on IPFS, CDN, or centralized servers, NCM compresses the model into deterministic data that can be stored directly inside **Solana PDAs**.

That means a character is not just metadata pointing to an image.

It is real on-chain state:

* reproducible by any client
* owned by the wallet
* editable through game rules
* composable with crafting and forging
* independent from external storage failure

Your character is not a JPEG skin.
It is an on-chain voxel identity.

Fully customizable. Fully verifiable. Fully player-owned.

This is what autonomous worlds should look like.

#NiceChunk #Solana #Web3Gaming #OnchainGaming #AutonomousWorlds #Voxel #GameFi #PDA #NFTs

[nicechunk @nicechunk]

iceChunk has no pre-minted machines, no dev-issued devices, and no fixed tech tree.

We only define the primitive laws of the world.

Resources are mined from the world, smelted into materials, forged into items — and now, materials can become programmable MCU chips.

Our new forged MCU system introduces an AVR simulator and Arduino compiler directly into the game.
Players can write Arduino-style code, compile it to Intel HEX, run it on an ATmega328P simulation, and use every forged pin as a real game-world device port.

A chip is no longer just an item.
It becomes a programmable on-chain primitive.

Pins can output signals.
Signals can drive devices.
Devices can become machines.

Cars. GPS. Automatic doors. Factory lines. Logic circuits. Automated defense systems. Resource-processing machines. Entire industrial networks.

The design space is not defined by the team.
It is defined by players.

This is why Web3 matters for games: persistent state, verifiable provenance, open composability, smart-contract validated rules, and a resource economy where every object can be traced back to mined materials and elemental properties.

NiceChunk gives players a world.
The future civilization inside that world is not scripted.

You build it.
You program it.
You govern it.
You expand it.

https://t.co/LQ8rptZ6qi

#NiceChunk #Solana #Web3Gaming #FullyOnchain #AutonomousWorlds #OnchainGaming #MCU #Arduino #AVR #DePIN #VoxelGame #GameFi #OpenWorld #ComposableGaming #BlockchainGaming

[nicechunk @nicechunk]

NiceChunk already has a Civilization System that allows players to vote on new gameplay rules and update PDA-backed world state through governance.

But if we are serious about credible neutrality, open ownership, and absolute fairness, governance cannot stop at the rule layer.

So we are now experimenting with a new feature:

World Developer Mode

A new governance-gated development pipeline where players can submit frontend updates, smart contract changes, gameplay logic, and protocol-level improvements directly through the world interface.

The flow is simple:

Players submit code proposals.
The community and core contributors review them.
CI, audits, simulations, and guardian checks run automatically.
If the proposal passes the required Civilization vote, a Civilization Git Bot commits the approved code to our GitHub repository with verifiable governance proof.
This is our attempt to move from “players vote on rules” to “players help evolve the codebase itself.”
We know this is an aggressive experiment.
Open code governance introduces real risks: malicious commits, broken economics, unsafe contract logic, bad incentives, and unexpected game-state impact. During the testing phase, every proposal will go through strict review, automated checks, community scrutiny, and developer verification. Unstable changes may be rolled back.

But we believe this direction matters.

If a fully on-chain world can only be upgraded by the project team, then it is not truly free.

NiceChunk is exploring a different path:

A world where gameplay, assets, resources, rules, and eventually code evolution itself can become publicly proposed, publicly reviewed, publicly voted, and publicly committed.

Not just open-source.
Not just on-chain assets.
A player-governed world development layer.

World Developer Mode is now entering experimental testing.

Builders, auditors, players, and protocol designers are welcome to join, test, break, review, and help us improve the model.

#NiceChunk #Solana #Web3Gaming #OnChainGaming #OpenSource #DAO #GitOps #GameFi #AutonomousWorlds #FullyOnChain #SmartContracts #CryptoGaming #DecentralizedGovernance #PDA #BuildInPublic

[nicechunk @nicechunk]

NiceChunk Seed User Campaign is now live.

We are officially opening our public beta and whitelist registration.

Starting today, users can register on the NiceChunk website, create an account, and bind their Solana wallet.

At the end of the campaign, the first batch of whitelisted users will receive an airdrop of 100 NCK as initial in-game startup capital.

The treasury purchase price is fixed at:

1 NCK = 0.01 SOL

NiceChunk is built with one goal:

A fully fair, free, and fully on-chain world.

No IPFS.
No centralized asset storage.
No hidden backend asset issuance.
No team-minted resources or items.
Game assets, gameplay logic, user data, resources, items, and progression are designed to live on-chain.
The team cannot arbitrarily issue resources.
The team cannot mint items out of thin air.
Every item must come from crafted materials.
Every material must come from smelted resources.
Every resource must come from the open world.
NiceChunk is not just building a Web3 game.

We are building a verifiable world where fairness is enforced by code.

Whitelist registration is open now.
Enter the world. Bind your wallet. Become part of the first seed users of NiceChunk.
#NiceChunk #Solana #Web3Gaming #FullyOnchain #OnchainGaming #GameFi #FairLaunch #BlockchainGaming #NCK

[nicechunk @nicechunk]

**NiceChunk Smelting Station is not just a crafting UI.
It is the beginning of an on-chain production economy.**

In NiceChunk, the team does not mint resources.
The team does not issue items.
There is no hidden admin inventory, no server-side loot table, and no centralized material supply.

Everything starts from the world itself.

Players mine raw resources from the open world.
Those resources are then smelted into materials.
Materials are then forged into tools, weapons, armor, and other items.

**World → Resource → Smelted Material → Forged Item**

Every step is part of a transparent production chain.

The screenshot shows our Smelting Station: players place mined resources into the thermal core, match them against public recipes, add fuel, and produce forge-ready materials.

But the important part is not only the UI.
The important part is the rule layer behind it.

NiceChunk uses public recipes as part of the game’s economic foundation. A material cannot appear unless the correct inputs exist. An item cannot appear unless the correct materials were produced first.

This is how we prevent arbitrary issuance.
This is how we keep the economy grounded in the world.

In the future, recipes will not only be defined by the original protocol.

Through the NiceChunk Civilization System, players will be able to discover new material formulas, propose new recipes, write them into civilization rules, and let the community vote.

Once a civilization approves a recipe, it can be written on-chain into a recipe PDA and become part of the public recipe table.

That means new materials can emerge from player knowledge, player experimentation, and player governance — not from centralized updates.

This is the kind of game economy we want to build:

No artificial item minting.
No invisible admin supply.
No fake scarcity.
No black-box crafting server.

Only resources extracted from the world, materials refined through public rules, and items forged through verifiable production.

NiceChunk is building a fully on-chain world where every object has origin, cost, and history.

A sword should not be “issued.”
A sword should be born from ore, fire, labor, and civilization.
#NiceChunk #Web3Gaming #GameFi #OnchainGaming #FullyOnchain #OnchainEconomy #CraftingSystem #PlayerDrivenEconomy #DecentralizedGaming #Solana #BuildOnSolana #BlockchainGaming #OpenEconomy #PDA #SmartContracts

[nicechunk @nicechunk]

We built NCM for NiceChunk: a compact, on-chain 3D asset format designed for Solana.

The idea is simple:

A game asset should not be a mutable URL.
It should be part of the state.
Most Web3 games still store the real visual asset off-chain: IPFS, metadata JSON, external gateways, centralized asset servers, or some URI that needs to keep resolving forever.

That is not enough for the kind of world we want to build.

In NiceChunk, characters, items, equipment, resources and world objects should be readable, verifiable and reconstructable directly from chain state.

So we built NCM.

A normal .vox character file can be around 22KB+.
With NCM, the same voxel character can be represented in around 400 bytes of compact chain text.

That means a 3D character can live directly inside a Solana PDA.
No IPFS dependency.
No metadata server.
No external model gateway.
No hidden asset layer.

A client can fetch the account data through RPC, decode the NCM payload, and reconstruct the 3D model locally.

This makes the asset PDA-native, RPC-readable, and much closer to fully on-chain game state.
For NiceChunk, this matters because we are not trying to build a Web2 game with token rails attached.
We are building a world where assets are part of the protocol.
The model, ownership, crafting logic, resource origin and game rules should be composable and verifiable together.

NCM also makes player identity and customization more powerful.

A character is not just a static NFT image.
It is not just a link to a model file.
It is a compact, editable, rule-based 3D object.

Colors, parts, equipment, body structure, materials and future modifications can all become state transitions instead of off-chain updates.

But NCM is only the first layer.

We also designed NCM-DNA.

NCM-DNA is our approach to useful Proof of Work.

Instead of spending compute to find a meaningless nonce, searchers work on something the network can actually reuse:
finding shorter deterministic “genes” that reproduce the same 3D model.
Today, a model may need around 400B of NCM data.
With NCM-DNA, the goal is to search for a shorter seed / gene that deterministically reconstructs the same canonical model.

If a 400B asset can be represented by a 100B gene, storage cost goes down.
If it can be represented by a 10B gene, the entire asset layer becomes dramatically lighter.

This turns compression into an economic primitive.

Searchers contribute compute.
The protocol gets shorter model expressions.
On-chain storage becomes cheaper.
The saved storage cost can be redirected back as incentives for useful computation.

That is the core idea behind NCM-DNA:

Proof of Work should not only prove that energy was spent.
It should leave behind a smaller, cheaper, reusable piece of state.

In NiceChunk, miners/searchers are not just producing hashes.
They are helping compress the world.

This creates a new loop:
Players create assets.
NCM makes them small enough to live on-chain.
NCM-DNA searches for shorter genes.
Shorter genes reduce state cost.
Reduced cost funds more useful compute.
The asset layer gets lighter over time.

We think this is important for fully on-chain games.
Because the bottleneck is not only TPS.
It is also state size, data availability, asset permanence and the cost of keeping game objects verifiable forever.

NCM is our first step toward an on-chain 3D asset standard for Solana games.

NCM-DNA is our attempt to turn compression into useful PoW.
NiceChunk is not just putting transactions on-chain.
We are trying to make the world itself readable from chain state.
A Solana game asset should be part of the state,
not a URL attached to it.

#NiceChunk #Solana #OnchainGaming #FullyOnchain #FOCG #Voxel #PDA #ProofOfWork #Web3Gaming

[nicechunk @nicechunk]

We are currently speaking with physicists, chemists, and geologists to review and refine the natural attributes, elemental parameters, material rules, mineral distribution, resource generation, terrain structure, and ecological logic behind NiceChunk.

NiceChunk is not just an “on-chain Minecraft.”
It is not a random map with NFTs and tokens attached to it.
What we are trying to build is a natural world on-chain — a world that can be explored, verified, expanded, and collectively owned.

In NiceChunk, a material should not be just a name.
A resource should not be just a drop table.
A world should not be just a map generated by a server.

Why is iron heavy?
Why do certain ores appear in specific geological layers?
Why do resources from different regions carry different elemental compositions?
Why should materials require specific processes, energy, tools, and environments before they can be forged into equipment?
Why should every chunk discovered by a player have its own natural logic?
These questions all point to the same belief:
The rules of NiceChunk should not simply be decided by the project team.
They should be grounded, as much as possible, in the logic of physics, chemistry, geology, materials, and nature itself.

Mass, density, melting point, elemental composition, mineral structure, terrain evolution, biome distribution, processing methods, and energy requirements — these basic parameters are the foundation of a world that can be trusted over the long term.
We believe on-chain games should not only record ownership of assets.
They should also record the rules of the world itself.
When an item is forged, it should not be just an NFT.
It should have origin, material, process, attributes, and history.
When a piece of land is discovered, it should not be just a coordinate.
It should have terrain, resources, environment, and meaning.
NiceChunk is not being designed as a short-term game loop.
It is being built as a long-term world system.

A world driven by natural rules.
Expanded through player exploration.
Verified by on-chain data.
Owned and shaped by its community.

This path is slower.
It is harder.
But if we want to build an on-chain world that can last for years, we cannot stop at making it look real.
We have to make its rules feel real.

Nature is the base layer of NiceChunk.
And we are taking the time to write it properly.

#NiceChunk #OnchainWorld #Web3Gaming #Solana

[nicechunk @nicechunk]

Hey guys, our development is almost complete, this is the final test.