A recap of the QualitaX webinar featuring CoinChange and the Enterprise Ethereum Alliance
Decentralised finance has matured considerably since its early days of anonymous teams, unaudited contracts, and spectacular collapses. But the risks have not disappeared — they have become more sophisticated, and the consequences of getting risk assessment wrong are now larger as institutional capital enters the space. In a recent QualitaX webinar, Jerome Ostorero, Director of Research and Risk at Coinchange Financials, and Charles Nevile, Technical Programs Director at the Enterprise Ethereum Alliance (EEA), joined us to discuss how DeFi risk frameworks are being built and standardised — drawing on the EEA’s newly published DeFi Risk Assessment Guidelines which has been developed over two and a half years with contribution from EY, CoinChange, insurance firms, security companies, and DeFi protocol builders.
Why DeFi Risk Assessment Is Different
The starting point for both speakers was a deceptively simple observation: in DeFi, the counterparty is often a piece of software. When you deploy assets into a DeFi protocol, you are not relying on the creditworthiness of a bank or the governance of a regulated financial institution — you are relying on the correctness of smart contract code, the integrity of the people who control that code, the accuracy of the data feeds that inform it, and the liquidity conditions in which it operates.
This changes the risk calculus in several important ways. Traditional financial risk assessment has well-established frameworks for counterparty credit risk, market risk, and operational risk. DeFi inherits all of those, but adds a layer of software-specific risks — smart contract vulnerabilities, oracle manipulation, bridge exploits, and governance attacks — that have no direct equivalent in traditional finance and for which standardised assessment methodologies are only now being developed.
The EEA’s DeFi Risk Assessment Guidelines are designed to fill that gap: providing a structured, defensible framework that accounting firms, asset managers, and financial institutions can use to assess how DeFi protocols should be treated on a balance sheet, what due diligence is required before deploying capital, and what mitigation strategies are available.
The EEA Guidelines: Origins and Structure
Charles traced the origins of the guidelines to EY, who raised the problem in the EEA’s DeFi interest group roughly two and a half years ago. As an accounting firm with clients holding DeFi assets on their balance sheets, EY needed clarity: what are the recognised risks, how should they be assessed, and what are the defensible best practices for compliance with accounting standards and regulatory requirements? In the absence of clear regulatory guidance — which has not yet arrived in most jurisdictions — an industry-developed standard, produced by a broad coalition of practitioners, provides the next best thing: a documented, peer-reviewed baseline that represents what the industry knows and agrees on.
The working group that developed the guidelines includes over a dozen organisations: EY, CoinChange, insurance providers, security firms, DeFi protocol developers, and protocol assessment specialists. The document was in review draft at the time of the webinar, with the review period open until April 15th. A revised version incorporating feedback will follow, with a Version 1 release thereafter. As Charles was clear to emphasise, this is a living document — the field is evolving too rapidly for any version to be final.
The guidelines are structured around four substantive sections:
DeFi basics: An introduction to key concepts — stablecoins, wallets, liquidity pools, governance mechanisms — for readers who need the foundational vocabulary before engaging with the risk taxonomy.
Risk taxonomy: A structured catalogue of the risks present in DeFi protocols. Not all risks apply to every protocol, and the guidelines describe what each risk is, how it manifests, and the conditions under which it is most relevant.
Key information for assessment: Two categories of information are identified. The first is structural — how is the protocol set up, what are its parameters, and what governance mechanisms exist? The second is operational — what has actually happened in this protocol’s history, what security incidents have occurred, how has the team responded, and what does real-time on-chain data show?
Mitigation strategies: Concrete actions that can reduce exposure to specific risks. As Charles noted, one of the planned refinements to the next version is to decouple the mitigation section from the risk taxonomy — many mitigations address multiple risks, and tying them one-to-one is unnecessarily constraining.
CoinChange’s Internal Risk Framework: Four Pillars
Jerome walked through CoinChange’s proprietary risk framework, which predates the EEA guidelines but was refined in the process of contributing to them. CoinChange’s platform deploys user assets into DeFi protocols as part of its earn product, which means every protocol it interacts with is effectively a counterparty — and must be assessed accordingly.
The framework organises protocol risk under four pillars:
1. Smart Contract Risk
The most technically specific pillar covers the security of the code itself. Key data points include whether the protocol has been previously exploited, whether any exploits were patched, whether the codebase is a fork of an existing protocol (and if so, what changes were made), the maturity of the smart contracts, the activity level of the GitHub repository, and the quality and recency of independent security audits.
This pillar typically receives the highest weight in CoinChange’s scoring. The empirical basis for this is straightforward: the majority of funds lost in DeFi have been lost through smart contract exploits. Code security is the foundation on which everything else depends.
2. Operational Risk
This pillar covers the human and organisational layer behind the protocol, subdivided into three areas:
The team: Who are they, what is their track record, are they publicly identified or anonymous, and who controls the protocol’s core infrastructure? Anonymous founding teams are treated as a significant risk flag — not because anonymity is inherently problematic, but because accountability becomes difficult when things go wrong.
Counterparties: What other protocols, oracles, and bridges does this protocol depend on? DeFi composability is one of the ecosystem’s strengths, but it also means that a protocol’s risk profile includes the risk of every dependency in its stack. Mapping this dependency graph is essential for understanding true exposure.
Tokenomics and business model: What are the token incentives that drive user behaviour? Which business models have historically proved sustainable, and which have not? Understanding how a protocol’s economics actually work — and whether they are likely to work over time — is as important as understanding the code.
3. Financial and Liquidity Risk
This pillar covers the practical financial parameters of the protocol: total value locked (TVL), number of users, trading volumes, pool liquidity, token distribution, inflation schedule, and secondary market liquidity for the protocol’s own token. CoinChange uses specific internal thresholds and ratios to score these metrics.
Jerome was direct about why this pillar receives a lower weight than smart contract and decentralisation risk in the scoring model: liquidity and financial risks, while real, are largely manageable through automated thresholds, rebalancing mechanisms, and withdrawal limits. The infrastructure risks — bad code, compromised governance — are harder to manage after the fact. You address the existential risks first.
4. Decentralisation Risk
This pillar assesses who controls the protocol and under what conditions that control can be exercised. The spectrum runs from externally owned accounts (EOAs) — essentially a single MetaMask wallet with admin keys, treated as a significant red flag — to DAO governance with time locks, where any parameter change requires a community vote and a waiting period before execution. The more distributed and time-delayed the control, the more difficult it is for any single actor to drain the protocol overnight.
Charles framed this in the starkest terms: rug pulls — where the people nominally managing a protocol withdraw all deposited funds — are one of the most commonly realised risks in DeFi. Decentralisation risk assessment is fundamentally an assessment of whether that scenario is possible, how easy it would be to execute, and what protections exist against it.
The Due Diligence Process in Practice
Jerome described the practical reality of running a protocol assessment. For a well-documented protocol with transparent code and clear governance, the process takes one to two days. For more complex protocols — or those that do not clearly disclose their architecture, team, or governance — the process can take four or more days, requiring manual review of GitHub repositories, smart contract comments, and community forums. Unsurprisingly, protocols that require more time to assess also tend to score lower when the assessment is complete.
The process is largely manual today. Automation is being developed, but Jerome noted the challenge: a risk assessment requires a holistic view of the protocol that is difficult to assemble from structured data feeds alone. Qualitative judgement — is this team experienced and credible? Does this business model make economic sense? — cannot yet be automated reliably.
Protocols that pass the assessment are scored and fed into a strategy factory that provides fund allocation guidelines for the asset management team. Protocols that do not pass are retained in a database and reassessed periodically, since protocols can improve over time as code is audited, governance is decentralised, or teams become publicly identified.
Systemic Risk, Institutional Adoption, and What Comes Next
An audience question raised the question of priority: as institutional capital enters DeFi and the market matures, will financial and liquidity risk eventually become the primary concern, displacing the current emphasis on technical security?
Both Jerome and Charles agreed that the ordering reflects the current state of the market, not a permanent hierarchy. Smart contract and governance risks receive the highest weight today because empirically that is where the losses are occurring. As the leading protocols mature, undergo repeated audits, and demonstrate sustained operational stability, the technical risk baseline will improve. At that point, financial risk — market risk, liquidity risk, counterparty risk in the traditional sense — will become the dominant concern, as it is in traditional finance. The trajectory is towards a DeFi risk landscape that looks increasingly like a traditional financial risk landscape, with a layer of software-specific risks that are understood and managed rather than existential.
The regulatory dimension is also evolving. Major tier-one protocols are beginning to add KYC layers for institutional participants. MiCA in Europe will bring DeFi progressively into the regulatory perimeter, though the timeline for DeFi-specific regulation remains longer than two years by most estimates. As regulation arrives, the compliance and legal risk section of the EEA guidelines will become increasingly important — and the guidelines themselves will need to evolve to reflect new requirements.
Charles flagged one specific emerging risk that the working group is beginning to address: the use of machine learning for real-time protocol monitoring. ML tools offer genuine capability for high-speed analysis of whether a protocol is showing signs of stress. They also carry their own risks — bias from training data, false confidence from models that have not encountered the specific failure mode occurring in real time, and the general problem that ML systems can only build on the input they have received. How to characterise and mitigate ML-specific risks in a DeFi context is a live discussion within the working group.
How the Guidelines Will Evolve
Charles described the process for maintaining and updating the guidelines as broadly analogous to how ISO standards or major open-source projects are managed. The working group meets roughly fortnightly. Issues are raised, proposals are submitted, and changes are adopted by consensus. Major versions are released on a timing basis — when the accumulated changes justify a new publication rather than waiting indefinitely for a theoretically perfect document.
The working group is open to new members. EEA membership fees range from $3,000 to $50,000 per year depending on organisation size, and participation in specific working groups is available to all members.
Key Takeaways
DeFi risk is structurally different from traditional financial risk: the counterparty is often software, and software-specific risks — smart contract exploits, oracle manipulation, bridge vulnerabilities, governance attacks — sit alongside the conventional financial risks of liquidity, market exposure, and counterparty credit
The EEA DeFi Risk Assessment Guidelines provide the first industry-developed, peer-reviewed framework for assessing and mitigating DeFi protocol risks — developed by EY, CoinChange, insurance firms, security companies, and protocol builders over two and a half years
CoinChange’s four-pillar framework — smart contract risk, operational risk, financial and liquidity risk, and decentralisation risk — provides a practical template that any organisation deploying capital into DeFi protocols can adapt
Smart contract and decentralisation risks receive the highest weight in current frameworks because they represent the highest empirical frequency of actual losses — but this ordering reflects where the market is today, not a permanent hierarchy
Decentralisation risk is primarily a rug pull assessment: who controls the protocol, under what conditions, and what protections prevent malicious or accidental fund loss?
Liquidity and financial risks are manageable through automation: thresholds, rebalancing algorithms, and withdrawal limits address most scenarios — the existential risks must be addressed first
Machine learning for real-time monitoring is a near-term development that introduces its own risk category (model bias, false confidence) that the working group is beginning to address
The guidelines are living documents: the EEA working group meets fortnightly and updates the framework as the market evolves — participation is open to all EEA members
The EEA DeFi Risk Assessment Guidelines are available on the Enterprise Ethereum Alliance website. Organisations interested in contributing to the working group or joining the EEA are encouraged to contact the EEA directly.