Market Folklore Legends turns market culture into collectible Unicode portraits. Brokers, believers, bears, frogs and exhausted optimists inhabit a world of trading desks, candle charts, sacred coins and questionable conviction. Every expression, accessory and punchline belongs to the same visual language: characters arranged into a picture.

There are {{legends}} Legends. This paper explains how their art is written and kept on chain, how their rarity is measured, and the rules of the game they play with {{tokenName}} ({{tokenSymbol}}), the collection's token.

## The text is the artwork

A Market Folklore Legend is a composition of Unicode code points, spaces and line breaks. Its face, clothes, surroundings, frame and lettering occupy the same 49-column, 54-row grid, presented at a 400:540 ratio. Box-drawing characters provide structure; blocks, geometric marks and unusual glyphs form expressions, textures and objects.

The stored work contains the characters and their placement. It contains no underlying painted pixel grid, JPEG or PNG. A browser renders the text onto a screen in the same way it renders a sentence. The display uses pixels; the artwork's source remains text.

Colour is a separate set of roles attached to the character cells. Skin, hair, clothing and market signals can receive different inks while the character sequence and geometry stay the same. Monochrome and colour are presentations of the same composition. A Legend that is switched off is drawn in white on black; switched on, it takes one of four palettes, chosen by its scene.

## A public seed, a reproducible identity

One fixed collection seed anchors the edition. It is hashed into a 32-byte value. For each token, the generator combines that value with the token number and a draw tag, using Solidity's fixed-width ABI encoding:

**Draw = Keccak-256(ABI-encode(seed hash, token number, draw tag + 256 × retry value))**

Keccak-256 produces a 256-bit integer. Separate tags select the archetype, the individual traits and the line of lore, so each selection keeps to its own part of the procedure. The same inputs and the same frozen rules always produce the same output.

The allocation does not use the owner's address, the time of minting or block randomness. A public fixed seed makes the whole edition calculable in advance, and no change of owner can reroll a character.

Which token number carries which Legend is settled only when the last Legend is minted: one random offset, recorded on chain, shifts the whole edition. Until then every token shows a card of question marks, on OpenSea as on this site, so nobody can choose a rare Legend by timing a mint.

## How a number selects a trait

Each compatible trait pool assigns a positive whole-number weight to every option. Add those weights to obtain a total W. Reduce the draw to its remainder after division by W:

**Selection position = draw mod W**

The options occupy consecutive ranges whose lengths equal their weights. The range containing the selection position supplies the trait.

For illustration, weights of 6, 3 and 1 produce ten positions. The first option occupies positions 0 to 5, the second 6 to 8 and the third 9. Their selection probabilities are about 60%, 30% and 10% across hash inputs. This explains the method; it is not a claim about any particular trait's weight.

The implementation uses the remainder directly, without rejection sampling, so there is a minute bias whenever W does not divide the 256-bit hash space exactly. Weights describe selection probabilities; they do not promise exact counts in a finite edition.

Pools also depend on context. The chosen archetype selects the relevant feature pools, and expression pools follow the face so that moods stay compatible. The artwork comes from drawn glyph fragments; the mathematics decides how they are allocated.

## From selected traits to written artwork

The selected features pass through a shared set of branching composition rules. Those rules choose drawing fragments for 32 ordered composition stages. Together they form an 84-byte recipe, derived in memory when needed.

A Solidity renderer reads the referenced fragments, decodes their glyph and colour-role data, and composes the fixed grid in order. It writes the card into the NFT metadata twice: as a complete HTML document of literal Unicode characters, which is the artwork, and as an SVG image of the same characters, which marketplaces use as the thumbnail.

The renderer does not store a recipe or a finished picture for each token. It stores the shared vocabulary and the rules for composing it. A Legend's place in the edition, with the frozen collection data, is enough to recover every choice.

## Distinct hashes and distinct pictures

A cryptographic hash makes repeatable selections possible. Several combinations of selections can still produce the same visible portrait or scene, so visual uniqueness needs a separate check.

