19 min read

Overview

The Ethereum Virtual Machine (EVM) has been the foundation of decentralized application (dApp) development for years, but Solana’s innovative architecture offers unique advantages like high throughput, low latency, and cost efficiency. This guide is designed for EVM developers who want to build on Solana. By leveraging your existing knowledge of Ethereum and EVM, this guide will help you understand Solana’s key concepts, tools, and workflows.

By the end of this guide, you’ll have a strong understanding of Solana’s architecture and how it differs from Ethereum. You’ll learn how key concepts like accounts, execution models, and transaction processing compare to EVM, helping you shift your development mindset from Solidity-based smart contracts to Solana’s stateless Rust-based programs.

What You Will Do

• Understand key differences between EVM and SVM, including execution models, account structures, and fee mechanisms
• Learn how data is stored and accessed on Solana compared to Ethereum’s storage model
• Explore the transaction processing models of both networks to understand execution efficiency
• Shift your mindset from Solidity-based smart contract development to Rust-based Solana programs and its account-driven architecture

What You Will Need

• Ethereum smart contract development (Solidity, Hardhat, Foundry) experience
• Knowledge of Basic EVM concepts (transactions, storage, gas fees, contract execution)

No prior experience with Rust or Solana is necessary. We’ll explain key differences in a way that makes sense for Ethereum developers.

Why Solana?

As an Ethereum developer, exploring Solana offers unique opportunities due to its technical strengths and notable ecosystem growth.

Technical Advantages

• Parallel Execution for High Throughput: Solana leverages Sealevel, a parallel execution engine that allows multiple transactions to be processed simultaneously, unlike Ethereum’s sequential execution model. This enables higher throughput without network congestion.

• Stateless Programs: Unlike Ethereum smart contracts, which store their own state, Solana programs are stateless and interact with external accounts for data storage. This separation of code and state improves efficiency and reduces on-chain storage costs.

• Monolithic Design: Unlike Ethereum’s modular roadmap, Solana is designed to scale natively without relying on rollups or sharding. This means simpler development, fewer cross-chain complexities, no liquidity fragmentation, and better user experience across the network.

• Cost Efficiency: Solana’s Layer 1 architecture is designed for low transaction fees, offering an economically viable environment for developers and users without relying on additional scaling solutions.

Ecosystem Growth and Developer Opportunities

• Chain GDP Growth: In Q4 2024, Solana's total application revenue, referred to as Chain GDP, grew by 213% quarter-over-quarter (QoQ), rising from $268 million to $840 million. Notably, November alone accounted for $367 million in application revenue.

• DeFi Total Value Locked (TVL): Solana became the second-largest blockchain by DeFi TVL, reaching $8.6 billion at the end of Q4 2024, marking a 213% QoQ increase.

• Decentralized Exchange (DEX) Dominance: Raydium, a leading DEX on Solana, averaged $3.2 billion in daily volume during Q4 2024, a significant increase from the previous year. Raydium's share of global DEX volume also rose by over 66% quarter-over-quarter, positioning it as the second-largest DEX by volume share, trailing only Uniswap.

• Liquid Staking Growth: The liquid staking rate on Solana increased by 33% QoQ, reaching 11.2%. Sanctum, a leading liquid staking provider, now supports over 100 liquid staking tokens (LSTs).

The network's technical capabilities, combined with its expanding ecosystem, make it an attractive option for developers. By learning how to build on Solana, you can take advantage of these opportunities and contribute to the network's growth.

For a detailed analysis, refer to Messari's State of Solana Q4 2024 report.

Key Architectural Differences Between Ethereum and Solana

Before starting, getting familiar with the differences between Ethereum and Solana's terminology is essential.

Ethereum vs. Solana: Terminology Comparison Table

