> For the complete documentation index, see [llms.txt](https://cifer.gitbook.io/cifer-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cifer.gitbook.io/cifer-docs/ghost-economy/mint-reveal-and-art-provenance.md). # Mint, reveal and art provenance The character system separates **genome creation** from **image production**. Smart contracts enforce ownership and commitments; they do not run AI image generation. ### Founder preparation All 500 Alpha and 500 Omega founders should be generated, reconstructed through the approved production pipeline, and reviewed before mint. Each founder must pass: * Genome-schema validation. * Stage-seal validation. * Trait-to-image consistency review. * Uniqueness checks. * Visual and animation QA. * Genome-hash and image-hash verification. Bad, inconsistent, duplicated, or unreadable images are rejected and replaced before the collection is sealed. ### Sealed founder pool The founder assignment process should prevent Cifer from choosing a character after seeing the buyer. {% stepper %} {% step %} ### Finalize the collection Complete founder genomes, production assets, QA, and immutable identifiers. {% endstep %} {% step %} ### Seal and commit Publish or commit the collection root, genome commitments, supply split, and assignment rules before mint begins. {% endstep %} {% step %} ### Shuffle fairly Use an auditable, unbiased shuffle or reveal mechanism defined before mint. {% endstep %} {% step %} ### Assign at mint A whitelist mint assigns a character from the sealed, shuffled pool. Staff cannot secretly select traits after identifying the buyer. {% endstep %} {% step %} ### Reveal and verify Reveal the genome, image, hashes, art revision, and QA status so the holder can verify the committed character. {% endstep %} {% endstepper %} ### Ghost Egg preparation and reveal The campaign uses two independently accounted sealed allocations: | Allocation | Redemption route | Campaign role | | ------------------- | ------------------------------------------------------------------------- | ---------------------------------------------- | | Creator Reward Pool | Spend 100 MARK earned through validated contributions | The complete $20,000 creator reward allocation | | Direct Mint Pool | Mint for 0.004 ETH on Robinhood Chain through a verified Swaymark account | Separate capped paid allocation | An Egg is a hidden assignment to a precommitted character, not an instruction to invent a character after redemption. Before either pool opens, Cifer should disclose or commit: * Total supply for that pool. * Alpha, Omega, Wisp, and Fantom quantities and odds for that pool. * Assignment and shuffle method. * Reveal date and unclaimed-Egg treatment. * Genome, lineage, image, and QA commitments for every underlying character. * Creator Reward capacity backing the published MARK issuance. * Direct Pool supply cap and per-account limit. The two pools may share one reveal event, but inventory cannot be moved between them after creators, buyers, scores, wallets, or demand are known. A Direct mint cannot consume a Creator Egg reserved for MARK. Both pool commitments are bound to the Robinhood Chain deployment. Every successful Creator Egg redemption or Direct Egg mint creates one real sealed Egg NFT. There are no empty reveal outcomes. ### Dynamic Wisp and Fantom creation Wisp genomes are finalized during a valid Alpha/Omega Attic session. Fantom genomes are finalized when ten specific Wisps are selected for convergence. The creation transaction or associated commitment must record enough information to verify: * Eligible parents or contributors. * The randomness or selection commitment. * The finalized canonical genome hash. * The burned or locked inputs. * The final image hash and metadata revision when rendering completes. A Wisp or Fantom placed inside the campaign Egg pool must retain this complete lineage. Egg distribution cannot bypass the biological or convergence rules. ### AI-assisted concept art AI does not run inside the smart contract. AI-generated PNGs are concept references used to explore silhouettes, personality, trait combinations, and family resemblance. For production, final mint and animation assets should be reconstructed through the approved deterministic layered/vector pipeline. Given the same genome and approved art revision, the renderer should produce the same trait assembly and attributable output. ### Image binding and versioning The immutable genome is bound to the final art through a genome hash, image hash, and versioned metadata. * Before mint, a failed or inconsistent render is rejected and replaced before the pool is sealed. * After mint, a genuine rendering defect may be corrected only by re-rendering the same genome under an approved art revision. * A corrected render must preserve the original genome, publish a new image hash, increment the art revision, and retain the prior provenance record. * A rendering correction cannot secretly change rarity, lineage, stage, utility, or buyback eligibility. ### Provenance boundary The blockchain records or commits the immutable genome and creation lineage. Rendering systems produce the visual asset from that record. This separation keeps character identity verifiable without pretending that AI execution occurs on-chain. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://cifer.gitbook.io/cifer-docs/ghost-economy/mint-reveal-and-art-provenance.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.