Rarity Layers
Mirage Garden soTokens can use frozen, fully on-chain rarity layers.
Each layer is a visual slot such as Background, Body, Face, Hat, or Effect. Each trait inside that layer has a weight. When an object is born, the renderer uses the object seed to pick one trait from every layer by weight, then composes the image and metadata on-chain.
The object format is not limited to 24 x 24 pixel art. A project can use larger pixel art, SVG, or compact raster layers as long as the stored assets remain practical for Base deployment and rendering.
What is stored on-chain
The launch flow deploys:
- a trait storage contract with the layer names
- base64 image data for every uploaded trait
- the MIME type for each trait image
- the trait weight for every trait
- a renderer that reads the frozen storage table
The renderer writes rarity_bps into object metadata attributes. Viewers can also read the selected trait indexes and rarity percentages directly from the renderer.
Why storage freezes
Trait storage is frozen before the renderer is deployed. This prevents creators from changing weights or replacing art after collectors claim objects.
That freeze is part of the rarity guarantee: the object seed, layer table, image data, and weights are all on-chain and stable.
What about in-order drops?
The current Mirage launch direction is weighted rarity, not in-order edition assignment.
In-order would mean object #1 receives asset #1, object #2 receives asset #2, and so on. That is useful for deterministic edition sets, but it is a different renderer mode from layered rarity. The current creator UI does not expose in-order launches until that separate path is implemented.