Ethereum (EVM)	Solana (SVM)	Description
Smart Contracts	Programs	In Ethereum, smart contracts store both logic and state. In Solana, programs are accounts that contain executable code but are stateless, with data stored in separate accounts.
Wei	Lamports	In Ethereum, wei is the smallest unit of ETH, where 1 ETH = 10¹⁸ wei. In Solana, lamports are the smallest unit of SOL, where 1 SOL = 1,000,000,000 lamports.
Gas	Compute Units	In Ethereum, gas measures the computational effort required for a transaction, where Fee = gas used × (base + priority). In Solana, compute units (CUs) serve a similar role, where Fee = fixed base (per signature) + (CU × CU price).
ABI	IDL (Interface Description Language)	In Ethereum, an ABI (Application Binary Interface) defines how contracts interact with external applications. In Solana, IDLs (Interface Description Language) serve the same purpose, defining how programs expose functions for client interaction.
Proxy Contracts	Programs	In Ethereum, proxy contracts are used to enable smart contract upgrades. In Solana, programs are upgradable by default.
Nonce	Blockhash / Durable Nonce	Ethereum transactions use incrementing nonces per account to prevent replay attacks. Solana primarily uses a recent blockhash for transaction validation but also supports Durable Nonces for offline signing and longer transaction validity.
Transaction	Instruction	In Ethereum, a transaction typically calls a single contract function, even if it involves complex contract logic. In Solana, a transaction is composed of one or more instructions, each calling a program to execute a specific action.
ERC20 Token	SPL Token	In Ethereum, ERC-20 tokens are individual smart contracts deployed for each token. In Solana, SPL tokens are managed under a single shared Token Program, eliminating the need to deploy separate contracts for each token.

Don’t worry if some of these concepts seem a bit unclear still. We will cover them in more detail later in this guide.

Account Model: Stateful vs. Stateless

On Ethereum, smart contracts store their own state, meaning storage and execution are bundled together. In Solana, programs don’t store any state at all. Instead, all states are stored in accounts separate from the contract itself.

Ethereum’s Account Model

Ethereum accounts come in two forms:

• EOAs (Externally Owned Accounts): User-controlled accounts with private keys.
• CAs (Contract Accounts): Smart contract accounts that store both code and state.

When you deploy a smart contract on Ethereum, it is stored in a Contract Account, and all state modifications happen inside that account.

Solana’s Account Model

On Solana, everything is an account. But they are split into two categories:

• Program Accounts (Executable): Contain only code, similar to Ethereum smart contracts, but without state.
• Data Accounts (Non-Executable): Store all on-chain data, acting as persistent storage for programs.

How Accounts Work in Solana

• Every account has an owner. The owner program is the only entity allowed to modify an account’s data.
• By default, new accounts are owned by the System Program, which handles some operations like transferring tokens, allocating data on accounts, and assigning ownership of accounts.
• To create an account, all you need to do is send SOL to that address.
• Once an account is assigned to a program, the program itself controls what can happen to that account.
• Accounts need to hold some SOL (lamports) to pay for rent, a mechanism that ensures efficient usage of the blockchain’s resources. It requires accounts to maintain a minimum balance to remain active. This rent can be reclaimed if the account is closed.

Program accounts can store their data in data accounts by assigning an account from another program or using the Program Derived Addresses (PDAs) model. Developers can generate these data accounts by setting the program as the owner of the account and using a seed to derive the address.

As you can see from the image below, an Account has 5 fields: lamports, owner, executable, rent_epoch, and data.

Image Source

Program Derived Addresses (PDAs)

A Program Derived Address (PDA) is a special type of account address that a program can control without needing a private key. They enable program signing. Programs can sign for PDAs if they are derived from its program ID. Also, they allow deterministic data storage, ensuring the same seed values will always generate the same PDA.

A PDA can then be used as the address (unique identifier) for an on-chain account, providing a method to easily store, map, and fetch program state. Source

Developers can generate PDAs using seeds and a bump, ensuring they don’t collide with user-controlled addresses. The bump is an additional value (between 0 and 255) that is added to the seed to generate a unique address.

Image Source

For example, let's assume that our program has an increment function that increments a counter. Instead of storing all user counters in a single account, we can create a separate PDA for each user, where the PDA’s seed is based on the user’s public key.

