⚠️ Alpha · testnets only. ChainRender is in active alpha and deployed on testnets only — Ethereum Sepolia, the Robinhood Chain Testnet, and the Circle Arc Testnet — not on any mainnet. Contracts, addresses, and APIs may change. Do not use with real funds or production assets.
← Back to chainrender.orgOpen the Visual Builder ↗Markdownllms.txt
Concepts

On-Chain Size Limits & the Glamsterdam Upgrade

ChainRender stores your app as bytecode on-chain, so Ethereum's contract-size limit is a real constraint the architecture is built around — and an upcoming upgrade may relax it. This page explains the current limit, how ChainRender already handles it, and what Glamsterdam could change.

A note on forward-looking content. Ethereum's roadmap evolves. The specifics below are accurate as of this writing but may change — always check the current status of any EIP before relying on it. ChainRender is designed so that none of these outcomes require it to change; that design is the durable part.

The current constraint: EIP-170's 24 KiB limit

Since EIP-170, a single contract's deployed bytecode is capped at 24,576 bytes (24 KiB). ChainRender stores app components as bytecode (via SSTORE2 — cheap, immutable code-backed storage), so this cap bounds how much a single stored chunk can hold.

This is why ChainRender was architected with two mechanisms from day one:

  • SSTORE2 chunked storage — large apps are split across multiple code chunks, each within the limit, and reassembled at render time.
  • Paginated reads (IChunkedRender) — large outputs (a world atlas, a long table) are read in chunks that concatenate byte-identically to the whole, so an app can exceed any single-call bound.

The result: the 24 KiB limit constrains a chunk, not an app. ChainRender apps are already effectively unbounded in size through chunking — today, on every chain, unchanged.

The design that makes upgrades a non-event: the ChainProfile seam

Critically, no ChainRender contract hardcodes 24576. The size ceiling lives in exactly one place — a ChainProfile — and every component reads the ceiling from it (maxChunkPayload(), etc.). This is a deliberate forward-compatibility seam: a chain with a different limit just uses a different profile.

Profiles already exist for both today's chains and a larger-limit future:

  • evm-legacy-24k — the 24,576-byte ceiling (pre-Glamsterdam Ethereum + L2s).
  • evm-glamsterdam-64k — the 65,536-byte ceiling for a Glamsterdam-enabled chain (EIP-7954).

So when the limit changes, ChainRender doesn't need new code — it needs a different profile at deployment. The upgrade is a config choice, not a rewrite. This is the "no layer hardcodes a current EVM constant" discipline in action.

What Glamsterdam could change

Glamsterdam is Ethereum's next major upgrade. It is live on Sepolia (since 2026-10-06); its Hoodi activation was postponed on 2026-10-22 and mainnet has no date. Its headliner changes are structural (enshrined Proposer-Builder Separation, Block-Level Access Lists for parallel execution), but two threads matter directly for on-chain apps like ChainRender:

1. A larger contract-size limit (EIP-7954)

Scheduled for Glamsterdam is EIP-7954, which raises the maximum contract code size from 24 KiB to 64 KiB (24,576 → 65,536 bytes) and the initcode limit from 48 KiB to 128 KiB (49,152 → 131,072). If it ships, each SSTORE2 chunk can hold roughly 2.7× as much, meaning markedly fewer chunks per app and simpler large components.

