DeFi Protocol Monitoring Under ADGM's Draft Guidance

Video transcript

ADGM's draft DeFi guidance makes protocol monitoring a control in its own right, and periodic review alone will not satisfy it.

A protocol approved in good faith can change after onboarding. A proxy gets a new implementation, a timelock shrinks, an oracle is swapped.

The draft lists seven areas: exposure, operational health, governance activity, external stress like depegs, financial crime, and your own signing systems, plus whether controls stay adequate.

Instead of periodic review, it wants threshold alerts, escalation triggers and clear alert ownership. Continuous means responding to material events in time, not watching every data point.

Much of this is visible onchain. Standard events flag role changes, upgrades, timelock queues, multisig signer changes and pauses. Emergency roles skip the queue, so treat any use as top priority.

Escalation must work outside business hours. A material Cyber Incident at a protocol you rely on may trigger FSRA notification within 24 hours.

For each alert, write down the owner, the threshold, the first actions, who decides on exit, and who assesses notification.

Guardian's Managed Security watches contracts and multisigs you control on every block, with engineers responding around the clock. Allocator monitoring tracks upgrades and signers in protocols you hold.

The text is still a consultation draft, so read the full guide, then talk to Guardian about watching every protocol you hold.

The FSRA's draft DeFi Risk Management Guidance, published on 6 October 2026, treats DeFi protocol monitoring as a control in its own right.

A protocol approved in good faith can change after onboarding. A proxy gets a new implementation, a multisig loses a signer, a timelock is shortened, an oracle is swapped.

The draft is direct about pace. DeFi incidents “may unfold at the speed of block production” and may be visible onchain before the firm detects them (2.10.1).

This guide covers what to watch once a position is live. Choosing a protocol, and the baseline you monitor against, is in our DeFi protocol due diligence checklist.

This article explains the technical and security side of the FSRA's draft DeFi Risk Management Guidance. It is not legal advice; confirm how it applies to you with counsel.

Periodic Review Is Not Enough

The text is a consultation draft, with comments due by 30 November 2026. It applies to Authorised Persons and Recognised Bodies that engage with DeFi, not to protocols.

Two paragraphs set the standard:

• 2.7.5: monitoring should not rely solely on periodic review. Threshold alerts, escalation triggers and clear ownership of outputs should be in place.
• 2.7.4: firms do not generally control protocol safety mechanisms, so monitoring should cover their observable status and the firm's readiness to act.

Paragraph 2.7.2 adds a limit. Continuous means identifying and responding to material risk events within a timeframe appropriate to the engagement.

It does not mean “undifferentiated review of every protocol, dependency or data point at all times”. Design for the events that matter to your positions.

The Seven Monitoring Areas

Admin Changes as Onchain Events

Most of area (c), and much of (b), is observable onchain. Widely used libraries emit standard events when authority changes.

Subscribe to them on every contract in your onboarding role map.

Events are where monitoring starts, not where it ends. Custom contracts may change state without a standard event.

Two habits close the gap. First, decode the calldata of every multisig and timelock transaction that targets a contract you depend on.

Second, compare live state against the onboarding baseline on a schedule: implementations, role holders, thresholds, delays and oracle addresses.

Emergency powers need their own rule. The draft names emergency upgrades that bypass normal governance review as a risk (3.4.2(d)).

Any use of a role that can act without a timelock is a top-priority alert. There is no queue to give you warning.

Governance, Oracles and Depegs

The draft expects firms to monitor proposals, votes, authority changes and emergency powers for every protocol they rely on (3.5.3(b)).

They should adjust exposure in response to material adverse governance change (3.5.3(d)).

• Proposals. Decode the actions of any proposal touching your contracts. Offchain signaling votes and forum posts often come first.
• The timelock queue. A queued operation shows what will execute and when. It is often the moment to reduce exposure.

For oracles, the draft names stale data and misconfigured bounds, deviation thresholds or fallback parameters (3.6.2). Alert on:

• Time since the last oracle update against the expected interval.
• Deviation between the oracle price and independent market references.
• Fallback activation, or any change to the feed address itself.