• If User A calls increment, the program locates and updates User A's counter PDA.
• If User B calls increment, the program locates and updates User B's counter PDA.
• Since the program owns the PDA, only the program can modify it—the user has no direct control over the data. But programs can also design permission checks by storing an authority field inside the PDA's data, in order to give the user indirect control based on the program's logic.

This removes the need for explicit authorization on every write, making Solana programs highly efficient.

Solana's account model introduces key advantages that improve the user experience and make it easier to build on Solana. Let's explore some of these benefits.

Parallel Execution and Localized Fee Markets

Solana’s account model enables parallel execution by requiring each transaction to predefine the accounts it will read from and write to. This allows non-conflicting transactions to be processed in parallel, improving network efficiency and reducing congestion.

How It Works:

• If two transactions only read from the same account, they can be executed simultaneously.
• If one writes and another reads from the same account, execution must be sequential to maintain data consistency.
• If multiple transactions attempt to write to the same account, they are processed one at a time. Processing is determined in a localized fee market, where higher-priority (higher-fee) transactions are executed first.

Solana Priority Fee API

QuickNode’s Solana Priority Fee API allows developers to retrieve priority fees on recent fee data.

Transaction 1	Transaction 2	Execution Model on Solana
Alice sends SOL to Bob	Alice sends SOL to Charlie	Sequential
Alice sends SOL to Bob	Charlie sends SOL to Carol	Parallel

Why It Matters:

• Users not involved in high-demand operations (e.g., a popular token mint) won’t be affected by fee spikes in unrelated transactions.
• Program design affects performance. For example, Automated Market Makers (AMMs) and token minting programs with high write contention can experience execution bottlenecks. Designing programs to minimize write contention can improve performance.

Program Reusability

Other key advantages of the Solana account model include program reusability. Solana allows multiple applications to interact with shared on-chain programs. This reduces code duplication, deployment costs, and execution inefficiencies, making Solana more scalable and composable.

Ethereum: Smart Contracts Are Isolated

On Ethereum, each new use case (tokens, NFTs, DeFi protocols) typically requires:

• A separate smart contract deployment, leading to redundant logic across the network.
• Unnecessary transaction fees on contract creation due to repetitive contracts.
• Independent storage and execution, making it harder for contracts to interact seamlessly.

For example, if you create a new ERC-20 token, you must deploy an entirely new smart contract, even though most ERC-20 contracts are functionally identical.

Solana: Reusable Programs

Solana programs are built to be shared and reused. Instead of deploying a new program for each use case, developers can create new accounts under existing programs.

For example, the Solana Token Program governs all SPL tokens (token standard on Solana), eliminating the need for separate token contracts:

• Instead of deploying a contract, you create a mint account under the Token Program.
• This mint account defines the token’s properties, like supply, decimals, and authorities.
• The Token Program handles all operations (minting, burning, transfers) without requiring a separate contract per token.

These examples can be extended to other use cases like DAOs, NFTs, etc.

It's not possible to cover all details of the Solana Account Model in this guide. If you're interested in learning more about the Solana account model, check out our An Introduction to the Solana Account Model guide.

Gas Fees

Understanding how transaction fees work is crucial when transitioning between Ethereum and Solana, as their approaches differ significantly due to architectural choices. While they have similarities such as having a priority fee and base fee, the fee structure is different.

Ethereum Fees

• Global Fee Market: Ethereum operates with a universal fee market where high demand in one area (like an NFT mint) can drive up gas prices for all transactions. Gas measures computational effort, while the gas price you set determines transaction priority, leading to fee spikes and higher costs during congestion.

• Base Fee: Every block on Ethereum has a base fee, which is determined by the blocks before the current block.

• Priority Fee: Priority fees are a way to incentivize validators to prioritize transactions. Users can pay a higher priority fee to ensure that their transaction is included in a block before other transactions, which may lead to fee spikes during congestion.

