What’s in Atlantis? EIP-170 (Contract Code Size Limit)

Stevan Lohja
Jun 5 · 3 min read

During the core dev Atlantis call on May 30th, some developer stakeholders expressed uncertainty or alternative solutions to EIP-170.

EIP-170 introduces a code size limit of 24 kilobytes. This is a precautionary measure due to dynamic gas limit rules. A contract call takes a constant amount of gas but can trigger O(n) cost in terms of reading the code from disk, preprocessing the code for VM execution, and also adding O(n) data to the Merkle proof for the block’s proof-of-validity. While this is not an issue at current gas limits, it can cause inconvenience at higher gas limits. The solution is adding a hard cap to contract code size limits.

By enacting a limit sooner than later, we mitigate colossal sized contracts being deployed on the network. If someone desires a contract greater than the specified hard cap, then this can be accomplished by using multiple smaller contracts.

Community QA Highlights

Does EIP-170 cause issues with existing large contracts on ETC?

No. Large contracts deployed before the fork will not be affected to ensure backward compatibility. However, contracts equal to and after the fork’s block number will be affected by the hard cap.

Will rejected large contracts lose initial ETC?

No. The transaction will not be rejected and the value will not be lost. The transaction will operate normally.

Can these rules be applied via a soft-fork rather than a hard-fork?

Yes, but EIP-170 has no mutability concerns and maintains compatibility with ETH test-suites. With our size, including it into Atlantis is the most feasible option. These contract caps may also be changed in future forks if need be.


If block.number >= FORK, then if contract creation initialization returns data with length of more than0x6000 (2**14 + 2**13) bytes (24 kb), contract creation fails with an out of gas error.



Jade is coming!

Jade-service-runner has been released. Service Runner is an opinionated JSON-RPC service manager, that provides daemonization, installation, and discovery for JSON-RPC based services.

Allows dApp developers to specify what services they’d like to use:

  • Provides defaults for the services to run
  • Provides users with an easy installation path
  • Provides reliable discovery of pre-existing services run by the service runner
  • Provides OpenRPC interface to the Service Runner functionality, as well as the underlying services
  • Allows dApp developers the ability to retrieve reliable JSON-RPC connection information from the service
  • Provides typed interfaces to develop applications against

Jade-service-runner is a fundamental milestone in the Jade tooling to come that will improve the dApp development environment.

Interested in getting more involved with ETC? We’re focused on accelerating the development of Ethereum Classic and need your help! Reach out to us to see how you can get more involved today!

Our team links: About, Github, Medium, Twitter

Come chat with us on Discord


ETC Labs Core is the ETC core development team of ETC Labs. https://github.com/etclabscore

Stevan Lohja

Written by

Technology Coordinator at ETC Labs. Previously Technical Writer at ETCDEV Team.


ETC Labs Core is the ETC core development team of ETC Labs. https://github.com/etclabscore