11 Sept 2026/ Chuks Agu

Solana, Move, and EVM Audits Are Not the Same Job: A Chain-by-Chain Guide

A lending protocol clears a Solidity audit, rewrites for Solana six months later, and sends the Rust program to the same firm, which returns a clean report in nine days. Three weeks after launch, a caller passes a look-alike vault account carrying a fabricated balance into the withdraw instruction, and the program pays out because nobody on the review had ever needed to check which program owned an account.

That team did not buy a bad audit. It bought the wrong one. A Solana smart contract audit reads Rust programs and the accounts they are handed, and the firm that did its Solidity work had never shipped a finding in that runtime. (Solana calls its on-chain code programs, not smart contracts. This guide keeps “smart contract” only where a founder would search for it.)

Audit competence is runtime-specific and mostly non-transferable. The sections below show what actually changes, chain by chain. If you have not yet read what a smart contract audit covers in general, start there.

Key Takeaways

An auditor who hunts Solidity reentrancy brings no catalog for Solana account validation. Solana programs are stateless, and the runtime blocks cross-program reentrancy, so the bug they know best is absent.
Move’s linear resource model closes the copy-and-drop family of accounting vulnerabilities at compile time, so a Move audit spends its hours on ability annotations and upgrade policy.
Sui Move stores state as objects that are owned, shared, or immutable, and Aptos Move stores resources under account addresses, so fluency in one dialect is not fluency in the other.
Two clean single-chain audits leave the message-passing layer between them unreviewed, and the Wormhole exploit of February 2, 2022, lived in the bridge program that sits in that layer.

What “Solana Smart Contract Audit” Actually Means in 2026
Why an Audit Record on One Chain Does Not Transfer to Another
EVM and Solidity: The Audit Everyone Benchmarks Against
Solana and Anchor: Auditing Rust Programs and the Account Model
Move on Sui and Aptos: One Language, Two Audits
The Cross-Chain Case: Where Two Audits Still Leave a Gap
Side by Side: What Changes Per Chain
How to Tell Whether a Firm Can Actually Audit Your Chain
Conclusion
FAQs

What “Solana Smart Contract Audit” Actually Means in 2026

A Solana smart contract audit is a time-boxed security review that reads Rust programs, checks every account those programs are handed, and tests the cross-program invocation paths between them on one frozen commit. It is a review of Rust programs and their account model, not a review of Solidity contracts and their call stack.

By default, that scope covers account validation, program-derived address (PDA) handling, and the privilege that flows through each cross-program invocation. According to the Solana documentation as of September 2026, programs are stateless, and all mutable state lives in separate data accounts passed via instructions. The caller supplies the state. The program checks it.

Why an Audit Record on One Chain Does Not Transfer to Another

An audit record is a list of findings in one runtime, and the runtime decides which findings are even possible. Three things carry from one chain to the next in any blockchain smart contract audit: threat modeling discipline, economic and incentive analysis, and process rigor such as fix verification and disclosure handling.

Three things do not carry: the vulnerability catalog, the tooling, and the reviewer’s instinct for what looks wrong in a given runtime. Instinct is the expensive one.

Here is the question for the next vendor call: which named auditor on this engagement has shipped a finding in my runtime, on a protocol my size, in the last twelve months? A named person with a report is an answer. A company history is not.

EVM and Solidity: The Audit Everyone Benchmarks Against

An Ethereum smart contract audit is the baseline every other chain gets priced and scheduled against because the Ethereum Virtual Machine (EVM) has the largest body of public reports, the deepest reviewer pool, and therefore the most competitive quoting. Most of those public reports describe a Solidity smart contract audit, though Vyper runs on the EVM too.

A contract on the EVM holds its own balance, and when it calls another contract, that contract runs before the first one has finished updating its own books. Three classes define the EVM review:

Reentrancy: an external call re-enters a function before its state update lands, so a withdraw pays twice.
Proxy and delegatecall storage collisions: an upgradeable proxy keeps its data in numbered storage slots, and an upgrade that shifts those slots silently corrupts state.
Oracle price manipulation: lending code reads a spot price an attacker can move inside one transaction. If your oracle logic follows our DeFi architecture patterns guide, the reviewer should name which pattern you chose.

As of September 2026, the tooling to expect is Slither for static analysis with its 100 detectors, Echidna for fuzzing, Foundry for forge tests, and Certora for formal verification. A scope that names none of them is a scan.

Solana and Anchor: Auditing Rust Programs and the Account Model

