Use case · Migration

Migrating from Ethereum to Solana

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