Before deployment, the full edition is generated and checked for duplicates. If a token repeats an earlier portrait or scene, its retry value is advanced and its tagged draws are calculated again. Only tokens that need a retry receive a stored exception. These exceptions are frozen with the edition; minting never changes them.

The seed, supply, catalogues, weights, composition rules, retry values and rarity ranks are fixed together. Changing any of them defines a different edition, which would have to be checked again in full.

## Fully on chain: material and method

The deployment puts the shared drawings, glyph dictionary, palettes, labels, weighted trait pools, composition rules, retry exceptions and rarity ranks into immutable contract data on Robinhood Chain. The Solidity renderer reads those data contracts and reconstructs each card when asked. The collection's references to that data, and the order of the edition, are fixed when the collection is deployed and cannot be replaced. The renderer itself, the code that draws a card from the data, can be replaced by the team until the team locks it. The lock is recorded on chain and cannot be undone; after it, nobody can change how a Legend is drawn.

On-chain storage holds both the material the work is composed from and the procedure that selects and arranges it. A token's metadata carries the generated card itself, as HTML and as an SVG image, so reconstructing it needs no external image address, image-hosting account, IPFS gateway or remote rendering service.

Once deployed, the artwork can be rebuilt by reading the contracts even if this website disappears. It still needs access to the chain and a viewer that can show the text. The card carries its own monospaced font, so glyph shapes stay the same from one device to the next, and code points, positions and colour roles stay exactly reproducible.

These are the collection's deployment commitments. The collection's contracts have not been deployed yet.

## Rarity measured from the complete edition

Rarity follows OpenRarity 0.7.5, which evaluates the actual frequencies of the collection's 16 fixed catalogue attributes. Frequency is the share of the edition carrying a given value; a trait carried by fewer cards contributes more information. The method sums these contributions and normalises the total by the collection's entropy. [OpenRarity scoring](https://github.com/OpenRarity/open-rarity/blob/f2bc4d8b6e6eea1dd0a7f57017aa3d87d01fcc43/open_rarity/scoring/handlers/information_content_scoring_handler.py)

Ranking first counts the attributes unique to one token, then compares information scores. Scores equal within the reference tolerance share a competition rank, for example 1, 2, 2, 4. [OpenRarity ranking](https://github.com/OpenRarity/open-rarity/blob/f2bc4d8b6e6eea1dd0a7f57017aa3d87d01fcc43/open_rarity/rarity_ranker.py)

The ranks set five tiers. In an edition of {{legends}} they hold:

| Rank, as a share of the edition | Tier | Legends | Rarity factor |
| --- | --- | --- | --- |
| Up to 1% | Mythic | {{count.mythic}} | {{rarity.mythic}} |
| Above 1%, up to 5% | Legendary | {{count.legendary}} | {{rarity.legendary}} |
| Above 5%, up to 20% | Rare | {{count.rare}} | {{rarity.rare}} |
| Above 20%, up to 50% | Uncommon | {{count.uncommon}} | {{rarity.uncommon}} |
| Above 50% | Common | {{count.common}} | {{rarity.common}} |

Each token's rank will be stored on chain with the edition. A card's tier never changes: playing the game does not alter its rank.

## The game

A Legend plays with MFL. Switching it on (activating it) costs {{activation}} MFL. It can then be raised through five levels at {{promotion}} MFL each, so reaching the top costs {{ladder}} MFL in all. Every step, and retiring, has to wait {{cooldown}} after the Legend's previous step.

Every spend is shared. Half goes to the other Legends that are switched on, in proportion to their weight. The other half goes into the retirement fund. When no other Legend is switched on, the first half goes into the fund too. Nothing is burned.

A Legend's weight is its rarity factor times its level factor. The level factor is {{level.0}} when a Legend is activated, then {{levelSteps}} at levels 1 to 5. The Legend that pays never shares in its own spend.

A switched-on Legend earns in two ways: its share of what every other Legend spends, paid in MFL, and its share of the market fee, paid in ETH. The official MFL pool takes {{fee}} of the ETH side of every trade and passes all of it to the switched-on Legends, by weight. The owner can claim both at any time. Everything a Legend has, its level, its clock and what it has not claimed, stays with it when it changes hands.

## The Legendary Retirement Home

Any switched-on Legend can retire, at any level, {{cooldown}} after its last step. The retirement fund pays it {{payoutMultiple}} everything that was spent on it, times its rarity factor, together with anything it has not claimed. The Legend then moves into the Legendary Retirement Home, a contract that holds it for good: it can never be sold, moved or played again.

| Tier | Activated, then retired | Retired at level 5 |
| --- | --- | --- |
| Common | {{payout.common.start}} MFL | {{payout.common.top}} MFL |
| Uncommon | {{payout.uncommon.start}} MFL | {{payout.uncommon.top}} MFL |
| Rare | {{payout.rare.start}} MFL | {{payout.rare.top}} MFL |
| Legendary | {{payout.legendary.start}} MFL | {{payout.legendary.top}} MFL |
| Mythic | {{payout.mythic.start}} MFL | {{payout.mythic.top}} MFL |

The fund starts with {{fund}} MFL. Half of every spend flows into it, and so do {{unsoldFund}} of any tokens the auction does not sell. Only a retiring Legend can take anything out of it; nobody can change that.

The fund is not sized to pay every Legend in full. If most Legends climbed to the top and retired, it would run out before the last of them. When the fund runs short, a retirement pays what is left, and whoever retires names the least they will accept.

## The token

{{totalSupply}} {{tokenName}} ({{tokenSymbol}}) exist, all created at once. Nobody can create more, and the game burns none.

| Part | MFL | Share | What it is for |
| --- | --- | --- | --- |
| Retirement fund | {{fund}} | {{fundShare}} | Pays retiring Legends |
| Auction | {{auction}} | {{auctionShare}} | Sold to the public over {{auctionHours}} hours |
| Pool | {{pool}} | {{poolShare}} | Paired with every ETH the auction raises, locked for good |

No tokens are set aside for the team. If the auction leaves tokens unsold, {{unsoldFund}} go into the retirement fund and {{unsoldTreasury}} to a treasury in the team's multisig wallet.

## The launch

The launch runs in four steps.

| Step | What happens |
| --- | --- |
| Mint | {{legends}} Legends on OpenSea: {{mint.team}} free for the team, {{mint.whitelist}} on the whitelist at {{mint.whitelistPrice}}, {{mint.public}} in the public stage at {{mint.publicPrice}}. Up to {{mint.cap}} per wallet across all three stages. |
| Auction | {{auctionHours}} hours on Uniswap. For the first {{holdersHours}} hours only Legend holders can bid, and most tokens are released near the end. The lowest price values all MFL at {{floorFdv}}. If the auction raises less than {{minRaise}}, every bid is refunded. |
| Pool | Every ETH the auction raises goes into the MFL pool with the other {{pool}} MFL, locked for good. The team takes none of it. |
| Game | Opens. Rewards are paid from the first second. |

## Before you play

- Retiring is permanent. The Legend leaves your wallet for good.
- MFL's price moves. Spends and payouts are counted in MFL, not in ETH.
- The official pool takes {{fee}} of the ETH on every buy and every sell and passes it to the switched-on Legends.
- Other MFL pools will appear. Trades there pay the Legends nothing.
- The retirement fund can run short. Then a retirement pays what is left.
- The first Legend switched on collects every trading fee until a second one joins.
- Once the game opens, nobody can change these rules, pause the game or take MFL out of the fund.

## References

- [OpenRarity: the reference implementation, at the version used](https://github.com/OpenRarity/open-rarity/tree/f2bc4d8b6e6eea1dd0a7f57017aa3d87d01fcc43)
- [OpenRarity: trait-count handling](https://github.com/OpenRarity/open-rarity/blob/f2bc4d8b6e6eea1dd0a7f57017aa3d87d01fcc43/open_rarity/models/token.py)
- [Robinhood Chain documentation](https://docs.robinhood.com/chain/)