3.12.6 Non-EVM Execution Environments

For most of this book, "smart contract" has meant "Solidity contract running on the EVM." This reflects industry reality — the EVM ecosystem remains the dominant target for smart contract development by every measure of TVL, transactions, and developer activity. But it is not the only target. By 2026, substantial value is secured by contracts that don't run on the EVM at all: Solana programs in Rust, Move modules on Sui and Aptos, Cairo contracts on StarkNet, Stylus contracts on Arbitrum, and various other environments. Each platform has its own programming model, its own security pitfalls, and its own track record of exploits.

This subsection covers the architectural differences that matter for security across non-EVM environments. The goal is not to be a tutorial — each platform has its own language, runtime, and development practices that require dedicated study — but to identify where the security model differs from EVM expectations. An EVM-experienced developer who assumes EVM mental models will transfer to other platforms will produce vulnerable code. The patterns don't transfer; they require platform-specific learning.

Section 3.10.7 (Wormhole) was the only non-EVM case study in Section 3.10 — its bug was specific to Solana's account-validation model. The lesson generalized to EVM (and the section made that translation), but the original was Rust on the Solana Virtual Machine. This subsection extends that single example into the broader landscape.

Why Non-EVM Matters

A reasonable EVM-focused developer might ask: why care about non-EVM platforms at all? Several practical reasons:

Integration. Many DeFi protocols span multiple chains. A bridge connecting Ethereum to Solana, or a protocol with deployments on both, has security concerns that include the non-EVM side. Section 3.11.5 (bridges) touches this; this subsection covers the contract-side concerns.

Talent migration. Developers move between ecosystems. A team that built on Ethereum may rebuild on Solana for performance, or extend to Sui for object-model fit. Carrying EVM assumptions to the new platform produces bugs.

Real value at stake. Non-EVM platforms hold meaningful TVL — Solana alone has had multiple multi-billion-dollar peaks. Bugs on these platforms produce real losses to real users.

Cross-ecosystem reasoning. Understanding what's different about other platforms clarifies what's actually true about the EVM. Some "smart contract security principles" that feel universal are actually EVM-specific; understanding the contrast deepens understanding of all of them.

The major non-EVM environments worth knowing about, in order of TVL and ecosystem maturity:

  • Solana (Rust/BPF/SBF) — high-throughput L1, ~$10B+ TVL, mature DeFi ecosystem
  • Move-based chains — Sui and Aptos primarily; resource-oriented language; ~$2-5B combined TVL
  • StarkNet (Cairo) — ZK rollup with custom language; ~$300M TVL
  • Stylus (Rust/C/C++ on Arbitrum) — WASM-based smart contracts on Arbitrum L2; emerging
  • Others — Aleo (Leo), Mina (o1js), NEAR, ICP, various other smaller ecosystems

Solana: Account Model and Rust Runtime

Solana is the largest non-EVM smart contract ecosystem by a wide margin. Its programming model differs from EVM in nearly every dimension.

The Account-Based Architecture

Solana programs are stateless. All state lives in accounts — separate data structures that programs read from and write to. A program execution doesn't have its own storage; it operates on accounts passed in as part of the transaction.

This creates a fundamentally different security surface. Where an EVM contract knows its own storage layout is sacrosanct, a Solana program must validate every account it receives. The transaction includes a list of accounts; the program must check that each account is what it expects. The account's owner program, its data layout, its signer status, and its address relationship to the program (via Program Derived Addresses) all require explicit verification.

The Wormhole incident (Section 3.10.7) was a canonical example: the program trusted an account that was supposed to be the instructions sysvar but didn't verify the account's address. The forged account passed every other check because the program had asked the wrong question first.

A typical Solana account validation flow:

#![allow(unused)]
fn main() {
// Without Anchor — manual validation
pub fn process_instruction(
    program_id: &Pubkey,
    accounts: &[AccountInfo],
    data: &[u8],
) -> ProgramResult {
    let account_iter = &mut accounts.iter();
    let user_account = next_account_info(account_iter)?;
    let config_account = next_account_info(account_iter)?;

    // Must verify: signer status, ownership, address derivation, data format
    if !user_account.is_signer {
        return Err(ProgramError::MissingRequiredSignature);
    }
    if config_account.owner != program_id {
        return Err(ProgramError::IncorrectProgramId);
    }
    let expected_config = Pubkey::find_program_address(&[b"config"], program_id).0;
    if *config_account.key != expected_config {
        return Err(ProgramError::InvalidArgument);
    }
    // ... and so on
}
}

