How to Handle Incident Response on Non-EVM Blockchains

Incident response on non-EVM chains requires a fundamentally different toolkit and mindset compared to Ethereum. While the core principles of containment, investigation, and recovery remain, the execution varies drastically. Key differences include the transaction lifecycle (e.g., Solana's optimistic confirmation vs. Ethereum's finality), program architecture (e.g., Cosmos SDK modules vs. Solidity smart contracts), and the available forensic tooling. A generic EVM-centric playbook will fail to address chain-specific attack vectors and mitigation paths.

The first critical step is establishing a monitoring and alerting baseline. For Aptos or Sui, this means tracking Move module publishes and key resource changes. On Solana, monitor for unexpected Program Derived Address (PDA) authority changes or large, anomalous token transfers. Tools like Solana Explorer, Solscan, and chain-specific indexers (e.g., Figment for Cosmos) are essential. Setting up alerts for failed invariant checks within a Cosmos SDK module or a surge in custom error types from a Solana program can provide early warning signs.

When an incident is detected, such as a potential exploit in a Solana program, immediate containment is paramount. This may involve:

• Revoking upgrade authorities for the compromised program.
• Pausing vulnerable entry points via a program's pause authority, if architected.
• Halting associated token mints or liquidity pools on DEXs like Raydium or Orca. Communication with validators for a Cosmos chain or RPC providers for Solana may be necessary to temporarily filter malicious transactions, a process less straightforward than on EVM chains with mempool monitoring.

Forensic investigation requires parsing chain data in the native format. For a Solana exploit, you must analyze the transaction version (v0), inner instructions, and log messages to trace the attack path. On Cosmos, you'll examine begin-blocker/end-blocker execution and IBC packet flows. Unlike EVM's unified eth_getTransactionReceipt, you'll use chain-specific APIs and may need to write custom scripts using SDKs like @solana/web3.js or cosmjs. Preserving evidence—such as the exact block height, transaction signatures, and program logs—is critical for post-mortem analysis and potential recovery efforts.

Recovery and remediation strategies are also chain-dependent. On some non-EVM chains, social consensus and validator coordination for a chain halt or state rollback might be the only recourse, as seen in past Cosmos and Solana incidents. For upgradable programs, a patched version must be deployed, and user funds may need to be migrated via a new, secure contract. This phase underscores the importance of pre-established off-chain communication channels with your user base and clear, transparent post-mortem reporting to maintain trust in the ecosystem.

The first prerequisite is deep familiarity with the target chain's core technology. Unlike the standardized EVM, non-EVM chains like Solana, Cosmos, or Polkadot use distinct virtual machines (e.g., SVM, CosmWasm), consensus mechanisms, and state models. You must understand its transaction format, account model, and how smart contracts (or programs) are executed. Official documentation, such as the Solana Cookbook or Cosmos SDK Docs, is essential. Install and configure the chain's primary CLI tools, like solana, junod, or substrate, to interact with the network directly.

Next, set up a dedicated monitoring and analysis environment. This requires running an archival node or connecting to a reliable RPC provider that offers full historical data. For forensic analysis, tools must be chain-specific. For Solana, familiarize yourself with solana-ledger-tool for parsing blockchain data and exploring the geyser plugin interface. For Cosmos chains, learn to use the cosmosvisor and query transaction logs via the Tendermint RPC. Bookmark blockchain explorers like Solana Explorer or Mintscan for Cosmos, as they are critical for initial triage.

Finally, prepare your response toolkit. This includes wallets with a small amount of the native token for gas fees on the testnet and mainnet (kept separate). Establish communication channels with the chain's core development team and security communities, often found on Discord or Telegram. For automated monitoring, set up alerts using services like Tenderduty for Cosmos-based chains or custom scripts listening to Solana's WebSocket JSON-RPC for suspicious program invocations. Having these elements in place before an incident occurs drastically reduces response time and increases effectiveness.