A Rust smart contract audit on Solana starts from one structural fact: the program is stateless, state lives in accounts passed in by the caller, and the program must validate everything it is handed. Every Solana-specific bug class is a failure to do that validation somewhere.

Anchor, the Rust framework most Solana programs are built on, generates a layer of those checks. According to the Anchor documentation as of September 2026, its account constraints check account ownership, signers, and PDA seeds and bumps. A program written without Anchor loses that layer, and the Rust smart contract auditing scope grows to cover every check by hand.

Three classes live here:

Missing ownership and signer checks: an instruction trusts an account the caller supplied, so a look-alike account with the right layout passes as the real one.
Cross-program invocation privilege escalation: the Solana documentation states that account privileges extend from caller to callee, so a signer accepted in error is forwarded down the call chain.
PDA seed collisions and bump handling: two seed sets that derive the same address, or a program that accepts any bump value instead of the one canonical bump, points the program at an account it never created.

Reentrancy has no direct Solana equivalent, because the runtime blocks one program from re-entering another through a cross-program invocation. Account validation plus a privilege check on every cross-program invocation takes its place in the review, and a firm that describes a Solana security audit as checking for reentrancy has told you which runtime it actually knows.

SigIntZero publishes that most Solana program audits take one to three weeks, with simple programs under a week, and that is one vendor’s published figure rather than a market survey.

Move on Sui and Aptos: One Language, Two Audits

A Move smart contract audit reviews code in a language built around one idea: assets are linear types the compiler will not let you duplicate or silently discard. That linear resource model closes a whole EVM bug family at the language level, using a short list of permissions called abilities. According to the Move on Aptos book as of September 2026, copy allows values to be copied, and drop allows them to be dropped, so a coin type without either cannot be duplicated or lost by accident.

Sui Move and Aptos Move are not interchangeable, and an auditor fluent in one is not automatically fluent in the other. The split is storage. Sui structures storage around objects addressable by unique IDs on-chain, each with an owner, and has no global storage. Aptos organizes global storage as a forest consisting of trees rooted at an account address. A Sui smart contract audit reads object ownership and transfer rules. An Aptos smart contract audit reads global storage access.

Three classes live in Move:

Ability annotations granted too broadly: a resource carrying copy or drop where the design needs neither, which reopens the accounting vulnerabilities the language exists to prevent.
Module upgrade policy: an upgradeable module lets its publisher change logic under live assets, so the policy and the keys behind it are in scope.
Access-control logic: ordinary application logic, which the compiler does not check and which teams still get wrong.

Reentrancy has no Move equivalent either, because Move has no dynamic dispatch to re-enter through, and the ability and access-control review replaces it. The Move smart contract auditing tools, verified in September 2026, are the Move Prover and aptos move test on Aptos, plus the Sui Prover, built by Asymptotic, and sui move test on Sui. Formal verification proves only the properties somebody wrote down.

The Cross-Chain Case: Where Two Audits Still Leave a Gap

Two clean single-chain audits do not cover the message-passing layer between them, and that layer is where the largest losses have happened. A bridge smart contract security audit adds what a single-chain scope stops short of: the validator and relayer trust assumptions, replay and message-ordering handling, and the failure behavior when one side halts.

On February 2, 2022, an attacker got past signature verification on the Solana side of Wormhole and minted 120,000 wrapped ETH, then worth roughly $326 million. The bridge program that verifies messages is its own codebase, and that is where the bug was.

If a protocol runs on two runtimes, the statement of work must name the bridge contracts explicitly, or they are out of scope by default. If you need the general boundaries first, our buyer’s guide to audit scope covers them. Write the bridge into the scope.

Side by Side: What Changes Per Chain

Four runtimes sit in one table, and every row is what a scoping call should surface before a quote arrives. If a vendor cannot talk through its row, it is selling a page, not a review.

Runtime	Language and framework	Bug classes that live here	Tooling an auditor must know	What makes scope expand
EVM	Solidity or Vyper, Foundry	Reentrancy, proxy and delegatecall storage collisions, oracle manipulation	Slither, Echidna, Foundry, Certora	Upgradeable proxies, external price feeds
Solana	Rust, Anchor framework	Missing owner and signer checks, cross-program invocation privilege, PDA bump handling	Anchor test suite, cargo test	Programs without Anchor, deep invocation chains
Sui Move	Move, object model	Broad ability annotations, object ownership errors, upgrade policy	Sui Prover, sui move test	Shared objects, custom transfer rules
Aptos Move	Move, global storage	Broad ability annotations, global storage access errors, upgrade policy	Move Prover, aptos move test	Resources under shared accounts, cross-module access

