The Bank Stack of Ethereum
The Bank Stack: an institutional architecture using private ZK-execution and safety controls to bring secure, programmable finance to Ethereum.
ZKsync Blog > solx 0.1.2 - Smaller Binary Si...
Published Oct 1, 2025
solx 0.1.2 - Smaller Binary Size When It Matters Most
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-irare 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).
- Better code quality. The compiler now eliminates unused stores (heap, transient, or persistent storage) (PR-865) and generates more efficient conditional jumps (PR-870).
- 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. 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).
| | solx 0.1.1 | solx 0.1.1 --via-ir | solc 0.8.30 | solc 0.8.30 --via-ir |
|---|---|---|---|---|
| Total (sum of all contract sizes) | -8.54% | -11.30% | -11.67% | -2.76% |
| Median | -6.13% | -13.10% | -28.80% | -21.96% |
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.
| | solx 0.1.1 | solx 0.1.1 --via-ir | solc 0.8.3 | solc 0.8.30 --via-ir |
|---|---|---|---|---|
| % Better | 95.5% | 98.5% | 89.0% | 43.5% |
| % Worse | 0.3% | 0.4% | 11.0% | 56.4% |
| % No Change | 4.2% | 1.1% | 0.0% | 0.1% |
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.
| | solx 0.1.2 | solc 0.8.30 | solx 0.1.2 vs solc 0.8.30 |
|---|---|---|---|
| uniswap-v4, PoolManager | 22191 | 23996 | -1805 (-7.5%) |
| aave-v3, PoolInstance | 18258 | 19737 | -1479 (-7.5%) |
| aave-v3, L2PoolInstance | 20812 | 20728 | +84 (+0.5%) |
| aave-v3, StateTokenV2 | 24350 | 20166 | +4184 (+20.8%) |
| aave-v3, PoolConfiguratorInstance | 14862 | 16312 | -1450 (-8.9%) |
| aave-v3, MockPoolInherited | 18610 | 19861 | -1251 (-6.3%) |
| aave-v3, AaveOracle | 2702 | 2169 | +533 (+26.7%) |
| aave-v3, MockL2Pool | 20841 | 20728 | +113 (+0.6%) |
| art-gobblers, ArtGobblers | 13600 | 20265 | -6665 (-32.9%) |
| beefy, StrategyVelodromeGaugeV2 | 20236 | 22318 | -2082 (-9.3%) |
| beefy, StrategyConvexCRV | 19546 | 19222 | +1324 (+7.3%) |
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).
| | solx 0.1.1 | solx 0.1.1 --via-ir | solc 0.8.30 | solc 0.8.30 --via-ir |
|---|---|---|---|---|
| Total gas spent by all tests | -0.35% | -0.50% | -1.80% | -1.37% |
| Median | -0.15% | -0.01% | -12.90% | -12.82% |
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.
| | solx 0.1.1 | solx 0.1.1 --via-ir | solc 0.8.30 | solc 0.8.30 --via-ir |
|---|---|---|---|---|
| % Better | 16.9% | 37.3% | 94.2% | 89.4% |
| % Worse | 56.4% | 59.4% | 4.6% | 9.4% |
| % No Change | 26.8% | 3.4% | 1.3% | 1.1% |
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).
| Project | solc 0.8.30 | solc 0.8.30 --via-ir | solx 0.1.2 (vs solc) | solx 0.1.2 --via-ir (vs solc --via-ir) |
|---|---|---|---|---|
| aave-v3 | 108.18 | 891.99 | 198.93 (↑83.89%) | 122.18 (↓86.30%) |
| art-gobblers | 4.93 | 26.02 | 9.19 (↑86.24%) | 6.99 (↓73.12%) |
| balance-snapshot | 0.64 | 1.94 | 2.03 (↑217.00%) | 1.64 (↓15.35%) |
| beefy | 20.59 | 111.21 | 18.09 (↓12.13%) | 14.62 (↓86.85%) |
| diamond-foundry | 0.91 | 3.92 | 3.05 (↑236.42%) | 1.85 (↓52.73%) |
| diamonds | 0.59 | 1.50 | 1.95 (↑233.33%) | 1.60 (↑6.66) |
| forge-std | 5.59 | 27.32 | 8.57 (↑53.41%) | 5.99 (↓78.08%) |
| foundry-upgrades | 0.93 | 2.63 | 1.70 (↑81.67%) | 1.29 (↓51.12%) |
| gov-of-venice | 3.64 | 25.17 | 5.39 (↑48.06%) | 3.76 (↓85.07%) |
| lil-web3 | 2.35 | 11.10 | 2.49 (↑5.74%) | 2.10 (↓81.12%) |
| maple-erc20 | 1.83 | 5.57 | 2.11 (↑15.31%) | 1.70 (↓69.44%) |
| openzeppelin | 17.97 | 57.52 | 13.17 (↓26.71%) | 14.42 (↓74.92%) |
| playpen | 1.86 | 7.44 | 2.54 (↑36.47%) | 2.03 (↓72.67%) |
| prb-math | 6.43 | 31.64 | 6.02 (↓6.43%) | 7.37 (↓76.71%) |
| rollcall | 0.86 | 5.78 | 2.66 (↑207.76%) | 2.40 (↓58.58%) |
| solady | 25.66 | 148.22 | 23.52 (↓8.32%) | 23.48 (↓84.16%) |
| solmate | 5.98 | 32.65 | 8.53 (↑42.63%) | 5.07 (↓84.47%) |
| tokenlon | 21.26 | 106.41 | 19.88 (↓6.50%) | 12.71 (↓88.06%) |
| uniswap-v4 | 17.94 | 98.63 | 23.18 (↑29.22%) | 16.73 (↓83.04%) |
| unix | 0.78 | 2.53 | 2.92 (↑272.92%) | 2.23 (↓11.93%) |
| Total | 248.93 | 1599.20 | 355.92 (↑42.98%) | 250.15 (↓84.36%) |
| Median | 4.29 | 25.59 | 5.71 (↑33.07%) | 4.41 (↓82.75%) |
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
PUSHNinto 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
returnand 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). On the main branch, it's also removed from deployment code. - The Peephole Optimizer now emits more efficient code for conditional jumps involving
ORconditions.
Hardhat v3 Integration
Starting with Hardhat v3.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.
solx 0.1.2 also resolves a key integration issue by producing all the artifacts required by Ethereum Developer Runtime (PR #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). 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 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.
Share the article
More from ZKsyncView all
Privacy and Compliance Are Not Opposites. The Law Should Catch Up.
Modernizing the CLARITY Act with ZK proofs eliminates the trade-off between privacy and compliance through secure cryptographic verification.
No shortcuts: ZKsync Roadmap 2026
ZKsync Roadmap 2026: building privacy-first, high-performance, interoperable infrastructure to bring real-world finance onchain at institutional scale.