Incident response on non-EVM chains requires a protocol-specific toolkit. Unlike the uniform revert mechanism of the EVM, failure modes are diverse. On Solana, a transaction can partially succeed, where some instructions fail while others execute, requiring you to parse the TransactionError object and inspect individual instruction logs. In the Cosmos SDK, failed transactions are typically reverted entirely, but the code and raw_log fields in the response provide deterministic error information from ABCI. For Polkadot's Substrate, extrinsic failures are captured in the DispatchError enum within the transaction events. Your first step is always to query the chain for the precise failure state using the network's RPC methods, such as getTransaction for Solana or querying the transaction by hash via Cosmos' Tendermint RPC.

Effective monitoring and alerting form the proactive layer of incident response. You need to track chain-specific health metrics beyond simple uptime. For high-throughput chains like Solana, monitor vote latency and skipped slots as early indicators of validator stress that could lead to transaction failures. In Cosmos-based zones, watch the consensus_state for halted height or abnormal validator set changes. Set up alerts for specific error types from your application's logs, such as InstructionError for Solana or insufficient fee errors in Cosmos, which may indicate fee market volatility. Tools like Prometheus with custom exporters for non-EVM chains or dedicated services like Chainscore are essential for aggregating these disparate signals into a coherent alerting dashboard.

When a critical incident like a chain halt occurs, your response must be systematic. First, establish impact: determine if it's a network-wide halt, a consensus failure, or localized to your application's transactions. Consult chain-specific status pages and validator communication channels (e.g., Discord, Telegram). Second, secure assets: if the chain is halted but not forked, assets are typically safe, but you must pause deposits/withdrawals at your bridging or custodial interfaces. For a contentious fork, you may need to implement guardrails to prevent replay attacks. Third, document and communicate: maintain a clear internal log of the timeline, errors, and actions taken. Transparent communication with your users is critical to maintaining trust during downtime.

Post-mortem analysis is where the most valuable long-term improvements are made. After resolving an incident, conduct a formal review to answer key questions: Was the root cause a bug in your smart contract (or program), an RPC provider failure, a chain-level bug, or a configuration error? For example, a Solana program might have failed due to an unanticipated rent exemption rule, while a Cosmos transaction could fail from an incorrect gas estimate. Update your runbooks, adjust your gas/fee estimation logic, and consider implementing circuit breakers in your application logic. Share findings (where appropriate) with the broader ecosystem; contributing to open-source client software or documentation helps improve resilience for everyone.

Incident response on non-EVM chains requires a fundamentally different toolkit and approach than on Ethereum. The first step is chain-specific triage. For a Solana program exploit, you must analyze the transaction logs from a Solana RPC node using the solana CLI or libraries like @solana/web3.js, focusing on the programLogs field for execution details. On Cosmos SDK chains, you inspect the Tendermint RPC for block and transaction data, often using gRPC endpoints or chain explorers. The goal is to quickly identify the malicious transaction hash, the affected smart contract or program, and the attacker's destination addresses across these heterogeneous environments.

Forensic data collection must capture the chain's native state. This involves creating a forensic node snapshot at the block height preceding and following the incident. For UTXO-based chains like Bitcoin or Cardano, you need the full set of unspent transaction outputs. For account-based chains like Aptos or Sui, you must record the global state of the affected resources. Tools like a local bitcoind node, aptos-node, or a dedicated archival RPC provider are essential. Simultaneously, gather all relevant off-chain data, including frontend application logs, RPC provider metrics, and any multisig or oracle transaction relays that may have been an attack vector.

The core of the analysis is transaction simulation and state diffing. Replay the suspicious transaction in a isolated, sandboxed environment matching the chain's mainnet version. On Solana, use the solana-test-validator with a snapshot. For Cosmos chains, tools like simd can simulate transactions. Compare the state root or storage changes before and after the transaction execution to pinpoint the exact logic flaw—whether it's a missing validation check in a CosmWasm contract, an arithmetic overflow in a Move module on Aptos, or a signature verification bypass in a Solana program. This step reveals the root cause vulnerability.

