The FUNI Engine

1 · Architecture

Four contracts, one hot path

The token holds two privileged references, both set once: mintingHook (immutable; the only address permitted to write trait seeds) and renderer (swappable by the artist role only, which allowed one live art upgrade already). The mirror is deployed by the token’s own constructor, so the pair is born atomically and cannot be mismatched.

One canonical buy, end to end

2 · The DN404 engine

Whole tokens have faces

Let B(a) be the ERC-20 balance of address a and U = 10^18 one whole token. For every address not exempted by the skip rule, the engine maintains:

N(a) = floor(B(a) / U)                    NFT count tracks whole tokens
invariant: mirror.balanceOf(a) ≤ base.balanceOf(a) / U   never over-minted

every transfer of amount x from a to b:
burn(a): max(0, N_before(a) - floor((B(a) - x)/U))        ids leave a
mint(b): max(0, floor((B(b) + x)/U) - N_before(b))        ids arrive at b

The transfer algorithm

Every token movement executes this sequence atomically, inside the ERC-20 transfer:

1. 1Debit sender, credit receiver. Standard ERC-20 accounting.
2. 2Compute NFT deltas from the crossing formulas, respecting each side’s skip flag.
3. 3Burn surplus ids from the sender into the FIFO burn pool.
4. 4Mint deficit ids to the receiver, recycling burned ids first.
5. 5Enqueue for reveal. Collect freshly minted ids, reset any stale trait seed, and push the batch to the hook via recordPendingMints.

The skip policy

The contract skip is what makes FUNI safe in any AMM: a pool holding 4,000 FUNI holds a plain balance, not 4,000 NFTs. The NFTs materialize only when tokens reach a wallet. And with the burn pool enabled, burned ids recycle first-in-first-out, keeping the live id range compact.

3 · Venue independence

The engine travels with the token

The claim: create any additional market for FUNI, on any protocol version, and the NFT mechanics continue to work, unchanged, with zero cooperation from that market. The argument is structural: the entire NFT engine lives inside the token’s transfer function, and any venue that delivers tokens must call transfer or transferFrom. There is no third way to move an ERC-20.

The honest nuance is the reveal-latency column: minting and revealing are separate steps. A foreign-venue mint shows placeholder art until the queue drains, and the queue is public and permissionless (requestReveal(), thirty ids per call, callable by anyone). Nothing can strand: current queue depth is zero, and after the largest mint waves a single script pass cleared thousands of ids.

4 · Trait lifecycle

The anti-cherry-pick rule

5 · The renderer

The entire collection lives on chain

The renderer stores the full sprite sheet in packed contract storage and assembles art on demand:

canvas: 128 × 128
rect:   5 bytes = (x, y, w, h, shadeIdx)
palettes: 36 body colors, 6 backgrounds
layer modes: RANDOM       per-NFT rolled color; shadeIdx picks dark/mid/light
             FIXED        layer ships its own "#rrggbb" palette
             BORROW_BODY  reuses the rolled body color (legs)

tokenURI(id) computes traits from the seed, walks the layers, and emits base64 SVG plus JSON in a single eth_call. The naive approach (nested string concatenation) is quadratic in memory and would revert on heavy pieces; the renderer uses a dynamic buffer for O(n) assembly, so the heaviest traits render in one call:

No server. No IPFS pin. No metadata rot. If the chain exists, the art exists, and any marketplace that calls tokenURI gets the full piece with zero infrastructure. The renderer address is swappable by the artist role only, exercised once in production to upgrade art quality without touching ownership or seeds.

6 · Gas envelope

Bounded by design, measured in production

Measured on chain 4663 (gas price about 0.02 gwei, so dollar costs are negligible; the engineering constraint is block gas, not price):

The 30-id reveal cap plus the contract-skip rule are the two governors that keep worst-case transactions bounded no matter how large a buy is or how much liquidity a pool holds.

7 · Game theory

Every actor, every attack, the defense in code

8 · Security posture

What can and cannot happen

• Reveal integrity. Only the immutable mintingHook can write seeds. Mint-without-enqueue is impossible by construction (loud revert). Stale seeds cannot survive a remint. Inline randomness is predictable and therefore, by policy, gates nothing until VRF is enabled behind its timelock.
• Reentrancy. The hook’s reveal path carries a dedicated guard; the token’s transfer engine performs effects before external interaction with the hook.
• Venue risk. Foreign pools cannot corrupt state: the worst a hostile venue can do is what any venue does, move tokens, which triggers exactly the engine in section 2. Contract skip caps their footprint at plain balances.
• Governance surface. Owner powers are narrow and enumerable: flip minting, flip the burn pool, swap the renderer (artist role, art only), and arm VRF behind a two-day public delay.

9 · Deployment record

Everything, verifiable