DeFi Protocol Due Diligence Checklist for Regulated Firms

Video transcript

ADGM's draft guidance expects regulated firms to diligence a DeFi protocol before using it. This checklist turns that into checks a risk team can run.

The draft, open for comment until 30 November 2026, tests each engagement in order: permissibility, fit with risk appetite, then suitability through due diligence.

Paragraph two point five point two names eight areas. Beyond legal review, the technical work covers contract architecture, audit history, admin authority, safety mechanisms, dependencies and front-end integrity.

An audit report is not enough. It gives point-in-time assurance over a defined scope. Confirm the audited commit, the exclusions, and that deployed bytecode matches.

Next, map every power from chain state: who can upgrade, grant roles, change parameters, pause, or set an oracle price. Record multisig thresholds, signers and timelock delays.

As the draft says, exposure is shaped not only by the protocol's current rules but by the credible threat of change to those rules.

A timelock only protects you if its delay exceeds the time you need to see a change and unwind. Mark every role that can bypass it.

Define re-diligence triggers at onboarding: a new proxy implementation, new multisig signers, a swapped oracle or new bridge, or a change in your own custody.

Guardian runs these checks in system reviews. Read the full checklist, or book a review at guardian.security.

On 6 October 2026, ADGM's Financial Services Regulatory Authority (FSRA) published Consultation Paper No. 5 of 2026, with draft DeFi Risk Management Guidance.

It says every material DeFi engagement by a regulated firm should be approved before it starts, with due diligence on the protocol.

This checklist turns that diligence into checks a risk team can run.

The draft admits firms “do not generally control” protocol safety mechanisms such as pause functions or upgrade authorities (2.5.3).

So diligence has to establish who does, and what happens to your position when they act.

This post covers choosing and onboarding a protocol. For what to watch once a position is live, see our guide to DeFi protocol monitoring under the same draft.

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.

How the Draft Works

The text is a consultation draft, open for comment until 30 November 2026.

What it adds is a sequence. Each material engagement is tested in three steps, in order (2.2.2(b) and 2.4).

1. Permissibility. Is it within the firm's Financial Services Permission? Diligence cannot make an impermissible engagement permissible (2.4.2).
2. Fit. Is it within the firm's DeFi risk appetite, and can the firm operate it safely?
3. Suitability. Has the venue, protocol or provider had adequate due diligence (2.5)?

Novel engagements should be raised with the FSRA before they start (2.4.3). Onboarding should set up monitoring and rehearse escalation (2.4.5).

The Checklist at a Glance

Paragraph 2.5.2 lists eight areas, examined at a level that matches materiality. Due diligence outputs and the approval rationale should be kept (2.8.2(d)).

Item (g) belongs to counsel and compliance. The sections below cover the technical items.

Deployed Code and Audits

Paragraph 3.4.1 puts it plainly: the protocol does what the code dictates, regardless of its stated intentions.

• Build the inventory from the chain. Every contract you call or that holds your assets, on every chain.
• Read each proxy. Record the live implementation, proxy admin and block number.
• Match bytecode to the audit. A mismatch means the code you rely on is not the code that was reviewed.
• Map the composability path. A transaction is only as secure as its most fragile dependency (3.8.3).

Next, the audits. Paragraph 3.4.2(e) says audits give point-in-time assurance over a defined scope, and lose validity when the code changes.

So an audit report is not enough on its own. Check:

• Which commit was audited. A report without a commit hash cannot be matched to deployed code.
• What was out of scope, such as periphery contracts, oracle adapters or governance modules.
• Findings acknowledged rather than fixed, and every upgrade since the audit.

Admin and Upgrade Authority

Paragraph 2.5.2(c) asks where administrative and upgrade authority sits, and when it may be exercised.

Section 3.5 adds the line for the top of every memo. Exposure is shaped “not only by the protocol's current rules but by the credible threat of change to those rules”.

So map every power from chain state: who can upgrade, grant roles, change parameters, pause, or set an oracle price.

