Wizard Art: How Your Internet Wizard Gets Its Look

Every Internet Wizard is drawn from a library of hand-drawn components, composed by deterministic software at the moment you conjure. Its look is pinned to an immutable on-chain identity (serial, catalog, index, seed), so the same Wizard renders the same way every time, on any machine, with no image model in the loop. Changing your spell changes the orb and a few accents; time and real allocated Mana can add cosmetic prestige overlays. None of this affects rewards: every active Wizard holds exactly one share, whatever it is wearing. This page explains what is promised about the art, what is deliberately not promised, and what the current prototype assets mean for you.

What "generated at mint" means here#

The MIFI art system is closer to a very careful sticker book than to a text-to-image model.

Artists draw a compatible set of parts (poses, hats, faces, beards, robes, props, familiars) on a shared 1024 x 1024 template with fixed anchor points, stroke weights, and a curated palette. At conjure time, the protocol fixes which parts your Wizard is made of. A renderer then stacks those approved drawings in a pose-specific layer order and rasterizes them with a pinned, deterministic toolchain.

There is no live AI call when you conjure. Nothing is prompted, sampled, or "reimagined". If you re-render a Wizard next year from its on-chain state and the archived catalog, you get the same pixels.

Why this design: whole-image generation on each mint brings style drift, malformed hands and props, variable latency, and outputs nobody can reproduce later. A composed library gives the collection a single hand and a stable character, which is the point. Generative tools may be used by the art team during asset development; they are never in the mint path.

The identity of a Wizard#

Four on-chain facts fully determine a Wizard's base portrait. They are written once during conjure and never change.

Alongside these, the program stores an identity hash: a SHA256 over the length-delimited ids of the seven structural parts, in canonical order (pose, robe, hat, face, beard, prop, familiar). At conjure, the program verifies a Merkle proof that this hash is the one the catalog assigns to your art index, then reserves it permanently in a UsedIdentity account.

That reservation account is small but permanent. Its rent appears as a separate line in the conjure quote and is not refunded on dispel. Internet Wizards: Conjure, Own, Dispel has the full quote breakdown.

What we promise, and what we don't#

Three separate promises, in order of how easy they are to prove:

Things that are not promised, stated plainly:

• Not infinite art from a finite library. Each catalog has an exact count of valid combinations, computed by exhaustive enumeration and published in the frozen manifest. The app shows the real number, not the raw multiplication of a trait table. The intent is to add new catalogs with new artwork before the active one runs out. Because the 10,000 figure is only the simultaneous collateral limit, the art system is built to serve more than 10,000 historical mints.
• Not random. The order in which a catalog hands out identities is a public, predictable permutation (next section). It is not a lottery, it is not a "fair random draw", and it is never used for anything financial.
• Not economically rare. Some hats will be seen less often than others. That is charm, not yield. Traits, serial number, age, and prestige stage never change a Wizard's reward weight, which is always exactly one active share. Rarity-based rewards are explicitly out of scope.
• Not a mathematical uniqueness proof for visuals. Near-duplicate detection is a heuristic that flags candidates for a human to judge.

What makes two Wizards different#

Parts fall into three groups. Only the first defines identity.

A background recolor does not make a "new" Wizard, and the identity rules reflect that. The familiar slot may legitimately be none; the awkward pigeon is optional. Seeded jitter is bounded to a few pixels and never touches the face, hands, or orb, so the parts that make a Wizard readable stay put.

The visual language itself is fixed by an art contract: chunky, slightly uneven black outlines; flat fills with no gradients or effects; an oversized bent hat; a beard that does most of the facial work; mitten-simple hands; and a quiet single-color background. No text of any kind appears inside a portrait. Serial numbers, balances, and labels belong in the app, not on the wizard.

Catalogs, versions, and why old Wizards never get redrawn#

A catalog is a frozen manifest: the list of parts with their content hashes, the compatibility rules (a cloud beard hides a pendant, so the pair is excluded), the exact count of valid combinations, the issuance permutation constants, and the pinned renderer version. Its hash is committed on-chain in a Catalog account.

Anything that would change a rendered pixel for an already-issued Wizard is a breaking change and requires a new catalog. Old Wizards keep their pinned catalog and renderer for good. A later art update, a better rasterizer, a bug fix in a hat: none of these silently repaint a Wizard that already exists. New catalogs serve new conjures only.

New catalogs must also contain genuinely new structural artwork. Part ids name visual content, not files, and a build-time check diffs content hashes and ids across the full catalog history. Re-exporting the same drawing under a new version number does not make it new.

Each catalog carries a status flag, prototype or approved, and the app labels Wizards accordingly (see the prototype notice below).

How the next Wizard's look is chosen#

Within a catalog, identities are handed out by a simple modular permutation:

M     = exact number of valid structural identities in the catalog
j     = this catalog's issuance counter (0-based, stored on-chain)
index = (a * j + b) mod M        with gcd(a, M) == 1

The constants a and b are derived from the catalog hash when it is frozen and are published in the manifest. Because gcd(a, M) == 1, the mapping visits every index exactly once, so two conjures in the same catalog cannot land on the same combination. Anyone with the manifest and a calculator can check it.

It is also predictable: with the manifest in hand you can compute what the next few Wizards will be. We say so up front. This is a uniqueness mechanism, not a game of chance, and it has no bearing on money.

If the permutation ever points at an identity that is already reserved (for example, one issued from an earlier catalog), the conjure fails as a whole: no MIFI is locked, no conjure fee is taken, and the operator advances the counter past the offending index with a public repair instruction. There is no secret backend re-roll, and a user is never charged principal for a failed mint.

Spells change the orb, not the wizard#

