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.
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.
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.
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.
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.
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.
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?
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?
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 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.
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.
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.
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.
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.
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.