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.
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:
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
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.soIt 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] += amountreads like global storage, but on Solana someone has to passto'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 likeToken(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
- cryptuon/solscript (GitHub) · docs.rs/solscript-cli
- Solana PDAs — what
mappingcompiles to - Anchor vs Pinocchio vs Steel — the frameworks underneath
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.