Following the exploit's path requires cross-chain tracing. Attackers often bridge stolen funds. You must trace the outflow from the native chain to others. If funds moved to an EVM chain via a bridge like Wormhole or LayerZero, the investigation continues with EVM tools. However, if assets are swapped within a non-EVM DEX (e.g., on Solana or on a Cosmos-based DEX like Osmosis), you need to analyze those chain's AMM pools and order books. Utilize the native blockchain explorers (Solana Explorer, Mintscan, Sui Explorer) and any available mempool analysis tools to track the attacker's steps before funds are laundered through privacy tools or mixers.

Finally, compile a forensic report and execute containment. The report should detail the attack vector, the exploited vulnerability (e.g., "Incorrect pool accounting in a Rust-based Constant Product Market Maker"), the transaction trail, and the total loss. Immediately work with validators, node operators, or foundation stewards to implement mitigations. This could involve halting the chain via governance (in Cosmos), disabling the vulnerable program (on Solana via upgrade authority), or coordinating with major exchanges to flag the attacker's addresses. The response concludes with a post-mortem to harden the protocol's code and monitoring systems against similar future attacks on its unique runtime.

Effective incident response on non-EVM chains requires a pre-defined, chain-specific playbook. This plan must account for the unique governance models, validator sets, and upgrade mechanisms of networks like Solana, Cosmos, or Aptos. Key components include a clear communication hierarchy, predefined on-call rotations, and pre-approved steps for engaging with core developers or validators. Crucially, your plan should outline procedures for chain halting or pausing smart contracts, which may involve submitting governance proposals or coordinating directly with a permissioned validator set, unlike the more decentralized pause functions on some EVM networks.

Immediate technical containment is the first priority. For a live exploit, this may involve using administrative keys to freeze a vulnerable program, as seen in Solana's spl-token program's freeze authority. On Cosmos SDK chains, a governance proposal for a software upgrade or parameter change might be the only way to patch a critical bug. Simultaneously, initiate forensic analysis using chain-specific tools: a Solana validator's RPC endpoint for transaction tracing, a Cosmos chain's block explorer with IBC packet tracking, or a Sui Move analyzer to examine mutated object states. Preserve all logs, transaction hashes, and state changes as immutable evidence.

Communication must be timely, transparent, and multi-channel. Internally, use encrypted channels to coordinate with your team and legal counsel. Externally, promptly notify your user base through all official channels—Twitter, Discord, project blog—with a clear, factual statement acknowledging the incident. For cross-chain incidents involving bridges like Wormhole or LayerZero, coordinate disclosure with the bridge's security team. Engage with the broader ecosystem by reporting the vulnerability to the chain's core development foundation (e.g., Solana Foundation, Aptos Foundation) and relevant security firms that specialize in that ecosystem.

Post-mortem analysis is non-negotiable. Publish a detailed report following a format like those from Solana's Neodyme or Aptos's OtterSec. The report should chronologically detail the root cause—whether it was a logic error in a Move module, a misunderstanding of Cosmos IBC timeouts, or a Solana account privilege escalation. Include concrete code snippets showing the vulnerable and patched logic. Outline specific, actionable remediation steps, such as implementing formal verification for Move contracts, adding more rigorous IBC relayer monitoring, or adopting a more secure program-derived address (PDA) derivation scheme on Solana.

To build long-term resilience, integrate these lessons into your development lifecycle. Adopt chain-specific security tools: Move Prover for Aptos/Sui, cargo-audit for Rust-based Solana programs, or Ignite CLI's scaffolding checks for Cosmos. Consider engaging auditors with proven expertise in your chain's native language and runtime. Finally, establish a bug bounty program on platforms like Immunefi, clearly specifying the scope for your non-EVM contracts and offering rewards commensurate with the chain's market cap and the complexity of its technology.