Transitioning from EVM to Solana: Essential Security Concepts You Need to Know

Source: Transitioning from EVM to SVM: Key Concepts for Solana Security Assessment

Solana operates differently from Ethereum’s EVM, especially in how it manages programs, storage, and transactions. This guide highlights the key Solana concepts developers and security auditors must understand when assessing Solana programs.

Program Derived Addresses (PDAs) and Their Lifecycle

• Storage Separation: Unlike EVM contracts that combine code and storage, Solana’s SVM isolates program logic from storage. Data lives in accounts, often at Program Derived Addresses (PDAs).
• PDA Characteristics: PDAs resemble Solana public keys but are deliberately generated off the Ed25519 curve using a `bump` seed to ensure uniqueness.
• Initialization & Rent: PDAs require explicit initialization with allocated storage (which costs a rent fee). They can later be resized or closed-closing refunds the rent.
• Access Control: Securing PDAs is critical. Only authorized callers should initialize, modify, or close them. Improper constraints on accounts, especially authorities, can lead to major vulnerabilities, such as unauthorized fund withdrawals.
• The Anchor framework simplifies PDA lifecycle management with directives like init, realloc, and close.

Security Tips: Verify seeds, bump values, ownership, and ensure closed PDAs aren’t reused to avoid state corruption.

Cross-Program Invocation (CPI)

• CPI lets one Solana program call another, requiring three items: the target program’s address, related accounts, and instruction data.
• The caller may use a PDA to "sign" the invocation. This is not a cryptographic signature but a Solana-specific trust mechanism where the called program validates the PDA using seeds and program ID.
• When auditing, confirm that the PDA signer is verified correctly to prevent caller spoofing.

SPL Tokens: Solana’s Token Standard

• SPL Tokens resemble ERC20 but operate via separate Mint Accounts (token metadata) and Token Accounts (holder balances).
• Users must create Token Accounts before owning tokens-this extra step is sometimes bypassed with Associated Token Accounts that are deterministically derived for convenience.
• Robustly verify token and account ownership to prevent unauthorized token manipulation.

Transactions and Instructions

• A Solana transaction bundles multiple instructions-each an atomic operation.
• Transactions must fit within a 1,232-byte limit, encouraging developers to aggregate inputs across multiple instructions when handling complex actions.
• Atomicity prevents partial execution – for example, swapping tokens typically combines approval and swap instructions in one transaction to avoid front-running or sandwich attacks.

Handling Solana’s Native Asset (SOL)

• SOL resides in accounts and is mutable during program calls.
• Programs have broad access to SOL balances under their control, posing risks if unchecked.
• Security assessments should ensure proper access control and use intermediary accounts with limited SOL amounts for sensitive operations.
• Avoid letting programs execute arbitrary SOL transfers without strict validation.

Summary

When assessing Solana programs, focus on:

• PDAs: enforce strong access control and correct initialization.
• CPIs: validate PDA signers and program ownership.
• SPL Tokens: understand Mint vs. Token Accounts, verifying all involved addresses.
• Transactions: leverage atomic multi-instruction transactions to avoid execution vulnerabilities.
• SOL: restrict free access and safeguard transfers with strict permissions.

Mastering these core components ensures stronger security in the Solana ecosystem.