Contract reference Mining5 source only Source e0617449

DotGrid format and identitiesLink to this section

TL;DRLink to this section

DotGrid v1 generates the same traits, SVG and JSON from the same visual page, collection seed and token ID.
Strict calls check chunk hashes and validate the full page; pinned calls require an exact page root already validated.
Check renderer, validator, page and NFT identities separately; one matching hash does not verify them all.

ResponsibilityLink to this section

The renderer reads visual data stored in contract code and generates each token's image and metadata. NFT ownership, Level, reward balance and settled work do not affect its output.

This visual data forms a logical page with a 44-byte header and ten ordered sections: strings, derivation, palettes, glyphs, optics, field, arrays, sets, tables and programs. The page bytes live in root and chunk contracts, not editable hosted files.

Dependencies and authorityLink to this section

Component	What to verify
`DotGridRenderer`	Exact canonical runtime; renderer ID `keccak256("sqk.dotgrid-renderer.v1")`
`DotGridPageValidator`	`Renderer`-created first CREATE child; separately runtime-pinned because renderer codehash does not commit to it
Page root	Exact runtime identity committing to chunk hashes
Page chunks	Derived root CREATE children, checked by strict reads
Collection seed	Nonzero fixed `NFT` seed that keeps each collection's trait generation separate
Token ID	Positive input within the allowed range; the renderer does not check that the NFT exists
`NFT` constructor	Performs strict validation and pins canonical renderer/page identities before later pinned renders

The page deployer installs the supplied code but does not check that it contains valid DotGrid data. Consumers must verify and validate the deployed page.

State and viewsLink to this section

`Renderer` view	Result
`rendererId()`	Canonical bytes32 renderer identity
`rendererVersion()`	`sqk.dotgrid-renderer.v1`
`pageValidator()`	Full-validation contract address
`validatePage(page)`	Strict read plus validation; logical page hash and asset-set hash
`traitWord(page, seed, tokenId)`	Packed deterministic trait choices
`resolvedFieldHash(page, seed, tokenId)`	Deterministic resolved-field commitment
`renderSVG(page, seed, tokenId)`	Strict validated SVG string
`tokenURI(page, seed, tokenId)`	Strict validated base64 JSON data URI
`renderSVGForPinnedPage(page, codehash, seed, tokenId)`	SVG using exact previously validated root identity
`tokenURIForPinnedPage(page, codehash, seed, tokenId)`	Metadata using exact previously validated root identity

Metadata fieldsLink to this section

Field	Meaning
`name`, `description`	Page-defined text with token-specific title
`image`	`data:image/svg+xml;base64,` embedded SVG
`attributes`	Deterministically selected trait names and values
`properties.renderer`, `rendererId`	`Renderer` version and commitment
`properties.pageHash`, `assetSetHash`	Logical page and renderer-bound asset identity
`properties.traitWord`, `resolvedFieldHash`	Derivation and resolved-field evidence
`properties.emitters`	Active emitter count in the resolved result

The asset-set hash identifies both the page content and the renderer: keccak256(ASSET_SET_DOMAIN || RENDERER_ID || pageHash), with domain keccak256("sqk.dotgrid-asset-set.v1"). It is different from the root codehash and logical page hash.

ActionsLink to this section

Rendering and validation are read-only calls. They cannot change tokens, rendering settings or reward rules.

A DotGridPage constructor creates chunk contracts in order, then installs the root code. The canonical Genesis page deployer uses verified generated bytes; NFT construction then validates the full page identity.

Use strict calls for a new page. Use pinned calls only after validating that exact root with the verified renderer and validator; supplying a codehash alone does not establish trust.

Events and errorsLink to this section

DotGrid emits no application state-transition events. The collection's ERC-4906 announcement notifies metadata readers without changing the fixed rendering inputs.

All structured validation/input failures use DotGridInvalid(uint16 code):

Code family	Meaning
1–5	Page size, magic, format, header or directory
10–14	Strings, categories, options or section trailing bytes
20–26	Derivation counts, seeds/tags, weights or trait capacity
30–31	Palettes
40–44	Glyph count, flags, path length/charset or trailing bytes
50–53	Optics, passes or opacity
60–64	Emitter field records, positions, reserved bits or glyph references
70–73	Arrays, bit width or padding
80–86	Sets, kinds, padding, ordinals or duplicates
90–97	LUTs, tables, update modes/arguments or trailing bytes
100–107	Program order/length, opcodes, references, arguments or key terms/ranges
110–112	Resolve-cost, SVG or URI budget
120	Segment structure or creation
121	Chunk hash mismatch
130	Token ID outside permitted range
131	Zero collection seed
132	Pinned root codehash mismatch