Gas measures computational effort, similar to Solana's Compute Units, and the total fee is calculated as gas used * gas price, while the gas price consists of the base fee and the priority fee.

Solana Fees

Solana's fee structure ensures that only transactions interacting with the same accounts compete for priority, while other transactions remain unaffected by high-demand operations.

Base Fee:

• Depends on the number of signatures required for a transaction.
• Each signature costs 5000 lamports (0.000005 SOL).
• Half of the fee is burned, and half goes to validators.

Priority Fee:

• Users can bid additional fees to prioritize their transactions, similar to Ethereum’s priority fee.
• Validators use this fee to determine which transactions to include first in high-demand situations.
• Half of the fee is burned, and half goes to validators.

Total fees depend on the price a user is willing to pay for priority and the total compute required by the transaction (more complex transactions require more Compute Units).

Rent (Storage Cost):

• Solana requires accounts to deposit SOL to remain active—this prevents inactive accounts from taking up unnecessary storage.
• This is not a fee but a refundable deposit. When an account is closed, the rent is reclaimed as specified by the program owner (e.g., usually account authority).
• More details on rent can be found in the Rent on Solana guide.

Transaction Processing

Both Solana and Ethereum support atomic transactions, meaning that if any part of the transaction fails, the entire transaction is reverted. However, transaction processing is slightly different on Solana and Ethereum.

Ethereum Transactions

On Ethereum, a transaction is typically a single function call to a smart contract. Thus, developers may need to create custom functions to handle specific use cases.

Ethereum uses incremental nonces (a counter tied to your account) to ensure transactions are unique and prevent replay attacks. Transactions wait in a mempool, where validators pick them up, but this can lead to front-running or higher gas fees during network congestion.

Solana Transactions

Solana takes a different approach on processing transactions. A transaction can bundle multiple instructions -think of them as mini-function calls- allowing you to chain actions (e.g., transfer tokens and update a balance) in one go.

However, there are limits to how many instructions can be included in a single transaction:

• Transaction Size Limit: 1232 bytes per transaction
• Compute Unit Limit: Transactions must stay within the max compute budget, meaning complex transactions may need to be split

Compute Units on Solana

Limits	Compute Units
Max Compute per block	48 million
Max Compute per account per block	12 million
Max Compute per transaction	1.4 million
Transaction Default Compute	200,000

As you get more experience with Solana, you may encounter these transaction limits. There are tools like Lil' JIT Jito Bundles that enable atomic batching of multiple transactions, allowing complex executions beyond the standard CU cap.

Source: Strategies to Optimize Solana Transactions

Solana uses a recent blockhash instead of a nonce to validate transactions. This blockhash is valid for 150 blocks, after which the transaction expires.

Alternatively, Solana supports Durable Nonces, which allow transactions to be signed offline and submitted at any time. Durable Nonces are unique and sequential, preventing replay attacks and ensuring safe execution for delayed transactions.

There’s no mempool, but priority fees still play a role in ordering transactions. Transactions go straight to validators and leaders, cutting overhead and reducing delays, but needing validators to forward transactions to the leaders until they are processed.

Leaders are responsible for producing blocks and are rotated every 4 blocks.

Solana Transactions

A Solana transaction is composed of:

• an array of instructions
• an array of accounts to read or write from
• an array of signatures
• a recent blockhash

For more details on Solana transactions, check out our guide.

Development Tools

Below is a table comparing some of the common development tools between Ethereum (EVM) and Solana (SVM) to help you transition smoothly.

