Deploy consistently rejected with "gas limit too high" for contracts above ~26KB on Bradbury

[2TheMoom]

Summary

genlayer deploy fails with gas limit too high on Bradbury testnet for a
contract in the 26-33KB range, on every attempt across multiple days, while
smaller contracts (12-15KB) from the same account deploy cleanly in the same
window. The failure looks size-correlated rather than tied to a specific
opcode, import, or computation the contract performs.

Environment

• CLI: genlayer v0.39.2
• SDK: genlayer-js ^1.1.8
• Network: Bradbury Testnet, chain ID 4221
• Deploy path: genlayer deploy running the boilerplate's
  deploy/deployScript.ts via client.deployContract(...)

Error

GenLayer RPC error (eth_sendRawTransaction): [<txHash>]: gas limit too high

Error: Error during deployment:, InvalidParamsRpcError: Invalid parameters were provided to the RPC method.
Details: [<txHash>]: gas limit too high
Version: viem@2.37.2

Reproduction

Contract: contracts/recovery_arbiter.py in
https://github.com/2TheMoom/salvage-arbiter (public), commit d26d924.

1. genlayer account use <deployer>
2. genlayer deploy
3. Fails immediately with the error above. No retry count or backoff helps,
   it fails identically every time.

Four attempts from today alone, all with the same error:

• 0x270036dc493d16ad853b9cd4e6f9b22b2a8842670370718a0830c34ee998e4ff (32,847 bytes)
• 0xba1294cdc78fac3cc6229f414e83e8bd788796370cc3a93233f1f7546419dbdb (32,847 bytes)
• 0xb0927b2b546ccbdbee5aae846d70f9d86c49ee4666e0b49d3d360b9dff6dbeda (26,376 bytes, after trimming)
• 0x30d06bcba4a7823c586a1aff538cebfe435b8cae5144325092d0b27f695fea15 (26,376 bytes, after trimming)

This same contract has failed identically on every deploy attempt across
several days, well before today's four. Trimming the source ~20% (32,847 to
26,376 bytes, no logic change, same test coverage before and after) did not
help.

Size correlation

Two other contracts from the same account, deployed successfully around the
same dates with no gas errors at all:

Contract	Size	Deploy date	Result
waypoint.py	12,796 bytes	2026-09-23	Deployed clean, first attempt
tote.py	15,101 bytes	2026-09-24	Deployed clean, first attempt
recovery_arbiter.py	26,376 bytes	2026-09-25	Rejected, every attempt
recovery_arbiter.py	32,847 bytes	2026-09-20 through 2026-09-25	Rejected, every attempt

The threshold where this starts failing appears to sit somewhere between
15KB and 26KB, and hasn't moved across several days of retries.

Question

Is this a gas estimate that's currently miscalibrated for legitimately
larger (but still modest) contracts, or an intentional cap that's lower than
documented anywhere? If it's the latter, it would help to know the actual
limit so contracts can be sized against it up front instead of discovering
it by trial and error.

Happy to share the full contract source or try anything that helps narrow
this down.

[ygd58]

This is the same underlying issue as genlayer-cli#419, in a different repo — the size correlation you found (12-15KB fine, 26-33KB rejected) matches that thread exactly.

Root cause (already diagnosed in #419)

Bradbury enforces a fixed 16,777,216 (2^24) gas limit per transaction — a zksync-os runtime chain config value (DEFAULT_MAX_TX_GAS_LIMIT), added for EIP-7825 alignment. It's not documented anywhere, and eth_estimateGas doesn't enforce it (simulation skips the check), so you get no warning until the actual eth_sendRawTransaction — matching your exact error.

Python Intelligent Contracts need roughly ~730 gas per byte of source to deploy, so this fixed ceiling puts contracts above ~20KB at real risk, which lines up closely with your own 15KB-clean / 26KB-rejected boundary (a systematic binary search in #419 pinned the exact per-tx boundary at 16,777,216 gas for a small-calldata contract).

Full derivation, including a debug_traceTransaction-confirmed out-of-gas trace and the exact zksync-os PR that introduced the cap, is in genlayer-cli#419 — credit there to eudomar500 for tracing the mechanism.

To answer your question directly

It's an intentional cap (not miscalibration), currently undocumented, and it's a runtime chain config value — not baked in by a fork, so it's something GenLayer could raise on Bradbury without a network upgrade.

What might help right now

I opened genlayer-docs#566 documenting this (still awaiting maintainer review, not merged yet) — covers the exact ceiling, the ~730 gas/byte practical size implication, and the workaround of splitting a large contract into multiple smaller deploys if your contract structure allows it.