The Missing Layer in Crypto Security: Continuity Defense

Crypto security is well supplied at both ends of an incident. Audits and advisories find defects before they are exploited; monitoring and incident response deal with the aftermath once they are. The article's claim is that the interval between those two — the hours in which a vulnerability is public, unpatched, and live — is served by almost nothing, and that this interval is where continuity is actually won or lost.

The gap is a question of information rather than diligence. An advisory can name the affected code and recommend a patch. What it cannot tell any particular operator is whether the vulnerable feature is enabled on their chain, whether the defective path is reachable given their configuration, which of their contracts sit in front of it, or what their exposure is if it is reached. Those answers are specific to a deployment, and the advisory is written for all of them at once.

The article grounds this in the Cosmos EVM ICS20 precompile flaw disclosed as ASA-2026-002, where state changes made during nested calls were not correctly carried back into the outer execution context, allowing the same balance to be spent more than once inside a single transaction. Fifteen chains were running code that contained the issue. Six had the affected feature disabled and were never exposed by it. Most of the remainder mitigated before anyone reached it. One did not, and was exploited first — an estimated loss of roughly seven million dollars.

That distribution is the argument. Identical vulnerable code produced fifteen different exposures, and the variable separating them was not the presence of the defect but whether the defective path was reachable in that deployment. An operator who could answer the reachability question on the day of disclosure was in a different position from one still reading the advisory to find out whether it applied to them.

Continuity defense is the name the article gives to the capability that answers it: determining whether vulnerable code is reachable, containing exposure with the controls the protocol already has, and verifying that recovery is safe before normal operation resumes. It is neither auditing nor incident response, and it does not replace either. It is the operational judgement exercised between them.

The Sagitta Continuity Engine is presented as the system built to carry that work, coordinating four lanes against a live disclosure. White establishes what the protocol actually runs and where the exposure could reach. Red reproduces the conditions rather than assuming them. Blue separates the controls the protocol holds itself from those it depends on others for. Black documents what recovery would require and what evidence would show it had been achieved.

What the lanes produce is the point of the exercise: a continuity record stating what was exposed, what was contained, and what was verified — the artifact a DAO, an auditor, or a counterparty can read afterwards to establish that the response was deliberate rather than fortunate. The full article is published on The Continuity Desk, Sagitta's Paragraph publication.