Ethereum Tool	Solana Equivalent	Description
Solidity	Rust, C, TypeScript, Assembly	Rust (with or without Anchor) is the standard for Solana. C, Assembly, and TypeScript are also used in Solana.
Hardhat/Foundry	Solana Test Validator, LiteSVM, Luzid	Local blockchain for testing programs and accounts, similar to Hardhat’s node.
Hardhat/Foundry	Program-test, BankRun.js	Rust and JS testing frameworks for programs
Ethers.js / Viem	@solana/kit (formerly Solana Web3.js 2.x), Solana Web3.js 1.x (deprecated)	JavaScript SDK for client-side dApp interactions, akin to Ethers.js.
Remix	Solana Playground	Web-based IDE for writing, testing, and deploying Rust programs, mirroring Remix’s ease.
ABI	Codama, Shanks, Anchor	Standardized IDL and client generation tool, replacing Ethereum’s ABI for program interactions.
Etherscan	SolanaFM, Solana Explorer, Solscan	Blockchain explorers for inspecting accounts and transactions, similar to Etherscan.
scaffold-eth	create-solana-dapp	Boilerplate generator for quick dApp setup, comparable to scaffold-eth.
RainbowKit	Solana Wallet Adapter	A framework for handling wallet connections, similar to wagmi or RainbowKit in Ethereum.

Not Ready for Rust?

If you’re not ready to dive into Rust, you can use Neon, an EVM deployed in a Solana program, for Solana. It allows you to write Solidity contracts and deploy them on Solana. You can find more information on Neon here and check our Neon Guides.

Smart Contract (Program) Development

In smart contract (program) development, Solana takes a different approach, where programs are stateless, and data is stored in separate accounts.

This section will help you understand key differences between Ethereum and Solana smart contract development without going too deep.

Smart Contract Structure: Code & State Separation

Ethereum: Smart Contracts Hold Both Code & State

• On Ethereum, a smart contract is a single unit that contains both logic (code) and persistent storage (state).
• It is deployed as a Contract Account (CA), separate from Externally Owned Accounts (EOAs) that users control.
• Example: If you retrieve a token balance, it's fetched directly from the contract's storage.
• Upgrades require proxy patterns (e.g., Transparent Proxy, UUPS).

Solana: Programs Are Stateless; State Is External.

• Solana programs do not store any state. Instead, all data is stored in accounts that the program interacts with.
• Programs are deployed into executable accounts, and state is stored in non-executable accounts (e.g., PDAs - Program Derived Addresses).
• Example: A token balance isn’t stored in a smart contract but in an account owned by the Token Program.
• Programs are upgradable by default (but can be locked for immutability).

Data Storage: Mappings vs. Accounts

Ethereum: Uses Mappings for Storage

• Solidity allows mappings (e.g., mapping(address => uint256) balances;) to store data inside the contract.

Solana: Uses Accounts Instead of Mappings

• There’s no direct equivalent to mappings in Solana. Instead, PDAs (Program Derived Addresses) act as deterministic accounts that store structured data.
• Example: Instead of mapping a token balance to an address, you create a PDA account that stores user balances.

Instead of thinking in terms of mappings, think in terms of creating separate accounts that hold the necessary data for each user or entity.

Function Execution: Message Sender vs. Explicit Accounts

Ethereum: msg.sender and tx.origin Handle Authorization

• In Solidity, contracts automatically know who is calling the function via msg.sender and who is the user that originated the transaction via tx.origin.

Solana: Explicit Account Passing Required

• Solana programs do not have a built-in msg.sender equivalent. Instead, you must explicitly pass the accounts the program will interact with.
• Example: To transfer tokens from one user to another, the transaction must include:
  • The Token Program account: This is the program that executes the token transfer logic.
  • The sender’s token account: This account holds the sender’s tokens and will be debited.
  • The recipient’s token account: This account will receive the transferred tokens.
  • The sender’s main wallet account: This account pays the transaction fee and is typically the signer of the transaction.
• This explicitness ensures the Solana runtime knows exactly which accounts are involved and what roles they play (e.g., readable, writable, or signer).

Always think in terms of accounts when designing Solana programs. You must pass in every account your program interacts with.

Token Standards: ERC-20, ERC-721, etc. vs. SPL Tokens

Ethereum: Each Token Has Its Own Contract

• Ethereum has different token standards (e.g., ERC-20, ERC-721, etc.) for each token. Each token follows the corresponding standard, but each of them is a separate smart contract, requiring a new contract deployment for each new token.

