Seeds and fair minting

Reproducible editions, mint-order mixing and the limits of bot resistance.

An edition needs a repeatable identity. A mint also needs a fair allocation policy. A deterministic seed helps with the first; it does not, by itself, guarantee the second.

What the current platform gives you

The deployed contract increments the project's edition counter and emits the project, edition and token IDs when an edition is minted. The viewer obtains that event's transaction hash and passes it to the script. The contract does not generate a VRF seed or store a delayed random reveal.

A signed Ethereum transaction has a hash before it is included in a block. A determined minter can evaluate candidate transactions and their resulting art before submitting a preferred one. This follows from the transaction lifecycle described in Ethereum's transaction documentation.

The default for a new artwork

Mix the full mint hash, full edition ID and project ID, with a fixed version/domain, before deriving your drawing stream. Include all 64 hex digits of the transaction hash, not just its first few bytes. Normalize decimal IDs and keep the original mint hash separately for provenance.

The standalone helper implements this deterministic convention. It is synchronous, self-contained and compatible with the wizard examples. It uses non-cryptographic mixing for art variation; neither its 32-byte-shaped output nor its name implies cryptographic security. p5's random stream is initialized with a 32-bit value.

// Include the complete helper in your posted script first.
const seed = immutablesSeed(props);
p.randomSeed(parseInt(seed.slice(2, 10), 16));
p.noiseSeed(parseInt(immutablesSeed(props, 'noise').slice(2, 10), 16));
// Metadata still uses props.transactionHash, never seed.

Use separate named streams such as composition, palette and noise when adding a new random choice should not rearrange unrelated parts of the work. Keep their names and the seed version fixed after release.

The wizard's adapted built-in studies apply this full-ID convention. Loading a new example changes the editor after confirmation; it does not rewrite saved drafts or existing on-chain artwork.

What edition mixing improves

Different editions from the same transaction can produce different art. The final result also depends on the edition number assigned in mint order, so a hash-only shopping strategy cannot ignore ordering. Using the full ID avoids deliberately repeating an eight- or fifty-edition seed-selection cycle.

That is a limited mitigation. The next edition number may be predictable when minting is quiet. A bot can search against likely IDs; transaction ordering, private inclusion and builder influence can preserve an advantage. Hashing repeatedly, choosing a different substring, discarding random draws, obfuscating the script, or using a longer-looking seed does not create an unpredictable input.

When stronger allocation is required

A stronger design commits the purchase or allocation before its decisive entropy is available, then binds one later random result to it under rules the minter cannot selectively retry. Candidate mechanisms include a reviewed VRF integration or a carefully designed future-randomness/reveal protocol.

That design needs more than an artist-script edit: exact commitment and fulfillment rules, immutable association with each edition, no favorable rerolls, handling for failed reveals or unavailable entropy, a finality policy, preserved historical data, and viewer support. A commit/reveal scheme also needs to address participants withholding an unfavorable reveal.

Using the current timestamp, a recent block hash, or current prevrandao as a magic replacement is insufficient. Block producers can influence timing and randomness selection; EIP-4399 describes predictability and bias considerations. The generic viewer does not currently pass those values to scripts.

Bot participation is a different problem

A fair seed does not stop a bot buying many editions. Allowlists, allocation limits and gated eligibility may reduce unwanted participation when enforced by the actual mint path. A browser-only check is bypassable, and a per-address limit is not a per-person limit.

The deployed open mint method has no general wallet-limit, allowlist, commit/reveal or VRF parameter. Do not advertise those protections unless a verified contract integration actually enforces them. Coordinate a different launch mechanism before publishing a project that depends on one; see current and proposed features.

Test before you publish

The wizard's Hash & mint checks run automatically after you pause editing the script. Run checks now repeats them on demand; Stop cancels the current run. Results also appear as a status in Review & Deploy. Copy report includes the exact source's SHA-256, test inputs and findings so you can share it with a collaborator or LLM without including the unpublished source.

The suite uses 13 fresh isolated previews: a repeat of the baseline, edition IDs 2, 9, 51 and 257 against edition 1, changes at five byte positions across the hash, a different project ID, and a one-day clock shift. The global token ID stays fixed during the edition comparisons, so a token-ID dependency cannot masquerade as edition mixing. It compares observed p5 seed calls, logged traits and sampled canvas pixels. Provenance fields are excluded from the variation comparison, and the original transaction hash is checked separately in metadata.

