Use case · Migration

Ethereum to Solana migration for Solidity teams

Solana offers high throughput and low fees, but native development is in Rust and Anchor. SolScript lets an Ethereum team carry its Solidity knowledge — and much of its contract logic — across to Solana.

The challenge

The two chains use different virtual machines. Ethereum runs the EVM with a flat storage model and mappings; Solana runs BPF with an account model and Program Derived Addresses. A naive port means rewriting storage access, account handling and program structure by hand — in a new language.

How SolScript bridges it

• Same syntax. Your team keeps writing Solidity — state variables, mappings, events, modifiers.
• Mappings become PDAs. SolScript converts mapping storage to PDA-backed accounts automatically.
• Auditable output. You get readable Anchor/Rust to review and adapt where Solana semantics differ.

contract Vault {
    mapping(address => uint256) public deposits;
    event Deposited(address indexed user, uint256 amount);

    function deposit(uint256 amount) public {
        deposits[msg.sender] += amount;
        emit Deposited(msg.sender, amount);
    }
}

Where you still have to think

Solana's account model surfaces in ways the EVM hides — accounts must be passed explicitly, and EVM-only features have no equivalent. SolScript handles the mechanical translation; the architectural decisions remain yours. The migration guide and Solana for Ethereum developers go deeper.

FAQ