No Hosting: How ChainRender Actually Works
A ChainRender app has no host. There is no web server, no S3 bucket, no IPFS pin, no CDN — nothing that anyone has to keep running for your app to exist and work. This page explains how that's possible and why it's different from every other approach.
Where a normal app lives vs. where a ChainRender app lives
A normal web app is files (index.html, JS, CSS) sitting on a server. Someone pays for that server, controls it,
and can change or remove the files. Even a "decentralized" dApp usually works this way — the contract is on-chain,
but the frontend is hosted.
A ChainRender app is bytes stored on-chain (via SSTORE2) and rendered by an on-chain view function. To
display it, you call renderHash(hash) — a free eth_call that returns the HTML. There is no file on a server
anywhere in this picture. The app exists as long as the chain does, hosted by no one.
normal app: browser → your server → index.html (server can change/remove it)
ChainRender app: browser → any RPC → renderHash(hash) → HTML (on-chain, immutable, hosted by no one)
Why not just use IPFS?
IPFS is a real improvement over a centralized server — it content-addresses files, so a CID always refers to the same bytes. But IPFS solves a different, smaller part of the problem, and it has gaps ChainRender doesn't:
| IPFS-hosted frontend | ChainRender | |
|---|---|---|
| What's addressed | The frontend files (a CID) | The app itself (a hash), rendered on-chain |
| Availability | Depends on someone pinning the files | Guaranteed by the chain — nothing to pin |
| Discovery | Off-chain (you need the CID from somewhere) | On-chain (resolve a name → the app) |
| Live data | The files are static; data still needs a separate call | Data is read on-chain at render time |
| Rendering | Your browser runs the fetched JS (trust the code) | The chain renders it (analyzable, graded, safe by construction) |
| Verifiable trust | The CID matches the files — but the files can do anything | Graded A/B/C, enforced, actions declared |
The short version: IPFS makes the files immutable; ChainRender makes the app immutable, available, discoverable, data-live, and provably safe — with nothing to host and nothing to pin. IPFS still needs someone to keep the content pinned or it disappears; a ChainRender app can't disappear as long as the chain is alive.
What "no hosting" buys you
- Permanence. Your app outlives you, your company, your servers. No renewal, no re-pinning, no bit-rot.
- Censorship-resistance. There's no host to pressure, no domain to seize, no files to take down.
- Zero ops. No deploy pipeline, no hosting bill, no uptime to maintain. Register once; it renders forever.
- Verifiability. Anyone reproduces the exact app from the chain — trust becomes verification.
The one honest caveat
You still read through something — an RPC endpoint. The app and its output are on-chain and reproducible
(nobody can change what renderHash returns), but which RPC you query is your choice, and that RPC sees your
request (a metadata concern, not an integrity one). Use a private or light-client RPC if that matters to you. This
is the only "infrastructure" left, and it's swappable and optional — not a host of your app.