Solana: One Token Program, Many Tokens

• Solana has one centralized Token Program that manages all SPL (Solana Program Library) tokens.

• Instead of deploying a new contract for each token (like ERC-20 on Ethereum), you create a mint account under the Token Program.

• The Token Program handles all core token functionality including:

  • Creating new tokens (mint accounts)
  • Minting new tokens into accounts
  • Burning tokens
  • Transferring tokens between accounts

• Each user’s token balance is stored in a dedicated token account — an Associated Token Account (ATA) tied to both the user’s wallet address and the token’s mint address.

• Solana also introduced SPL Token 2022, which extends the original Token Program with advanced functionality like metadata, transfer guards, transfer fees, and more.

While this guide doesn’t cover every difference, these are some key distinctions to keep in mind when transitioning from Ethereum to Solana.

Next, we’ll explore the basics of getting started with Solana, including wallets and CLI tools.

Getting Started with Solana: Wallets & CLI Basics

While it's possible to create wallets programmatically using libraries, Ethereum developers typically use browser-based wallets like MetaMask or Rabby to create their wallets. These wallets generate an Externally Owned Account (EOA), allowing users to sign transactions and manage funds.

On Solana, you can create a wallet using a browser extension (e.g., Phantom, Solflare) or via the command line (Solana CLI).

Creating a Wallet on Solana

Option 1: Using a Browser Wallet (Phantom, Solflare, Backpack)

• Install a wallet. Check out this guide for more details.
• Create a new wallet and back up your Secret Recovery Phrase.
• Use this wallet to sign transactions and interact with Solana dApps.

Option 2: Creating a Wallet with Solana CLI

If you want a wallet for development purposes, you can generate a keypair using the CLI:

solana-keygen new --outfile ~/.config/solana/id.json

This creates a keypair JSON file (id.json), which contains your private key in array format. Also, you will have a mnemonic phrase that you can use to recover your keypair.

Secure Your Keypair

Keep your id.json file safe and private. Never share its contents or your mnemonic phrase, as they grant full access to your wallet and funds.

Importing & Exporting Wallets

If you have a wallet in a browser extension (i.e., Phantom) but want to use it in the CLI, you need to export its private key from the extension.

We'll cover how to export a Phantom wallet into the Solana CLI and vice versa.

Export a Phantom Wallet into Solana CLI

1. Open Phantom and find the option to export your secret recovery phrase.
2. Copy the phrase (a series of words).
3. Run the following command:

   solana-keygen recover 'prompt://?key=0/0' -o my-wallet.json
4. Enter your secret recovery phrase when prompted.
5. The keypair will be imported to the Solana CLI.

Import a Solana CLI Wallet into Phantom

1. Open the id.json file in a text editor.
2. Copy the contents of the file (it looks like [12, 34, 56, ...]).
3. In Phantom, find Import Private Key and paste the copied value.

This will restore your CLI-generated wallet into Phantom.

Setting Up Solana CLI & RPC Configuration

Developers interact with the Solana network through RPC endpoints. You can configure which network you interact with (mainnet, testnet, or devnet).

QuickNode RPCs

For faster development, QuickNode provides RPC endpoints for Solana. You can use these RPCs to interact with the Solana network without having to set up your own node or using public RPCs. To get your RPC endpoint, sign up for a free account here.

Check your current config:

solana config get

Set your RPC endpoint (e.g., devnet):

solana config set --url devnet

Verify your wallet address:

solana address

Airdrop test SOL for development:

solana airdrop 2
solana balance

This will give you 2 SOL for testing on Devnet. Also, you can use the QuickNode Faucet to get test SOL.

For more information, check out the A Complete Guide to Airdropping Test SOL on Solana.

Multichain Development with QuickNode

While Ethereum and Solana differ significantly in their technical designs, QuickNode provides a robust, unified infrastructure that bridges these ecosystems for developers. Below is a technical overview of how QuickNode supports seamless transitions between Ethereum (and other EVM-compatible chains) and Solana, along with key features that enhance the development experience.

