Source publication time: November 3, 2026, 00:00 (UTC+08:00). This catch-up covers the release described in Paradigm’s original announcement.
Solar v0.3 turned the Rust-based Solidity frontend into a compiler capable of generating EVM bytecode. In its announcement, Paradigm said the release shipped in Forge, bringing faster compilation, lower-cost contract code and a Solidity language server to the Foundry workflow.
The headline results come from Paradigm’s own benchmarks: 100× faster builds on average than solc with via-IR, alongside code that used 5% less execution gas, cost 26% less to deploy and was 29% smaller. Those figures describe the tested workloads and configurations—not a guaranteed improvement for every contract.
What changed in the compiler
Paradigm introduced Solar two years before this release as a fast, modular Solidity frontend. By v0.3, it had added an optimizing compiler with a typed middle end that models Solidity and a backend that models the EVM.
The compiler moves code through several intermediate representations, or IRs. Its typed MIR retains concepts such as mappings and checked arithmetic, allowing optimizations that remove redundant checks or avoid unnecessary storage and memory operations. A lower-level EVM IR handles stack operations, block layout and peephole rewrites.
One example in the announcement illustrates the distinction: a factorial function updates a storage variable on every loop iteration. Solar keeps the intermediate result on the stack and writes to storage once at the end, while retaining overflow checks. Paradigm explains that a revert would undo earlier storage writes anyway.
How to read the performance claims
Paradigm compared six real-world Solidity projects using solc 0.8.38 and Solar at commit 0303bb7d. With solc’s via-IR pipeline enabled, it reported an average build speedup of 100× and a maximum of 159×.
The default comparison was not thread-for-thread: Solar used eight threads; solc used one. Paradigm also reported single-threaded Solar results: 19× faster than solc with via-IR, and 7× faster when using each project’s own settings.
Other reported results included:
- With project-specific settings, many using solc’s faster legacy pipeline, Solar was over 30× faster on average and used about one-third of solc’s memory.
- Solar compiled Uniswap v4 in 0.35 seconds. In the via-IR comparison, solc failed on Uniswap v4 core and Seaport with “Stack too deep” errors.
- Of the five compilers tested, only Solar built Seaport with via-IR.
For gas and deployment measurements, Paradigm used contracts from OpenZeppelin, Solady, Aave, Arbitrum, Maple, Tempo and others. Its benchmark suite deployed each compiler’s output to a local node, replayed the same transactions and checked that results matched.
Compute-heavy code showed the largest gas reductions. Fixed transaction costs limited savings on simple token calls. Paradigm also reported fewer executed opcodes—including one-tenth as many JUMP instructions—and fewer CPU cycles for the same calls in the evm2 interpreter.
Comparisons with other Solidity compilers
The broader comparison included solc 0.8.38, slang-solx 0.1.8, an October preview of the Slang rewrite at build 5e6ec5e1, oksolc 0.2.2 and Solar at commit 0303bb7d.
With the same inputs and settings, including via-IR, Paradigm said Solar built whole projects faster than the alternatives and produced lower average execution and deployment costs. It did not win every workload: slang-solx beat Solar on one, and the Slang preview beat it on three.
The announcement also cautioned that enabling via-IR for projects configured for solc’s legacy pipeline could produce more expensive code. That settings difference explains why solc’s gas and deployment figures varied between the comparisons.
Testing checked Solidity against hand-written assembly
Paradigm rewrote Solady in mostly plain, checked Solidity to test whether compiler optimizations could replace manual low-level work. The rewrite retained every exposed function, leaving assembly and unchecked operations only in small functions tagged for review where Solidity could not express the required operation, such as reading a raw storage slot or propagating a revert.
Both versions produced the same results under Solady’s own test suite. Compiled with Solar, the rewritten version used 19% less gas than the original compiled with solc and was cheaper in nearly every test, according to the announcement. These are test and benchmark results, not a claim of formal verification of the library.
Forge integration and editor support
The announced workflow was to update Foundry and explicitly select Solar:
foundryup
forge build --use solar
forge test --use solar
For editor integration, forge lsp runs a language server built on Solar’s frontend. Paradigm reported startup readiness 15× to 20× sooner than the next-fastest Solidity language server on Uniswap v4 and Aave. Hover, go-to-definition and completion responses took under 0.2 milliseconds, reported as 8× to 170× faster. Rename and errors shown while typing were also supported.
At publication, VS Code and Zed extensions were still being published; installation was available through Open VSX or from source.
What remained planned
Solar already powered forge lint and forge fmt. Further work described in the announcement included compiler-based security checks, a standard library without assembly, ethdebug support and tooling to verify optimization passes by comparing IR before and after transformation.
Paradigm said it already proved individual rewrite rules in Lean. Broader pass-verification tooling and LLM-proposed optimizations accepted only after proof were future plans, not completed capabilities of the release.
Read the original Paradigm article: “Solar: 100× faster Solidity”