Source checks point to calls such as Math.random(), fresh browser entropy, clock reads and short edition-modulo expressions. These are review prompts: a time-dependent animation or an intentionally repeating trait may be exactly what you want. Merely pasting the recommended helper into a script does not make an unused seed pass.

Visual repeatability is reported separately from seed calls and traits. If baseline pixels differ, the suite excludes pixels from the edition and hash comparisons so renderer variation cannot create a false pass. You will still see the visual review finding.

Interpret the evidence, not just the label. Changed seed calls do not prove that every trait uses that seed. Matching coarse traits do not prove two whole editions are identical. The suite samples an early animation moment at a fixed 360px size with a controlled clock; it does not exhaustively test animation, every hash bit, resizing, GPU behavior or external dependencies. Network requests are blocked in the isolated test frames. Missing output, failed initialization and unsupported dependencies remain inconclusive rather than receiving a pass. An edit invalidates the old report.

The allocation review remains even when the sampled checks pass: these are synthetic hashes, not signed mint transactions or an estimate of a bot's search cost. No browser-only artwork test can establish fair transaction ordering or enforce mint limits.

• Same mint hash and same IDs: identical traits and initial composition.
• Same hash, edition IDs 1, 2, 9, 51 and 257: distinct seed inputs, without modulo-only cycles.
• A change in the last bytes of the hash: reaches the derived seed.
• Resize and reload: preserve the edition's identity.
• Metadata: still carries the original transaction hash.
• Describe allocation protections precisely; never label a seed alone “bot-proof.”

Statistics across rolls

Use Analyze 100 rolls beside the preview, or choose 100, 250 or 1,000 under Statistics across rolls. The wizard automatically analyzes the batch when it finishes. Larger batches are deliberate runs, not something repeated after every keystroke. The current art preview and its hash stay in place, and quick seed checks pause while the batch uses isolated previews.

Two modes answer different questions:

• Random hashes, one fixed edition holds the preview project, edition and token IDs constant. Each roll uses a fresh uniformly sampled synthetic 32-byte hash. This explores variation over hash inputs for that edition.
• New hash for each sequential edition advances both the edition ID and the preview token ID from the chosen starting values. This describes a hypothetical sequence of editions; the preview token ID is not a prediction of the global token counter on chain.

The report shows counts, percentages, numerical histograms and summaries, missing metadata, repeated trait combinations, and repeated sampled-frame fingerprints. Percentages use all captured metadata records with a correct original mint hash. A trait's missing or invalid values are reported separately. Numeric summaries use finite number values that are present; numeric-looking text stays categorical. Raw hashes and IDs are excluded from trait profiles so provenance alone cannot make each roll seem unique.

Repeated profiles mean repeated reported traits, not identical art. The frame fingerprint is a coarse early-frame comparison, not a comparison of whole animations. Uneven frequencies can be intentional artistic weights. Without a declared target distribution, the report does not call them biased or defective.

For complete fixed-ID batches with no excluded records and no missing values for that trait, the report adds approximate 95% Wilson intervals for individual value frequencies. These intervals assume independent uniform hash sampling; they are not simultaneous bounds for every value, a probability that an interval contains the true rate, or guaranteed mint odds. Partial batches, failed renders, missing metadata and sequential-ID runs retain descriptive counts but have intervals withheld. The NIST handbook explains Wilson proportion intervals.

Small samples can miss uncommon outcomes. For a predefined outcome with probability p under independent rolls, the chance of seeing it at least once in n rolls is 1 - (1 - p)^n. The report illustrates this with a hypothetical 1% outcome; it does not assign that probability to an unseen trait or infer all possible trait values from the code.

Stop keeps a clearly labeled partial analysis. Three consecutive render failures stop the batch automatically. Changing the draft, renderer or preview seed IDs invalidates the previous report. Copy report includes every attempted roll, actual input IDs and hash, exclusions, sample mode and source fingerprint. Results stay in the current wizard session until replaced or the page is reloaded; copy anything you want to retain.

These are synthetic-input statistics, not signed transaction simulations. A seed-shopping minter need not sample hashes uniformly, so attractive distribution charts cannot establish resistance to adversarial selection. Use the quick checks, inspect the code and review the mint mechanism as separate evidence.

Source basis: anyoneMintProjectEdition in the deployed art contract, viewer mint-event decoding, and the primary references above.