ONE SHARED NAMESPACE
GlobalConfig is first an address anchor, then a data account
The Core Program ID and the single seed global-config derive one stable public key. On Devnet that PDA is 46bTKGThh96ChxJEmcKz6GvudGi3d7YDiAFtVhKb2Y5f with bump 253. Player profiles and sessions, broken-chunk records, foundations and buildings, Guardian registry and regions, and Smelting PlayerProgress either store this key or include it in their seeds. Backpack reward authentication reads the supplied root transiently. Market uses it during listing creation to validate PlayerProfile and equipment relationships, while Listing state, listing seeds, and the purchase flow do not contain it.
That makes the public key a strong namespace boundary: an account from another world root should not be interchangeable just because its other fields look plausible. It does not mean every consumer reads all 293 bytes. Several current programs validate only owner, length, magic, or address relationships; others read one field; some replace legacy world fields with current constants.
The program ID compiled into current Core, SDK, and dependent program configuration.
A 293-byte Core-owned PDA derived only from the fixed seed and Core Program ID.
Dependent PDAs bind to the address even when their transition does not consume the stored economic or terrain fields.
CURRENT CORE SOURCE
Instruction zero allocates once and writes constants chosen by the build
The current repository Core dispatcher accepts exactly one byte: zero. Initialization requires four accounts: a writable signer payer, the writable derived GlobalConfig PDA, the cluster-specific NCK mint, and the System Program. The payer cannot submit a seed, fee, world height, wallet, or hash in instruction data; the program writes compiled constants plus the observed genesis slot, timestamp, and derived bump.
Initialization is dust-safe. A prefunded system-owned zero-data PDA is topped up to rent exemption if needed, allocated, and assigned with the PDA signer seeds. A Core-owned account is rejected as already initialized, while a non-system owner or existing data is rejected. The account's sealed byte is written as one, but no downstream cryptographic mechanism is attached to that byte.
- Validate the address and mint
Re-derive GlobalConfig, require the configured SPL Token mint, and inspect the current supply against the genesis predicate plus both disabled authorities.
- Create or adopt the empty PDA
Create a zero-lamport account or safely allocate a prefunded system account after topping up rent.
- Pack one exact layout
Write all constants, verify the writer stopped at byte 293, and leave no current Core update instruction.
CLUSTER-LOCAL TOKEN INVARIANT
NCK identity is a mint key plus five byte-level checks
The devnet feature selects HSnWF5kjkWVrceW2SaSskScuLveUZE4gpthZ2ZXRPQPo instead of the mainnet mint. Core initialization requires that account to be owned by the legacy SPL Token Program, initialized, configured with six decimals, and carrying exactly one billion displayed NCK in base units at that moment. Both authority COptions must be zero.
The finalized Devnet snapshot at slot 476,367,811 still matched those conditions: an 82-byte mint account, supply 1,000,000,000,000,000, six decimals, no mint authority, and no freeze authority. This proves the current token account cannot inflate or freeze through those SPL Token controls. Holders can still burn tokens, so the supply can fall. The snapshot also does not prove that every price field in GlobalConfig is charged by a live instruction, nor that no separate token program or market can represent another asset.
Exactly 10^15 base units at six decimals in the audited Devnet mint.
The SPL Token COption tag is zero, so the current mint exposes no authority that can increase supply.
The mint exposes no authority that can freeze token accounts through the legacy SPL Token mechanism.
293 LITTLE-ENDIAN BYTES
The account records identity, hashes, economics, geometry, and time in one layout
Offsets zero through 11 hold NCKCFG01, version one, bump, and the sealed byte. The next 73 bytes hold the mint, decimals, supply, and development wallet. World ID and a 32-byte seed follow, then three 32-byte hashes intended to describe terrain configuration, resource rules, and the client world configuration. Sale, Guardian, fee, vertical-world, region, mining-cooldown, and creation fields fill the remaining bytes.
A 32-byte hash is only a commitment if verifiers know the exact preimage encoding and compare it. The local generator uses a recursively key-sorted JSON serialization before SHA-256, but the account stores no schema identifier, source path, or canonicalization version. The current resource-rule hash still matches config/resource_rules_v1.json, a placeholder fixture with no authoritative rules; that equality does not prove the live ResourceDropTable or SurfaceDecorationTable PDAs. The audited world seed, terrain hash, and client-world hash do not match the current generated files.
Current consumers generally use length and magic as their minimum format gate.
Terrain, resource rules, and client-world commitments without an embedded preimage codec version.
The account stores Unix time 2026-06-12T09:01:13Z and a slot shortly after the recorded Core deployment slot.
FIELD-BY-FIELD ENFORCEMENT
Each dependent program chooses a different GlobalConfig view
Current Chunk source validates the 293-byte envelope, reads the development wallet, and substitutes the current world seed, chunk size, vertical range, terrain ceiling, and sea level. Current Building source similarly validates length and magic but uses compiled 16, -32, and 320 geometry. Current repository Guardian source validates Core ownership, length, and magic for its registry namespace, then uses its own compiled 100-chunk region size instead of the stored value 64; deployment parity for that source is not established here. Backpack reads the stored chunk size when authenticating a ChunkBroken producer. Market calculates a one-percent fee from its own constant rather than reading GlobalConfig's market-fee field.
Player is the important counterexample: its current GlobalConfig view reads world ID, minimum build Y, and maximum build Y from the account. Position updates therefore follow the legacy stored maximum of 256 even though current Chunk and Building source use 320. Smelting uses the supplied root key to derive and bind PlayerProgress, while RecipeTable identity and layout do not contain GlobalConfig. A single label such as global configuration cannot summarize these different trust boundaries.
The account remains a valid root and format gate while legacy terrain bytes are overridden.
Current source reads offsets 263 and 265, leaving a 256-versus-320 vertical boundary.
The stored field is also 100 bps today, but equality of values is not evidence that Market read the account field.
Current repository Guardian derivation and records use their program constant rather than the legacy Core field; this is a source claim until deployment parity is established.
DATED DEVNET SNAPSHOT
The account, current world source, and local Core artifact have diverged
At finalized slot 476,367,811 on 2026-07-15, the GlobalConfig account was Core-owned, 293 bytes, version one, sealed, and rent-exempt. Its raw seed was ba1a9d446157c537af58fc5ff53a28422cdc6ab3dd88daa24095db3bd9c0f041; it stored maximum build Y 256, maximum terrain height 160, and sea level 2. The current generated configuration instead uses the padded text seed nicechunk-mainnet-001, maximum build Y 320, maximum terrain height 240, and sea level 96. Only the hash of the local placeholder resource-rule fixture among the three audited hashes still matched; that file is not the live ResourceDropTable or SurfaceDecorationTable state.
The upgradeable Core Program points to ProgramData CT1fyW3Yp9XZ1h4AdKRchr9gdqKcimxxAKVQjGBmtUyh, reports last deployment at slot 468,886,701, and retains authority 9XuoVVwqP2jipt3jpJVXCSS2N2jr9vDuV3d6K73FKVud. Its dumped 87,824-byte code hashed to 726326aa288f8ee05a5d9203326c90bab5fa7384ade4666bb838766016532e5c. The local target artifact had the same length but hash d72ae5d355083f98fbbe9553e5195bd94cb90353295e6733de6e3c12ce586404 and predates the current modified state source, so neither the artifact nor source is proven byte-identical to deployment.
Raw decoded bytes, retained for namespace and selective field use rather than current Chunk generation.
Compiled into current Chunk and Building source and applied by the browser chain adapter.
Deployed and local artifacts have equal length but different SHA-256 values; current source changed after the local artifact.
WHAT A VERIFIER CAN CONCLUDE
Verify the account, mint, program, and every consumer as separate layers
A strong account check derives the PDA, requires Core ownership, verifies length, magic, version, bump, and field offsets, then separately fetches the NCK mint and validates its program owner, supply, decimals, initialization, and disabled authorities. A source audit can prove that the current repository initializer packs constants and has no update tag. A deployment audit must additionally inspect ProgramData, dump the deployed code, and reproduce its hash from a controlled build before treating that source as executable truth.
Finally, inspect the transition that matters. Terrain verification follows Chunk's current GlobalConfigView and generator. Player movement follows Player's view. Building geometry follows Building's compiled view. Marketplace settlement follows its own fee constant. The same root address organizes all of them, but it does not collapse those independent programs, artifacts, and authorities into one immutable contract.
- Verify the root account
Derive the PDA and decode all 293 bytes with owner, magic, layout, bump, and snapshot slot evidence.
- Verify the external accounts
Inspect the NCK mint plus the upgradeable Program and ProgramData accounts instead of trusting stored public keys.
- Trace the consuming transition
Identify exactly which offsets or compiled constants the program handling the action reads, then verify its deployed binary separately.
ADDRESS, BYTES, SUPPLY, AND TRUST
Five equations separate the root account from the rules that actually execute
The first three equations cover deterministic addressing, the exact binary envelope, and the NCK mint invariant. The final two expose the runtime override and the extra condition required before a sealed account can support a protocol-level immutability claim.
One program-scoped root address
(GlobalConfig, bump) = findProgramAddress([utf8("global-config")], CoreProgram); Devnet bump = 253The seed is constant, but a PDA is also scoped by its program ID. The audited Core Program derives 46bTKGThh96ChxJEmcKz6GvudGi3d7YDiAFtVhKb2Y5f; many dependent PDAs include that public key to bind their own state to the same world namespace.
- CoreProgram
- The Core Program public key 9EhMCRYMJej1F21KzaA5Zao3khGGc5aJbDGbnxaogQHu.
- global-config
- The sole UTF-8 seed used by the current Core SDK and program.
- bump
- The off-curve derivation byte stored at GlobalConfig offset 10.
The binary layout closes at exactly 293 bytes
LEN = 12 + 32 + 1 + 8 + 32 + 2 + 32 + 3*32 + 2*8 + 2 + 4 + 8 + 7*2 + 9*2 + 2*8 = 293The sum follows the actual little-endian field sequence: header, mint, supply, wallet, world identity, seed, three hashes, sale limits, Guardian stake, seven basis-point fields, nine geometry and radius fields, genesis slot, and timestamp. A decoder that consumes more or fewer bytes is not reading this account format.
- 3*32
- Terrain configuration, resource-rule, and client-world hash fields.
- 7*2
- Guardian tax, protocol fee, market fee, slash, and three SOL allocation basis-point fields.
- 9*2
- Chunk, section, vertical bounds, sea level, Guardian region and radius, and mining cooldown fields.
The initializer accepts one exact supply and leaves only downward burns
S_cap = 1,000,000,000 * 10^6 = 10^15; acceptInit = initialized AND decimals=6 AND supply=S_cap AND mintAuthority=None AND freezeAuthority=None; thereafter S(t)<=S_capCore initialization checks the SPL Token mint account bytes before writing GlobalConfig. The July 15 Devnet snapshot still satisfies all five predicates. With no mint authority the legacy SPL Token supply cannot rise, although holders can burn tokens and reduce it below the initialization value.
- 10^6
- Six decimal places, or one million base units per displayed NCK.
- S_cap
- The accepted initialization supply and permanent upper bound, 1,000,000,000,000,000 base units.
- None
- A zero COption tag in the SPL Token mint-authority or freeze-authority field.
Runtime world values are an explicit override, not the raw account
C_runtime = override(C_chain, seed="nicechunk-mainnet-001", chunk=16, minY=-32, maxY=320, maxTerrain=240, sea=96)Current Chunk source reads only the legacy account's development wallet and substitutes compiled world constants. The browser keeps chainWorldSeedHex and chainSeaLevel for diagnostics, then applies the same current values. In the audited account, C_chain still has maxY 256, maxTerrain 160, and sea 2.
- C_chain
- The 293 bytes decoded directly from the audited GlobalConfig account.
- C_runtime
- The world parameters passed into current Chunk.js and canonical Chunk generation.
- override
- A deliberate field replacement in both the JavaScript chain adapter and current Chunk Program source.
A sealed byte is only one term in an immutability claim
protocolImmutable => accountUpdatePath=None AND coreUpgradeAuthority=None AND dependentUpgradeAuthorities=None AND consumersEnforceCommittedFieldsThe current account has sealed=1 and current Core source exposes only initialization, yet Devnet ProgramData names an upgrade authority. Dependent programs can also compile their own values or retain their own authorities. Therefore the implication's right-hand side is not currently proven.
- accountUpdatePath
- Any instruction in deployed code capable of rewriting the program-owned GlobalConfig bytes.
- dependentUpgradeAuthorities
- Authorities for the programs that interpret GlobalConfig during Player, Chunk, Building, Market, or other actions.
- consumersEnforceCommittedFields
- A field-by-field source and deployment check proving that stored values actually gate the relevant transition.
Current Core source dispatches only instruction zero
Rustprograms/nicechunk_core/src/lib.rspub fn process_instruction(
program_id: &Pubkey,
accounts: &[AccountInfo],
instruction_data: &[u8],
) -> ProgramResult {
if instruction_data != [0] {
return Err(NicechunkError::InvalidInstruction.into());
}
initialize_global_config(program_id, accounts)
}In the current repository source every payload except the one-byte zero tag is rejected. This proves the source has no update, pause, withdraw, or mutation dispatcher; deployment parity must still be checked separately.
Initialization rejects a mint with supply or authority drift
Rustprograms/nicechunk_core/src/lib.rspub fn validate_nck_mint(mint_data: &[u8]) -> ProgramResult {
// SPL Token Mint layout:
// 0..36 mint_authority: COption<Pubkey>
// 36..44 supply: u64
// 44 decimals: u8
// 45 is_initialized: bool
// 46..82 freeze_authority: COption<Pubkey>
if mint_data.len() < 82 {
return Err(NicechunkError::InvalidNckMint.into());
}
if mint_data[44] != NCK_DECIMALS {
return Err(NicechunkError::InvalidNckDecimals.into());
}
if mint_data[45] != 1 {
return Err(NicechunkError::InvalidNckMint.into());
}
if read_u64_le(&mint_data[36..44]) != NCK_GENESIS_SUPPLY {
return Err(NicechunkError::InvalidNckGenesisSupply.into());
}
if read_u32_le(&mint_data[0..4]) != 0 || read_u32_le(&mint_data[46..50]) != 0 {
return Err(NicechunkError::InvalidNckAuthority.into());
}
Ok(())
}The mint public key is selected by the cluster build, then its SPL Token bytes must match decimals, supply, initialization, and two disabled authorities before GlobalConfig can be created.
GlobalConfig bytes come from compiled constants
Rustprograms/nicechunk_core/src/state.rs writer.bytes(&CONFIG_MAGIC)?;
writer.u16(CONFIG_VERSION)?;
writer.u8(global_config_bump)?;
writer.u8(1)?;
writer.pubkey(&NCK_MINT)?;
writer.u8(NCK_DECIMALS)?;
writer.u64(NCK_GENESIS_SUPPLY)?;
writer.pubkey(&DEVELOPMENT_WALLET)?;
writer.u16(WORLD_ID)?;
writer.bytes(&WORLD_SEED)?;
writer.bytes(&TERRAIN_CONFIG_HASH)?;
writer.bytes(&RESOURCE_RULE_HASH)?;
writer.bytes(&CLIENT_WORLD_CONFIG_HASH)?;
writer.u64(STARTER_PACK_PRICE_LAMPORTS)?;
writer.u64(GENESIS_PASS_PRICE_LAMPORTS)?;
writer.u8(STARTER_PACK_MAX_PER_WALLET)?;
writer.u8(GENESIS_PASS_MAX_PER_WALLET)?;
writer.u32(GENESIS_PASS_MAX_SUPPLY)?;
writer.u64(GUARDIAN_STAKE_AMOUNT)?;
writer.u16(GUARDIAN_TAX_BPS)?;
writer.u16(PROTOCOL_FEE_BPS)?;
writer.u16(MARKET_FEE_BPS)?;
writer.u16(SLASH_BPS)?;
writer.u16(SOL_TO_LIQUIDITY_BPS)?;
writer.u16(SOL_TO_REWARD_BPS)?;
writer.u16(SOL_TO_DEVELOPMENT_BPS)?;
writer.u16(CHUNK_SIZE)?;
writer.u16(SECTION_HEIGHT)?;
writer.i16(MIN_BUILD_Y)?;
writer.i16(MAX_BUILD_Y)?;
writer.i16(MAX_TERRAIN_HEIGHT)?;
writer.i16(SEA_LEVEL)?;
writer.u16(GUARDIAN_REGION_SIZE_CHUNKS)?;
writer.u16(GUARDIAN_REALTIME_RADIUS_CHUNKS)?;
writer.u16(MINE_COOLDOWN_SLOTS)?;
writer.u64(genesis_slot)?;
writer.i64(created_at)?;The payer supplies accounts and rent, not arbitrary configuration values. Every semantic field except the observed slot, timestamp, and PDA bump is selected by the program build.
Current Chunk source treats legacy terrain bytes as an identity anchor
Rustprograms/nicechunk_chunk/src/state.rsimpl GlobalConfigView {
pub fn unpack(data: &[u8]) -> Result<Self, NicechunkChunkError> {
if data.len() != GLOBAL_CONFIG_LEN || data[0..8] != GLOBAL_CONFIG_MAGIC {
return Err(NicechunkChunkError::InvalidGlobalConfigData);
}
// Player/Profile/Backpack PDAs still bind to this account address, but
// all generated block results come from the current chunk.js world.
Ok(Self {
development_wallet: Pubkey::new_from_array(
data[GLOBAL_CONFIG_DEVELOPMENT_WALLET_OFFSET
..GLOBAL_CONFIG_DEVELOPMENT_WALLET_OFFSET + 32]
.try_into()
.map_err(|_| NicechunkChunkError::InvalidGlobalConfigData)?,
),
world_seed: CANONICAL_WORLD_SEED,
chunk_size: CANONICAL_CHUNK_SIZE,
min_build_y: CANONICAL_MIN_BUILD_Y,
max_build_y: CANONICAL_MAX_BUILD_Y,
max_terrain_height: CANONICAL_MAX_TERRAIN_HEIGHT,
sea_level: CANONICAL_SEA_LEVEL,
})
}
}Chunk still requires the correct account format and uses its development wallet, but canonical generation comes from current compiled constants. Merely decoding seaLevel from the Core account would describe the legacy value, not the block generator used by this source.
The browser preserves raw diagnostics before applying the same override
JavaScriptsrc/chain/nicechunkChain.jsfunction applyCanonicalChunkWorldConfig(config) {
if (!config || typeof config !== "object") return config;
return {
...config,
chainWorldSeedHex: config.worldSeed ? Buffer.from(config.worldSeed).toString("hex") : config.worldSeedHex,
chainSeaLevel: Number.isFinite(config.seaLevel) ? Number(config.seaLevel) : null,
worldSeed: Buffer.from(canonicalChunkWorldConfig.worldSeedHex, "hex"),
worldSeedHex: canonicalChunkWorldConfig.worldSeedHex,
chunkSize: canonicalChunkWorldConfig.chunkSize,
sectionHeight: canonicalChunkWorldConfig.sectionHeight,
minBuildY: canonicalChunkWorldConfig.minBuildY,
maxBuildY: canonicalChunkWorldConfig.maxBuildY,
maxTerrainHeight: canonicalChunkWorldConfig.maxTerrainHeight,
seaLevel: canonicalChunkWorldConfig.seaLevel,
canonicalSource: "chunk-v4",
};
}The chain adapter does not silently discard drift. It exposes the account's raw seed and sea level under diagnostic fields, then returns the current Chunk configuration to gameplay callers. The string chunk-v4 is only this adapter's source label; the current Chunk.js world generator independently defaults to generation version 5.
IMPLEMENTATION EVIDENCE
Where these claims come from
Each claim is intentionally scoped to a concrete implementation path. These references are for verification, not decoration.
programs/nicechunk_core/src/lib.rs
Declares the Core Program, dispatches only tag zero in current source, validates four initialization accounts, handles dust-safe PDA allocation, and checks the SPL Token mint bytes.
programs/nicechunk_core/src/state.rs
Defines the 293-byte layout, compiled genesis constants, exact field order, sealed byte, three hashes, economic values, world geometry, and byte writer.
programs/nicechunk_core/src/cluster_config.rs
Selects distinct devnet, testnet, and mainnet NCK mint public keys and the compiled development wallet.
programs/nicechunk_core/src/errors.rs
Enumerates the invalid instruction, PDA, mint, account-owner, authority, allocation, and packing failures used by Core source.
programs/nicechunk_core/Cargo.toml
Defines the cluster feature set and shows devnet as the default Core build feature.
sdk/nicechunk-core.ts
Derives GlobalConfig, builds the four-account initialization instruction, decodes every byte through offset 293, and rejects wrong length or magic.
scripts/init-global-config.ts
Builds instruction zero for the selected cluster and exits when the Core-owned GlobalConfig account already exists.
scripts/verify-global-config.ts
Fetches the derived account, checks its owner and configured NCK mint, then exposes decoded values and hashes for inspection.
scripts/generate-global-config.ts
Constructs current local world inputs, applies stable key-sorted JSON serialization, hashes three preimages, and emits the initialization reference data.
scripts/generated-global-config.json
Records the current local padded world seed, three expected hashes, canonical geometry, prices, limits, fees, and Guardian parameters.
scripts/core-script-utils.ts
Selects RPC, Core program, payer, and cluster-local NCK mint inputs for initialization and verification scripts.
tests/nicechunk_core.ts
Checks the exact GlobalConfig PDA, generated constants, every documented byte range, genesis supply scaling, fee-split total, and current local sea level.
docs/nicechunk_core_genesis.md
Documents the original one-time genesis design, instruction accounts, full binary layout, cluster build policy, verification steps, and dust-safety rationale.
src/chain/nicechunkChain.js
Loads and decodes GlobalConfig, preserves raw chain seed and sea-level diagnostics, overrides current world fields, and derives dependent gameplay PDAs from the root key.
programs/nicechunk_chunk/src/state.rs
Validates the legacy GlobalConfig envelope, reads its development wallet, substitutes current canonical world constants, and uses the root address across Chunk state.
programs/nicechunk_chunk/src/lib.rs
Validates Core ownership for supplied GlobalConfig and routes the resulting view into mining, foundations, rules, and progress transitions.
programs/nicechunk_player/src/state.rs
Reads world ID and stored minimum and maximum build Y from GlobalConfig while binding profiles, appearances, sessions, usernames, and invites to its key.
programs/nicechunk_player/src/lib.rs
Uses the stored vertical bounds for position updates and the stored world ID when initializing or migrating player state.
programs/nicechunk_backpack/src/lib.rs
Validates GlobalConfig length and magic and reads its stored chunk size when authenticating a signed ChunkBroken reward producer.
programs/nicechunk_backpack/src/state.rs
Defines Backpack records plus PlayerProfile and PlayerSession views used to authenticate owner and session relationships without treating GlobalConfig as inventory payload.
programs/nicechunk_building/src/state.rs
Validates the GlobalConfig envelope but substitutes compiled chunk size and vertical bounds for current Building geometry.
programs/nicechunk_building/src/building.rs
Applies the Building GlobalConfig view to BuildSite surface and active building height validation.
programs/nicechunk_building/src/lib.rs
Requires Core ownership for the root account and threads its program-specific view through building creation and indexing.
programs/nicechunk_guardian/src/lib.rs
Uses GlobalConfig as the registry and region namespace while its direct validator checks Core ownership, exact length, and magic.
programs/nicechunk_guardian/src/state.rs
Stores the root public key in Guardian registry and region layouts and validates that relationship independently of legacy terrain bytes.
programs/nicechunk_market/src/lib.rs
Computes the current one-percent fee from a compiled constant and uses a supplied GlobalConfig key only while validating PlayerProfile equipment relationships during listing creation.
programs/nicechunk_market/src/state.rs
Defines the 216-byte Listing layout and seller-scoped PDA; neither the record nor its seeds retain GlobalConfig.
programs/nicechunk_smelting/src/lib.rs
Uses the supplied GlobalConfig public key in PlayerProgress derivation and recipe execution without treating every stored Core field as a smelting rule.
programs/nicechunk_smelting/src/state.rs
Stores GlobalConfig in PlayerProgress, while RecipeTable layout and its table-ID PDA remain independent of that root.
sdk/nicechunk-player.ts
Derives the same Core root for Player instructions and decodes the GlobalConfig public key stored in profiles, appearances, and sessions.
sdk/nicechunk-chunk.ts
Includes GlobalConfig in ChunkBroken, foundation, resource-rule, and surface-rule PDA derivations and instruction account lists.
sdk/nicechunk-guardian.ts
Derives registry, treasury-authority, region, and neighbor PDAs from the supplied GlobalConfig public key.
sdk/nicechunk-building.ts
Derives BuildSite, manifest, shard, and Guardian blueprint authority addresses from GlobalConfig and foundation identity.
sdk/nicechunk-smelting.ts
Derives RecipeTable from its table ID independently, then uses the supplied Core root only to derive PlayerProgress for execution.
src/world/config.js
Defines the current client world vertical range and sea level consumed by local generation and the global-config generator.
public/mainnet.json
Supplies the current public world seed and world metadata used by the local configuration generator.
config/resource_rules_v1.json
Provides the placeholder local resource-rule preimage whose SHA-256 still matches the audited account's resource-rule hash; it contains no authoritative rules and is not either live rule-table PDA.
chunk.js/world/world-generator.js
Defines the current Chunk.js default generation version as 5, independently of the chain adapter's legacy chunk-v4 source label.
tests/worldgen_golden.ts
Locks representative current world generation inputs and sea level independently of the legacy account's raw world values.
tests/nicechunk_player_chunk.ts
Checks that Player and Chunk SDK instructions and decoded state consistently carry the derived GlobalConfig public key.
tests/nicechunk_building.ts
Exercises GlobalConfig-scoped BuildSite, manifest, shard, and blueprint authority derivations in the current Building SDK.
docs/audits/global-config-genesis-devnet-2026-07-15.json
Persists the finalized-slot account bytes and decoded GlobalConfig and NCK fields, compressed full ProgramData plus its ELF digest, rent thresholds, source-file digests, and the dated local-artifact comparison used by this guide.