Status (updated 2026-10-23): Glamsterdam has been live on Sepolia since 2026-10-06. On 2026-10-21 a 65,535-byte chunk was deployed and byte-checked there, so ChainRender's Sepolia profile is now 64 KiB. Hoodi's activation was postponed on 2026-10-22 (to study EIP-8037's effect on mainnet contracts) and mainnet is unscheduled. Confirm the live status on Forkcast before trusting any date.

The number, verified against EIP-7954: the code limit rises 24,576 → 65,536 bytes (64 KiB, 0x10000), and the initcode limit 49,152 → 131,072 bytes (128 KiB, 0x20000). A stored DataChunk is deployed code, so the chunk ceiling becomes 64 KiB. (Earlier drafts and some client work used 0x8000 = 32 KiB; the EIP of record now specifies 0x10000. Confirm on the live chain with a near-64 KiB test chunk before relying on it — the doc-101 runbook does exactly this before raising the chain profile.)

2. State-creation repricing (EIP-8037) — this makes deploys ~7× pricier (measured)

Glamsterdam reprices state creation (EIP-8037): the cost of deployed code rises from ~200 gas/byte to ~1,530 gas/byte (the client's cost_per_state_byte is fixed at 1530 for Glamsterdam). Measured on Sepolia (October 2026), one stored chunk costs ~208,723 gas plus ~1,558.9 gas per byte, against ~52,518 + 216.4 before the fork: about 7.2× per byte. Because ChainRender stores apps as code (SSTORE2), this hits deploys directly — it is not modest, and earlier drafts of this page understated it.

The two size EIPs therefore pull in opposite directions:

  • EIP-7954 (64 KiB code) → markedly fewer chunks per app.
  • EIP-8037 (~7.2× per byte, measured) → each byte you deploy is much more expensive.

The net effect on a given app's deploy cost depends on its size and is a real tradeoff — do not assume the bigger limit means cheaper deploys. Benchmark it with scripts/compare-deploy-cost.mjs against the post-fork schedule before relying on any savings. (Related repricings EIP-7976/EIP-7981 raise calldata-floor and access-list costs, which also touch deploy transactions; EIP-7778 removes refunds from block-gas accounting.)

3. The transaction gas limit now sets the chunk size, not the code-size limit

One chunk is one transaction, and under EIP-8037 a full 64 KiB chunk costs ~101.6M gas (measured). That is more than a wallet will usually send: a 45,000,000-gas MetaMask transaction is proven on Sepolia, and Hardhat's local signer refuses anything above 30,000,000. So each chain's entry in chains.json carries a txGasCap (Sepolia: 45,000,000) and its measured storageGas, and the visual builder sizes every chunk to fit both: the smaller of the code-size ceiling and what the gas cap can pay for, after a 20% estimate margin and a 500,000-gas registration reserve. On Sepolia that is about 23.6 KB per chunk — below the 64 KiB code ceiling — and the builder refuses to send a transaction whose estimate exceeds the cap rather than letting the wallet warn "likely to fail". Raising the cap is a manifest change, made only after a larger transaction is proven on that chain.

What does not change: ChainRender's render path is a free view call — reads are unaffected by any of these write/create repricings. The cost story is entirely about deploying, never viewing.

What this means for you as a developer

  • Today: build without worrying about size — chunking handles it, transparently. The limit constrains a chunk, not your app.
  • When Glamsterdam ships EIP-7954: your existing apps keep working unchanged (backward-compatible); new deploys on updated chains can use the larger profile for fewer chunks — but each stored byte costs ~7× more (EIP-8037), and the per-transaction gas cap limits how big a chunk can be in practice. You change a deployment profile, not your code.
  • Rendering stays free forever — a view call — no matter how gas schedules or size limits change. The repricings touch deploy/write costs, not reads.

Cross-chain & cost roadmap — what actually helps (and what doesn't)

It's tempting to look at the flashy "cross-chain" EIPs for cost relief, but for ChainRender's specific constraint — the cost of storing app bytecode on-chain — most of them are irrelevant. Here's the honest ranking, grounded in what touches ChainRender's storage/deploy cost versus what's generically hyped.

Verify status + timing. The roadmap shifts monthly and dates slip. Treat everything below as "on the radar," and confirm live status on Forkcast / the EF roadmap before relying on any of it.

Tailwinds (genuinely help ChainRender)

  • Blobs + PeerDAS + blob-count increases (EIP-4844, EIP-7691, EIP-7742, PeerDAS). The biggest lever. Blobs already made L2 data 90–99% cheaper; PeerDAS (expected late 2026/early 2027) and higher blob counts keep pushing L2 storage cost down. This is why deploying on an L2 is the real cost answer — see L2 Deployment Strategy. The ecosystem is optimizing exactly the cost that dominates ChainRender.
  • Larger code limits (EIP-7954, Glamsterdam). 24→64 KiB (~2.7×) = markedly fewer chunks per app. A real win, though (see above) partly offset by EIP-8037's ~10x code-deposit cost.
  • Block-space capacity (BALs, EIP-7928). Parallel execution + higher future gas limits mean more block-space headroom for chunked deploys ecosystem-wide.

Headwinds (make on-chain storage more expensive — watch these)

  • EIP-8037 (state-creation repricing, Glamsterdam). ~10x on code deposit. Already covered above — the single biggest near-term cost change for ChainRender deploys.
  • EIP-8032 (Size-Based Storage Gas Pricing). Proposed: make SSTORE cost scale with a contract's storage size to discourage state bloat. Because ChainRender stores apps as state/code, this cuts against the model if it ships. Not scheduled as of writing — but the one to watch, because it's philosophically aimed at exactly what ChainRender does (put durable data on-chain). Monitor its status.

Not relevant to storage cost (don't be misled)

  • ERC-7683 (cross-chain intents), EIP-7702 (smart EOAs / account abstraction), chain abstraction. These improve user UX across chains (one signature, gas sponsorship, cross-chain orders). They matter for the action layer of apps a developer builds with ChainRender — but they do nothing for ChainRender's storage/deploy cost. Useful to know; not a cost fix.

The strategic conclusion

The highest-leverage cost decision isn't waiting for an EIP — it's where you deploy today. L1 storage is 10–1000x pricier than an L2, and the L2 cost curve is bending down (blobs → PeerDAS). So: deploy real apps on an L2, keep L1 for flagships, watch EIP-8032 as the headwind, and treat Glamsterdam's bigger 64 KiB limit as a real but EIP-8037-offset help. The full decision framework is in L2 Deployment Strategy.

The durable takeaway

The specific numbers and timelines will keep moving — that's the nature of a live protocol roadmap. What's durable is that ChainRender abstracts the limit behind a single seam, so whatever Ethereum settles on, adopting it is a profile change, not an architectural one. The system was designed to inherit protocol improvements without rework — bigger contracts, cheaper storage, new execution models — as they arrive.

Related

← Trust Signals & LineageRich Media: p5.js & three.js →