# Resolc bytecode size optimizations

**URL:** <https://forum.polkadot.network/t/resolc-bytecode-size-optimizations/17917>\
**Category:** Tech Talk\
**Created:** [June 23, 2026, 1:29pm UTC](https://forum.polkadot.network/t/resolc-bytecode-size-optimizations/17917 "2026-06-23T13:29:37Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Cyrill](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/cyrill/32/7339_2.png) [@Cyrill](https://forum.polkadot.network/u/Cyrill)\
**Post date:** [June 23, 2026, 1:29pm UTC](https://forum.polkadot.network/t/resolc-bytecode-size-optimizations/17917/1 "2026-06-23T13:29:37Z")

</div>

Hey everyone, brief update regarding code sizes on compiled Solidity.

While `pallet-revive` supports contracts of up to `1mb` in size, smaller contract code blobs get less startup and proof size overhead, which directly translates into more transaction throughput. Like [on the Rust side](https://forum.polkadot.network/t/update-on-cargo-pvm-contract-a-rust-sdk-for-smart-contracts/17896), we worked on bringing Solidity contract sizes down as well: We just released [resolc v1.3.0](https://github.com/paritytech/revive/releases/tag/v1.3.0). This version ships the `newyork` (NEW Yul OptimizeR Kit), an IR in between Yul and LLVM. Thanks to the `newyork` optimizer, we observe code size improvements typically between -20% up to -50% vs. resolc without `--newyork`.

As the result we can demonstrate: Business logic can be expressed in Solidity and JITed via PVM, while deployed contracts have about the same size (or can be even smaller) as well optimized Rust versions of the same business logic. Below chart shows a comparison of various popular ERC implementations in different languages or with different compilers (the pattern is quite consistent, I just took the ones from @smiasojed that aren’t synthetic benchmarks):

 ![image](https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/f/f859c379eb28f87adaa1bc129000680020627a94.png)

Notes:

- Contracts taken from [here](https://github.com/paritytech/contracts-boilerplate/tree/sm/pvm_macro/contracts).
- Stylus is a [forked version of the Stylus SDK](https://github.com/smiasojed/stylus-sdk-rs/tree/revive-integration) that can compile to PVM.
- I applied a small code change to [`revmc`](https://github.com/paradigmxyz/revmc) such that it targets RISC-V with `-Oz`, to match the target machine and optimization settings with resolc. The result isn’t a fully functional PVM blob but an .ELF object, but this gives us some hints into how bytecode recompilation would perform nonetheless.
- EVM still being a lot smaller in code size is expected and a structural trade-off for runtime performance gains via PVM JIT.

---

<div class="post-metadata">

**Author:** ![Alex](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/alex/32/765_2.png) [@Alex](https://forum.polkadot.network/u/Alex)\
**Post date:** [June 23, 2026, 1:41pm UTC](https://forum.polkadot.network/t/resolc-bytecode-size-optimizations/17917/2 "2026-06-23T13:41:26Z")

</div>

Huge congrats. Are there still some long hanging fruits with regards to optimization passes that can implemented?

---

<div class="post-metadata">

**Author:** ![Cyrill](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/cyrill/32/7339_2.png) [@Cyrill](https://forum.polkadot.network/u/Cyrill)\
**Post date:** [June 23, 2026, 2:14pm UTC](https://forum.polkadot.network/t/resolc-bytecode-size-optimizations/17917/3 "2026-06-23T14:14:07Z")

</div>

Thanks! I regard the low hanging fruits as picked for now. Potentially there are more significant code-size gains on the table if we combine significant efforts like our own Solidity frontend, dynamic linking and maybe custom opcodes.