Cover photo

The Missing Layer in Crypto Security: Continuity Defense

How SCE is being designed to turn vulnerability intelligence into exposure analysis, adversarial reproduction, protocol defense, environmental containment, and verified recovery.

Crypto security has built strong systems for finding weaknesses. Audits review contracts, monitoring platforms watch transactions, and incident teams investigate exploits. The harder problem begins when a vulnerability reaches infrastructure a live protocol depends on.

An advisory can identify affected code and recommend a patch. It cannot tell a protocol operator whether the vulnerable feature is enabled, whether their contracts can reach it, what remains within their authority to fix, or what evidence permits a safe return to normal.

That gap is continuity defense.

Sagitta Continuity Engine is being built to connect those decisions. Its Case Library, a normalized source of vulnerability and incident intelligence, would feed four software-driven operational lanes with defined human approval points for protocol operators. The lanes represent capabilities delivered through SCE, not four departments a protocol must staff.

The incident that proves the gap

In March 2026, Cosmos Labs disclosed ASA-2026-002, a critical vulnerability in the ICS20 precompile. Incorrect state handling during nested EVM execution could allow the same token balance to be reused within a single transaction. Fifteen chains were running code containing the issue. Six had the affected feature disabled. Most of the remainder mitigated before exploitation; one was exploited first and lost approximately $7 million. The immediate mitigation was a coordinated upgrade disabling the precompile, and the permanent fix shipped in Cosmos EVM v0.6.0.

Those six chains are the argument for configuration-level exposure analysis. Shared vulnerable code did not produce equal exposure. Presence of the defect was never the answer; reachability was.

For the protocols deployed on top of those chains, the questions were different again: Is our contract path exposed? Which assets or bridge routes depend on the precompile? Which controls can we exercise ourselves, and which remedies belong to the chain? How long should restricted operation continue? No standard process exists for answering them. Protocols were left to interpret chain announcements against their own contracts, routes, and operating controls under time pressure.

A recurring class, not an isolated defect

The failure class had appeared before. CVE-2024-37153 affected the ICS20 precompile in Evmos, patched in 18.1.0. Exploitability there required three conditions to align: an affected chain version, an enabled and reachable precompile, and a contract function combining a local state change with an ICS20 transfer using the contract's own address as sender. In 2026, a different implementation under different execution conditions produced the same shape of failure — state consistency breaking across EVM execution, token accounting, and interchain transfer.

The details differed, but the class returned.

Audits and patches close individual defects. They rarely close a failure class across every chain, precompile, bridge, and integration where it can recur. What shortens the exposure window is a standing capability: once an advisory lands, exposure is filtered quickly, protocol-specific consequences are tested, and containment begins before disclosure becomes a wider incident.

Four lanes, one continuity decision

Under the planned SCE model, White Team would verify runtime versions and configuration, test the exact impact gates, trace reachable contract paths, and map the assets, channels, and protocol functions depending on them. This is what turns an ecosystem-wide advisory into a protocol-specific finding rather than a version-match alert.

Red Team would reconstruct the target conditions against forked mainnet state or an isolated chain replica, preserving the relevant bytecode, balances, precompile configuration, and contract state. The test would determine whether an outbound transfer completes while the expected balance reduction fails, and whether the same balance can then be reused within the transaction. That produces a checkable protocol-level observable without putting live funds at risk.

Blue Team would separate the controls a protocol holds from the dependencies it can only track. Protocol-controlled levers could include a guardian pause, circuit breaker, outbound rate limit, relayer allowlist, channel restriction, replacement route, or controlled migration — a protocol might suspend the affected interchain route while preserving local withdrawals and unrelated operations. Only the chain's authorized maintainers can disable or patch a vulnerable runtime component. A non-upgradeable protocol on an unpatched chain may execute every defensive action available to it and still remain in Degraded mode for weeks. Continuity defense treats that as a governed dependency condition rather than forcing a premature return to normal.

Black Team would secure relayers, RPC services, validator dependencies, privileged access, deployment pipelines, and monitoring. It would also look backward using the same observable Red Team tested forward: outbound ICS20 transfers completed without the expected balance reduction, correlated against supply and accounting changes to surface possible prior exploitation.

Recovery requires a record

SCE would evaluate the combined evidence and recommend a continuity state. The protocol's authorized operator, multisig, or governance process would declare the transition. Confirmed exposure could trigger Degraded operation. Successful reproduction or anomalous transfers could trigger Incident. Containment and remediation would begin Recovery. Return to Normal would require the exploit path to fail, balances and supply to reconcile, affected routes to pass verification, monitoring to remain active, and the authorized decision maker to approve restoration.

The deliverable would be a continuity record binding the advisory, exposure proof, reproduction results, containment actions, environmental findings, remediation evidence, remaining dependencies, and restoration decision. That record is what a protocol can present to its DAO, auditors, insurers, integrators, and the next incident responder who inherits the history.

Crypto already has audits, alerts, and incident response. Continuity defense connects them into an operating system for protocol survival.

What can this vulnerability reach, what must continue operating while it is contained, and what evidence proves the protocol is ready to return to normal?

That is the missing layer SCE is becoming. Subscribe to The Continuity Desk to follow as we build and share research on continuity defense.