Solana is a high-throughput blockchain designed for low latency and parallel transaction execution. Its smart contracts, called programs, follow a model very different from the EVM, so Ethereum experience does not transfer directly. For a project, choosing Solana means working with Rust specialists and budgeting for a review focused on how accounts are passed and validated.
Building on Solana
Programs are stateless: data lives in separate accounts that each transaction must list explicitly, and the program is responsible for checking that every account it receives is the one it expects. Programs can call each other through cross-program invocations and control accounts derived from their own address (program derived addresses). Programs are upgradeable by default through an upgrade authority, which can be kept, transferred or removed.
- Language: Rust, compiled for the Solana runtime
- Framework: Anchor, which generates much of the account validation code
- Tokens: the SPL token programs, including the newer token program with extensions
- Not EVM-compatible
What auditors look at
- Account validation: owner checks, signer checks, type confusion between accounts, and substitution of a legitimate account by an attacker's account
- Program derived addresses: seed design, bump handling and collisions between different account types
- Cross-program invocations: calling the expected program ID and the privileges passed along
- Arithmetic and precision in token amounts, and rounding in favor of the protocol
- Upgrade authority, account closing and reinitialization, and compute limits on large operations
Before requesting quotes
- Specify whether the program uses Anchor or native Rust, and the Anchor version
- Provide a description of every instruction with the accounts it expects and their constraints
- Share tests that exercise failure cases, not only successful flows
- State who holds the upgrade authority and whether the program will be made immutable