Solang is a Solidity compiler that builds smart contracts for Solana and Polkadot instead of the Ethereum Virtual Machine. Its documentation says it uses the LLVM compiler framework to produce WebAssembly or Solana SBF code, and aims for source compatibility with the Ethereum Solidity compiler, version 0.8. That makes it one route to sharing code across EVM chains and Solana, but not a single compiler for both.
​

Developers asking "which frameworks let me write one onchain program for EVM and Solana?" usually want one of two things: one source file that deploys as a contract on both, or one piece of transaction logic that executes on both. Those are different problems with different tools. This article covers how Solang works, where it breaks Solidity's assumptions, the other options teams use, and a comparison table to pick between them.
​

Key facts at a glance:

Three approaches exist. Solang lets one Solidity source compile for Solana while solc compiles it for EVM chains. Teams can maintain two native codebases, Solidity for EVM and Rust with Anchor for Solana. SauceScript compiles one TypeScript-subset program to both EVM and SVM bytecode, but runs as transaction logic rather than a deployed contract.
​

The right choice depends on what the "program" is. A token, a vault, or a lending market holds state and must be a deployed contract on each chain. Routing, settlement checks, and multi-step swaps often do not need persistent state; they need logic that runs at execution time. The two categories map to different tools.

For the chain-level differences behind these choices, see Eco's Solana vs Ethereum comparison.
​

Solang is an LLVM-based compiler that takes Solidity source and emits Solana SBF bytecode or WebAssembly for Polkadot. It targets source compatibility with Solidity 0.8 and documents each place where behavior differs. It does not emit EVM bytecode, so EVM deployments of the same source still go through the standard solc compiler.
​

The workflow for a cross-chain team looks like this. Write the contract in Solidity. Compile it with solc for Ethereum, Base, or another EVM chain. Compile the same file with Solang for Solana. Then fix the parts that do not translate, which is where most of the effort goes.
​

The project's documentation lists Solana and Polkadot as targets and notes differences in the language reference wherever they apply. Because the Solana output runs under Solana's account model, a Solang contract on Solana is called like any other Solana program: the client passes the accounts the call reads and writes, as the Solana target page describes.
​

Solana's account model differs from Ethereum's, so several Solidity features change or disappear under Solang. msg.sender and msg.value are not available, try-catch does not work, value transfers inside a call are not supported, gas functions are absent, and every external call must list the accounts it touches.
​

The Solang Solana target page spells out each difference:

The upshot is that "one codebase" with Solang usually means one codebase with chain-specific branches for authorization, value handling, and error recovery. Access control written around msg.sender, which most EVM contracts use, needs a rewrite before it is safe on Solana.
​

Solang shares Solidity source but still needs chain-specific rewrites. Two native codebases give full control of each chain's model at double the maintenance. SauceScript shares one program across EVM and Solana for transaction logic but is not a replacement for deployed contracts that hold persistent state for many users.
​

Teams often combine these. A protocol might keep its vaults as native contracts on each chain and use a transaction program for the routing logic that moves money between them, because routing changes weekly and vaults change rarely.
​

SauceScript is a subset of TypeScript. The Sauce compiler turns a main function into compact bytecode for EVM chains or Solana, and that bytecode travels with the transaction and runs once against live state. Token and protocol names resolve per chain, so the same source targets Base or Solana by changing the chain flag.
​

The Sauce SDK launch post (October 28 2026) states that the SDK supports Ethereum, Base, Arc, and Solana at launch, and that the same SauceScript program runs on EVM chains and Solana so developers write logic once for both. The product page shows the compile step as npx sauce compile pay.sauce.ts --chain base, with Solana selected the same way.
​

A program reads state from many contracts, compares results, loops, and passes the output of one call into the next. Then it commits as a whole or reverts as a whole. That is the defining difference from Solang: Solang ships a contract that sits onchain and waits to be called; SauceScript ships logic inside the transaction that calls existing contracts.
​

The Sauce security notes show the two targets are not identical either. On Solana, try/catch does not compile ("try/catch is not available on the svm target"), so every failure reverts the whole transaction, and checks must be written as require statements before the call that can fail. That mirrors Solang's no-try-catch limit on the same chain, because both inherit Solana's runtime model.
​

Solang fits teams with an existing Solidity contract that must also live on Solana as a deployed program, and who accept rewriting authorization and value handling for Solana's account model. It fits less well when the cross-chain logic is mostly routing or settlement, which does not need a persistent contract on either chain.
​

A short decision guide:

Test each compiled target on its own chain model. EVM output runs on a local fork or testnet; Solana output runs on Devnet or a local validator. Shared source does not mean shared behavior, so the same test cases should run against both targets, including failure cases that must revert.
​

For EVM targets, Foundry's Anvil forks mainnet or any EVM chain at a specific block, which lets a test suite replay the same state every run. For Solana targets, size is the first constraint to test: a Solana transaction is capped at 1,232 bytes, per the Solana transaction docs, and complex logic hits that cap long before it hits compute limits.
​

SauceScript programs follow the same rule. The Sauce agent docs list the testnets where transactions can be built and sent: Arc Testnet, Base Sepolia, Ethereum Sepolia, Solana Devnet, and Solana Testnet. The compile step runs locally and prints the bytecode as hex; the Sauce quickstart shows a USDC payment compiling to a 223-byte program, with amounts in USDC's six decimals, so 1,000,000 base units means 1 USDC.
​

A practical test matrix for a one-source program has four cells: EVM success, EVM revert, Solana success, Solana revert. Revert tests matter more than success tests. On Solana, neither Solang nor SauceScript supports try/catch, so a failure anywhere reverts the whole transaction; a test that passes on an EVM fork by catching an error has no equivalent on Solana.
​

No option delivers true write-once for every case. Solang changes Solidity semantics on Solana, two native codebases double audit work, and SauceScript covers transaction logic on four chains with proprietary licensing. Each choice trades portability against control of a specific chain's execution model.

These are short answers to the questions developers and operators ask most often about Solang and writing one program for EVM chains and Solana. Each answer stands on its own and points to the primary documentation used in this article, retrieved in November 2026, for readers who need the full detail.
​

No. Solang targets Solana (SBF) and Polkadot (WebAssembly). EVM bytecode still comes from solc, per the Solang documentation.
​

With Solang, the same source can compile for both, but features such as msg.sender, msg.value, and try-catch behave differently or are unavailable on Solana, so most contracts need chain-specific changes.
​

SauceScript is a TypeScript subset that compiles to EVM and SVM bytecode for logic that runs inside a transaction. For deployed contracts, Solidity and Rust remain the standard languages.
​

Anchor is a development framework for building Solana programs, per the Anchor documentation. It is the usual path for teams that write native Solana programs in Rust instead of Solidity.
​

EIP-5792 wallet batching and EIP-7702 delegated account code cover simple multi-call flows on EVM chains, per EIP-5792 and EIP-7702. Neither runs on Solana.
​

No. Each compiled target runs under a different execution model and should be reviewed and tested on that chain.
​

Sources retrieved November 9 2026: Solang documentation and its Solana target page, Solidity documentation, Anchor documentation, and Eco's Sauce product page, launch post, and security considerations.
​

Related reading: Sui Programmable Transaction Blocks and the EVM Equivalent, Solana vs Ethereum, What Is a Smart Contract?, Solana DeFi Stack, Claude Code vs Cursor vs Codex for Onchain Development, Transaction Simulation Tools Compared, Solana Agent Kit Explained, AI Smart Contract Security and EVMbench.
​