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.