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.

Reserves. Collateral. Audits. Controls. Backstops.

Sagitta adds another question:

What happens when protection is no longer enough?

The Three Deaths Doctrine is Sagitta’s base philosophy for treasury continuity through structured failure. It defines the conditions under which the Treasury loses the ability to originate new activity, and the revival paths that bring that capacity back.

The point is simple:

A protocol treasury is resilient when its failure states are named, bounded, and given revival paths in advance.

Status note: Sagitta is currently in testnet. This doctrine describes the treasury-continuity design the protocol is being built toward, not a claim that all revival mechanics are live, audited, or mainnet-proven. Execution authority, trigger conditions, and revival mechanics belong in the protocol specification and must be validated before production use.

What Death Means

In Sagitta, death has a precise meaning.

Death is the loss of origination capacity.

New deposits require collateral. Collateral requires treasury value. When treasury value reaches zero, the protocol can no longer originate new activity. No new deposits. No new collateral. No new flows.

That is treasury brain death.

The system can no longer initiate.

Existing positions are different.

They are the autonomic system. They keep running on stored momentum: completing withdrawals, honoring claims, settling obligations already in motion, and preserving the user-facing commitments that were already created before the Treasury entered the dead state.

This distinction is the foundation of the doctrine:

A dead treasury does not mean a dead user.

It means the protocol has entered a dormant state. Origination stops. Existing obligations continue through their defined paths. The system waits for revival instead of pretending nothing happened.

Death is the loss of capacity to originate.

It is not the loss of everything.

Dormancy Is a Design State

A system designed for continuity should know what happens when a critical asset fails.

Sagitta treats treasury death as a state the system can enter, hold, and recover from.

That changes the design question.

The question is not only:

How do we prevent failure?

The deeper question is:

What does the system do when failure arrives anyway?

Dormancy gives the system a disciplined response. It stops new activity when collateral capacity is gone. It protects existing claims from being mixed with new origination. It creates room for the relevant revival mechanism to activate.

The system does not collapse at zero.

It becomes still.

Then it follows the path assigned to that failure.

Where Biology Ends and Architecture Begins

The doctrine borrows the language of death because the metaphor is useful.

The Treasury is the brain of the system. When treasury value reaches zero, the protocol loses its ability to initiate new activity.

But Sagitta departs from biology at the exact point where architecture becomes powerful.

In biology, brain death is final because the organism has no structural revival path.

In protocol architecture, a dead state can be defined. It can be held. It can be connected to a recovery mechanism.

That is the purpose of the Three Deaths Doctrine.

Sagitta is designed toward something biology cannot do: enter a dead state without rotting, preserve existing obligations, and return through named revival paths without becoming a different system.

The Three Deaths

Three is not symbolic decoration.

Three corresponds to three structurally distinct assets in Sagitta’s current treasury architecture.

Each asset can fail in a different way.

Each failure has its own intended revival path.

Death I — Stablecoin Failure

The first death is a stablecoin failure.

If the active stablecoin collateral base depegs and the Treasury’s collateral value collapses, the Treasury loses origination capacity.

The intended revival path is substitution.

A replacement stablecoin collateral base can become the active collateral layer, restoring the Treasury’s ability to support new deposits and new flows once the substitution path is validated and approved.

The design point is not loyalty to one stablecoin.

The design point is continuity of collateral capacity.

A stablecoin can fail.

The collateral function must have a path back.

Death II — Reserve Failure

The second death is reserve failure.

Sagitta’s reserve layer is designed as a structural backstop to the Treasury. In the current design, gold-backed reserve assets such as XAUT sit in the reserve model as a stabilizing layer against treasury value.

If the reserve asset itself fails and the reserve function collapses, the system enters a reserve-death state.

The intended revival path is reserve reconstruction.

The Treasury and Reserve model must rebalance around the surviving asset base through a defined continuity path before production use.

The design point is not that any one reserve asset is permanent.

The design point is that the reserve role is named, monitored, and recoverable.

A reserve asset can fail.

The reserve function must have a path back.

Death III — Protocol Token Collapse

The third death is protocol token collapse.

SAG is part of the protocol’s value architecture. If SAG collapses through its floor and reaches a state where it no longer contributes meaningful treasury support, the Treasury loses another load-bearing pillar.

The intended revival path is stablecoin-backed restoration.

Treasury capacity is designed to be rebuilt through stablecoin reserves and collateral support independent of the token’s market price.

The design point is not that the protocol token can never fail.

The design point is that the Treasury does not depend on belief alone.

A protocol token can fail.

The collateral engine must have a path back.

