# solx 0.1.2 - Smaller Binary Size When It Matters Most

By [ZKsync](https://paragraph.com/@zksync) · 2025-10-01

---

solx 0.1.2 targets binary size — cutting deployment costs and fitting more contracts under Ethereum’s 24 kB limit — without sacrificing gas efficiency or compile time. That focus turns into:

*   **Smaller binaries without losing gas efficiency.** Contracts compiled with `--via-ir` are **13% smaller on median vs 0.1.1**, and about **22% smaller than solc 0.8.30** `–via-ir`.
    
*   **More often under the 24 KB limit.** If a contract would exceed the cap, solx 0.1.2 optimizes for size more aggressively to make a contract deployable ([PR-854](https://github.com/matter-labs/era-compiler-llvm/pull/854)).
    
*   **Better code quality.** The compiler now eliminates unused stores (heap, transient, or persistent storage) ([PR-865](https://github.com/matter-labs/era-compiler-llvm/pull/865)) and generates more efficient conditional jumps ([PR-870](https://github.com/matter-labs/era-compiler-llvm/pull/870/files)).
    
*   **Improved tooling support.** Integration with **Hardhat v3** is now smoother out of the box.
    

This post walks through the current results and explains the optimizations in detail.

**Still Beta, But Better Than solc** `--via-ir` **in Every Non-Functional Metric**
==================================================================================

solx 0.1.2 remains in **beta**. It passes the full Solidity test suite, internal tests, and 24 real-world Hardhat/Foundry projects (e.g., Uniswap V4, Aave V3, Solady, Beefy, Lens). Code coverage is tracked; PRs that reduce it are not accepted.

QA is sufficient for development use — some teams already build with solx. Deploying **non-mission-critical** contracts is also viable today.

Raw benchmarking data is available in the **solx 0.1.2** [release PR](https://github.com/matter-labs/solx/pull/130#issuecomment-3263629087). The subsections below provide a summary view and key highlights from that data.

### Runtime Code Size

**solx 0.1.2** reduces contract size across both the `--via-ir` and default pipelines. Like solc, it still uses the legacy pipeline by default.

The table below shows the relative **runtime size improvements** compared to **solx 0.1.1** and **solc 0.8.30** (negative values indicate smaller size, i.e., better).

![](https://storage.googleapis.com/papyrus_images/2853ab3ded0e23f8bcefe60a6d640ca72e810a4dd63bcb831ecea2629ca0c812.png)

Despite a clear median win, the odds that a specific contract ends up smaller still slightly favor `solc --via-ir`. The measurement includes **all artifacts** produced by a `foundry build`.

![](https://storage.googleapis.com/papyrus_images/3531cc1c5f6826c1a060d9c6093467a531decf541588d0f51da45bc5fe220271.png)

The data shows considerable variation in whether a given contract compiles smaller with solc or solx; however, when **solx** wins, the margin is typically larger. The table below samples real-world contracts to show you how it looks in practice.

![](https://storage.googleapis.com/papyrus_images/15a1b3d8c935f3b916f7363ab1e3b48adf781c58785790cd9f8f7a96d128fae9.png)

### Gas Efficiency

The average gas metric remained stable in **solx 0.1.2**: the **gas-for-size tradeoffs** were offset by other optimizations introduced in this release.

The table below compares **solx 0.1.2** against **solx 0.1.1** and **solc 0.8.30**, showing **relative gas changes** (negative values indicate reduced gas usage, i.e., better).

![](https://storage.googleapis.com/papyrus_images/6c7e10cd0275bdb9e7c8595d719fcaaf3fac1fa1529224ecd4db138342b78045.png)

The table below also shows the **likelihood that a given test consumes less gas** with **solx 0.1.2** compared to solx 0.1.1 and solc 0.8.30.

![](https://storage.googleapis.com/papyrus_images/7256bf7142decb06d78105052c7d1d0e315e26e4cc7a029ff6b0697a0bbb8801.png)

### Compilation Time

**solx 0.1.2** doesn’t introduce pipeline changes, so **compilation time remains similar to solx 0.1.1**.

The table below shows how long each test run takes on our **CI hardware (in seconds)**, comparing against **solc 0.8.30** (both default and `--via-ir`).

![](https://storage.googleapis.com/papyrus_images/6cbb93203686b2835b99554b5da4f426943854c1c60940b2c433a8396ad8f92a.png)

### How It Works: Optimizations Behind the Gains

The earlier sections focused on what solx 0.1.2 achieved — smaller contracts, same or better gas usage. This section explains how we got there.

Three new optimizations made this possible:

*   The Constant Unfolder now splits `PUSHN` into multiple instructions if it reduces total bytecode size by at least 2.5× and fits within 4 instructions. Once the 24 kB limit is hit, it unfolds for any size reduction — prioritizing code outside of loops first, then loops of nesting depth 1, then 2, and so on. This acts as a hot/cold code heuristic to preserve performance while keeping contracts deployable.
    
*   The Dead Store Elimination pass can now remove not only overwritten stores to memory and storage, but also accounts for contract termination scenarios like `return` and `revert`. In `solx 0.1.2`, the common free heap pointer initialization (`PUSH1 0x40 PUSH1 0x80 MSTORE`) is eliminated from runtime code when unused (see [example in Compiler Explorer](https://godbolt.org/z/vocaq8WP1)). On the main branch, it's also removed from deployment code.
    
*   The Peephole Optimizer now emits more efficient code for conditional jumps involving `OR` conditions.
    

Hardhat v3 Integration
======================

Starting with [Hardhat v3.0.5](https://github.com/NomicFoundation/hardhat/releases/tag/hardhat%403.0.5), it’s now much easier to use **solx** in Hardhat.

To get started, just specify the following in your `hardhat.config.ts`:

    solidity: {
      profiles: {
        default: {
          version: "0.8.28",
          path: "./path/to/solx",
        },
      },
    },
    

You can find a detailed guide in [the Hardhat documentation](https://hardhat.org/docs/learn-more/configuring-the-compiler#using-a-custom-compiler).

**solx 0.1.2** also resolves a key integration issue by producing all the artifacts required by Ethereum Developer Runtime ([PR #133](https://github.com/matter-labs/solx/pull/133)).

Next Steps: From Optimization to Functionality
==============================================

Considering non-functional metrics alone, `solx` now leads across the board — except for default-pipeline compile time, where `solc` remains faster. We expect the upcoming MLIR pipeline to close this final gap ([learn more about it in the X thread](https://x.com/solx_compiler/status/1963980589628870773)). With performance largely handled, our focus is shifting toward functional gaps — starting with debugging support, which is now our top priority.

If you’ve read this far, chances are you care about `solx`. If you haven’t already, join our [Telegram group](https://t.me/solx_devs) and tell us more about your use case. Your input helps us prioritize wisely — especially as we move beyond optimization and work to make `solx` a first-class development experience.

---

*Originally published on [ZKsync](https://paragraph.com/@zksync/solx-0-1-2-smaller-binary-size-when-it-matters-most)*