Your active spell (see Spells) is visible on the portrait, but only within a bounded overlay: the orb color, the glyph drawn on it, and at most three small accent marks. Face, hat, beard, robe, prop, and familiar are untouched.

Changing spell updates the appearance overlay to the new spell. It does not sell anything already in the vault: a former Orange Wizard that switches to Sol keeps its balance of the configured tokenized BTC asset (shown in the app with its issuer, mint, and decimals) while its orb turns violet. The portrait shows the active spell; the vault's actual contents are on the profile page, where they can be read precisely rather than guessed from a color. All three spells receive the same gross SOL entitlement for the same period; the orb is decoration, not a multiplier.

Glyphs are source-controlled vector marks. No model draws them, so the "B" never grows an extra serif.

Prestige stages I to V#

A Wizard can earn cosmetic prestige from two durable protocol facts: how long it has existed, and how much SOL has been allocated to it over its lifetime. Both are read from chain. There are no USD thresholds, because a hat should not flicker when the market does, and no oracle should be needed to draw one.

The following thresholds are proposed launch defaults. They may change after cost measurement and are not a promise, a schedule, or a forecast of anything.

How the numbers are counted:

• Lifetime allocated SOL is the cumulative SOL settled to the Wizard from the Mana Pool before any spell execution. Choosing Orange, Sol, or Infinity therefore neither helps nor hurts prestige. Unsettled entitlement counts toward the estimate shown in the app without double-counting amounts already settled.
• Timing follows receipt-time entitlement: SOL counts when the protocol actually receives and allocates it, not when a trade happened on a venue.
• Voluntary deposits, principal, and rent do not count. The number of processing transactions does not count either; splitting one execution into many would earn nothing.
• Whether a Wizard ever reaches a given threshold depends entirely on actual protocol activity. Conjure fees come from new conjures; trading fees come from trading. If activity is quiet, stages arrive slowly or not at all.

Rules that always hold:

• Stage never decreases: not on transfer, not after a spell change, not when prices fall.
• Stage is cosmetic only. A Stage V Archmage and a Stage I Internet Wizard each hold exactly one reward share.
• Overlays stay inside reserved areas of the pose template. A Stage V Wizard should read as the same character it was at Stage I, wearing slightly nicer things.

"Conjuring…" and the render pipeline#

Financial activation and image rendering are deliberately separate.

When your conjure transaction confirms, your Wizard already exists on-chain: it has its serial, its locked principal, its identity, and its reward share at the current index. Rendering the portrait happens afterwards in an asynchronous, retryable job. Until the first render is pinned, the NFT shows a branded "Conjuring…" placeholder. The app displays your serial and your usable financial position immediately; nothing about your money waits on a picture.

The pipeline works like this:

1. The render worker reads the Wizard's finalized on-chain state and loads the catalog whose hash matches.
2. It resolves unrank(index) to the seven structural parts and checks that their identity hash equals the one stored on-chain.
3. It composes the parts, applies the seed-driven palette, background, accessory, and jitter, then applies the current spell and stage overlays.
4. It rasterizes a 1024 px master, a 512 px display image, and a 128 px thumbnail, and pins them to content-addressed storage.
5. The Wizard's stable metadata URI is updated to point at the new image. The genesis render (Stage I, birth spell) is kept immutable forever, alongside the latest appearance.

Spell changes and stage milestones trigger a new render of the same identity. Previous renders remain retrievable. If the renderer is offline, previously published images stay available, the site shows an honest stale-state indicator, and settlement and dispel continue to work regardless.

Marketplaces cache metadata and may lag behind a recent spell change or stage update. The profile page in the app reads live chain state. Financial values are never written into NFT metadata; see Estimated NAV and Marketplaces for how vault contents and estimated NAV are shown.

Prototype art notice#

The current asset bank is PROTOTYPE art. The parts in the present catalog were drawn by the engineering team to prove the system: anchors, layer order, compatibility rules, deterministic rendering, and QA gates. They are honestly labeled prototype in the manifest and on-chain, and the app shows a PROTOTYPE ART banner wherever they appear.

The plan is to replace the prototype bank before mainnet with an approved production catalog: a hero Wizard and style sheet, at least twelve whole-character studies, six pose families with distinct silhouettes, and the full component library reviewed on contact sheets at portrait and avatar size. Production parts will carry the status approved.

Prototype renders are not finished collection art and should not be judged as such. They are also not a preview of any specific Wizard you might conjure: sample art in the app is labeled as a sample until your own mint identity exists on-chain.

Checking it yourself#

Because the inputs are public, anyone can verify a Wizard's art:

• Read serial, catalog_index, art_index, identity_hash, and art_seed from the Wizard's on-chain state or its Core attributes.
• Fetch the catalog manifest whose hash matches the on-chain Catalog account.
• Run unrank(art_index) and hash the resulting part ids. It must equal identity_hash.
• Re-render with the pinned renderer version. The decoded pixels must match the published image.

The renderer, manifests, and QA tests live in the packages/art and tests/art directories of the repository.

Related pages#

• Magic Internet Finance: Overview: what MIFI is and the one-sentence version of the product.
• Internet Wizards: Conjure, Own, Dispel: conjure, own, transfer, and dispel a Wizard; the full quote, including the permanent identity reservation.
• The Mana Pool: where revenue actually comes from, receipt-time entitlement, and how lifetime allocated SOL is settled.
• Spells: Orange, Sol, and Infinity in detail, and what changing spell does to your vault.
• Estimated NAV and Marketplaces: estimated NAV, marketplace listings, and why cached metadata can lag the chain.
• Risks and Disclosures: honest limitations, including that art, serial, and stage never change rewards.