End-to-End Solana Smart Contract Development in Rust

We develop Solana smart contracts in Rust turnkey — from accounts model design to multisig deployment. Solana attracts developers with sub-second finality and $0.00025 transaction cost. But behind that speed lies a fundamentally different execution model: accounts model instead of contract storage, stateless programs, PDA derivation instead of mappings. A developer coming from EVM spends the first two weeks thinking Solana is broken — because the familiar Solidity patterns either don't work here or lead to a different class of vulnerabilities. We've learned to sidestep these pitfalls over 5 years of practice.

Why Solana Programs Break EVM Developers

According to Solana documentation, programs do not own data — they only authorize operations on passed accounts. In EVM, the contract stores its state internally. In Solana, the program is a stateless executable, and data lives in separate accounts that the program does not own — it only authorizes operations on them. This means every instruction call requires explicitly passing all accounts involved.

Missing signer check

First pitfall: missing signer check. The program receives an account via AccountInfo but does not check that the passed authority actually signed the transaction. In Anchor, this is caught with the #[account(signer)] attribute or Signer<'info> type. In native Rust, it is done via explicit check if !authority.is_signer { return Err(...) }. It's easy to miss when writing your early programs.

Account substitution

The second classic vulnerability is account substitution. The program receives a token_account and authority but does not check that token_account.owner matches the passed authority. An attacker passes their own token_account and someone else's authority — the program executes without error and drains foreign tokens.

PDA derivation mismatch

The third major pain is PDA derivation mismatch. Program Derived Address is derived from seeds + program_id. If seeds are not explicitly verified via find_program_address with a constraint in Anchor (seeds = [b"vault", user.key().as_ref()]), an attacker can pass an arbitrary account that happens to match the PDA address but is not legitimate.

How Anchor Changes the Security Equation?

We mainly use the Anchor framework (current version 0.30.x). Anchor generates a discriminator for each account type and checks it during deserialization — this automatically closes a whole class of type confusion attacks where an attacker passes an account of the wrong type.

A typical instruction structure in our codebase:

#[derive(Accounts)] pub struct Deposit<'info> { #[account( mut, seeds = [b"vault", user.key().as_ref()], bump, constraint = vault.authority == user.key() @ ErrorCode::Unauthorized )] pub vault: Account<'info, VaultState>, #[account( mut, associated_token::mint = mint, associated_token::authority = user )] pub user_token_account: Account<'info, TokenAccount>, pub user: Signer<'info>, pub mint: Account<'info, Mint>, pub token_program: Program<'info, Token>, pub system_program: Program<'info, System>, } 

Constraints in #[account(...)] are not just syntactic sugar. They compile to explicit checks executed before the instruction logic. If a constraint is violated — the transaction reverts before instruction logic runs.

How to Test Solana Programs Without Starting a Validator?

For most unit tests, we use solana-bankrun — it spins up a synthetic runtime in memory without starting a validator. A test that would take 3 seconds on localnet (a slot every 400 ms) executes in 50 ms — 60 times faster. This is critical for fuzzing.

Integration tests run on localnet via anchor test. We add --skip-local-validator where the test scenario requires real programs (Associated Token Program, Metaplex) — we clone their state from mainnet using --clone.

For fuzzing SPL programs, we use Trident (Ackee Blockchain's fuzzer). It generates random sequences of instructions and looks for panics, unexpected account state, integer overflow. On one project, Trident found in 4 hours a scenario where the sequence init → close → reinit led to reinitialization of an account with foreign data — Anchor discriminator passed because reinit used the same type.

Compute Units Optimization

Solana limits each transaction to 1.4M compute units by default (you can request up to 1.4M via SetComputeUnitLimit). Serialization/deserialization via Borsh is expensive for large structures.

Practice: split large state structures into multiple accounts. Instead of one ProgramState with 50 fields — several specialized accounts. Less data deserialized per call — less CU spent.

Second technique: zero_copy accounts via #[account(zero_copy)] in Anchor. Data is read directly from memory without Borsh deserialization. On structures >1KB, we save 30-50% CU.

Development Process

Analytics and design (2-5 days). We break down the accounts model for the task: which PDAs are needed, what seeds, where CPI to Token Program or Associated Token Program is required. We design state before writing code — reworking accounts structure during testing is expensive.

Development (3-10 days depending on complexity). Anchor + Rust stable. We cover each instruction with tests via Bankrun. Complex scenarios (PDA lifecycle, CPI chains) run on localnet.

Security review. We run it through Soteria (static analysis for Solana programs) and a manual review based on a checklist: missing signer, ownership checks, PDA validation, integer arithmetic (we use checked_add, checked_mul everywhere).