https://www.sagitta.systems/newsroom Continuity Engine dispatches: incident analysis, threat families, and doctrine updates. en Tue, 04 Aug 2026 00:00:00 GMT https://www.sagitta.systems/sagitta.png https://www.sagitta.systems/newsroom https://www.sagitta.systems/newsroom/the-missing-layer-in-crypto-security-continuity-defense https://www.sagitta.systems/newsroom/the-missing-layer-in-crypto-security-continuity-defense Tue, 04 Aug 2026 00:00:00 GMT Audits find defects and monitoring catches exploits. Neither tells an operator whether the vulnerable code is reachable on their own chain. 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. Article SCE Wire Sagitta Systems https://www.sagitta.systems/newsroom/the-three-deaths-doctrine https://www.sagitta.systems/newsroom/the-three-deaths-doctrine Tue, 30 Jun 2026 00:00:00 GMT How Sagitta defines treasury failure as a dormant state, not a terminal collapse. Treasury design is overwhelmingly concerned with protection. The Three Deaths Doctrine starts from a different question: what happens when protection is no longer enough? The doctrine's answer is that a protocol treasury is resilient when its failure states are named, bounded, and given revival paths in advance — not when it has been engineered to make failure unlikely. Those are different properties, and the second one is the only one that is still doing any work on the day the first one is wrong. This requires being precise about what death actually means. In the doctrine's terms, death is the loss of origination capacity: when treasury value reaches zero, the protocol can no longer initiate new deposits or accept new collateral. That is treasury brain death, and it is a specific, observable condition rather than a general sense of crisis. Critically, a dead treasury does not mean a dead user. Existing obligations continue along defined paths while origination halts. The system becomes still rather than collapsing, and dormancy is treated as a disciplined design state that was specified in advance — not as the absence of a plan. The article then names three deaths, each with its own revival path. Death I is stablecoin failure: the active stablecoin collateral depegs and takes treasury value with it, and the revival path is substitution onto a replacement stablecoin base. Death II is reserve failure: the reserve assets themselves fail, and the revival path is reserve reconstruction, rebalancing around whatever survived. Death III is protocol token collapse, where the revival path is stablecoin-backed restoration that does not depend on the token's price recovering — because a recovery plan contingent on the collapsed asset recovering is not a plan. What makes this a doctrine rather than a contingency list is the standard it generalises into. Any continuity system, Sagitta's or anyone else's, should be able to answer seven questions for each of its failure states: what triggers it, what stops, what obligations continue, which assets have failed, which revival path applies, who is authorised to invoke it, and what metric verifies the return. A continuity plan that cannot answer all seven has not specified a failure state. It has expressed a hope. The full article works through each death in turn, with the specific assets and mechanisms involved, and is published on The Continuity Desk — Sagitta's Paragraph publication, described there as protocol authority and continuity research. Article SCE Wire Sagitta Systems https://www.sagitta.systems/newsroom/signing-authority-is-the-real-custody-layer https://www.sagitta.systems/newsroom/signing-authority-is-the-real-custody-layer Thu, 04 Jun 2026 00:00:00 GMT Multisigs, timelocks, hashes, and custody providers matter. But DeFi security depends on who can authorize action, what they are signing, when it can execute, and which custody domain controls the path. Custody in DeFi is usually discussed as a question of where assets sit. The larger custody question is authority: who can move funds, who can upgrade contracts, and who can pause markets. A protocol can hold strong technical safeguards and still carry unresolved custody risk if the signing path is unclear. Two questions frame the whole subject, and the distance between them separates a basic reading from a real analysis. The first is who holds the keys. The second is what those keys can authorise. Multisigs are where most reviews stop. They are genuinely valuable — shared authorisation reduces single-signer dependency — but a multisig is one part of the custody model, not the model itself. Are the signers actually independent? How are the keys stored? Which contracts can that multisig reach? The custody question starts with the multisig. It does not end there. Timelocks add the temporal dimension: where a multisig governs who approves, a timelock governs when approval can become execution, creating a reaction window before a sensitive action goes live. Their value is entirely a function of implementation — which actions actually route through them, who can queue and execute, and whether anyone is monitoring the queue at all. A timelock nobody watches is a delay, not a control. Signatures prove intent, not safety. A signature authorises a message, so the next question is always the message: typed data, a permit, an offchain authorisation? A strong hash protects the message that was actually signed, and nothing more. Cryptography proves integrity; continuity review asks whether the authorised action was bounded, reviewable, and tied to the right custody domain. That word — domain — carries the argument. A protocol contains many: the treasury Safe, the emergency pause authority, the oracle updater, the bridge operator, the governance timelock. Each has its own authority and its own blast radius, and the risk compounds where one domain appears across several critical paths at once. A single Safe that controls treasury, upgrades, oracle configuration, and emergency pause is not four controls; it is one control wearing four labels. This is why a project map matters, and why it has to show where authority repeats and where control paths converge rather than simply listing contracts. The article extends the same logic through the signing interface — a signer with excellent key custody can still approve a dangerous action if the transaction builder presented incomplete context — through modules, guards, session keys, relayers, and keepers as alternate execution routes, and through cross-chain systems, where an action may be authorised on one chain and executed on another. It closes on the distinction between observable and evidential authority. A public call can confirm a specific fact; operating evidence explains the control behind it. The full text is on Paragraph. Article SCE Wire Sagitta Systems https://www.sagitta.systems/newsroom/what-a-public-surface-authority-review-actually-proves https://www.sagitta.systems/newsroom/what-a-public-surface-authority-review-actually-proves Tue, 26 May 2026 00:00:00 GMT A detector can observe authority evidence. It cannot prove operational control. A detector can observe authority evidence. It cannot prove operational control. That sentence is the whole argument, and the article is an examination of how much follows from it. Onchain systems are unusually legible, and a public-surface review can read a great deal without asking anyone's permission. A contract may expose an `owner()` call. A proxy may expose an implementation slot or an admin slot. Owner addresses, proxy paths, multisig structures, timelock delays, oracle behaviour, and role systems are all observable from the outside. These are real observations and they matter. The limitation is that each observation only proves what it was designed to observe. An owner address establishes that an address owns the contract. It does not establish who controls that address, whether the signer policy behind it is sound, or what happens in an emergency. A timelock establishes a delay. It does not establish governance intent, cancellation policy, or whether an emergency bypass exists. The mistake, then, is treating visibility as verification — seeing an owner and assuming the authority path is understood, seeing a timelock and assuming governance is safe. The observation was never wrong. The inference drawn from it was. This matters because of where continuity risk actually lives: in the gap between what a contract exposes and how a team operates it. Signer procedures, upgrade approval, treasury movement, incident response — the real controls are operating policies, and operating policies are invisible to public evidence by their nature. No amount of care in reading the chain will surface them, because they were never written to the chain. The method the article sets out handles this by classifying every finding rather than flattening it: Observed, Inferred, Unresolved, or Evidence Required. The classification is the discipline. It makes a review incapable of claiming more than its evidence supports, because every claim has to declare which of the four it is before it can be stated at all. The consequence is a standard that cuts in the direction reviewers usually find uncomfortable. A Defense Review should not inflate severity just because evidence is missing, and it should not turn unresolved authority into a vulnerability claim. An unanswered question is an unanswered question. Reporting it as a finding would be the same error as treating visibility as verification, committed in the opposite direction — and it is the more tempting of the two, because it looks like rigour. The full article is published on The Continuity Desk, Sagitta's Paragraph publication. Article SCE Wire Sagitta Systems