For every multisig and timelock in that map:

• Threshold and signers. Record both. The draft calls multisigs “without sufficiently independent signers” a weakness in a firm's own wallets (3.2.2(b)).
• Threshold bypasses. Check for modules that let an address execute without collecting signatures.
• Delay against exit time. A timelock protects you only if it is longer than the time you need to see a change and unwind.
• Immediate powers. The draft names emergency upgrades that skip governance review as a risk (3.4.2(d)). Mark every role that can bypass the timelock.

For how regulators read these facts, see who controls DeFi admin keys.

Safety Mechanisms and Dependencies

Paragraph 2.5.3 asks how the firm would respond if a mechanism was triggered, failed, operated against its position, or was unavailable.

• Pause scope. Which functions stop? A pause that blocks withdrawals while liquidations continue can turn safety into loss.
• Oracle failover. When the primary feed is stale or deviates: fallback, freeze or last price?
• Emergency upgrades. Who can push one, by which path, with what delay?

Write a response for each case. The draft warns that exit routes may fail under stress, so primary controls come first: position sizing, exposure limits and protocol selection (2.2.3).

Then the dependencies. Section 2.6 asks for a current record of each provider, and whether it could be substituted (2.6.2).

• Oracles: sources, deviation thresholds, fallback, and whether a source is thin enough for a flash loan to move.
• Bridges: every route, including indirect ones, and who attests to cross-chain messages (3.7.3).
• Concentration: one oracle or bridge may sit under several positions (2.6.3).

On the front end, the draft names the risk of approving transactions whose actual effect differs from what the interface shows (3.4.2(g)).

So decode every transaction independently before signing. See securing signing interfaces.

Approval and Re-Diligence

Paragraph 2.5.5 calibrates stress tests to DeFi failure modes, from depegs and oracle manipulation to bridge failure and cascading liquidation.

Residual risk should be documented and accepted by someone with authority to accept it (2.3.2(d)). The FSRA may ask for the file (2.10.5).

Material changes should be re-approved (2.4.6). Define them as concrete events at onboarding:

• A new implementation behind any proxy in the inventory.
• New signers or threshold on any multisig, or a shorter timelock.
• A swapped oracle source, a new bridge route, or a new chain.
• A change of custodian, wallet provider or signing arrangement on your side.
• An incident at a shared dependency, even if the protocol was untouched.

Catching these as they happen is a monitoring job, covered in our guide to DeFi protocol monitoring under ADGM's draft.

For UK rules, see token admission due diligence under the FCA rules.

How Guardian Helps

Guardian's system architecture review is an hour with a Guardian engineer on what is actually running.

That covers the live contracts, the services that can reach them, and who holds the keys.

For allocators, Guardian's underwriting reads the deployed code and maps signers, thresholds, timelocks and admin keys. It assesses oracles, bridges and keepers as inherited exposure.

For institutions, Guardian's counterparty and integration review treats the bridges, custodians, oracles and protocols a firm depends on as concentrations of risk.

Frequently Asked Questions

Is the ADGM DeFi Risk Management Guidance in force?

No. It is a draft attached to FSRA Consultation Paper No. 5 of 2026. Comments close on 30 November 2026. The FSRA will then consider changes and publish the final Guidance.

Does the guidance apply to DeFi protocols themselves?

No. It applies to Authorised Persons and Recognised Bodies that engage with DeFi, and imposes no obligations on protocols. Protocols are likely to feel it indirectly, as regulated firms ask them for this evidence.

When does a firm need to repeat due diligence on a DeFi protocol?

Material changes should be re-approved: a new venue or protocol, a material upgrade, a custody change, or a change in a provider's or dependency's risk profile. Diligence should also be refreshed at intervals that match how fast the engagement changes.

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: Public consultations (accessed November 4, 2026)
• Guardian: System architecture review
• Guardian: Capital Allocators
• Guardian: Institutional