The Economics: Write Once, Read Free Forever

ChainRender has an unusual and powerful cost model: you pay gas once to store an app, then render it for free, forever. This page explains the model, the numbers, and why it works — because it's one of the strongest reasons to build on-chain UIs at all.

The core model

The asymmetry is the point: storage is a one-time write; rendering is an unlimited free read.

Why rendering is free

Rendering is a view function (renderHash) — an eth_call. Reads don't change state, so they cost no gas. Whether the interpreter does a little work or a lot, whether one person renders it or a million, whether it renders today or in ten years — it's always free to the user. There is no per-render cost, no metering, no rate to pay.

A common point of confusion: an RPC provider may cap the work a single eth_call can do (a gas cap on the call), but that's a provider-side limit, not a cost to the user. And ChainRender's paginated reads handle apps that exceed any single-call limit. The user never pays to render.

Why storage is a one-time write

App bytes are stored via SSTORE2 — a pattern that stores data as contract code rather than in storage slots. This is dramatically cheaper than naive SSTORE, and once written, the bytes are immutable and read cheaply (via EXTCODECOPY) forever. You pay the write once; every future render reads those same bytes for free.

Storage runs on the order of ~222 gas per byte (at write time). So a component's one-time deploy cost scales with its size — and after that, it renders for free indefinitely. There's no recurring cost, no renewal, no re-upload.

Concrete numbers

• A small component: a one-time write on the order of tens of thousands of gas (e.g. a simple registered component measured at ~64,000 gas), then free renders forever.
• A large on-chain library (p5.js + three.js core, gzipped): on the order of ~$20 to pin once at sub-1-gwei gas — a one-time cost shared by every scene that references it.
• The full framework (the ~60+ contract system itself): a one-time deploy measured around 82.5M gas — but that's the infrastructure, deployed once by the operator, not something an app developer pays. You deploy your app against the live framework.

(Gas figures are indicative and depend on size and gas price; benchmark your own components before mainnet.)

Why this changes the calculus

A traditional web app has ongoing costs — hosting, a domain, a CDN, maintenance — that never end and that someone must keep paying or the app disappears. ChainRender inverts this:

• No recurring cost. Pay the one-time write; there's nothing to renew.
• No hosting bill. There's no server (see No Hosting).
• Cost scales with size, not usage. A popular app costs the same as an unused one — because rendering is free. A million users cost you nothing.
• Permanence is paid-for, once. The app exists as long as the chain does, with no further payment.

This is what makes on-chain UIs viable as public goods: an app can be deployed once and serve everyone, forever, with no one needing to keep funding its existence.

The one-time costs, summarized

You pay gas once for each of these, then never again:

1. Register your app's component bytes (the app itself).
2. (Optional) Register a subname (a refundable stake, not a fee — you get it back).
3. (Optional) Seed a custom theme on-chain (once, if you commit one).
4. (Optional, operator-level) Pin a rich-media library (p5/three) if your app uses one.

Everything else — rendering, reading live data, applying themes, verifying — is free, forever.

Related

• No Hosting: How It Works — why there's no recurring cost.
• Content Addressing — the immutability that makes read-once-store-forever work.
• Deploying an App — the one-time write in practice.