DEVICE TRUTH
The first frame belongs to your device
When the girl presses the mining control, the browser selects a target, checks reach and protection data already loaded on this device, and animates the tool. When the moving tool box actually touches the voxel, the controller records one contact, deducts local tool durability, and redraws the hotbar. The current Play runtime does not produce a mining contact sound or contact-chip particle effect.
On the current automatic mining path, reaching the required contact count creates a pending record, but the target block is not changed to air until that pending action is confirmed. If the wallet is unavailable or submission fails, the mining path can roll back the pending attempt and restore its locally deducted tool damage. When chain sync is deliberately disabled, the interface labels the result as a local preview instead of pretending that a transaction failed or succeeded.
The input, target selection, reach check, tool animation, collision, durability update, and temporary values ran here.
No animation frame, outline, label, contact count, or locally deducted durability identifies a successful Solana instruction.
RELAY TRUTH
Another player may hear the news before the world is settled
Guardian has a deliberately smaller job: deliver bounded nearby activity with low latency. A receiving client can react to movement, chat, equipment, digging, or building news without waiting for a Solana round trip. For the current digging message, the receiver draws air at the reported coordinate and schedules an independent account refresh.
There is an important current-runtime limit: that same session protects the new render delta until an account snapshot has observed the same value. If the next snapshot does not contain the coordinate, it does not immediately clear the unobserved Guardian gap. A full reload or a separate clean client clears the in-memory hint and rebuilds from public inputs plus validated records. Until that clean reconstruction supports the gap, two agreeing screens are still agreeing only about delivered news.
The receiving client obtained a bounded message and used it for a timely presentation update.
Guardian does not execute the Chunk instruction, and its current greeting is not a wallet-signature challenge.
PROGRAM AND ACCOUNT TRUTH
A program accepts one narrow claim, not the whole picture
For a supported mine, the client submits an integer coordinate and the required accounts with an allowed signer. The Chunk program independently derives and checks its relevant addresses, validates the session and account relationships, recalculates the generated block, rejects protected or duplicate removals, applies rule tables, and writes only if the transaction succeeds.
The current client waits for confirmed rather than finalized. In the automatic path, only a successful submitted result reaches the local pending-confirm step; rejected and exceptional mining paths roll back. For the single-block example on this page, the transaction can support the claim that the Chunk program accepted the removal at that coordinate. It does not by itself audit the camera, the girl's hand path, Guardian news, Backpack rewards, PlayerProgress, saved position, or every transaction in a multi-block collapse.
For this single-block example, it identifies the invoked instruction, supplied accounts and signers, result, coordinate, and observed commitment.
A clean client can derive the expected ChunkBroken address, validate its returned account data, and check that the removal coordinate is present.
Those claims touch other accounts or transactions and must be checked in their own scope.
The implementation does not wait for finalized on this path, so the page does not call the observation final or irreversible.
RECONSTRUCTION TRUTH
Refresh is a useful test, not magic proof
Here, a clean client means a full reload or separate client with no old in-memory render hints. It regenerates untouched terrain from the configured seed, version, integer coordinates, and world rules, then applies validated records such as ChunkBroken removals. The picture is an interpretation of those inputs; the program did not validate every tree surface, water pixel, camera angle, or character pose.
An account read is useful only when the client asks for the expected address and rejects returned data with the wrong program owner, executable flag, minimum world height, header, version, capacity, or byte length. Even then, it is a confirmed RPC observation of that one account. It is not proof that one RPC node is infallible, not finalized, not automatically tied to one transaction's confirmation slot, and not evidence for the Backpack or every other account.
If a clean client validates a ChunkBroken record containing the coordinate, it has evidence for rendering that coordinate as removed.
The read alone does not identify which transaction caused the bytes, upgrade confirmed to finalized, or verify Backpack rewards and PlayerProgress.
- The pickaxe moves but the target remains
Classify this as local feedback. It shows that the interaction ran on this device, not that shared state changed.
- A nearby client quickly shows the gap
Classify this as a Guardian hint. In the current session it can survive an ordinary refresh even when the account does not show it, so use a full reload or separate clean client before treating persistence as evidence.
- A confirmed single-block mine is followed by a valid Chunk read
When the expected ChunkBroken record contains the same coordinate, classify that as stronger evidence for this one removed coordinate. It does not silently prove rewards, progress, position, or another block.
- Two clean clients draw the same untouched hill
Classify this as deterministic reconstruction. It demonstrates reproducible public inputs, not a player transaction.
- A changed screen is not automatically a transaction.
- Two agreeing screens are not automatically settled shared state.
- confirmed is not the same observation as finalized.
- An account read must validate the intended address, owning program, executable flag, expected minimum world height, and byte structure.
- Deterministic reconstruction proves only the scope covered by its public inputs and selected records.
READ THE EVIDENCE
A confirmed removal and a validated Chunk record answer different questions
The formula lists evidence needed to audit one removed coordinate, not a whole mining reward and not a replacement for Solana consensus. The two excerpts show when the automatic client confirms a pending result and which returned Chunk records are rejected before reconstruction.
Evidence needed to audit one removed coordinate
E_removed(p) = T_confirmed(single-block mine at p) ∧ R_confirmed(expected ChunkBroken contains p)The symbol ∧ means 'and.' T_confirmed answers whether this single-block instruction completed under its supplied accounts and signers at the commitment the client observes. R_confirmed answers whether a clean client received and validated the expected ChunkBroken account and found coordinate p in it. The read does not create state or prove which transaction caused those bytes, confirmed is not renamed finalized, and Backpack rewards, PlayerProgress, saved position, and multi-block results need their own evidence.
- E_removed(p)
- The evidence needed to audit one coordinate p as a shared recorded removal.
- T_confirmed(...)
- The exact single-block mining transaction for p reached confirmed or stronger and reported no execution error.
- R_confirmed(...)
- A confirmed RPC response returned the expected ChunkBroken account, its owner and byte format passed validation, and its decoded removals contain p.
- ∧
- Both sides are required for this coordinate-level audit rule; neither side silently proves unrelated accounts, rewards, or visuals.
The automatic path confirms pending only after the adapter reports success
JavaScriptplay/play-chain-session.js if (result?.submitted) {
state.chainMode = "chain-ready";
const reconciliation = action === "mine"
? reconcilePendingMineWithChainResult(pending, result.result)
: null;
if (reconciliation?.droppedCount) {
gameState.playerProfile.minedBlocks = Math.max(
0,
Math.trunc(Number(gameState.playerProfile.minedBlocks) || 0) - reconciliation.droppedCount,
);
gameState.savePlayerProfile();
}
if (action === "mine" && result.result?.partialCollapse) {
logPartialCollapseFailure(pending, result);
}
if (action === "mine" && result.result?.partialBulkMine) {
logPartialBulkMiningFailure(pending, result);
}
state.chainResults.set(pending.txId, { signature: result.signature, result: result.result });
pending.chainSubmitted = true;
pending.chainAction = action;
pending.chainSignature = result.signature;
pending.chainPlayerPositionSaved = Boolean(result.result?.playerPositionSaved);
pending.chainResult = result.result ?? null;
const confirmed = controls.confirmTx?.(pending.txId);This is the automatic chain path after the adapter has returned submitted success. The adapter's lower-level send routine waits for confirmed, but that wait is outside this excerpt. This code first reconciles any partial multi-block outcome, stores the returned result and primary display signature, and only then calls confirmTx for the matching local pending action. Other branches roll mining back when the wallet is missing, the adapter rejects submission, or an exception occurs. A separate manual Confirm input remains local-only and is not covered by this branch.
- 1-2
Enter this branch only when the adapter reports submitted success, then return the UI to its chain-ready mode.
- 3-5
For mining, compare the proposed blocks with the subset the chain result actually accepted; other actions have no mining reconciliation here.
- 6-12
If a multi-block plan lost blocks during reconciliation, remove those unaccepted blocks from the locally counted mined total.
- 13-15
Report a partly failed support collapse instead of describing the whole plan as one all-or-nothing success.
- 16-21
Store the primary display signature, action kind, position-save result, and returned outcome on the matching pending record. A multi-transaction result can carry additional signatures outside this field.
- 22
Only now ask the mining or placement controller to confirm this exact pending transaction ID locally.
Fresh Chunk data must pass ownership and byte checks
JavaScriptplay/play-chain-chunk-deltas.js if (account && expectedOwner && accountOwnerAddress(account) !== expectedOwner) throw new Error("ChunkBroken account owner does not match the active chunk program.");
if (account?.executable) throw new Error("ChunkBroken account cannot be executable.");
const deltas = account?.data?.length
? decodeChunkBrokenDeltas(account.data, chunk.chunkX, chunk.chunkZ, chunkSize, expectedMinY)
: [];
snapshots.push({
id: chunk.id ?? chunkId(chunk.chunkX, chunk.chunkZ),
chunkX: chunk.chunkX,
chunkZ: chunk.chunkZ,
expectedChainRevision: chunk.expectedChainRevision,
contextSlot: Math.max(0, Math.trunc(Number(contextSlot) || 0)),
deltas,
});
} catch (error) {
errors.push({
id: chunk.id ?? chunkId(chunk.chunkX, chunk.chunkZ),
error: readableError(error),
});
}The sync has already derived the expected Chunk account addresses before this excerpt. Each returned account must still belong to the active Chunk program, must be data rather than executable code, and must decode with the expected minimum world height and ChunkBroken format. Only a passing result becomes a queued snapshot; a failure becomes an error instead of trusted terrain data. This validation does not make one RPC node infallible or tie the response to one transaction's confirmation slot.
- 1
Reject a returned account when its owning program is not the active Chunk program expected by this client.
- 2
Reject executable program code because a ChunkBroken record must be a data account.
- 3-5
Decode non-empty bytes using the expected Chunk coordinates, size, and world minimum height; an absent account represents no removals for that Chunk.
- 6-13
Only validated data becomes a snapshot carrying its Chunk identity, expected local revision, RPC context slot, and decoded removals.
- 14-19
Any thrown validation or decoding problem is recorded as an error, not inserted into the trusted snapshot list.
IMPLEMENTATION EVIDENCE
Where these claims come from
Each claim is intentionally scoped to a concrete implementation path. These references are for verification, not decoration.
play/mining-controller.js
Runs target, reach, collision, damage, durability, pending creation, confirmation, and rollback on this device.
play/play-chain-session.js
Separates local preview, wallet-needed, submitting, successful automatic confirmation, skipped submission, and mining rollback paths.
play/play-input-actions.js
Keeps the manual Confirm input separate from automatic chain confirmation, so a local confirmation is not silently called a receipt.
play/play-guardian.js
Shows that a Guardian digging hint changes the receiver's render delta and then requests an independent account refresh.
Guardian/src/app.cpp
Implements bounded regional message delivery, sequence checks, rate limits, and forwarding rather than Solana execution.
src/chain/nicechunkChain.js
Builds supported gameplay transactions, returns real signatures, and waits for confirmed rather than finalized.
programs/nicechunk_chunk/src/lib.rs
Independently validates the mining accounts and session, generated block, protection, duplicates, rules, rewards, and accepted writes.
play/play-chain-chunk-deltas.js
Derives current Chunk record addresses, fetches confirmed RPC data, validates owner and byte structure, and queues passing snapshots.
chunk.js/chunk/chunk-state.js
Defines generated, pending, and render-delta precedence, including the rule that retains an unobserved Guardian-style delta until a snapshot has first observed the same value.
chunk.js/world/world-generator.js
Reconstructs untouched world blocks from configured public world inputs and integer coordinates.
public/mainnet.json
Names the current world inputs and the actual Solana Devnet cluster used by the client despite mainnet wording in the product configuration.
docs/audits/global-config-genesis-devnet-2026-07-15.json
Provides dated Devnet observations used only where this page makes a deployed-account claim.