We recently talked about the massive progress we’ve been making with slang-solx, slang's LLVM backend, in terms of faster compilation times and providing a better UX for Ethereum developers. Today we’re sharing an update on slang, our full Solidity compiler that is independent of solc. It's available in Hardhat 3 as the alpha plugin hardhat-slang, and on average across our benchmarks it compiles 40x faster in via-IR mode and 8.7x faster than solc in legacy mode, with individual repositories up to 79x faster.

It compiles valid Solidity code reliably today; what's still incomplete is error reporting on invalid code, which is what makes it an alpha.

Slang started out as a modular set of compiler APIs empowering the next generation of Solidity code analysis and developer tooling. This became slang-frontend, and then with the integration with slang-solx, we have arrived at a fully independent Solidity compiler: slang.

To get the performance boost for local build-test developer workflows, install the Hardhat plugin from npm:

npm add --save-dev @nomicfoundation/hardhat-slang

and enable the new slang compiler in the config:

import hardhatSlang from "@nomicfoundation/hardhat-slang";
export default defineConfig({
  plugins: [
    // ...other plugins...
    hardhatSlang,
  ],
  // ...other config fields...
  solidity: {
    profiles: {
      // ...existing solidity config...
      slang: {
        type: "slang",
        version: "0.8.37",
      },
    },
  },
});

then run your tests using the slang build profile:

npx hardhat test --build-profile slang

What shipped in slang

This release is the first full, end-to-end compiler release where every component has been built independently, without relying on solc for any part of the compilation pipeline. It's the alpha integration of our blazing-fast slang-frontend, which is an evolution of the frontend that’s been in use in ecosystem tools since 2024, and slang-solx, our LLVM-based backend.

Since our last update the pipeline has gained a new, performance-optimized slang-frontend, a diagnostics framework, an MLIR middle layer, and it compiles every Solidity version 0.8.0 and above, from a single binary. The one component that is not yet complete is code validation: today only roughly half of the essential validation rules are implemented, so error messages on invalid Solidity are partial. Everything else including bytecode generation, optimization passes, and debug symbols is there.

As we explained in last year’s presentation, reusing an industry-standard, battle-tested compiler framework with MLIR+LLVM allowed us to reuse >90% of the framework’s proven code, and to focus most of our engineering time on Solidity’s specific UX, compile-time and gas-cost optimizations.

Given how sensitive this foundational component is, we stuck to human design and thorough code review, keeping long-term maintainability, extensibility, and safety as top priorities. Users should be able to dive in to understand what’s happening under the hood without facing brittle code that only an LLM can work with.

Performance numbers

Like last time, in order to measure performance, we tracked wall-clock time end-to-end across five runs of the cold compile of complete repositories. The runs were done on a custom CI Github runner to ensure consistency, with a 32-core CPU at 3.75 GHz, so comparison ratios of each run are more relevant than the absolute values in seconds.

slang vs solc --via-ir

Building all 9 repositories below one after another takes solc 953s in total, and it takes slang just 23.6s, a 40x improvement. There are some strong outliers such as graph-horizon: 79.3x faster.

slang vs solc legacy pipeline (without --via-ir)

Building all 7 repositories below one after another takes solc 154s, and it takes slang just 18s, a 8.7x improvement. Compared to our previous slang-solx announcement from 2 months ago, slang improved a further ~5x in speed.

Compilation + test execution is faster than forge with solc

Total times (build + test) show the same trend. Compiling with slang and running tests on Hardhat 3 for the below 6 repositories was on average 26x faster than forge with solc in via-IR mode, with individual repositories up to 44x faster. Test execution itself is mostly in the same range between Hardhat 3 and forge, and the gain is coming entirely from slang’s faster compile times compared to solc.

slang vs solc --via-ir compilation + tests run

slang vs solc legacy compilation + tests run

slang-frontend performance improvements

Our slang-frontend component was released in 2024 and has been used across the ecosystem in multiple code analysis tools, including our own Hardhat Solidity VSCode extension.

This new release has been optimized heavily across all of its components (lexer, parser, binder, and AST). The result is a blazing fast compiler frontend, which is then paired with our MLIR middle-layer and our slang-solx LLVM backend for fast, parallel compilation. The release is currently available only in the end-to-end compiler (hardhat-slang plugin), and not yet released for the VSCode extension.

Our internal benchmark comparing wall-clock time for 7 reference repositories (compiled one after another) between the previous slang-frontend and the latest release shows 55.4x faster parsing, and 234.8x faster binding.

Correctness, quality & resolving stack-too-deep

Slang is stable but not fully complete, due to the ongoing diagnostics/code-validation work. This means limited support when attempting to compile invalid Solidity code. For testing with valid Solidity codebases we used several third-party high-profile repositories. All compile and pass their test suites without issue.

In addition to the selected repositories, 100% of solc’s semantic tests pass when compiled with slang across all 38 Solidity versions we tested. We also tested against 2,326,676 contracts on Sourcify containing all 0.8.0 - 0.8.37 files with EVM target >= cancun, and ~99.97% of them compile correctly.

Our pipeline successfully compiles 99.85% of Sourcify test cases without stack-too-deep errors.

slang is tested against real projects, it's supported, and we'll respond to bugs. The major area of development that we’ll continue in the next few months is to add missing code validation rules, alongside continuing to boost performance.

Version support

In our last announcement, when we introduced slang-solx, version support was limited to a single Solidity version (0.8.34).

slang now supports all Solidity versions 0.8.0 and above , with EVM target >=cancun. Thanks to our long-standing multi-version approach in slang-frontend (which we talked about last year), the same binary of slang supports all Solidity versions in the 0.8.x range, up to the most recent Solidity version at the time of release. The caveat to 0.8.x support in the short term remains the ongoing work and the current limitations of code validation.

Proper gas optimizations for safe code

Our slang-solx backend supports multiple optimization levels tailored to your environment and goals, from prioritizing fast compilation during development to producing gas-efficient bytecode. While the backend isn’t ready for mainnet deployments, over time, we believe slang will meaningfully reduce gas costs. Thanks to our LLVM IR optimization passes, we aim to eliminate the need for potentially unsafe inline assembly in Solidity contracts. We’ll share gas optimization benchmarks in the future. Slang is already clearly better than solc, but it’s not as relevant now for local development use cases.

What’s next for Ethereum tooling

As we mentioned in our previous blog post, we’re close to the vision we shared in 2021: a reusable compiler, reusable runtime, and end-user tooling stack. If you’re curious to learn more about our compiler journey and how we got here, see the previous announcement.

We now have an end-to-end compiler, built on top of a standard, industry-proven, human-engineered stack with LLVM and MLIR; and Hardhat 3 has been stable for a while, with native Solidity tests support alongside Typescript integration tests.

We’ve also been shipping significant performance improvements to Hardhat 3’s build-test loop, which contributed to the fast end-to-end numbers we showed in this post. We’ll continue battle-hardening the compiler, adding the remaining code validation support, and improving performance.

For some of the repositories that we are benchmarking, the compile time is already down from hundreds of seconds to single-digit numbers, and in the context of significantly more AI / Agent usage in the ecosystem compared to one year ago, we’re rapidly reaching a point where, for the time being, further optimizing performance below 1-2s feels like we’ll reach diminishing returns soon.

Slang today is ready to boost compilation times in local dev workflows and CI builds.

It's all in Hardhat 3. Check it out.