---
title: "Solana smart contract gotchas every Anchor dev hits in 2026"
description: "Seven Solana and Anchor pitfalls that catch teams coming from EVM: account ownership, PDAs, rent exemption, compute budget, and Solidity's subtle differences."
date: 2026-04-22
updated: 2026-04-22
author: "Dezső Mező"
tags: "Blockchain, Solana, Anchor, Rust, Security"
slug: solana-smart-contract-gotchas-2026
canonical: https://dfieldsolutions.com/blog/solana-smart-contract-gotchas-2026
---

# Solana smart contract gotchas every Anchor dev hits in 2026

Solana is not Ethereum-with-better-TPS. Seven differences that bite every team coming from EVM.
Solidity developers bringing EVM intuitions to Solana hit the same seven gotchas on every project. They're not bugs in Solana · they're genuinely different mental models. Here they are, with the fixes we write in every Anchor codebase.

## 1 · Accounts are passed in, not looked up

In Solana, every account a program touches must be listed in the transaction's account set. There's no 'SELECT by ID' at runtime. Forgetting to include an account = the transaction fails. Forgetting to check ownership = your program trusts attacker-controlled data.

## 2 · PDAs and bump seeds

Program-Derived Addresses are deterministic · anyone can compute them. The security comes from the bump seed and the program's ownership of the account. Always verify bump + seed in the handler; never trust caller-supplied PDAs.

## 3 · Rent exemption

Accounts below ~2 years of rent are subject to deletion. Always make accounts rent-exempt at creation. If you don't, your program can read from a 'zeroed-out' account that used to hold real data.

## 4 · Compute budget

Each Solana tx has a 200k compute-unit default; you can request up to 1.4M. Loops over large account lists hit this fast. Plan for batch operations · and benchmark with `solana logs` before shipping.

## 5 · SPL token semantics ≠ ERC-20

In SPL, every token account is a separate account per (mint, owner) pair · not a balance in a contract. Transfers require both sender's and recipient's token accounts in the tx. The 'approve' flow is delegation on the token account, not an allowance in a contract.

## 6 · Reentrancy is different

Solana doesn't have classic reentrancy the way EVM does · you can't call another program and have it call you back mid-transaction (CPI doesn't recurse by default). But 'reentrancy-like' bugs show up when you trust an account's state between CPIs. Re-read after every CPI.

## 7 · The #[account] macro is doing a lot

Anchor's `#[account]` validates account types, constraints, and ownership. Removing a constraint to 'simplify' is how most Solana audit findings start. Trust the macro; don't optimise it away.

> **NOTE:** If you're coming from Solidity, invest 2 weeks in serious Anchor tutorials before you touch mainnet. The mental-model switch is real · not something you can absorb by trial-and-error.

---

Source: https://dfieldsolutions.com/blog/solana-smart-contract-gotchas-2026
Author: Dezső Mező · Founder, DField Solutions
Site: https://dfieldsolutions.com