What "37 chains" means
Smart contracts live in different languages on different runtimes. Audit work means adapting the methodology, not the bug classes. The methodology in our auditing methodology paper is the same on every chain: trust-boundary first, three-read pattern, tools as upstream triage, evidence-based severity. The pattern catalog changes per ecosystem.
This catalog names the coverage. The grouping is by ecosystem family because the audit work transfers within a family (an EVM-trained reviewer audits Arbitrum the same way as Ethereum mainnet, with adjustments for the L2's specific assumptions) and not across families (an EVM reviewer is not a Move reviewer).
The five ecosystem families
EVM family. Solidity and Vyper, running on the Ethereum Virtual Machine. Approximately twenty chains in production audit scope: Ethereum mainnet, Arbitrum (One and Nova), Optimism (OP Mainnet, plus the broader OP Stack chains), Base, Polygon (PoS and zkEVM), zkSync Era, Linea, Scroll, Mantle, Mode, Blast, Avalanche C-Chain, BNB Smart Chain, Fantom (Sonic), Gnosis Chain, Celo, Manta Pacific, Taiko. Patterns covered in smart-contract-security, gas-optimization-vs-security, upgradeable-smart-contracts, smart-contract-testing, defi-security, cross-chain-bridge-security, and layer-2-security.
Solana. Rust programs using the Anchor framework or raw solana-program. Stateless programs, accounts as state containers, Sealevel parallel execution. Patterns covered in solana-program-security.
Move family. Sui Move (object-centric) and Aptos Move (account-centric). Linear-type resources, capability-based access control. Patterns covered in move-contract-security.
Cairo / StarkNet. Cairo language, account-abstraction-by-default, validity-proof L2 architecture. Patterns covered in cairo-contract-security.
CosmWasm. Rust-to-WASM contracts running on Cosmos chains. Message-based execution, reply handlers, migration authority, IBC integration. Approximately ten chains in audit scope: Cosmos Hub, Osmosis, Juno, Neutron, Stargaze, dYdX v4 chain, Sei, Injective, Archway, and others. Patterns covered in cosmwasm-contract-security.
TON. FunC, Tact, and Tolk languages. Asynchronous actor model, bounce handling, code-cell mutation, sharded design. Patterns covered in ton-contract-security.
The remaining chains in the 37-chain scope are smaller-volume non-EVM L1s where the audit work draws on the closest-related ecosystem's methodology with chain-specific adjustments. NEAR contracts share Rust language tooling with CosmWasm but have a distinct contract model (synchronous cross-contract calls, account-based storage, NEAR-specific gas semantics). Tron's TVM is EVM-compatible with chain-specific quirks (resource model, energy accounting, native staking integration). Aptos and Sui share the Move methodology with dialect-specific adjustments noted in the Move paper. Polkadot parachains running ink! contracts share the Rust-to-WASM compile target with CosmWasm but execute under Substrate's pallet-based runtime with its own gas, storage, and cross-pallet authority model. We monitor adjacent ecosystems (Mina's zk-circuit contract model, Internet Computer's canister model, Hedera's hybrid contract/native-service surface) for inclusion as production volume warrants.
What transfers across ecosystems
Every audit shares:
- The pre-read. Trust-boundary diagram, threat model extraction, prior-audit review. Independent of language.
- The three-pass reading. Structural, adversarial, verification. Independent of language.
- The severity rubric. Reachability × outcome, multi-dimensional. Independent of ecosystem.
- Evidence standard. Reproducible PoC, failing invariant, symbolic counterexample, or rigorous argument. Independent of ecosystem.
- The report shape. Engagement summary, findings ranked, residual-risk section, fix confirmation. Independent of ecosystem.
The methodology paper describes this in detail.
What does not transfer
The pattern catalog is per-ecosystem. Reentrancy is an EVM concept; it does not exist in the same form on Solana (no synchronous CPI re-entry in the EVM sense) or in Move (the linear-type system constrains it). Conversely, PDA confusion is a Solana concept that has no EVM analogue. Capability leakage is a Move concept. Bounce-not-handled is a TON concept.
A reviewer trained on EVM cannot transfer their pattern catalog to Move without retraining. The methodology transfers; the catalog does not.
What this means for engagement scoping
A multi-chain protocol that deploys on Ethereum + Solana + Sui needs three separate ecosystem-specific audit passes plus an integration audit at the cross-chain boundary. The audit budget is not "Ethereum audit × 3"; the work is distinct per ecosystem.
The cross-chain boundary is itself an audit class. Our cross-chain bridge paper covers the surface where assets and messages move between chains; the integration audit checks that the assumptions on each side of the boundary actually match. A protocol that issues a token on Ethereum, bridges to Solana with one bridge protocol, and bridges to Sui with a different one inherits the threat model of every bridge it uses, not just the one with the fewest assumptions.
Coverage depth per ecosystem family
The audit scope per ecosystem is not uniform. Some ecosystems have mature property-based fuzzing harnesses; some have production formal-verification tooling; some require dedicated bridge or IBC review on top of the contract-level audit. The shape below names the depth we can deliver per family.
| Ecosystem | Source-level audit | Property-based fuzzing | Formal verification | Bridge/IBC specialist |
|---|---|---|---|---|
| EVM | Yes | Yes (Echidna, Medusa, Foundry invariants) | Yes (Certora, Halmos) | Yes (cross-chain bridge paper applies) |
| Solana | Yes | Yes (program-test harnesses) | Limited | Yes (Wormhole/Allbridge surface) |
| Move (Sui/Aptos) | Yes | Limited | Yes (Move Prover on Aptos) | Yes (cross-chain Move-bridge surface) |
| Cairo | Yes | Limited | Maturing (Certora, Lean) | Yes (L1↔L2 messaging specialist) |
| CosmWasm | Yes | Yes (cw-multi-test, cosmwasm-vm) | Limited | Yes (IBC specialist) |
| TON | Yes | Emerging | Emerging | Limited (TON cross-chain is younger) |
The "limited" and "emerging" entries are not gaps we hide. They are constraints on the audit budget shape for a given ecosystem, and we name them at the start of every engagement.
How we keep coverage current
Ecosystems evolve. Sui's object model has shifted since the chain launched. Cairo went through a major language transition (Cairo 0 to Cairo 1/2). The CosmWasm runtime gained features (IBC v3, dynamic linking) over multiple versions. EVM ships hard forks regularly (Cancun, Pectra, Prague-Electra) that change semantics.
The 37-chain catalog is a working scope, not a static list. We retire coverage on chains that stop being relevant and add coverage where new ecosystems gain enough volume to warrant it. The papers in this set reflect what we audit today; specific chains and tooling will shift, and the catalog is updated separately from each engagement.
What clean means at the catalog level
A clean engagement on any chain in this catalog means the per-ecosystem methodology was applied correctly. The methodology is general; the patterns are specific; the chains are many. Naming the scope explicitly is what makes the audit defensible, and what lets a security buyer compare two audit shops against a real coverage benchmark rather than against marketing claims.