Comparison to Alternatives
| ChainRender | Traditional dApp frontend | IPFS-hosted frontend | |
|---|---|---|---|
| UI location | On-chain | Centralized server | IPFS (content-addressed files) |
| Can the UI change under you? | No (content-addressed, on-chain) | Yes (server-controlled) | No, but discovery/pinning is off-chain |
| Renders from | A free eth_call |
A web server | An IPFS gateway |
| Trust disclosure | Graded (A/B/C) + itemized | None | None |
| Action safety | Declared + enforced on-chain | App-defined (opaque calldata possible) | App-defined |
| Themeable without redeploy | Yes (render-time) | Yes (it's just a server) | No (new CID) |
| Verifiable by a user | Yes (recompile + re-render) | No | Partially (CID matches files) |
When to use ChainRender: when the interface needs the same trust properties as the contract — canonical frontends for protocols, transaction-signing UIs where spoofing is a real risk, apps that must outlive their authors. When not to: rich, general-purpose web apps that need arbitrary code and don't need on-chain trust — a normal frontend is simpler.