Key Features for Multichain Development

• Unified Infrastructure: QuickNode serves as a trusted provider for both Ethereum and Solana ecosystems, eliminating the need to switch providers when transitioning between these blockchains.
• Chain-Specific Optimizations:
  • For Ethereum and EVM-compatible chains: High-performance RPC endpoints, advanced analytics, and tools tailored for smart contract development.
  • For Solana: Ultra-low-latency access optimized for high throughput and fast block times.
• Custom Products & Tooling:
  QuickNode provides specialized products and tools tailored to each blockchain’s unique requirements, including core RPC APIs, real-time data streaming, serverless functions, and add-on services.
  • Ethereum: Our Ethereum chain page provides an overview of everything possible with QuickNode, from core infrastructure to advanced tooling like Streams, Functions, and Marketplace add-ons. Read more in our Ethereum docs.
  • Solana: Our Solana chain page outlines QuickNode’s capabilities on Solana, including four different data streaming solutions, core RPC services, and additional developer tools through the Marketplace. See our Solana docs for more information.
• Global Low-Latency Architecture: Ensures optimal performance regardless of geographic location, critical for decentralized applications requiring minimal latency.

Reliability and Compliance

QuickNode’s infrastructure is designed to meet the demands of mission-critical applications, ensuring security, uptime, and support for developers.

• SOC Compliance: Adheres to SOC 1 and SOC 2 Type 2 standards, ensuring secure and reliable operations.
• Guaranteed Uptime: Maintains 99.99% uptime for consistent application performance.
• End-to-End Support: Offers direct technical support to resolve issues quickly and keep development on track.

With its robust infrastructure and developer-focused tools, QuickNode simplifies the complexities of building across Ethereum and Solana.

Foundational Solana Guides

To help you get hands-on with Solana, here are some foundational guides that cover the basics:

• Send Your First Transaction
• Create a Token
• Transfer SPL Tokens
• Write Your First Anchor Program
• How to Use the Solana Memo Program
• How to Use Program Derived Addresses

Conclusion

Transitioning from Ethereum (EVM) to Solana (SVM) requires a shift in mindset, especially when it comes to program architecture, execution models, and account management. Instead of smart contracts storing their own state, Solana separates execution (programs) and storage (accounts), leading to higher efficiency and better scalability.

While Solana development differs from Ethereum, many concepts can be mapped to make the transition easier. By understanding key differences and leveraging your existing knowledge, you can explore Solana’s ecosystem, build efficient dApps, and contribute to the network’s growth.

Want to see more content like this? Drop your feedback below!

We ❤️ Feedback!

Let us know if you have any feedback or requests for new topics. We'd love to hear from you.

Subscribe to our newsletter for more articles and guides on Web3 and blockchain. If you have any questions or need further assistance, feel free to join our Discord server or provide feedback using the form below. Stay up to date with the latest by following us on Twitter (@QuickNode) and our Telegram announcement channel.

Additional Resources

For those looking to dive deeper into Solana development, here are some helpful resources:

QuickNode Solana Content

• Solana Documentation - Technical documentation for Solana.
• Solana Guides - All guides for Solana developers.
• Intro to Solana Development - Free course on Solana development basics.
• Solana Fundamentals Reference Guide – Key concepts and terminology for Solana developers.
• Introduction to Solana Wallets – Find a Solana Wallet to get started.

Official Documentation & Guides

• Solana Docs – Official technical documentation.
• Solana Cookbook – Developer-friendly guides for Solana.
• Anchor Framework – Simplified framework for Solana smart contracts.

Explorers & Tooling

• Solana Explorer – View transactions and accounts.
• SolanaFM – Advanced block explorer.
• Solana Playground – Web-based IDE for writing and testing Solana programs.

Community & Learning

• Solana Stack Exchange – Ask technical questions.
• Solana GitHub – Explore the core Solana codebase.
• Anza GitHub-Agave client and other Solana tools (formerly Solana Labs)