How to Audit Non-EVM Program Designs

Auditing non-EVM programs requires a fundamental shift in perspective from Ethereum's account-based model. Blockchains like Solana, Aptos, Sui, and Cosmos SDK chains use different execution environments—often based on WebAssembly (WASM) or custom VMs—and data models like global state or object-centric storage. The core security model also differs; instead of a single msg.sender context, programs must explicitly validate all cross-program invocation (CPI) callers and passed account states. Understanding the specific blockchain's runtime semantics, fee model, and state ownership rules is the critical first step before any code review begins.

A primary audit focus is account and state validation. In Solana's Sealevel runtime, for instance, every account passed to a program must be checked for its signer status, writability, and ownership. A common critical vulnerability is missing checks, allowing an attacker to pass a malicious account that alters another user's data. Similarly, on Move-based chains (Aptos, Sui), the type system and resource-oriented model prevent double-spending by default, but auditors must verify proper capability and witness patterns to ensure access control is enforced. Auditors use tools like the Solana soteria analyzer or Move's move-prover for initial static analysis.

Integer and arithmetic precision present another major risk area. While Solana's Rust programs use standard integer types prone to over/underflow, Move has built-in overflow checks. Auditors must verify all mathematical operations, especially for financial calculations involving token amounts or price oracles. Furthermore, clock and timestamp dependencies can be manipulated in many non-EVM environments if not sourced securely from the runtime. Logic errors in program-derived address (PDA) derivation or in the order of instruction execution within a transaction are also frequent sources of exploits.

The final stage involves analyzing program composability and economic security. Non-EVM programs are often designed for high concurrency, requiring analysis of race conditions and front-running possibilities unique to parallel execution models. Auditors simulate complex transaction flows to test fee economics, ensuring the program cannot be drained via insufficient rent exemption (Solana) or gas starvation attacks. A comprehensive audit report details vulnerabilities with proof-of-concept exploits, provides code patches, and references the specific security framework of the target chain, such as Solana's Security Best Practices or the Move Security Guide.

The first prerequisite is understanding the target chain's execution environment and virtual machine. Unlike the EVM's stack-based architecture, other chains use fundamentally different models. For example, Solana's runtime is register-based and executes programs via the Berkeley Packet Filter (BPF) virtual machine, prioritizing parallel transaction processing. Cosmos chains use WebAssembly (WASM) for smart contracts, a stack-based VM designed for portability and near-native speed. You must learn the specific memory model, fee structure, and execution limits (e.g., compute units in Solana, gas in Cosmos) that govern contract logic.

Next, you must become proficient in the chain's native smart contract languages and frameworks. This goes beyond syntax to include idiomatic patterns and inherent security considerations. For Solana, this means deep knowledge of Rust, the anchor framework for generating Program Derived Addresses (PDAs), and the solana-program library's account model. For Cosmos, it involves Rust or Go using the cosmwasm library, with a focus on message handling and query responses. For StarkNet, it's Cairo, a language built for provable computation with a unique ownership system. Auditing requires reading code as the chain's runtime sees it.

A critical, non-negotiable skill is mastering the chain's security model and common vulnerability classes. The attack surface differs significantly from the EVM. On Solana, you must audit for: account confusion (mismatched Pubkey), missing ownership or rent exemption checks, improper PDA derivation, and cross-program invocation (CPI) reentrancy-like issues. In Cosmos CW, key risks include unchecked user inputs in Instantiate/Execute messages, improper state handling, and denial-of-service via infinite loops consuming gas. You need to study past audits and exploit post-mortems specific to the ecosystem, such as the Solana Sealevel attacks or CosmWasm vulnerabilities documented by Oak Security.

Finally, you must set up a local toolchain for static analysis, testing, and dynamic exploration. Relying solely on manual code review is insufficient. Essential tools include: a local node or test validator (e.g., solana-test-validator, wasmd), the chain's CLI for transaction simulation, framework-specific linters and security scanners (e.g., cargo-audit for Rust dependencies, cargo-clippy), and custom fuzzing setups. You should be able to write comprehensive integration tests that deploy programs and simulate malicious interactions. This hands-on environment is where you validate your hypotheses about contract behavior and uncover subtle logic flaws.

Auditing non-EVM smart contracts requires a fundamental shift in mindset. Unlike the EVM's single-threaded, gas-metered execution, platforms like Solana (Sealevel), Aptos (Move), and Cosmos (CosmWasm) introduce parallel execution, linear types, and different state models. The first step is environment familiarization. You must understand the runtime's core primitives: how programs are deployed, how accounts are structured for data storage, how cross-program invocation (CPI) works, and the security model for signers and privileges. For example, in Solana, you audit the interaction between a program's instruction logic and the AccountInfo structures passed to it, checking for missing ownership or signer validation.

The second step is architectural and dependency review. Map out the program's flow, identifying all external dependencies on other on-chain programs or oracles. For Move-based chains (Aptos, Sui), this involves scrutinizing module dependencies and friend declarations. A critical task is verifying the integrity and trust assumptions of any external calls. In CosmWasm, this means auditing the messages sent to other contracts and the handling of callbacks. This step surfaces systemic risks, such as reliance on a poorly-secured price oracle or a central administrative program that holds excessive upgrade authority.

