# 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.