A single missing check is the entire vulnerability. The "account confusion" attack pattern — where an attacker substitutes a similar-looking account for one the program expected — is the dominant failure mode.

Anchor Framework

Most modern Solana development uses Anchor, a framework that abstracts much of the account validation. Anchor lets developers declare expected accounts as a struct with constraints, and the framework enforces them:

#![allow(unused)]
fn main() {
#[derive(Accounts)]
pub struct Transfer<'info> {
    #[account(mut, has_one = owner)]
    pub from: Account<'info, TokenAccount>,
    pub owner: Signer<'info>,
    #[account(mut)]
    pub to: Account<'info, TokenAccount>,
    pub token_program: Program<'info, Token>,
}
}

Anchor checks the constraints automatically: has_one = owner ensures the token account's owner field matches the owner signer; the Account<'info, TokenAccount> type ensures the account is owned by the SPL Token program and has valid TokenAccount data layout; Signer ensures the account signed the transaction.

Anchor catches many account-confusion bugs that hand-written validation would miss. But Anchor is not bulletproof — the framework has its own footguns:

  • UncheckedAccount deliberately bypasses Anchor's checks. The /// CHECK: documentation requirement is a hint, but not a substitute for actual review.
  • AccountInfo types similarly skip validation.
  • Custom constraints can be incorrect or incomplete.
  • The framework's behavior changes across versions; assumptions from older versions may not hold.

For new Solana development, Anchor is the default. For existing native Solana programs, the manual validation patterns are essential.

Cross-Program Invocations (CPIs)

Solana programs invoke other programs via CPIs — similar in spirit to EVM contracts calling other contracts, but with distinct security properties:

  • The calling program's signature can be forwarded to the called program (via invoke_signed)
  • Account ownership can change during a CPI (the called program can re-own accounts)
  • The called program operates with the caller's signer context

This creates an attack surface around CPI patterns:

  • Forwarding user signers to untrusted programs: if your program CPIs to an attacker-controlled program while passing the user's signer, the attacker can use that signer for their own purposes
  • Account ownership changes: an account that was owned by your program before the CPI might be owned by another program after; subsequent reads can read attacker-controlled data
  • Lamport balances: native SOL balances on accounts can be manipulated during CPIs in ways that affect program logic

The defensive patterns:

  • Whitelist trusted programs for CPI; do not CPI to arbitrary user-provided program addresses
  • Use protocol-owned PDAs as authorities rather than forwarding user signers
  • Validate account ownership and balances after CPIs return, not just before

Integer Overflow

Rust's release builds do not check for integer overflow by default (Solana programs ship as release builds). An unchecked overflow can mint unlimited tokens, drain balances, or bypass security checks.

The mitigations:

  • Use checked_add, checked_sub, checked_mul, checked_div for security-critical arithmetic
  • Or use overflow-checks = true in the Cargo profile (with the performance cost)
  • Or use libraries that wrap arithmetic safely

This is a frequent failure mode. Multiple Solana exploits have traced to overflow bugs that would have been impossible in Solidity 0.8+ (where overflow checking is mandatory).

PDA Seed Collisions

Program Derived Addresses are derived deterministically from seeds. If two different code paths use the same seeds, they produce the same PDA — meaning data from one context can be confused with data from another.

The mitigation: ensure PDA seeds include sufficient discrimination. Include the user's address, a context identifier, or other unique data so that PDAs in different contexts cannot collide.

Token-2022 Extensions

The Token-2022 program (a successor to the original SPL Token program) adds optional extensions: transfer fees, interest-bearing tokens, transfer hooks, confidential transfers, and others. Each extension changes the assumptions a program can make about a token:

  • A token with transfer fees doesn't transfer the full amount — amount_in != amount_received
  • Transfer hooks let token programs run custom code on every transfer
  • Confidential transfers hide amounts; balances can't be observed directly

Programs that integrate with arbitrary tokens must handle these extensions, similar to how EVM contracts must handle ERC-20 quirks (Section 3.11.2). The threat surface is analogous but distinct.

The Solana Ecosystem's Audit Premium

