May 21
Loading video player...
Struggling to port an Ethereum contract to Solana? Early design decisions — before a single line of Solana code — cut rework, reduce user disruption, and align your implementation with Solana's account and compute model. What you'll learn In this lesson you'll translate a contract surface inventory into a concrete porting plan. You will learn how to reshape EVM storage into Solana accounts and Program Derived Addresses (PDAs), and when to choose a single account vs. multiple hot/cold accounts. You'll see patterns for splitting large EVM functions into Solana-compatible handlers, including expected transaction boundaries, signer and account requirements. The lesson compares dependency-replacement strategies (on-chain Cross-Program Invocation, oracle relays, or off-chain indexing) and explains how to justify choices based on performance, cost, and security. Finally, you'll learn how to produce an incremental migration plan and a concise design brief that documents state mapping, entry-point refactors, and tradeoffs with mitigations. Who this is for Intermediate smart-contract engineers who understand basic EVM storage and have some familiarity with Solana primitives (accounts, ownership, rent, and PDAs). Prior experience mapping contract storage or auditing gas/compute hotspots is helpful but not required. Key topics covered - State reshaping: mapping EVM storage slots to Solana accounts and PDAs - Account mapping decisions: ownership, rent-exemption, fixed allocation size - Entry-point refactors: splitting functions, transaction boundaries, signer requirements - Dependency strategies: CPI, oracle relays, off-chain indexers and tradeoffs - Performance and cost tradeoffs: compute limits, rent, account size, and mitigations - Incremental migration planning and producing a concise design brief Ready to turn design into implementation? Learn more and access Forge College resources at https://www.forge.college/