Storage: fully on-chain
A generative collection stores its script AND its metadata in the contract. No IPFS, no Arweave, no pinning service - nothing to renew, nothing that can go dark.
The script lives in contract storage
On deploy, your script is written into the contract with SSTORE2 - the bytes are stored as the runtime code of tiny data contracts, which is far cheaper per byte than a plain string array. It goes up in chunks of about 24 KB, one transaction each, so a 50 KB script is two transactions. Then it is LOCKED: minting is blocked until the script is finalised, so nobody can ever mint against a script that could still change.
The metadata is on-chain too
tokenURI() and contractURI() are built on the fly as data: URIs - base64 JSON assembled by the contract itself. Marketplaces read them straight from the chain, so there is no gateway in the path and no cover image to host: a generative collection's artwork IS its live render.
What that costs, and what it buys
You pay the deploy gas once - and nothing after that. There is no storage fee, no pin to renew, no bundler invoice. In exchange the work is reproducible from chain data alone: anyone can re-run the script with a token's on-chain seed and get exactly the same artwork, for as long as Ethereum exists.
What that rules out
Because everything must fit on-chain, your script has to be self-contained: no fetch, no XHR, no external assets, no CDN font. Whatever the piece needs must be in the script (a CDN library the runtime already loads is fine). Shorter scripts also deploy cheaper, so trimming dead code has a direct cost benefit.
Nami lives at the top of the Help center. It knows every topic in this center and can walk you through your specific collection, wallet or transaction.