Solana audits cost approximately 25-40% more than equivalent EVM audits in 2026, primarily because the pool of qualified Rust/Solana security reviewers is substantially smaller than the Solidity pool. Section 3.12.3 covers audit pricing more broadly; the premium reflects supply scarcity, not technical difficulty alone.

Move-Based Chains: Sui, Aptos, IOTA

The Move language was designed at Meta (then Facebook) for the never-launched Libra blockchain, then released as open source. Today, three production chains use it: Sui, Aptos, and IOTA's L1 MoveVM.

Resource-Oriented Programming

Move's defining feature is its resource type system. A resource in Move is a type that cannot be implicitly copied or dropped — it must be explicitly transferred or destroyed. The compiler enforces this via the ability system: types declare which operations they permit (copy, drop, key, store).

For asset modeling, this is a substantial improvement over EVM patterns. An ERC-20 balance is just a number in a mapping — there is no language-level guarantee that the number means anything specific. In Move, a token can be a resource that cannot be duplicated, lost, or arbitrarily modified. Many bugs that are easy to write in Solidity are impossible to write in Move.

// In Move, this resource cannot be duplicated
struct Coin has key, store {
    value: u64
}

// The compiler ensures Coin is either transferred or destroyed —
// never silently lost or copied
public fun transfer(coin: Coin, recipient: address) {
    // Compiler ensures `coin` is consumed exactly once
    move_to(recipient, coin);
}

The ability system catches many asset-handling bugs at compile time. This is a real safety improvement; it does not eliminate all bug classes.

Chain-Specific Differences

Sui, Aptos, and IOTA share the language but differ substantially in architecture:

Sui uses an object-centric model. State is organized as discrete objects with unique IDs. Transactions explicitly declare which objects they touch; parallel execution is possible when transactions touch different objects. The model is naturally suited for ownership-heavy applications (NFTs, game assets, individual user objects).

Aptos uses a global-storage model closer to traditional account-based systems, with parallel execution via Block-STM (optimistic concurrency with re-execution on conflict). The mental model is closer to Ethereum's but with Move's safety properties.

IOTA's MoveVM runs on a DPoS chain with Tangle DAG consensus; it also has EVM compatibility via an L2. The L1 Move environment supports batch atomicity in distinctive ways.

The implication for security: the same Move code can be safe on one chain and exploitable on another because storage assumptions differ. Sui requires objects to be passed as transaction inputs; Aptos can borrow globals if the type is accessible. A Move module that assumes one model may not work correctly on the other.

Common Move Vulnerabilities

Even with the type system's protections, several bug classes persist:

Borrow validation. borrow_global<T> and borrow_global_mut<T> borrow from a specific address. If the address is user-controlled and not validated, an attacker can substitute their own data. The fix: always validate the address before borrowing.

Integer division. Move's integer arithmetic is more strict than Solidity's (no implicit truncation), but division by zero and precision-loss issues persist. Cetus's $220-260M exploit on Sui (May 2025) involved arithmetic in the CLMM tick math library — multiple audits had not caught it.

Capability leaks. Move uses "capability objects" to gate privileged operations. A capability inadvertently exposed (returned from a public function, stored in a public location) is equivalent to admin keys being public.

Atomic batching assumptions. IOTA and Aptos both support batching many operations atomically. A protocol that assumes "users perform one operation at a time per transaction" may not survive a batched attack. The pattern is similar to flash loan reasoning on EVM but in a different form.

Storage deposits and refunds. Sui requires storage deposits for new objects; these must be accounted for in protocol economics. Forgotten storage cleanup can produce dust-level accounting errors that accumulate.

The Cetus Exploit (Sui, May 2025)

The largest production Move exploit to date. Cetus Protocol — a major DEX on Sui — was drained of approximately $220-260M through an arithmetic overflow in the CLMM (concentrated liquidity market maker) tick math library. The vulnerability allowed creating fake tokens that the protocol treated as legitimate, then swapping them for real liquidity at favorable rates.

Several aspects of the case generalize:

  • The bug was in shared open-source math code, not protocol-specific logic
  • Multiple respected audit firms had reviewed the code without identifying the bug
  • Move's resource safety didn't prevent the issue because the bug was at the integer arithmetic layer, below the resource abstraction
  • Sui validators coordinated to freeze $162M in attacker wallets via blacklist voting; ~$60-63M escaped to Ethereum before the freeze