Why Three, Not Infinite

A doctrine of infinite revival would be too easy to say and too weak to trust.

Three deaths means three named failure surfaces:

Stablecoin collateral failure.

Reserve failure.

Protocol token collapse.

Those are the current load-bearing asset failures in the architecture.

A fourth structurally distinct failure would require a fourth named mechanism. It would not be absorbed by rhetoric. It would need to be mapped, bounded, tested, and given its own continuity path.

That is what gives the doctrine strength.

It names what it covers.

It also names the edge of what it covers.

The Continuity Standard

The Three Deaths Doctrine is not a promise that failure disappears.

It is a standard for how failure is handled.

A serious continuity system should know:

What state triggers dormancy?

What activity stops?

What obligations continue?

What asset failed?

Which revival path applies?

Who can authorize the revival?

What evidence proves the system has returned?

Those questions matter more than the claim that a system is protected.

Protection is one layer.

Revival is the deeper layer.

Death as a Wait State

Under the Three Deaths Doctrine, death is not chaos.

Death is a wait state.

The Treasury stops originating new activity. Existing claims continue through their defined paths. The system holds the line between old obligations and new risk.

That boundary is critical.

A treasury that keeps originating while its collateral base is dead turns failure into contagion.

A treasury that enters dormancy gives itself room to revive without dragging new users into an unresolved state.

This is why the doctrine matters.

The goal is not to pretend death will never happen.

The goal is to make death survivable.

Continuity-First Architecture

Continuity-First Architecture treats the Three Deaths Doctrine as a worked example.

The Treasury becomes a Continuity Vault.

Each death becomes a Continuity Trigger event.

Each revival path is intended to become a Continuity primitive in the production architecture.

The philosophy and the system specification describe the same structure at two altitudes.

At the philosophical level, Sagitta accepts that failure can happen.

At the architectural level, Sagitta names the failure state, stops origination, preserves existing obligations, and routes the system toward revival.

The authority layer behind these revival paths — including trigger validation, signer approval, multisig execution, and Dead-Man style recovery controls — belongs in the protocol specification, not this doctrine note.

That is the essence of the doctrine.

The Treasury is not protected by the fantasy of permanent invulnerability.

It is protected by the discipline of named failure and structured return.

What This Doctrine Does Not Claim

The Three Deaths Doctrine does not claim infinite revival.

It does not claim every possible failure mode is covered.

It does not claim user risk disappears.

It does not replace audits, treasury controls, governance controls, oracle monitoring, reserve management, or protocol-level security review.

It does not claim the production system is complete.

It names the current system’s three load-bearing asset failures and gives each one a design path for structured return.

That is the useful standard.

A doctrine should not pretend to cover everything.

It should make the known failure map clear enough to build against.

Closing

The Three Deaths Doctrine is Sagitta’s answer to a harder question:

What should a protocol do when one of its load-bearing assets dies?

The answer is structure.

Name the death.

Stop new origination.

Protect existing obligations.

Activate the correct revival path.

Return only when the Treasury can originate again.

Sagitta is still in testnet, and the production mechanics must be validated before mainnet use. But the doctrine establishes the design standard: treasury failure should be named, bounded, and routed through structured return.

That is continuity.

That is the doctrine.

DeFi custody is usually described by where assets sit.

That is only one layer.

The larger custody question is authority.

Who can move funds?

Who can upgrade contracts?

Who can pause markets?

Who can change oracle inputs?

Who can approve bridge messages?

Who can execute governance?

Who can act during an emergency?

A protocol can have audited contracts, a multisig, a timelock, verified source, and a clean frontend while still carrying unresolved custody risk if the signing path is unclear.

The first question is:

Who holds the keys?

The deeper question is:

What can those keys authorize?

That is where custody becomes signing authority.

Multisigs sit inside the custody model

A multisig is a strong control because it requires multiple approvals before an action can execute.

That matters.

It creates shared authorization.

It reduces single-signer dependency.

It gives a protocol a clearer approval path than a single EOA.

But the multisig is one part of the custody model.

A 3-of-5 Safe can show the public threshold. It can show how many approvals are needed. It can show the owner set where the interface is supported.

The next questions are operational.

Are the signers independent?

Are signer roles separated?

How are keys stored?

How are signers replaced?

Who reviews the transaction before approval?

Who confirms that the transaction matches the intended action?

Which contracts can the multisig control?

What else has the same authority?

The custody question starts with the multisig.

It does not end there.

Timelocks add time to the authority path

A multisig controls who can approve.

A timelock controls when approval can become execution.

That distinction is important.

A timelock can create a reaction window before a sensitive action goes live. It gives tokenholders, users, integrators, monitors, and internal reviewers time to inspect a queued change before execution.

That is a valuable continuity control.

The next question is how the timelock is used.

What actions pass through it?

Who can queue transactions?

Who can execute them?

Who can cancel them?

Which contracts are actually controlled through the timelock?

Who watches the queue before the delay expires?

A timelock is time-control around authority.

Its value depends on the execution path around it.

The signature is only one part of the security boundary

A signature proves that a key authorized a message.

The next question is the message.

What was signed?

Was it a direct transaction?

Was it typed data?

Was it a permit?

Was it an offchain authorization?

Was it a governance action?

Was it bound to the right chain, contract, nonce, expiry, and domain?

Was the signer shown enough context to understand what the signature would authorize?

This is where hashes, signature algorithms, and signing standards matter.

They give structure to authorization.

They help bind messages to specific data.

They help make signatures verifiable.

But the practical risk lives in the full signing context.

A strong hash protects the message that was actually signed.

A valid signature authorizes the action that the message actually represents.

Typed data becomes stronger when the domain, nonce, verifying contract, expiry, and displayed intent are clear.

Cryptography proves integrity.

Continuity review asks whether the authorized action was bounded, reviewable, and tied to the right custody domain.

Custody domains matter

A custody domain is a zone of authority.

It answers:

Where does control actually live?

In a simple wallet, the custody domain may be one EOA.

In a protocol, there may be several custody domains:

• Treasury Safe

• Protocol admin Safe

• Emergency pause authority

• Oracle updater

• Bridge operator

• Upgrade executor

• Governance timelock

• Offchain signer set

• Institutional custody provider

• Transaction builder

• Frontend or internal dashboard

• Automation layer that submits transactions

Each domain has its own authority.

Each domain has its own blast radius.

A treasury Safe may be well-controlled while the oracle updater needs more evidence.

A governance path may be public while an emergency signer path needs clearer documentation.

A timelock may delay upgrades while a pause guardian acts immediately.

A custody provider may protect keys while the protocol still needs to map what those keys can authorize.

This is why a Defense Review looks beyond “multisig detected.”

The review asks what the multisig can do, what other paths can do the same thing, and what evidence supports the signing policy behind each path.

The signing interface is part of the authority path

Signers usually approve transactions prepared by another system.

That system may be a frontend, Safe app, internal dashboard, script, bot, transaction builder, or policy engine.

That interface becomes part of the custody domain.

A signer may have strong key custody and still approve a risky action if the transaction builder presents incomplete context.

The signing process has to answer:

• Who prepares the transaction?

• Who reviews the calldata?

• Is simulation part of the workflow?

• Is there a second review for upgrades or treasury movement?

• Are signers approving human-readable intent?

• Are transaction templates controlled?

• Are emergency actions pre-planned?

• Are queued governance actions monitored before execution?

Signing authority is not just the key.

It is the full path from intent to execution.

Modules, guards, and delegated authority change the map

A Safe threshold is one part of the story.

Modules can create alternate execution paths.

Guards can restrict or inspect execution.

Delegates, keepers, bots, session keys, relayers, and operators can carry narrow authority or broad authority depending on how the system is designed.

Some of these paths are visible onchain.

Some require submitted evidence.

All of them matter to the authority map.

A module installed on a Safe may create another way for an action to execute.

A keeper role may affect liquidation, settlement, oracle updates, rebalancing, or treasury operations.

A session key may carry delegated signing authority with a defined blast radius.

A relayer may sit between approved intent and executed transaction.

The continuity question is:

What can this authority path do if it is wrong, compromised, unavailable, or misunderstood?

Blast Radius Grows When Authority Repeats

Every signing path has blast radius.

If this signer is compromised, what can happen?

Can funds move?

Can implementation logic change?

Can markets pause?

Can oracle prices update?

Can reserves be redirected?

Can governance execute?

Can bridge messages be approved?

Can an emergency signer act faster than the public governance process?

The blast radius grows when the same authority domain appears across multiple critical paths.

The same Safe may control treasury movement, proxy upgrades, oracle configuration, and emergency pause.

The same signer set may sit behind multiple Safes.

The same operator may control keepers, relayers, and admin dashboards.

The same governance executor may control protocol parameters and treasury movement.

Each control may make sense in isolation.

Together, they may create concentration.

This is why project maps matter.

A project map does not only list contracts. It shows where authority repeats, where control paths converge, and where one custody domain can affect multiple parts of the system.

That is the difference between looking at a wallet and understanding a protocol.

The review question is:

Does the signing model match the blast radius?

Authority reuse is where risk compounds

One of the most important questions in a Defense Review is whether the same authority domain appears across multiple critical paths.

The same Safe may control treasury movement, proxy upgrades, oracle configuration, and emergency pause.

The same signer set may sit behind multiple Safes.

The same operator may control keepers, relayers, and admin dashboards.

The same governance executor may control protocol parameters and treasury movement.

Each control may make sense in isolation.

Together, they may create concentration.

This is why project maps matter.

A project map does not only list contracts. It shows where authority repeats, where control paths converge, and where one custody domain can affect multiple parts of the system.

That is the difference between looking at a wallet and understanding a protocol.

Cross-chain systems multiply custody domains

Cross-chain systems add another layer.

A protocol may authorize action on one chain and execute on another.

A bridge may rely on a separate signer set.

A message relayer may hold operational authority.

A chain-specific executor may have upgrade power.

A governance action may begin on Ethereum and execute somewhere else.

The custody domain includes more than the admin wallet.

It includes cross-chain messaging, relayer assumptions, destination-chain executors, bridge controls, and chain-specific emergency paths.

The question becomes:

Where is the action authorized, where is it verified, and where does it execute?

When those are different places, each one needs its own authority review.

What public evidence can show

A public-surface review can observe parts of the signing authority system.

It can identify owner addresses.

It can identify multisig contracts.

It can identify Safe owners and thresholds.

It can identify proxy admin slots.

It can identify implementation addresses.

It can identify timelock delay surfaces.

It can identify some modules, guards, and role surfaces where public interfaces are supported.

It can identify oracle updater paths where exposed.

It can identify source and ABI availability.

It can identify authority concentration across mapped assets.

Those observations matter.

Each observation has a boundary.

A public call can confirm a specific fact. Operating evidence explains the control behind that fact.

Where operating evidence enters

Public evidence gives the review a starting point.

Operating evidence gives the review context.

A protocol team may need to provide:

• Signer policy

• Threshold policy

• Key rotation process

• Emergency signer replacement process

• Upgrade approval policy

• Treasury movement policy

• Oracle update policy

• Timelock execution policy

• Module and guard inventory

• Custody provider boundaries

• Transaction simulation or review process

• Relayer, keeper, and automation authority

• Cross-chain executor and bridge authority

That evidence is matched against the authority map.

The result is a clearer view of which paths are observed, which paths are understood, and which paths still require verification.

What SCE looks for

A Defense Review treats signing authority as a system.

The review maps the public authority path first:

• Who can call?

• Who can upgrade?

• Who can pause?

• Who can move funds?

• Who can change price inputs?

• Who can execute governance?

• Who can authorize offchain messages?

• Who can bypass or accelerate the normal process?

• Who can build the transaction signers approve?

• Who can rotate, replace, or remove signers?

Then it maps the evidence behind those paths.

This is the difference between seeing a multisig and understanding a custody model.

The practical standard

A protocol can have fast emergency control.

A protocol can use different signer structures for different actions.

A protocol can separate treasury, upgrade, oracle, emergency, and governance authority into different domains.

The important thing is intention.

Fast emergency control should be documented.

Treasury movement should have a separate policy.

Upgrade authority should have a clear approval path.

Oracle authority should have fallback and stale-price policy.

Signer sets should match the consequence of the action.

Timelock monitoring should be assigned.

Modules and guards should be inventoried.

Cross-chain executors should be mapped.

Signing interfaces should be reviewed as part of the authority path.

Domains should be separated where one compromised path could otherwise control too much.

The strongest systems do more than protect keys.

They reduce what any one signing domain can break.

Closing

DeFi security is not only about code.

It is also about authority.

The hash matters.

The signature matters.

The multisig matters.

The timelock matters.

The custody provider matters.

But the continuity question is larger:

Who can authorize the action, what exactly are they signing, when can it execute, where is the signature valid, and which custody domain controls the path?

That is where protocol risk becomes visible.

Before a launch, treasury growth milestone, contract upgrade, governance change, cross-chain deployment, or new signing workflow, Sagitta Defense Review maps public authority surfaces, signing domains, unresolved control paths, and evidence gaps before those paths are stressed.

It is what that owner can do, what controls the owner, and what evidence exists when that authority path is stressed.

A public-surface authority review starts with what can be observed: owner calls, proxy slots, timelocks, multisigs, role surfaces, oracle paths, source and ABI status, and public governance context.

But observation is not assurance.

A detector can identify an authority surface. It cannot prove custody practice, signer independence, upgrade approval policy, emergency response, or governance intent. That evidence boundary is the foundation of Sagitta’s Defense Review method.

