All articles
solanadeveloper-toolssoliditycompilerevm

SolScript: write Solidity, compile to Solana

SolScript compiles Solidity-syntax contracts to Anchor/BPF, turning mappings into PDAs automatically. A real EVM-to-Solana on-ramp — and where the account-model abstraction leaks.

Share

SolScript is a Rust-written compiler with a simple pitch: write Solidity, deploy to Solana. You write contracts in familiar Solidity syntax; it compiles them to standard Anchor programs (or directly to BPF). For the large population of EVM developers eyeing Solana, it's one of the more interesting on-ramps — and an instructive case study in what does and doesn't translate.

The clever part: mapping → PDA

The single hardest concept for an EVM dev arriving on Solana isn't Rust — it's the account model. Ethereum gives you global contract storage (mapping(address => uint256) just works); Solana makes you derive a PDA per key, validate accounts, and pass them into every instruction. SolScript's core trick is mapping one onto the other automatically:

solidity
contract Token {
    mapping(address => uint256) public balanceOf;
    event Transfer(address indexed from, address indexed to, uint256 value);
    error InsufficientBalance();

    function transfer(address to, uint256 amount) public {
        if (balanceOf[msg.sender] < amount) revert InsufficientBalance();
        balanceOf[msg.sender] -= amount;
        balanceOf[to] += amount;
        emit Transfer(msg.sender, to, amount);
    }
}

That mapping becomes PDA-derived accounts, the account structs and #[account(...)] constraints are auto-generated, and validation is inferred from your types. The README's before/after says it plainly: ~70 lines of raw Anchor (program + #[derive(Accounts)] + errors + events) collapse to ~12 lines of Solidity.

Quick start

bash
cargo install --git https://github.com/cryptuon/solscript solscript-cli

solscript new my-token
cd my-token
solscript build-bpf
solana program deploy target/deploy/my_token.so

It supports the patterns you'd actually reach for — tokens/AMMs, escrow and marketplaces (enum/struct/mapping), events, custom errors, modifiers, cross-program invocation, and SPL Token operations. Rust 1.83+, MIT-licensed, published as solscript-cli on crates.io.

The escape hatch that makes it sane

The most important design decision: the output is standard Anchor/Rust. SolScript isn't a walled runtime — it's a source-to-source compiler whose artifact is an ordinary Anchor program you can read, audit, modify, and keep maintaining without SolScript in the loop. "Eject anytime" turns it from a risky lock-in into a low-risk accelerant: prototype in Solidity, graduate to Rust when you need to. It sits naturally next to Poseidon (TypeScript→Anchor) and Solita (IDL→client) as another compiler entry point into the Solana stack.

Where the abstraction leaks (the honest read)

Solidity and the SVM disagree at a deep level, and no compiler fully hides that:

  • The account model still shows through. balanceOf[to] += amount reads like global storage, but on Solana someone has to pass to's balance PDA into the transaction (and pay rent to create it). The abstraction is elegant until the moment a caller has to know which accounts to supply — which is most non-trivial moments.
  • EVM idioms map awkwardly. msg.sender, address(this), and cross-contract calls like Token(x).transferFrom(...) have no clean 1:1 with Solana signers, PDAs, and CPIs into the SPL Token program. They can be translated, but the semantics aren't identical, and subtle differences are where bugs live.
  • Solana-specific concerns are invisible in Solidity. Compute-unit budgets, rent, account size limits, the 1232-byte transaction ceiling — none of these are expressible in the source language, so you can write valid Solidity that compiles to a program with Solana-native problems.
  • It's early. v0.1.x. Treat it as a fast prototyping and learning tool, not a battle-tested production compiler — and audit the generated Anchor, not just the Solidity.

The right mental model: SolScript is a bridge for your brain, not a way to avoid learning Solana. It gets an EVM developer to a working Solana program in minutes and teaches the mapping → PDA correspondence by showing the generated code. For production DeFi you'll still want to understand — and probably hand-tune — the Rust it emits.

References

You can't compile away Solana's account model — but SolScript can compile your Solidity into it, and show you the translation. For an EVM dev, that's a genuinely useful first step onto the SVM.

SolScript: write Solidity, compile to Solana | devrels.xyz