The "validator-coordinated freeze" response is itself notable. Solana has done similar things (the FTX-related funds were censored by validators in late 2022). Move-based chains demonstrating this capability raises both functional recovery questions and broader centralization concerns.

Move Prover and Sui Prover

A distinctive feature of the Move ecosystem: first-class formal verification. The Move Prover is a deductive verification tool integrated into the Move toolchain, allowing developers to write specifications and prove that code satisfies them.

Sui's ecosystem added Sui Prover in 2025 — a more developer-friendly formal verification tool. Used in audits and available open-source.

This is a substantial advantage Move has over Solidity (which has formal verification tooling per Section 3.12.1, but it's third-party and less integrated). Move developers can specify and prove invariants natively. Many production Move modules ship with formal proofs of key safety properties.

The Cetus exploit notwithstanding, the Move ecosystem's emphasis on formal verification has produced genuinely strong safety properties in many deployed protocols.

StarkNet and Cairo

StarkNet is Ethereum's longest-running ZK rollup, with a custom smart-contract language called Cairo. Cairo is designed specifically for STARK-based proving — it efficiently expresses computations that can be proved.

What's Distinctive About Cairo

Cairo's design choices reflect the proving system:

  • Field-based arithmetic. All values are field elements (mod a 252-bit prime), not standard 256-bit integers. Integer operations need explicit width handling.
  • Felt (field element) by default. The native type is the field element, not the byte-array. EVM patterns that assume byte-level operations don't translate.
  • Account abstraction natively. StarkNet has no EOAs; every account is a contract from day one. The patterns from Section 3.11.7 apply natively to every user.
  • Different storage model. Storage is per-contract, similar to EVM, but with field-element values rather than 32-byte slots.

Cairo Security Considerations

Bugs specific to Cairo and StarkNet:

  • Field arithmetic surprises. Operations that look like integer arithmetic are actually field arithmetic. Multiplication overflowing the field modulus produces unexpected results.
  • Account contract patterns. Every user has a smart contract account; the account's __execute__ function dispatches calls. Bugs in account implementations affect all transactions from that account.
  • Cross-contract calls. Cairo's call semantics differ from EVM's. The patterns from Section 3.11.2 apply but with platform-specific differences.
  • L1-L2 messaging. Like other L2s (Section 3.11.8), StarkNet's L1-L2 messaging has its own security considerations, with the additional complication of ZK proof verification on the L1 side.

Cairo Tooling

The Cairo ecosystem has matured substantially. Specific tools:

  • Stark Analyzer Pro — production-focused auditing tool for StarkNet contracts
  • Cairo 1.0 (released 2023) — major language overhaul; the previous Cairo 0.x is deprecated
  • Scarb — package manager and build tool (similar to Cargo)
  • Starknet Foundry — testing framework (analogous to Solidity's Foundry)

Stylus: WASM Smart Contracts on Arbitrum

Arbitrum's Stylus is a relatively new addition to the smart contract landscape: it allows writing Arbitrum smart contracts in Rust, C, or C++, compiled to WebAssembly (WASM). The contracts run alongside ordinary Solidity contracts on the Arbitrum chain, with cross-language calls supported.

Why Stylus Matters

Stylus is an interesting hybrid: it brings non-EVM languages into the EVM-compatible ecosystem. A developer can write performance-critical components in Rust while keeping the rest in Solidity. The performance benefit is real — WASM-compiled contracts are substantially cheaper for compute-heavy operations.

Security Implications

Stylus contracts have to be reasoned about in two ways simultaneously:

  • As WASM contracts, they have the security properties (and pitfalls) of their source language. Rust's memory safety helps; C/C++ memory bugs (use-after-free, buffer overflow) are real concerns.
  • As Arbitrum contracts, they participate in the EVM-compatible environment. They can call EVM contracts; they can be called by EVM contracts; they're targeted by EVM-style adversaries.

The composition is the security surface. A Stylus contract that's perfectly safe in isolation may be vulnerable when EVM contracts call into it with adversarial inputs.

Stylus is still emerging as of early 2026; the audit ecosystem for it is small. Protocols using Stylus should expect a thinner pool of qualified reviewers and a corresponding cost premium.

Cross-Platform Considerations

For protocols that span multiple execution environments:

Don't Assume Mental Models Transfer

The single most important principle. A Solidity developer's intuitions about reentrancy, storage layout, gas, or call semantics will not all transfer to Solana, Move, Cairo, or Stylus. Each platform requires its own learning curve. Failure to do this learning produces vulnerabilities that are obvious to platform-native developers but invisible to ported assumptions.

Audit by Platform Specialists

Generic auditors don't translate across platforms. A team that has audited 50 Solidity contracts may not be qualified to audit Solana programs. Section 3.12.3 covers the audit market; platform-specific firms (Neodyme, OtterSec, Halborn for Solana; MoveBit for Move; specialized Cairo audit firms) exist for reason.

Bridges Compound the Surface

Cross-chain bridges (Section 3.11.5) become more risky when they span execution environments. A bridge between EVM and Solana has both EVM-side bugs and Solana-side bugs as failure modes; the combined attack surface is larger than either alone.

Tooling Maturity Varies Dramatically

EVM tooling is mature: Foundry, Hardhat, Slither, Mythril, Echidna, Tenderly, etc. Solana tooling is less mature but functional: Anchor, Solana Test Framework, several emerging fuzzers. Move tooling has the Prover but less integration. Cairo and Stylus are earlier. For protocols, this means: budget more time and effort for non-EVM development than for equivalent EVM work, and expect to encounter rough edges that EVM has long since smoothed.

Specific Knowledge Gaps Common to EVM Developers Moving to Non-EVM

The patterns that bite EVM developers the most when they move to other platforms:

  • Account/object validation discipline (Solana) — the volume of explicit validation feels excessive but is essential
  • Resource handling (Move) — the abilities system feels restrictive but prevents real bugs
  • Field arithmetic (Cairo) — looks like normal integers but isn't
  • CPI/cross-contract authority (Solana) — signer forwarding is more permissive than EVM call
  • No automatic overflow checks (Solana, sometimes Move) — Rust release builds don't check; explicit checked arithmetic required

Practical Checklist

For a protocol building on a non-EVM platform:

  • The team has at least one engineer with substantial platform-specific experience
  • Platform-specific tooling (Anchor for Solana, Move Prover for Move, etc.) is used appropriately
  • Audits are conducted by platform specialists, not generic Solidity firms
  • Integer overflow protections are explicitly used (where the platform doesn't enforce them)
  • Platform-specific failure modes (account confusion, capability leaks, field arithmetic) are explicitly tested
  • Documentation includes platform-specific assumptions and constraints
  • Cross-platform composability (bridges, cross-VM calls) is treated as additional surface, not transparent integration

For a protocol bridging between EVM and non-EVM platforms:

  • Both sides of the bridge are audited by platform specialists for that side
  • The bridge's security model is documented per side (validator set for one side, ZK proofs for another, etc.)
  • Failure modes specific to each platform are considered
  • Per-platform exposure is bounded (rate limits, withdrawal caps) — Section 3.11.5

For a Solidity developer learning a non-EVM platform:

  • Multi-week dedicated learning before writing production code (not just porting EVM patterns)
  • Pair with platform-experienced developers for code review
  • Use the most opinionated framework available (Anchor for Solana, etc.) before considering native development
  • Start with non-value-bearing code; build intuition before handling user funds

Cross-References

  • Composability — Section 3.11.2 covers composability principles that translate across platforms with platform-specific details
  • Bridge security — Section 3.11.5 covers the cross-chain bridges that connect EVM to non-EVM platforms
  • Wormhole case study — Section 3.10.7 covers a Solana-specific exploit that illustrates account validation
  • Audit practices — Section 3.9 covers general auditing; this section's platform specialization complement applies
  • Decentralized auditing — Section 3.12.3 covers audit pricing including per-platform premiums
  • Formal verification — Section 3.12.1 covers formal methods; Move Prover and Sui Prover are notably platform-specific implementations
  • Post-quantum considerations — Section 3.12.4 mentions STARK-based systems (StarkNet); the discussion applies here
  • Solana Cookbook — https://solanacookbook.com
  • Solana Security Workshop (Neodyme) — https://github.com/neodyme-labs/solana-security-workshop
  • Move Book — https://move-language.github.io/move/
  • Sui Documentation — https://docs.sui.io
  • Aptos Documentation — https://aptos.dev
  • Cairo Book — https://book.cairo-lang.org
  • Arbitrum Stylus Documentation — https://docs.arbitrum.io/stylus/