Public evidence is useful. It is not complete.

Onchain systems expose a lot.

A contract may expose an owner() call. A proxy may expose an implementation slot or admin slot. A Safe may expose owners and a threshold. A timelock may expose a delay. An oracle contract may expose feed behavior. A role system may expose part of its access-control structure.

Those are real observations.

They matter.

But each observation only proves what it was designed to observe.

An owner() call proves that an owner address was observed through a supported public call. It does not prove who controls that owner, whether the signer policy is sound, whether key rotation exists, or whether the emergency replacement process is usable.

A proxy admin slot can show where upgrade authority points. It does not prove that upgrades require the right approval process.

A timelock delay can show that execution is delayed. It does not prove governance intent, cancellation policy, emergency bypass policy, or which contracts are meaningfully protected by that timelock.

A Safe threshold can show the public signer structure. It does not prove signer independence, operational readiness, module risk, or incident response discipline.

That is the difference between evidence and assurance.

The mistake is treating visibility as verification.

Many protocol reviews collapse these ideas.

• They see an owner and assume the authority path is understood.

• They see a timelock and assume governance is safe.

• They see a multisig and assume operational control is mature.

• They see verified source and assume control design is verified.

That is not how continuity works. Continuity risk often lives between what a contract exposes and how a team actually operates it.

The public surface can tell us what exists. It can show where authority points. It can reveal proxy paths, admin paths, role paths, oracle dependencies, and unresolved control surfaces. But it cannot prove the private operating layer by itself.

That layer requires evidence.

Signer policy. Upgrade policy. Treasury movement policy. Timelock execution policy. Oracle fallback policy. Emergency pause policy. Governance execution process. Role inventory. Incident response ownership.

Without that evidence, the honest answer is not “safe” or “unsafe.”

The honest answer is: evidence required.

Evidence required is not a failed control.

This matters.

When Sagitta marks something as evidence required, that does not mean the protocol failed. It means the public surface does not prove the operating control.

That distinction keeps the review honest.

A Defense Review should not inflate severity just because evidence is missing. It should not turn unresolved authority into a vulnerability claim. It should not imply exploitability without proof. It should not treat source, ABI, graph, or detector output as control verification by itself.

The job is to separate what was observed, what was inferred, what remains unresolved, and what evidence is required before a control can be reviewed.

That is the discipline.

The four evidence states

Sagitta’s public-surface method uses a simple evidence model.

1. Observed means a specific public evidence item resolved through a supported call, storage slot, or verified source/ABI path.

2. Inferred means the review has a reasonable pattern or metadata basis, but the evidence is not complete enough to treat as directly verified.

3. Unresolved means an in-scope authority surface exists, but SCE could not resolve the path with enough confidence from the available evidence.

4. Evidence Required means the protocol team needs to provide policy, signer, governance, role, source, ABI, or operating evidence before that control can be reviewed for verification.

This model keeps the review useful without pretending to know more than the evidence supports.

Why this matters for protocol continuity

Protocol failure is rarely just about one contract. It is usually about paths.

• Who can upgrade the system?

• Who can pause it?

• Who can move treasury funds?

• Who can change the oracle?

• Who can change implementation logic?

• Who can execute governance?

• Who can act during an emergency?

• Who watches the timelock window?

• Who owns the fallback path?

A project map turns those questions into a reviewable surface. It connects contracts, proxies, implementations, admins, timelocks, Safes, governors, oracles, treasuries, keepers, and linked candidates into one authority picture.

That picture is not the same as an audit.

An audit looks deeply at code behavior and exploit paths.

A Defense Review looks at whether the system can survive control failure.

Both matter. They answer different questions.

What a public-surface authority review actually proves

• It proves what can be observed.

• It proves which authority surfaces were visible.

• It proves which detector methods resolved public evidence.

• It proves which paths remain unresolved.

• It proves which operating evidence is needed before a protocol can claim stronger continuity readiness.

That is enough to be valuable.

Not because it declares the protocol safe. Because it gives the team a clearer map of what still needs to be proven. That is the point of The Continuity Desk.

• Not to create noise.

• Not to dress up scanner output.

• Not to turn missing evidence into fear.

The work is to make authority evidence legible.

Teams preparing for launch, treasury growth, protocol upgrades, or governance changes can request a Sagitta Defense Review to map public authority surfaces, unresolved control paths, and evidence gaps before those paths are stressed.

The Continuity Desk is published by Sagitta Continuity Engine.
Protocol authority and continuity research from Sagitta.