Whitepaper eight sections

01The problem

A collectible and an instrument are normally two different things. You hold a picture because you like it, or you hold a bond because it pays, and the two have nothing to do with each other. When someone tries to join them the join is usually a second contract: stake the picture over here, collect the yield over there, and hope the two stay connected.

There is a second problem stacked on the first. Owning either one in public means being followed. An address that holds a recognisable token and collects a recurring payment is an address anyone can watch, and the more it earns the easier it is to find whoever is behind it.

Zomi answers both in one token. The picture is the instrument, so nothing has to be staked and there is no second contract to keep in sync. And a holder can point the payout at a shielded address, so what they are represented by and what they are paid are not the same trail.

02The pixel system

Every Zomi is 26 by 26 cells, which is 676 of them, and each cell holds one of eight colour slots. The slots are named by role rather than by value: ground, ground alternate, shell, shell shade, shell light, visor, eye glow, accent trim. Three independent draws fill them. A ground tone comes from ten, a shell plating from twelve, an accent family from ten, and the shade, light and visor values are derived from the plating so a shell stays one decision rather than four.

Seven layers draw in a fixed order: tone, ground, plating, shell, eyes, headwear, marks. Tone and plating are the colour draws and paint no cells; the other five are hand drawn string grids carrying their own anchors, so a small part like a mark is written at its real size rather than padded out. A layer paints only the cells it draws, which is how the ground shows through everywhere the shell is not. Headwear and marks are written in accent characters alone, so a crest can never borrow the colour of the head it sits on.

Two rules hold the whole thing together. Every shell leaves a visor plate open at the same fourteen by four cells, which is why an eye template never has to know which shell it landed on and why no combination can put a face's eyes in the wrong place. And the shell has to stand off its ground by at least 0.35 in relative luminance, measured the way a contrast checker measures text, or the plating is thrown away and drawn again.

03The engine

The engine is one pure function of one number. It seeds a small generator from the id, draws an accent family, then draws one option from each layer in order, paints them, and finishes with three texture passes that come off the same stream. No clock, no network, no randomness that is not derived from the id. Composing id 1337 gives the same 676 cells in this browser, in a build script and in a year.

That is what lets the same code render the six Zomi on the home page, the walkthrough on the engine page, all ten thousand in the explorer, the rank file and the share card. There is one engine and it is the one the page runs in front of you.

Ten pairs of traits are excluded because they do not compose well together. When a draw lands on one, the engine draws that one layer again from the same stream rather than nudging the result, so the exclusions never move the function off being a function of the id. The luminance floor on the plating is enforced the same way, and if thirty two draws all fail it takes the plating furthest from that ground, which makes the rule a guarantee for every one of the ten thousand rather than a tendency across them.

04Traits and rarity

Each option carries a weight, and the weights inside a layer are what a draw is made against. Weights are not decoration: they are the only thing that decides how often a trait appears, and changing one changes every rank on the site.

Rarity is not scored on the weights. It is scored on the counts, which come from composing all ten thousand once and tallying what actually came out. Every trait a Zomi carries contributes the issue size divided by how many Zomi carry that trait, and the sum of those is the score. Highest score is rank 1, and a tie goes to the lower id so the order never depends on who rebuilt the file.

The reason for scoring the counts rather than the weights is the exclusions. They move a trait away from the share its weight alone would give it, so a rank built on weights would describe a collection that was never issued.

05The bond

At mint the buyer picks a term: 30, 90 or 180 days. The term is written into the token and the contract has no function that changes it. It sets two things, the weight the token carries for ever, 10, 15 or 20, and the date before which nothing can be claimed.

The weight is what decides the share of the reserve. A 180 day Zomi accrues at twice the rate of a 30 day one, permanently, not just until maturity. Maturity only unlocks the claim.

Pending coupon belongs to the token, not to the address. When a Zomi is transferred the pending amount goes with it, so the new owner claims what the token has earned, and a buyer is buying the accrued position along with the picture. Claiming pays ETH to whoever holds the token at that moment.

06The reserve and the hook

The reserve is a balance held by the contract and kept apart from the mint proceeds. The owner can withdraw proceeds and cannot reach the reserve; that separation is the single most important control in the contract and it is the first thing to check in the code.

Accrual is an accumulator. The contract holds one index for the whole issue. When the reserve grows, the index rises by the growth divided by the total weight of every live token. Each token remembers the index it last settled at, so its pending amount is its weight times the difference. That is why a claim costs the same gas at ten tokens as at ten thousand.

What feeds the reserve is $Z0MI. The token trades in a Uniswap V4 pool with the Zomi hook attached, and the hook takes one percent of every swap, buy or sell, into the reserve. Anyone can also fund it directly. The hook arrives with the contract: no hook is deployed on this chain today and nothing on this site says one is.

07The shielded route

A holder can set a Zcash shielded address as the payout preference on a Zomi. The site validates it, including its checksum, and what reaches the chain is a hash of it. The address itself is never written on chain and never leaves the page unless the holder sends the transaction.

Two forms are accepted, a Sapling address beginning zs1 and a unified address beginning u1. They use different checksum constants and both are checked against the right one, so a single mistyped character is caught here rather than at payout.

What is honest about the state of this: coupons pay in ETH on Robinhood Chain today. The conversion rail that would honour a shielded route does not exist yet, and until it does a route is a stored preference that an off chain settler would have to act on. That is a trust assumption and it is listed as one in the contract controls.

08The contract

ZomiBond is an ERC-721 with the bond on top. It keeps Ownable2Step with renounce disabled, a pause, a reentrancy guard and the EIP-712 authorization the mint path is built on. Supply is capped at 10,000 as a constant and a batch at 20.

A mint is authorized off chain and settled on chain. The client signs what it is asking for, the server checks the signature, validates the metadata strictly and refuses rather than cleaning it, pins exactly what was signed, reads the contract's own nonce, price and hashing rule back before signing, and signs an EIP-712 authorization the contract verifies. The token uris and the terms are hashed together, so a term cannot be swapped after the signature was made.

This is the first tokenized bond you hold as a shielded pixel identity on Robinhood Chain. That claim is made once, here, and nowhere else on this site.

Nothing is deployed. Every page that would read the contract says so plainly instead of showing a zero, and the contract controls lists each power the owner has, each one the owner does not, and what remains a residual risk. The terms set out the same risks in plain language, together with what this site does not hold and what it does not promise.

When there is an address, it is announced from @ZomiV4Bond and written into the site configuration by a script that checks the code and the symbol over RPC first. That account is the only one this project posts from, and it is named once, here.