Step three focuses on business logic and financial correctness. This is where you trace the flow of value (tokens, points, NFTs) through the program's functions. For non-EVM chains, you must use chain-native methods. On Solana, this means verifying correct use of the Token Program for SPL token transfers. In Move, you check that Coin resources are properly deposited and withdrawn without violating conservation laws. Key questions include: are arithmetic operations safe from overflow/underflow (using checked math)? Are withdrawal functions properly permissioned? Does the logic for calculating rewards, fees, or penalties produce expected and fair outcomes?

The fourth step is testing and validation. Go beyond code review by executing the logic. This involves writing and running integration tests using the chain's native testing framework (e.g., solana-program-test for Solana, the Move unit test framework for Aptos). Create test cases for edge conditions: maximum mint amounts, minimal deposits, and sequences of actions designed to break invariants. For performance-critical chains like Solana, you must also validate compute unit consumption to ensure the program doesn't exceed block limits. Fuzzing tools specific to the ecosystem, like solana-fuzz or move-prover for formal verification, can be incorporated here.

The final, crucial step is reporting and remediation guidance. A good audit report clearly categorizes findings by severity (Critical, High, Medium, Low) and provides concrete, actionable recommendations. For each issue, include: a clear description, the exact code location (program ID and file path), a proof-of-concept exploit script or detailed scenario, and a specific code fix. For non-EVM audits, the fix must use the platform's correct idioms—for instance, recommending the secure_transfer function in CosmWasm or proper signer capability checks in Move. This enables developers to efficiently understand and resolve the vulnerabilities you've uncovered.

Auditing a non-EVM program requires shifting from EVM-specific assumptions to a chain-agnostic analysis of economic logic and incentive alignment. The core principles of game theory and mechanism design remain universal, but their implementation differs. You must first understand the chain's execution model—whether it's Solana's parallel execution, Cosmos' IBC-enabled app-chains, or Aptos/Sui's Move-based object model—as these dictate transaction ordering, fee markets, and state access patterns that directly influence economic attacks like front-running or congestion-based exploits.

The audit begins with tokenomics and value flows. Map all inbound and outbound value transfers within the system's state machine. For a Solana program, trace the flow of native SOL and SPL tokens through instructions. In a Cosmos SDK module, audit the bank keeper interactions. In Move, examine Coin deposits and withdrawals. Key questions include: Are there infinite minting loops? Can rewards be claimed without cost? Is the treasury drainable? A common flaw is missing slippage checks in AMM calculations or improperly weighted governance token distributions that centralize control.

Next, analyze incentive mechanisms and staking logic. Non-EVM chains often use native staking for security (e.g., Cosmos validators) or parallel fee markets (e.g., Solana priority fees). Audit how the protocol incentivizes desired behavior (like liquidity provision) and disincentivizes attacks. Check for: - Time-based decay functions in rewards - The ratio of stake slashing to potential attack profit - Whether vote-selling or MEV extraction breaks governance assumptions. For example, a flaw might be a staking contract where early unstaking penalties are less than the profit from an oracle manipulation attack executed during the unstaking period.

Finally, conduct stress-test simulations using the chain's native tools. For Solana, use the solana-test-validator with custom scripts to simulate high load and observe program behavior. For Cosmos chains, use the simapp for randomized testing. For Move, use the Move Prover for formal verification of economic invariants. Model extreme scenarios: a 90% drop in token price, a validator cartel forming, or a sudden liquidity withdrawal. The goal is to verify that the system's economic safeguards—like circuit breakers, fee adjustments, or emergency shutdowns—activate correctly to protect user funds and protocol solvency.

Auditing non-EVM programs—like those on Solana, Aptos, or Cosmos—requires a fundamental shift from EVM-centric thinking. The core principles of security remain: verifying access control, validating state transitions, and ensuring economic invariants hold. However, the implementation details differ drastically. You must understand the runtime's execution model, its concurrency guarantees, and how the underlying data structures (like Solana's PDAs or Cosmos SDK's KV stores) interact with program logic. Treating these programs as 'just another smart contract' is a critical mistake that leads to missed vulnerabilities.

To solidify your skills, apply this framework to existing open-source programs. Start with a simple token program on Solana or a basic CosmWasm contract. Use the steps outlined: first, map the program's architecture and authority flows; second, trace through core logic paths for arithmetic and state errors; third, analyze the program's interaction with the host environment for systemic risks. Tools like cargo-audit for Rust dependencies, cargo-fuzz for property testing, and protocol-specific explorers (Solana Explorer, Mintscan) are essential for this hands-on verification.

The landscape of non-EVM ecosystems evolves rapidly. Stay informed by monitoring security reports from auditors like OtterSec and Neodyme, reading runtime upgrade proposals (e.g., Solana Agave updates, Cosmos SDK releases), and participating in developer forums. Key areas for ongoing research include the security of new parallel execution paradigms, cross-program invocation patterns, and the safety of novel standard libraries. Continuous learning is not optional; it's a requirement for effective auditing in these dynamic environments.

Your next practical step should be to contribute to an audit contest on a platform like Code4rena or Sherlock, focusing on a non-EVM protocol. This provides real stakes and peer review. Alternatively, perform a mock audit of a popular program and compare your findings with its published audit report. Documenting your process and creating a checklist tailored to a specific runtime (e.g., 'Sui Move Security Checklist') will cement your understanding and create a valuable resource for the community.