Solang solidity compiler for Solana, Soroban, and Polkadot

Why Solang targets chains beyond the EVM

Solang addresses a concrete portability problem. A Solidity codebase written for an EVM chain cannot be deployed unchanged to Solana, Soroban, or a Polkadot parachain because those platforms use different execution and contract models. Solang accepts Solidity-like source and generates artifacts for each supported target rather than producing Ethereum bytecode.

The compiler is aimed at developers and teams that want to retain Solidity syntax while changing the destination chain. This can be relevant for libraries, tooling experiments, and contract suites intended to span several networks. It does not make every Solidity program portable. The README states that Solang is source compatible with Solidity 0.8, with caveats caused by differences in the underlying blockchains.

That boundary matters. Shared source structure does not imply shared execution behavior. Target-specific calling conventions, account models, available libraries, ABI handling, and contract deployment steps can still force changes. Solang therefore suits teams willing to maintain target-specific adaptations, rather than developers expecting a Solidity file to move between chains without review.

The repository and Cargo metadata identify Solang as a Rust implementation under the Hyperledger Solang project. Its package description is "Solang Solidity Compiler," while the project documentation covers Solana, Soroban, and Polkadot parachains using the `contracts` pallet. The Polkadot target is therefore narrower than all Substrate deployments: the documented workflow depends on a parachain contract environment.

For organizations with an existing Solidity codebase, the useful question is whether Solidity is already the shared language across business logic and deployment targets. If the answer is yes, Solang can reduce the amount of source rewriting. If the answer is no, the value is less clear because the compiler does not remove the need to learn the target platform's deployment model.

LLVM compilation and target-specific artifact generation

Solang uses LLVM as its compiler backend. The repository is implemented primarily in Rust, parses Solidity input, and lowers the program for the selected destination. The Cargo manifest enables `inkwell` with `llvm16-0` for the WebAssembly target path, although that dependency is optional. This connects Solang to LLVM-based code generation without requiring the whole compiler to be written in C++.

The target choice occurs on the command line through `--target`. For Polkadot, the README's flipper example produces `flipper.contract`, which can be supplied to the Substrate Contracts UI as though the contract had been written using ink!. For Soroban, the token example produces `token.wasm`, which is then supplied to the Stellar CLI. For Solana, the compiler is distributed as part of the Solana Tools Suite, at version v1.16.3 or higher according to the README.

This architecture separates the front-end and target handling from the emitted artifact. The front-end understands Solidity-oriented source, while each target imposes its own contract format and deployment path. The resulting output is therefore not a portable container that can be moved unchanged among Solana, Stellar, and Substrate. Each target needs its own compilation, compatibility review, and deployment procedure.

The project also contains a separate `solang-parser` crate, standard-library sources, examples, integration material, and a `vscode` directory. Based on that repository layout, Solang is more than a single wrapper command around a conventional EVM compiler. Its standard library and parser are part of the broader compiler project, which means target support can depend on project-specific implementations rather than only on the input syntax.

The separate target outputs also explain why a successful compile should not be treated as proof of behavioral equivalence. The compiler can validate syntax and produce the requested artifact, while the destination runtime determines whether the contract can be initialized, invoked, funded, authorized, and observed correctly.

Installing Solang and compiling the first contract

On macOS, the README provides a Homebrew cask installation. The command installs the `solang` executable. After it completes, `solang` should be available in the shell configured for Homebrew.

brew install hyperledger/solang/solang

For other operating systems, the README directs users to the installation guide rather than giving a platform-specific command. The current `Cargo.toml` declares Rust 1.90.0 as the minimum Rust version, and the repository Dockerfile uses a purpose-built LLVM image. The Dockerfile builds the standard library, selects Rust 1.90.0, and builds the release binary:

FROM ghcr.io/hyperledger/solang-llvm:ci-7 as builder
RUN rustup default 1.90.0
WORKDIR /src
RUN cargo build --release

The container is also documented for a first Polkadot compilation. It mounts the current directory into the container and writes output into that mounted directory. The command expects the repository's `flipper.sol` example to be present at the mounted location.

docker run --rm -it -v $(pwd):/sources ghcr.io/hyperledger/solang compile -v -o /sources --target polkadot /sources/flipper.sol

A local installation can compile the same example from the repository root. The README identifies the result as `flipper.contract`.

solang compile --target polkadot examples/polkadot/flipper.sol

Solana installation follows a different route. The README says Solang is included in the Solana Tools Suite from version v1.16.3 onward and points to Solana's Getting Started Guide. It explicitly says there is no need to install Solang separately for that route. Users following this route must use the Solana-specific setup instructions rather than assuming that the Homebrew or container workflow is the same.

Soroban compilation and Stellar CLI deployment

The Soroban example provides the clearest documented path from Solidity source to a deployed contract. It selects the repository's token example and targets Soroban:

solang compile --target soroban examples/soroban/token.sol

The README states that this creates `token.wasm`. That file is consumed by `stellar contract deploy`, rather than by an EVM contract deployment command. The example deploys to testnet from the `alice` source account and passes constructor-style values after `--`:

stellar contract deploy --source-account alice --wasm token.wasm --network testnet -- --_admin alice --_name SolangToken --_symbol SOLT --_decimals 18

The deployment command performs more than copying the artifact. Its documentation shows simulation, signing, submission, and an eventual deployed contract ID. Those outputs depend on the account and network used by the operator. The contract ID shown in the README is an example value, not a value to reuse for another deployment.

After deployment, the README shows an invocation of the token's `mint` function. The command includes the testnet network, deployed contract ID, source account, function name, destination account, and amount:

