solar: a Rust rewrite of the Solidity compiler you can also embed

A compiler you can call, not only a compiler you can run

solar is described as a blazingly fast, modular and contributor friendly Solidity compiler, written in Rust, and the description in the repository is more than a slogan because the project ships the compiler in four different shapes.

There is the command line interface, there is a Rust library, there is a C API through the solar-capi crate, and there is a WebAssembly build with a soljson-compatible JavaScript wrapper. The library route is the simplest to add, through a Cargo.toml dependency:

[dependencies]
solar = { version = "=0.1.8", package = "solar-compiler", default-features = false }

or through the CLI with cargo add, renaming the crate as you go:

cargo add "solar-compiler@=0.1.8" --rename solar --no-default-features

Note the exact version pin in both, and the default-features = false, which suggests the feature set is where the weight is and that you are expected to choose what you need. The examples directory in the repository shows how the library is meant to be used.

The stated feature list is five items: instant compiles and low memory usage with a link to the benchmarks, expressive and useful diagnostics, a modular library-based architecture, a simple and hackable code base, and compatibility with the latest Solidity language breaking version, which is 0.8.

Compatibility with the latest breaking version is the right target for a rewrite, because a compiler that lags the language is not much use. What is not claimed is compatibility with every Solidity feature, and the caution block at the top of the readme is unambiguous about where the project stands: Solar is under active development and is not yet feature complete, use it to speed up your development workflows and tooling, and please do not use it in production environments.

Getting the binary, and pinning a version

Pre-built binaries are available for macOS, Linux and Windows on the releases page, and the readme gives an install command for each platform.

On macOS and Linux:

    curl -LsSf https://paradigm.xyz/solar/install.sh | sh

On Windows:

    powershell -c "irm https://paradigm.xyz/solar/install.ps1 | iex"

And for a specific version, the path carries the version in it:

    curl -LsSf https://paradigm.xyz/solar/v0.1.8/install.sh | sh
    powershell -c "irm https://paradigm.xyz/solar/v0.1.8/install.ps1 | iex"

There are two other routes. The cargo binstall route installs from the same release binaries, and it takes a version suffix if you want one:

    cargo binstall solar-compiler

Building from source has three variants, from crates.io, from GitHub, and from a checkout:

    cargo install solar-compiler --locked

    cargo install --git https://github.com/paradigmxyz/solar --locked

    git clone https://github.com/paradigmxyz/solar
    cd solar
    cargo install --locked --path crates/solar

The locked flag appears in every cargo install variant, which is a sign that the lock file is treated as part of the build contract rather than an optimisation. The path in the third variant points at crates/solar, which tells you that the command line application is one crate among several in the workspace.

Once installed you check the options with solar -h, and the readme shows a few invocations:

# Compile a single file and emit ABI to stdout.
solar Counter.sol --emit abi

# Compile a contract through standard input (`-` file).
echo "contract C {}" | solar -

and a Foundry example that resolves remappings automatically:

solar $(forge re) src/Contract.sol

That last one is a nice touch, since remapping resolution is the part of Solidity compilation that is most painful to do by hand.

The C API is the boundary everything else shares

The solar-capi crate exposes the compiler through a Solidity-compatible C API, and the readme is careful about what that means.

That same ABI is also the boundary used by the WebAssembly build and the soljson-compatible JavaScript wrapper. The C header is the source of truth for the ABI, and the API accepts Standard JSON input and returns Standard JSON output, matching the interface used by Solidity's libsolc and the raw soljson.js builds. Like Solidity, client code owns memory explicitly through the C API described in the header.

That last point is the one that bites. A C API with caller-owned memory means every caller has to free what it allocates, and a wrapper written in another language has to reproduce that discipline. It is the same contract libsolc has, which is precisely the point, because it means existing tooling that already drives solc through that interface can drive solar instead.

The JavaScript story follows the same shape. Solidity distributes JavaScript compiler builds as soljson.js files, and modern builds are WebAssembly modules loaded through a JavaScript wrapper, with the wasm bytes made available as Module.wasmBinary. The solc-js package then layers a higher level API over that raw module.

The repository ships the wasm distribution as solar-wasm.tar.gz in the releases, and the archive contains soljson.js, which is a packed soljson-compatible JavaScript file with the wasm embedded, solar.wasm, the raw WebAssembly module, and soljson-wrapper.js, the wrapper for loading solar.wasm yourself.

The choice between the packed and unpacked forms is the choice between convenience and control. The packed file is the most solc-js-compatible path and needs no setup. The separate wasm file with the wrapper is for when you want to control how the module is loaded, which the readme shows in Node:

const fs = require("node:fs");

globalThis.Module = {
  wasmBinary: fs.readFileSync("./solar.wasm"),
};
const solar = require("./soljson-wrapper.js");
delete globalThis.Module;

The global assignment of Module before the require is the hook, and deleting it afterwards keeps the global namespace clean.

Building the wasm yourself needs a growable table

The wasm distribution can be rebuilt from source, and the build has one non-obvious requirement that the readme explains.

rustup target add wasm32-unknown-unknown
scripts/wasm/dist-wasm.sh

This produces the same files under target/dist/. The script builds with an exported, growable WebAssembly table so JavaScript callbacks can be installed, then packs the wasm bytes into soljson.js.

The growable table is the detail worth understanding. A WebAssembly table is the indirect call mechanism, and if the table cannot grow then the number of functions that can be installed through it is fixed at compile time. A compiler that has to call back into JavaScript, which is what an import callback does during compilation, needs to install those callbacks dynamically. Without a growable table the design does not work, so the build script has to opt into it rather than rely on the default.

The callback mechanism itself is visible in the JavaScript example. The compile call takes a Standard JSON input object and an options object with an import function:

const solar = require("./soljson.js");

const output = solar.compile(JSON.stringify({
  language: "Solidity",
  sources: {
    "A.sol": { content: 'import "B.sol"; contract A is B {}' },
  },
  settings: { outputSelection: { "*": { "*": ["abi"] } } },
}), {
  import(path) {
    if (path === "B.sol") {
      return { contents: "contract B {}" };
    }
    return { error: `source not found: ${path}` };
  },
});

The import function is how the compiler asks the host for the source of an imported file, which is the same contract the C API and the Rust library use, and it is why the same binary serves all three consumers.

A workspace that treats its own tooling as part of the product

The repository layout and the manifest show a project that invests in the parts of a compiler most projects treat as overhead.

The Cargo workspace has members for the benches, the crates, the examples and the tools, with the crates as the default members, and a workspace package version of 0.2.0, edition 2024, a minimum Rust version of 1.98, and a licence of MIT OR Apache-2.0. The author listed is DaniPopes. The docs.rs metadata asks for all features to be built, so the published documentation covers the whole surface.

The lint configuration is where the contributor friendly claim is cashed out. The clippy lints include dbg_macro, manual_string_new, uninlined_format_args, use_self and redundant_clone, and the rust lints include rust_2018_idioms, unreachable_pub, unused_must_use, redundant_lifetimes, unnameable_types and unused_crate_dependencies, with rustdoc set to all. Every one of those is a lint that catches a specific class of mistake, and the unused_crate_dependencies one is a good fit for a project that ships many crates.

The build profiles are tuned for the two things that matter to a compiler. The dev profile reduces debug information to line-tables-only and splits debuginfo, with a comment explaining that it speeds up the edit build run cycle at the cost of less useful debugger output, and a note to uncomment it if you are using a debugger. The release profile uses opt-level 3, thin LTO, no debug info and strips debuginfo, and the dev package profile bumps the opt level to 3 for a list of hot dependencies including regex, indicatif and console, which are the crates a terminal compiler interface spends its time in.

There is also a Python side. The pyproject.toml defines a project named solar-python with no dependencies, a uv workspace with members for a compiler-diff tool and an analysis bench, a seven-day cooldown on registry packages, and a dev group with ruff, ty, jsonschema, pytest and pytest-xdist. The compiler-diff tool is excluded from the Cargo workspace and given its own extra path for the type checker, which tells you the tool compares compiler output against something and needs to live outside the main build.

The rest of the tree is what you would expect from a serious compiler: a fuzz/ directory, a testdata/ directory, benches/, crates/, tools/, tests/, a RELEASE_CHECKLIST.md, a deny.toml for dependency policy, a cliff.toml for changelog generation, and separate licence files for MIT and Apache-2.0.

Editorial conclusion

solar suits a team that wants the Solidity compiler as a library it can call in-process, or that needs the WebAssembly and soljson paths for a JavaScript toolchain, since a Rust compiler with a C ABI reaches more of the ecosystem than a standalone binary does. It does not suit anyone shipping Solidity to production, because the readme says plainly not to use it in production environments. Before trying it, pin the version you want since the API is moving, and treat the 40x ABI generation claim in the project benchmark image as something to reproduce on your own machine with hyperfine rather than as a settled number.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. paradigmxyz/solar on GitHub
4. README
5. Releases