The register requirement meets DeFi
If your company is a financial entity under DORA and holds a position in a DeFi protocol, that protocol is a technology dependency your business relies on — as real as AWS, your market data provider or your custody platform. The question is how it gets into your ICT third-party risk register, and DORA doesn't say.
The Digital Operational Resilience Act (DORA), which has applied to EU financial entities since 17 January 2025, requires under Article 28(3) a register of information on all contractual arrangements for ICT services provided by ICT third-party service providers. The purpose is clear: regulators want to know what technology dependencies a financial entity has, who controls those dependencies, and what happens if they fail.
For traditional ICT providers, filling this register is straightforward. AWS has a legal entity, a contract, an SLA, a notification process for service changes, and a defined exit procedure. Your market data provider has the same. There's a counterparty. There's recourse. There's a relationship.
A DeFi protocol has none of this.
The problem: DeFi protocols don't fit vendor register formats
When a compliance officer tries to put a Solana lending protocol into a standard ICT dependency register, they immediately run into structural problems that existing register formats weren't designed for.
No contract. There's no agreement between your company and the protocol. You interact with smart contracts through on-chain transactions. The "terms of service" — if they exist — are usually a website disclaimer, not a binding service agreement. And the register is built around contractual arrangements — a protocol you use without one has no obvious line in it.
No counterparty. Who is the protocol? The founding team? The DAO? The token holders? The multisig signers? There may be a legal entity behind the protocol — or there may not. Even when there is, the legal entity may not control the protocol's code.
No SLA. There's no guaranteed uptime, no performance commitment, no remediation process. The protocol works until it doesn't.
No notification of changes. Traditional ICT providers notify you when their service changes. DeFi protocols can change through governance votes, code upgrades, oracle reconfigurations, and parameter adjustments — none of which generate a notification to position holders.
No exit procedure. Your exit plan is "withdraw your position" — assuming the protocol's withdrawal function works, isn't paused, and liquidity is available.
A register entry that says "Solana Protocol X" captures none of this. It's a name that tells the regulator nothing about the actual dependency.
What the register actually needs
The purpose of the ICT dependency register isn't to list names. It's to document: what are you depending on, who controls it, and what's your exposure if it changes?
For a DeFi protocol, answering those questions requires three inputs that the protocol name alone doesn't provide:
1. Who controls the upgrade authority
This is the most direct dependency. The upgrade authority determines who can change the smart contract code your position relies on. On Solana, every program has an upgrade authority — a specific address that can deploy new versions of the code.
For your register, you need to know:
- Is the upgrade authority a single key, a multisig, or has it been revoked?
- If it's a multisig, what's the threshold (e.g., 3/5) and who are the signers?
- Are the signers independent — are they from different organizations?
- Has the upgrade authority changed since you entered your position?
This information is on-chain and verifiable. It tells your regulator exactly who can change the technology you depend on.
2. What oracle dependencies exist
Oracles feed external data — primarily prices — into the protocol. A lending protocol's liquidation engine, interest rate calculations, and risk parameters all depend on oracle data. If the oracle feed is manipulated, paused, or configured differently, the protocol behaves differently — even without any code change.
For your register:
- Which oracle network does the protocol use? (Pyth, Switchboard, proprietary)
- Who operates the oracle? Is it independent from the protocol team?
- Can the oracle configuration be changed through governance?
- Is there a fallback oracle, and who controls the fallback?
3. How few signatures can change the code — the floor
This is the synthesis: given the upgrade authority structure, the oracle dependencies, and the governance concentration, what is the fewest signatures that could change the code under your position — and do any of those signers share an owner? The count comes from the chain; shared ownership, where you can establish it, only lowers it.
This number — the floor — is the single most informative metric for a register entry. It tells the regulator, in one figure, how concentrated the structural dependency is.
A practical register entry format
Here's what a DeFi protocol entry in an ICT dependency register could look like, compared to a traditional vendor entry:
Traditional vendor entry:
- Service: AWS (Amazon Web Services)
- Legal entity: Amazon Web Services, Inc.
- Contract ref: MSA-2024-0847
- SLA: 99.99% availability
- Notification process: 90-day notice for material changes
- Exit plan: Data export via S3, 30-day transition window
- Last review: Q2 2026
DeFi protocol entry:
- Protocol: Solana Lending Protocol X
- Smart contract: [program address]
- Floor: 2
- Upgrade authority: 4/7 multisig, 3 verified independent signers
- Oracle: Pyth Network (independent)
- Governance: Token vote, 48h timelock, largest holder: 18%; the two largest holders together exceed the passing threshold
- Last structural change: October 12, 2026 (signer rotation)
- Exit mechanism: On-chain withdrawal (dependent on protocol liquidity)
- Monitoring: Continuous (alerts on authority, signer, oracle and governance changes)
- Last review: Continuous — last floor change: N/A
The second entry gives the regulator something actionable. They can see the control structure, the dependencies, and how recently the structure changed. The floor number — 2, set by governance as the weakest link — is immediately comparable: is this dependency concentrated or distributed?
The regulatory trajectory
The regulatory picture is becoming clearer:
DORA Article 28 requires financial entities to manage ICT third-party risk and to keep a register of their contractual arrangements for ICT services. It doesn't exempt DeFi — but it doesn't address it either. If your business depends on a smart contract for a financial function, that is an ICT dependency whether or not there is a contract to register; how to document it is left to you.
The EBA's MiCA review response (24 September 2026) goes further. The European Banking Authority recommended that the Commission consider regulating crypto-asset lending, including where crypto-asset service providers give clients access to DeFi lending protocols — and, among the safeguards, floated certifying those protocols for cyber resilience.
The MiCA review consultation (open from May to 30 September 2026) asked whether DeFi, staking and lending should be brought within a broader EU regime. The Commission's report on the review is due by 30 June 2027.
The direction is clear: DeFi protocols used by regulated entities will need to be assessed, documented, and monitored like any other ICT dependency. The question isn't whether this will be required, but what format the assessment will take.
Why "audited" isn't a register entry
Some compliance teams attempt to satisfy the register requirement by listing the protocol name and its audit status: "Protocol X — audited by Firm Y, Q2 2026."
This fails the register's purpose for three reasons:
1. The audit is a point-in-time assessment. The register needs to reflect the current state of the dependency, not a historical code review. The code may have changed since the audit. The control structure almost certainly has.
2. The audit doesn't assess the dependency structure. Audits verify code correctness — they don't verify who controls the code, how governance is distributed, or what oracle dependencies exist. These are the structural facts the register is designed to capture.
3. The audit doesn't measure change. DORA requires ongoing monitoring of ICT dependencies, not just initial assessment. An audit date tells you when the code was reviewed. It doesn't tell you whether the control structure has changed since then.
A register entry with a floor number, the control structure details, and the date of the last structural change gives the regulator what they actually need: a current view of the dependency and how it's changing.
Getting started: from existing positions to register entries
If your organization holds DeFi positions and needs to build or update its ICT dependency register, here's a practical starting point:
1. Inventory your DeFi exposures. List every protocol your company interacts with, including protocols used indirectly (e.g., a yield aggregator that deploys to underlying lending protocols).
2. Identify the structural dependencies for each. For each protocol: who controls the upgrade authority? What oracle does it use? How is governance distributed? This information is on-chain and verifiable.
3. Calculate the floor. For each protocol, determine the fewest signatures across all three dimensions, then lower it wherever signers turn out to share an owner. This gives you a comparable metric across your portfolio.
4. Document the current state. Create register entries that capture the control structure, the floor, and the date of the last structural change.
5. Establish monitoring. Set up a process — automated or periodic — to track structural changes: signer rotations, governance concentration shifts, oracle reconfigurations, and code upgrades.
The goal isn't perfection on day one. It's having a register that reflects structural reality rather than protocol marketing — and a process for keeping it current.
The register format the regulator needs doesn't exist yet. Build it now.
DORA is in force. The MiCA review has DeFi explicitly in scope. The EBA has recommended regulating access to DeFi lending, with protocol certification on the table. The regulatory frameworks for DeFi dependency management are being written now.
Organizations that build their DeFi dependency registers today — with structural metrics like floor rather than labels like "audited" — will be ahead when the specific requirements crystallize. They'll have the data, the methodology, and the documentation already in place.
The register that says "Protocol X — floor 2, oracle: Pyth, last structural change: 3 days ago" is ready for whatever format the regulation specifies. The register that says "Protocol X — audited Q2 2026" will need to be rebuilt from scratch.