For Fiat-Referenced Tokens, section 4.2 names peg loss, redemption failure, issuer freezes or blacklisting, and contagion.

Watch price against the reference across venues, redemptions, freeze events touching your pools, and large outflows.

Monitor wrapped and bridged assets separately from their underlying (4.5.3(a)).

Your Own Signing and Bots

Area (f) points the monitor at the firm itself. The draft wants firms to detect a compromise of their signing arrangements in time to respond (3.2.3(c)).

Where bots or agents execute DeFi transactions, paragraph 2.7.6 expects defined bounds and the ability to pause, constrain or override them.

• Alert on any signing request outside policy: an unknown destination, an unlimited approval, an unlisted contract.
• Reconcile outstanding token approvals daily and alert on new ones.
• Check bot actions against their bounds, and test the kill switch.
• Monitor the monitors: alert when a feed or detector goes quiet.

For the interface side, see securing signing interfaces after Bybit.

Escalation and Notification

Section 2.10 asks for escalation arrangements defined in advance and tested.

Procedures should operate outside normal business hours, with thresholds set so material events reach senior management in time (2.10.3).

Staffing should cover nights, leave and sickness without depending on one person (2.9.2(d)).

Notification is part of the same chain. An incident at a protocol the firm relies on may trigger GEN 3.5.18 if it is a material Cyber Incident (2.10.7).

GEN 3.5.18 requires notifying the FSRA immediately, and no later than 24 hours after the firm becomes aware, or has information reasonably suggesting, that one has occurred.

For each alert type, write down:

• The owner and the threshold.
• The first actions: stop new exposure, pause your own bots, revoke approvals, withdraw where possible.
• Who decides on exit, and who assesses notification.

Keep records of each control breach and incident, from detection to resolution (2.8.2(e)).

How Guardian Helps

For the contracts and multisigs a firm controls, Guardian's Managed Security monitors them on every block.

It covers privileged calls, role and ownership changes, upgrades, multisig transactions and large fund movements. A Guardian engineer responds, around the clock.

For protocols a firm holds but does not run, Guardian's allocator monitoring watches upgrades, signer sets, timelocks and role grants.

It checks them against what was last reviewed, and reports material moves the day they happen.

For other options, see our comparison of smart contract monitoring tools and our Web3 MDR explainer.

Frequently Asked Questions

Does ADGM require 24/7 DeFi protocol monitoring?

The draft does not use that phrase. It wants threshold-based alerts (2.7.5) and escalation that works outside normal business hours (2.10.3). Continuous means responding to material events in an appropriate timeframe (2.7.2). It is still a consultation draft.

Can a firm rely on a third-party monitoring tool?

Yes, but it should understand the tool's methodology, coverage and limitations, and keep the ability to interpret its output (2.7.5). Third-party tooling does not negate the firm's accountability, and outsourcing remains subject to GEN Chapter 3.

Can an exploit at a DeFi protocol trigger GEN 3.5.18 notification?

It can, if it is a material Cyber Incident at a protocol the firm relies on. GEN 3.5.18 requires notifying the FSRA immediately, and no later than 24 hours after becoming aware, or having information reasonably suggesting, that one occurred.

Sources

• ADGM FSRA: Consultation Paper No. 5 of 2026, DeFi Risk Management Guidance (6 October 2026)
• ADGM FSRA: Attachment 1, Proposed DeFi Risk Management Guidance (6 October 2026)
• ADGM FSRA: General Rulebook, GEN 3.5.18 Notification (current version, accessed November 4, 2026)
• OpenZeppelin Contracts v5.1.0: IAccessControl.sol
• OpenZeppelin Contracts v5.1.0: Ownable.sol
• OpenZeppelin Contracts v5.1.0: IERC1967.sol
• OpenZeppelin Contracts v5.1.0: TimelockController.sol
• OpenZeppelin Contracts v5.1.0: Pausable.sol
• Safe Smart Account v1.4.1: OwnerManager.sol
• Safe Smart Account v1.4.1: ModuleManager.sol
• Safe Smart Account v1.4.1: GuardManager.sol
• Guardian: Managed Security
• Guardian: Capital Allocators