Not every integer in these ranges has an assigned error. DotGridTypes defines each exact code; token input checks run before page reads.

LimitsLink to this section

Resource	Exact maximum / requirement
Token ID	`1..2^192-1`
Seed	Nonzero bytes32
Page format	Magic `0x44475047`, format 1
Logical page / chunks	49,152 bytes / 3 chunks
Runtime	24,576 bytes per runtime
Canvas dimension / coordinate units	4,096 pixels / 64 units per pixel
Emitters	2,048
Trait categories / options	16 / 64
Derivation seeds	4
Palettes / glyphs	64 / 64
Glyph path	1,024 bytes
Optics / passes	16 / 4
Arrays / sets	8 / 64
LUTs / tables	64 / 1,024
Updates per entry / key terms	4 / 4
Resolve cost	6,000,000 under the specification's cost accounting
SVG / JSON / URI output	131,072 / 196,608 / 262,144 bytes

The resolve-cost limit measures work under the format's rules, not a fixed eth_call gas cost. An RPC can reject a valid render if it exceeds the RPC's gas or response limits.

The canonical Genesis page contains 25,800 logical bytes and one chunk; its generated identity source fixes the root, chunk, page and asset hashes. DotGrid accepts IDs beyond the NFT's 9,999 lifetime IDs, but rendering an ID neither mints it nor proves ownership.

SourceLink to this section

Mining5 source specification e0617449. First-party source is private; see source and release scope.

Records verified work and tracks settled rounds and Squeek blocks on Ethereum. Calculates rewards from settled work, holds funded SQK, and pays eligible NFT owners. The Miner ERC-721 contract. Tracks NFT ownership and coordinates minting and merges with Mining. Applies Core or Mining upgrades authorized by its governing Timelock. Generates Miner NFT artwork from fixed onchain visual data. Queues governance operations and enforces a delay before they can be executed. The SQK ERC-20 contract. Enforces the lifetime supply cap; only Mining can mint SQK. Checks that visual data conforms to the required DotGrid format. When new mining power starts earning. Minting and merging schedule it for a later round, and a checkpoint must process the change. A reward update that processes settled work and scheduled mining-power changes. It can make rewards available but doesn't pay them to an owner's wallet. The Miner NFT permanently burned in a merge. Its unclaimed rewards move to the survivor, but its image is not combined or kept. SQK issued under the mining reward rules. You can direct a share of your Miner's rewards to fund SqueekFi projects. The physical mining device that records accepted wheel-magnet passages as work. It is separate from the virtual Miner NFTs. Squeekchain's record of accepted wheel-magnet passages. It doesn't prove animal identity and isn't how Ethereum reaches consensus. Combining two eligible same-level Miners you own into one higher-level Miner. One NFT is permanently burned; the survivor keeps both Miners' unclaimed rewards. The completed Squeek blocks a Miner must wait through before merging. It measures completed work, not elapsed time or Ethereum blocks; transfers don't reset it. The power used to calculate a Miner's share of rewards when eligible and active. A larger share of total power can mean a larger share of rewards. A ten-minute period used to group measured work. The device saves a completed round's work total when measurement remained uninterrupted. The transferable token used for mining rewards. It has a lifetime supply cap and is separate from the Miner NFT and the device's work count. A completed amount of settled work. Enough recorded work completes one Squeek block; it is not an Ethereum block. Squeek Miner NFTs earn SQK linked to recorded wheel activity. Owners can direct a share of those rewards to fund SqueekFi projects. Squeekchain's ecosystem for hamster-powered onchain finance. Miner owners can choose to fund projects with a share of their SQK rewards. The Miner NFT you keep in a merge. It gains a level, keeps its ID and image, and receives both Miners' unclaimed rewards. A Miner's recorded reward balance that hasn't been paid to a wallet. It stays with the NFT when ownership changes. One wheel-magnet passage that met the device's counting rules and was saved. It records work, not an amount of SQK.