⚠️ 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 ↗
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, expected to reach mainnet in the second half of 2026. 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 Sept 2026): EIP-7954 is Scheduled for Inclusion in Glamsterdam (per EIP-7773, the hardfork meta). Sepolia activates Glamsterdam at epoch 353024 = 2026-10-06 13:53:36 UTC (per EIP-7773); Hoodi and mainnet remain undated, with mainnet targeted for Q4 2026. Dates have slipped repeatedly — confirm the live status on Forkcast or the EIP before trusting any fixed 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 ~10x pricier

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). In plain terms, contract deployment gets roughly a 10x cost increase. 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 (~10x code-deposit cost) → 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.)

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 and cheaper storage. 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 →