Reentrancy appears in one row only, and the tooling column shares nothing across the four. A firm that quotes all four rows with one team has to explain how.

How to Tell Whether a Firm Can Actually Audit Your Chain

A Rust smart contract audit company earns the name by publishing findings on Rust programs, and the same test applies to every runtime here. Three red flags separate capability from sales.

Red flag: a public report list with no entries on your runtime. Two hundred Solidity reports and zero Solana programs is an EVM firm with a Solana landing page.
Red flag: named auditors whose disclosed findings are all on another chain. The person on your engagement matters more than the logo on the report.
Red flag: a quote with no runtime-specific scoping questions attached. A Solana quote that never asks whether you use Anchor, or a Move quote that never asks which dialect, was priced from a template.

The proof to ask for is always the same: a named auditor, a public report on your runtime, and the finding IDs that auditor personally filed. Anything vaguer is a brochure. Subcontracting (one firm on the contract, another name on the findings) is not disqualifying when disclosed, since a Rust smart contract auditing firm that openly partners for Move work is being honest. Undisclosed subcontracting is the problem because you cannot vet a reviewer you were never told about.

WebThree Consulting is held to the same test. When we run smart contract audit services, scoping starts with contract count, chain, repository status, and launch timeline. We also work with Solidity, Rust, and Move.

Conclusion

Audit competence stays inside the runtime that built it, so a shortlist built on Ethereum is a starting point for a Solana smart contract audit, not an answer. Check the report list for your runtime. Ask for named auditors. Put the bridge contracts in the scope.

If you want a per-chain scoping brief you can send to three firms and compare like for like, book a free 30-minute smart contract audit call. We’ll name the runtime-specific classes your code is exposed to, list the scoping questions each vendor should be asking you, and tell you plainly which of the four runtimes we’re thinnest on.

FAQs

Is a Solana audit harder than an Ethereum audit?

Neither is harder, because they are different jobs. Ethereum has the deeper reviewer pool and the larger public report corpus, and that usually makes an Ethereum smart contract audit faster to source. Solana concentrates its risk in account validation rather than call-stack behavior, so a Solidity shortlist may hold nobody with a Solana finding.

Can my Solidity auditor review my Solana program?

Only if a named person on that team has shipped Rust findings on Solana. Threat modeling and process rigor transfer between runtimes. The vulnerability catalog and the reviewer’s instinct for what looks wrong do not. Ask which Solana programs that person has reviewed and what they filed, and treat a company history as a no.

How long does a Solana program audit take?

Most Solana program audits take one to three weeks, with simple programs under a week, according to SigIntZero’s published range as of September 2026. Unaudited dependencies and deep cross-program invocation chains stretch that timeline. Treat the ranges as commonly cited industry figures to verify at quote time, not fixed rates.

What is a smart contract audit?

A smart contract audit is a time-boxed security review of contract code on one frozen commit, delivered as a findings list with severity labels and a remediation cycle. The chain sets which findings are possible. WebThree Consulting’s plain-English definition guide covers each stage of an audit and the final report in full.

Which companies offer smart contract audits?

Firms including OpenZeppelin, Trail of Bits, and Cyfrin audit smart contracts, and dozens more list Solana or Move on their pages. Any list goes out of date within months, so use one test instead: a public report on your runtime, filed by a named auditor, within the last twelve months. That test is your shortlist.

Is Move safer than Solidity?

Move is safer at the language level, not safer overall. The linear resource model means the compiler rejects code that copies or drops an asset without permission, closing a whole class of accounting vulnerabilities. It leaves access control, upgrade policy, and application logic untouched, so a DeFi security audit on Move spends its hours there.

Do I need a separate audit for Sui and Aptos?

Usually you do, since the dialects and runtimes diverge. Sui stores state as objects with owners, while Aptos stores resources under account addresses in global storage, so the ownership and access review differs on each. Core module logic can share a reviewer. The storage and ownership layer cannot, and that is where findings land.

Does a clean audit on one chain cover my bridge?

No, and assuming it does is how the largest bridge losses happened. Single-chain scopes stop at the contract boundary, and the message-passing layer between two runtimes sits outside both reports. A bridge smart contract security audit happens only if the statement of work names the bridge contracts explicitly, so write them in.