stellar contract invoke --network testnet --id CDGUMUXA6IRRVMMKIVQJWLZZONDXBJ4AITHQS757PTBVAL4U54HI3KEW  --source-account alice -- mint --to alice --amount 120

This workflow reveals an important distinction between compilation and deployment. `solang compile` produces the Wasm artifact, while `stellar contract deploy` submits it to the configured Stellar environment. Account setup, testnet configuration, contract arguments, signing, and network access remain part of the Stellar CLI process. The project points to a Soroban support matrix and target documentation for checking whether a particular Solidity construct is supported.

Target compatibility is the central constraint

The strongest warning in the README is also the easiest engineering risk to underestimate: Solidity 0.8 source compatibility has caveats. A compiler that accepts Solidity syntax does not necessarily preserve every EVM behavior across Solana, Soroban, or Polkadot. Account handling and execution environments differ, and the available target libraries may not match an Ethereum development stack.

The project maintains target-specific references rather than presenting one universal compatibility guarantee. For Soroban, the README points to a `Soroban support matrix` and `Soroban target docs`. Polkadot examples are described as usable in the Substrate Contracts UI like ink! contracts, but that does not remove the need to check the generated contract and runtime requirements. Solana users are sent to a Solana-specific getting started guide because the Solana toolchain provides Solang as part of its suite.

Several roadmap items show that compatibility is still changing. The V0.4 table lists OpenZeppelin support for Polkadot, Solana function account declarations, ink! and Solidity interoperability tooling, and broader Soroban example support as in progress. The same table marks optimization-pass management and a Solidity-to-Polkadot porting guide as not started. These are repository roadmap statements, not promises of completion.

For an existing contract suite, the practical first check is feature-by-feature compatibility. Review external calls, account authorization, storage assumptions, libraries, event behavior, value transfer, and constructor initialization separately for each target. A source file compiling successfully is evidence that the selected compiler accepted that input. It is not evidence that every downstream deployment requirement has been resolved.

A second constraint is versioning. The repository's release entries include v0.4.0, v0.3.5, and v0.3.4, so a project should record which compiler version generated each artifact. Reusing a contract artifact across tool versions or target changes can obscure whether a problem came from source semantics, compilation, or deployment configuration.

Solang versus native ink! and Solana workflows

The practical alternative for Polkadot is to write the contract in ink! and use that ecosystem directly. The difference is not merely a different file extension. Solang accepts Solidity-oriented source and targets the Polkadot contract environment through a compiler and an emitted `flipper.contract` artifact. The README's statement about using the generated contract in the Contracts UI does not establish equivalence between the two development workflows. The README's statement that the generated contract can be used in the Contracts UI like an ink! contract does not claim that the two source models or toolchains are interchangeable.

For Solana, the alternative is the native Solana development route rather than Solang. The README's strongest Solana guidance points to Solana's own getting started material and the Solana Tools Suite. Teams with existing Anchor programs or Solana-specific modules may already need native APIs and deployment conventions that a Solidity-to-Solana translation would not eliminate.

Solang is therefore more compelling when the organization already has Solidity source and values retaining that language across several supported networks. Native toolchains are usually the safer default when the contract is being designed for one runtime and its native libraries, account model, debugging flow, and deployment tools are already established. The repository supports multi-target portability at the compiler level, but it does not claim that Solang is a replacement for each platform's native development model.

There is also a maintenance difference. A Solidity team using Solang inherits the compiler's target support matrix and must track Solang releases, Rust and LLVM build requirements where applicable, and each destination chain's tooling. A native project still has target-specific work, but it does not add a Solidity compatibility layer. That trade-off should be based on the existing codebase rather than on the idea that multiple targets automatically require Solang.

Release cadence, build requirements, and Apache-2.0

The repository is not archived, and its last push was on 2026-09-30. Recent releases include v0.4.0 on 2026-09-30, v0.3.5 on 2026-07-07, and v0.3.4 on 2025-06-29. These dates indicate recent release work, but they also mean users may need to account for compatibility changes between versions. The V0.4 roadmap contains items marked in progress, so upgrading from an earlier release should include a fresh build and target-specific contract review.

The build requirement is explicit in `Cargo.toml`: Rust 1.90.0. The Docker build also depends on the `ghcr.io/hyperledger/solang-llvm:ci-7` builder image and compiles the standard library before invoking Cargo. That makes the container a documented way to avoid reproducing the local LLVM and Rust build environment. It does not remove the need to inspect the generated artifact or follow the destination chain's deployment instructions.

Solang is distributed under Apache-2.0, as shown in the repository license field, README, and Dockerfile metadata. Apache-2.0 is a permissive software license, but choosing a compiler does not automatically settle questions about imported contracts, libraries, generated output, deployment tools, or platform-specific terms. Review the license files for the actual components used in a distribution and keep deployment configurations under version control.

For upgrades, the first project-specific checks are the target support matrix, the generated artifact filename, and the destination CLI or deployment tool. Those checks matter because Solang's output format differs by target: `flipper.contract` is documented for Polkadot, while `token.wasm` is documented for Soroban. A successful compile with one target does not prepare the same artifact for another.

Editorial conclusion

Solidity teams that already use compatible libraries and can accept target-specific constraints should adopt Solang after checking their contracts against the relevant support matrix. Projects requiring exact Ethereum bytecode semantics should remain on an Ethereum compiler, while teams using native Solana or ink! code may gain less from introducing Solang. Before migration, verify the exact Solidity features, library APIs, ABI expectations, and deployment format required by the chosen target.

Frequently asked questions

Official sources

1. hyperledger-solang/solang on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases