Embedded supervision of decentralized finance PDF Free Download
1 / 125
/125
100%
Page 1 of 125
Embedded supervision of
decentralized finance
Final Report
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 3 of 125
Manuscript completed in June 2024
Revised edition
LEGAL NOTICE
This document has been prepared for the European Commission however it reflects the views only of the authors, and the
European Commission is not liable for any consequence stemming from the reuse of this publication. More information on the
European Union is available on the Internet (http://www.europa.eu).
PDF
ISBN 978-92-68-24313-8
doi: 10.2874/1217286
EV-01-25-000-EN-N
Luxembourg: Publications Office of the European Union, 2025
© European Union, 2025
The reuse policy of European Commission documents is implemented by the Commission Decision 2011/833/EU of 12
December 2011 on the reuse of Commission documents (OJ L 330, 14.12.2011, p. 39). Except otherwise noted, the reuse of
this document is authorised under a Creative Commons Attribution 4.0 International (CC-BY 4.0) licence
(https://creativecommons.org/licenses/by/4.0/). This means that reuse is allowed provided appropriate credit is given and any
changes are indicated.
For any use or reproduction of photos or other material that is not under the copyright of the European Union (*), permission must be
sought directly from the copyright holders.
Prepared by IBM Promontory, written by Nicolas Vasse, Vincent Fauquet, Aiad Outemsaa, Antoine Arnould and Nasreddine
Grihma.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 4 of 125
Table of Contents
1. Abstract .......................................................................................................................... 5
2. Executive summary ....................................................................................................... 6
3. Decentralized finance landscape ................................................................................. 8
3.1. EMERGENCE OF DECENTRALIZED FINANCE ......................................................................... 8
3.2. RISKS .............................................................................................................................. 8
3.3. LEDGER .......................................................................................................................... 9
4. Pilot project objectives ............................................................................................... 10
5. Phase 1: Selection of uses cases: protocols and benchmarks ............................... 11
5.1. PROTOCOLS SELECTION .................................................................................................. 11
5.2. BENCHMARKS SELECTION AND ADAPTATION ..................................................................... 13
5.3. DEFINITION OF EQUIVALENT TRANSACTION ....................................................................... 17
5.4. DATA MAPPING AND ANALYSIS APPROACH ......................................................................... 19
6. Phase 2: software development ................................................................................. 20
6.1. BUILD AN APPLICATION TO COLLECT DATA FROM THE LEDGER ............................................ 20
6.2. TECHNICAL DELIVERABLES ............................................................................................. 24
6.3. ESTIMATES OF THE TECHNICAL REQUIREMENTS TO RUN THE FULL SOLUTION ...................... 25
7. Phase 3: data collection and analysis ....................................................................... 27
7.1. DEX USE CASE .............................................................................................................. 27
7.2. LENDING USE CASE ........................................................................................................ 30
7.3. INSURANCE USE CASE .................................................................................................... 33
7.4. COMBINATION AND AGGREGATION USE CASE ................................................................... 35
8. Data analysis results ................................................................................................... 38
8.1. QUALITATIVE ANALYSIS OF THE RESULTS .......................................................................... 38
8.2. OTHER TAKEAWAYS ........................................................................................................ 40
8.3. ADDITIONAL DATA TO BE CONSIDERED FOR SUPERVISION .................................................. 42
9. Phase 4: conclusions .................................................................................................. 45
9.1. CONCLUSION PER SUPERVISORY OBJECTIVE ................................................................... 45
9.2. OPTIONS FOR POLICYMAKERS ........................................................................................ 47
10. Appendices .............................................................................................................. 50
10.1. ANNEXES OF SECTION 1: DEFI FUNCTIONING .................................................................. 50
10.2. ANNEXES OF SECTION 2: PROTOCOLS ............................................................................ 58
10.3. ANNEXES OF SECTION 3: BENCHMARKS .......................................................................... 81
10.4. ANNEXES OF SECTION 4: COMPOSITE REPOSITORY SETTING ............................................ 92
10.5. ANNEXES OF SECTION 8 ............................................................................................... 101
11. Glossary .................................................................................................................. 113
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 5 of 125
1. Abstract
This report presents the outcome of the study undertaken by IBM Promontory for the European
Commission on embedding supervision in the decentralized finance (DeFi).
The project comprised four distinct phases: identifying use cases and protocols to assess,
defining elements of comparison (benchmarks) to supervision in traditional finance (TradFi),
developing a software application to collect data from the ledger, and analysing the collected
data to assess the potential of embedded supervision.
After analysing four use cases and eight protocols, the report concluded that ledger
technologies offer real-time access to core transaction information. IBM Promontory also
identified that there is data available for supervision of DeFi activity which would allow
development of tools supporting regulatory objectives.
However, available data is limited compared to today’s data on traditional financial markets,
banking and insurance activities, due to the difference of maturity between TradFi and DeFi.
Significant challenges were faced when assessing the potential of embedded supervision in
the DeFi ecosystem, such as the lack of standards, the need for expertise across DeFi and
TradFi, and the pseudonymization of wallets. A risk-based approach targeting the largest
protocols and liquidity pools and the collection of reference data are crucial in overcoming
these obstacles.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 6 of 125
2. Executive Summary
IBM Promontory was engaged by the European Commission to assess the feasibility and
potential of embedded supervision within the DeFi landscape, with a focus on the
associated challenges and opportunities. The project was structured into four distinct
phases: identifying relevant protocols and use cases, defining appropriate benchmarks,
developing software to collect data from the ledger, and analysing the collected data to
evaluate the potential of embedded supervision.
In the initial phase, IBM Promontory identified eight protocols encompassing four key use
cases: decentralized exchange (DEX), lending, insurance, and DeFi applications that
integrate or aggregate multiple protocols. For each use case, corresponding benchmarks
were established, such as reporting regimes under specific regulations in TradFi, to facilitate
comparisons between the expected supervisory data and the data collected during the
project.
In the second phase, IBM Promontory developed a software application to retrieve and
analyze data from the Ethereum ledger. The development process encountered significant
challenges, including as regards ledger synchronization and smart contract analysis. Full
on-premises ledger synchronization was complex due to the Ethereum ledger's size,
necessitating high-performance computing resources and substantial storage capacity.
Additionally, analyzing smart contracts required a detailed examination of each contract’s
underlying code, rules, conditions, and triggers.
IBM Promontory successfully developed a software application comprising two main
services: a monitoring service to capture transactions from the ledger, and a Data Collection
& Processing (DCP) service to enhance and store this data in a database. The data analysis
confirmed that public distributed ledger technologies provide real-time access to core
transaction information, thereby enabling the development of surveillance tools and data
collection mechanisms to meet supervision requirements. These include the detection of
potential market manipulation and the macro-supervision of liquidity pools and related
market stability considerations.
IBM Promontory posits that monitoring liquidity pools from a macro-supervision perspective
(assessing assets versus liabilities) can yield valuable insights into the risks and exposures
associated with the largest liquidity pools. This provides a foundation for macro-surveillance
initiatives.
Despite the potential advantages of embedded supervision, several challenges must be
addressed to ensure its effective implementation within the DeFi ecosystem:
1. Lack of standardization: the heterogeneous nature of the DeFi ecosystem
necessitates adaptable data-monitoring tools for each protocol and smart contract,
which can be resource-intensive.
2. Technological and supervisory expertise: effective supervision requires a
combination of technological know-how and expertise in both DeFi and TradFi to
interpret ledger data and smart contracts.
3. Data enrichment: sole reliance on on-chain data is insufficient for comprehensive
supervision. Regulators need to supplement on-chain data with manually collected
off-chain data to gain a holistic understanding of the protocols, although this process
is costly and complex.
4. Pseudonymization of wallets: the pseudonymization of wallets remains a significant
barrier, complicating the identification and assessment of actors behind
transactions.
To address those issues, IBM Promontory proposes several options for consideration,
amongst which:
• Adopting a risk-based approach: focus initially on larger protocols and liquidity pools,
directing efforts towards those with the highest potential impact.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 7 of 125
• Encouraging cooperation: foster dialogue between experts in both DeFi and TradFi
domains to enhance mutual understanding and shared objectives. Such
collaborative relationships promote innovation and provide a foundation for informed
decision-making in supervisory matters.
• Promoting reference data: advocate for having additional standardised reference
data written on the ledger to get better understanding of transactions and limit
collection of off-chain data.
• As a next step, IBM Promontory proposes building on this initial initiative by
developing a Proof of Concept. This would have to involve not only a technical
provider but also actual supervisors who would analyze and monitor the data over
several months. Additionally, this initiative could be enhanced through partnerships
with technical providers and exploring further standardization possibilities.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 8 of 125
3. Decentralized Finance landscape
3.1. Emergence of Decentralized Finance
The theory of distributed ledger technology (DLT) and blockchain emerged at the beginning
of the 21st century, with the first implementation of bitcoin in 2009. However, blockchain
technology began to be widely explored only in 2014 with the development of Ethereum, which
revealed its potential for various transactions.
The creation of the Ethereum blockchain introduced smart contracts, which are the foundation
of DeFi. Initially, smart contracts were designed to facilitate simple asset transactions. Over
the past few years, more advanced smart contracts have been developed, creating an entire
DeFi ecosystem that supports activities such as lending, derivatives, trading, and settlement.
A key feature of these smart contracts is that they are open to all users on the Ethereum
platform. This means that a company or programmer can develop a smart contract (a piece of
code) that anyone can execute, independent of the developer, unless specific governance
restrictions are in place. This concept is known as “composability,” meaning smart contracts
can be used as building blocks for more complex applications. For example, if a smart contract
performs a specific function (such as issuing a token or executing a trade), other developers
can create new smart contracts that interact with it, using its functionality as part of a larger
process.
DeFi refers to financial activities that operate on a permissionless blockchain, often Ethereum.
It represents a shift from traditional, centralized financial systems to peer-to-peer finance
enabled by DLT. The key metric for measuring the growth of this space is the total value locked
(TVL), which represents the liquidity in smart contracts. DeFi has evolved significantly since
its early days in 2017. Initially, TVL was minimal, as the sector was experimental and limited
to a few pioneering platforms. By 2020, DeFi began to gain widespread attention and became
a significant force in the cryptocurrency world.
In 2021, DeFi experienced exponential growth, driven by a booming cryptocurrency market
and increased recognition and adoption of DeFi protocols. The sector expanded rapidly.
The evolution of DeFi's TVL reflects the sector's maturity and growing diversity in its products
and services, while also highlighting the inherent volatility and risks of the broader
cryptocurrency market. DeFi includes thousands of cryptographic asset protocols, with
investments exceeding $100 billion by April 2024, excluding bitcoin. Ethereum has become a
crucial settlement layer due to its robust smart contract functionality and large developer
community.
More information about the Ethereum ecosystem is available in Annex 10.1.
3.2. Risks
As the DeFi ecosystem is based on new technologies, it introduces a spectrum of new risks.
This raises a critical question: how can supervisory bodies possess the necessary data and
tools to effectively oversee DeFi markets? Given the highly dynamic nature of these markets,
it is imperative for supervisors and regulators to access reliable data for informed decision-
making. Moreover, the evolving maturity of these markets necessitates exploring diverse
methodologies for data collection to ensure comprehensive supervision.
The sharp increase in DeFi transactions over the past few years presents several major
challenges from a supervisory perspective:
• Increased usage and complexity: the widespread adoption of DeFi products and smart
contracts, evidenced by the significant rise in TVL, raises concerns related to investor
protection, market integrity, and financial stability.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 9 of 125
• Decentralized nature: DeFi operates on peer-to-peer transactions and is decentralized
by default. In contrast, TradFi supervision relies on monitoring financial infrastructures
and intermediaries. This fundamental difference makes it challenging to apply existing
supervisory frameworks to DeFi.
DeFi protocols can also be targets for hacks. This issue is further explained in the Chainalysis
Crypto Crime Report
1
(relevant extracts are available in Annex 10.1 c)).
Regulators have been studying DeFi extensively, and several reports have been published in
2022 and 2023 by various public institutions, including the OECD
2
(Organisation for Economic
Co-operation and Development), IOSCO
3
(International Organization of Securities
Commissions), ACPR
4
(Autorité de contrôle prudentiel et de résolution), FSB
5
(Financial
Stability Board) or ESMA
6
(European Securities and Markets Authority).
The European MiCA regulation aims to strengthen the supervisory system for intermediaries
facilitating access to crypto-asset services. However, it currently excludes decentralized
services from its scope.
3.3. Ledger
At the heart of DeFi is the blockchain ledger, a decentralized and distributed database that
records all transactions across a network of computers. This ledger is immutable, meaning
that once a transaction is recorded, it cannot be altered. This aims to ensure the integrity and
transparency of financial activities within DeFi. All transactions are publicly accessible,
allowing anyone to view the details of transactions on the blockchain.
The critical function of the distributed, public ledger, or blockchain, in DeFi opens the potential
for regulators and supervisors to access, evaluate, and monitor all completed transactions.
In TradFi, supervisors rely on reports and data provided by reporting entities, such as banks
and financial institutions, which act as intermediaries and record keepers. However, DeFi has
a different structure. All transactions are recorded on the ledger, meaning that regulators and
supervisory bodies could potentially access and monitor financial activities in real-time without
relying on intermediaries.
Moreover, the immutable nature of blockchain transactions makes this data reliable and
tamper-proof, arguably providing a more accurate and transparent view of financial activities.
In contrast, off-chain data pertains to information not stored on the blockchain. This includes
external market data, user information, and other complementary metadata. Extracted from
the websites of key DeFi players and protocol platforms, this data is not standardized and
does not come with any assurance of quality and accuracy.
The off-chain data collected during this project includes static public data, whitepapers, and
official documentation from DeFi protocols, offering a comprehensive view of the operational
and structural aspects of DeFi entities. While highly informative, this data requires thorough
analysis for effective interpretation.
1
The Chainalysis 2023 Crypto Crime Report
2
Why Decentralized Finance (DeFi) Matters and the Policy Implications - OECD
3
FR14/23 Final Report with Policy Recommendations for Decentralized Finance (DeFi) (iosco.org)
4
synthese_consultation_defi_fr.pdf (banque-france.fr)
5
The Financial Stability Risks of Decentralized Finance - Financial Stability Board (fsb.org)
6
ESMA50-2085271018-3349_TRV_Article_Decentralized_Finance_in_the_EU_Developments_and_Risks.pdf (europa.eu)
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 10 of 125
4. Pilot project objectives
Considering the context described above, DG FISMA launched a pilot project named
“Embedded Supervision of Decentralized Finance.”
As described in the invitation to technical specifications from the European Commission, this
pilot project aimed to:
• "Employ the opportunities offered by digital technologies to promote innovative,
secure, and competitive financial services that meet the EU regulatory objectives of
investor protection, market integrity, and financial stability;" and
• "Establish how and what data can be gathered from DeFi protocols on the Ethereum
public blockchain in real time, how this can be used for effective supervision of DeFi
activity and, if not, what critical data may be missing."
Following a call for tender, IBM Promontory was selected as the service provider to run this
project for DG FISMA.
The pilot project involved setting up and operating a full node on the Ethereum blockchain to
collect data from eight protocols providing DeFi services. The objective was to have two
protocols per use case, covering the following four use cases: DEX, lending, insurance, and
applications that combine and/or aggregate various protocols.
The project was executed in four phases.
Phase 1: Selection of Protocols and Benchmarks
During the first phase, two protocols were selected for each of the four use cases. In parallel,
an appropriate benchmark for specific supervisory data sets from the relevant EU financial
sector legislation was identified for the four DeFi use cases.
Phase 2: Development of Automated Data Collection Application
In the second phase, a specific application for automated supervisory data collection was
developed. This application was deployed on the main Ethereum blockchain and tested to
perform automated supervisory data collection. Additionally, information was collected from
the web interfaces of the relevant DeFi protocols.
Phase 3: Data Analysis and Benchmarking
The third phase involved analyzing the collected data and benchmarking them against the
appropriate supervisory data sets. This assessment covered the availability, quality, and
comparability of specific types of data across protocols and with traditional supervisory data.
Phase 4: Conclusions and Recommendations
The fourth phase consisted of drawing relevant conclusions on data availability for the
supervision of DeFi activity on the Ethereum public blockchain. This included confirming the
methodology to collect these data in an automated manner in real-time and evaluating whether
the data collected from the Ethereum blockchain for each use case are sufficient to meet the
EU financial regulatory objectives in DeFi.
This document, therefore, elaborates on each of the four phases of the project.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 11 of 125
5. Phase 1: Selection of uses cases: Protocols and
benchmarks
The first phase of the project consisted of:
1. Selecting two adequate and relevant protocols for each of the four use cases; and
2. Identifying the relevant supervisory data sets from regulatory reporting requirements –
used in TradFi - to consider as benchmarks to assess the data that will be collected
from the eight selected protocol.
5.1. Protocols selection
The initial step in this phase involved identifying a long list of candidate protocols for selection.
IBM Promontory began by examining DeFi information flows, focusing on key actors collecting
data on DeFi protocols, to define this long list and facilitate the selection process.
For each of the four use cases, IBM Promontory adopted the following approach to select two
relevant protocols:
1. Conducting a study of the most traded and/or most relevant protocols for each use
case.
2. Identifying selection criteria.
3. Defining a selection methodology for the first three use cases: DEX, lending, and
insurance.
4. Establishing a specific selection approach for the fourth use case:
aggregation/combination of protocols.
The pre-selection process involved identifying four candidate protocols for each of the first
three use cases. The initial criterion was TVL, representing the amount locked in each
protocol, calculated in US dollars.
IBM Promontory then conducted an analysis to gather information about each pre-selected
protocol. The protocol with the highest TVL for each use case was selected as the first
protocol, as TVL serves as the best proxy for the usage and popularity of a protocol.
For the second protocol, a mix of qualitative and quantitative criteria was applied:
• Volume criterion: specific metrics were used to assess this criterion:
o For DEX, annualized transaction volume.
o For Lending, annualized revenue.
o For Insurance, market capitalization.
• Ecosystem dynamism criterion: this relied on four metrics and a qualitative criterion:
o Number of users.
o Twitter community size.
o Discord community size.
o GitHub community size.
• Presence of feeds from oracles (binary criterion: Yes/No).
• Similarity with TradFi instruments or services: this qualitative criterion acted as a proxy
for potential development.
• Proximity to use case: this criterion assessed the protocol's closeness to the use case,
ensuring the selection aligned with the objective.
The aim was to select one popular protocol based on TVL and another protocol meaningful
for the assessment based on additional criteria. This approach ensured a comprehensive
assessment by combining popularity and relevance to TradFi.
IBM Promontory evaluated each criterion, ranked protocols for each use case, and finalized
the selection.
For the fourth use case, involving DeFi applications that combine and aggregate various
protocols, the approach was to select one aggregation protocol and one combination protocol.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 12 of 125
The aggregation protocol aimed to replicate activities similar to TradFi, such as a broker dealer
aggregating smart contracts across different DEX platforms.
In consultation with the European Supervisory Authorities (ESAs) — European Securities and
Markets Authority (ESMA), European Banking Authority (EBA), and European Insurance and
Occupational Pensions Authority (EIOPA) — and DG FISMA, IBM Promontory compiled a list
of 11 candidate protocols. The protocol that best combined multiple use cases, garnered
public interest, and had a significant impact on the DeFi landscape was selected.
Below is the final list of protocols for the
DeFi Pilot project: Use Case
Protocols
DEXs
Curve Fi
Uniswap
Lending
Aave
Compound Fi
Insurance
Nexus Mutual
Unslashed
Aggregation and Combination
1inch
Maker Dao
The following tables present a brief description of each protocol:
DEXS PROTOCOLS
SHORT DESCRIPTION
CURVE FI
Curve is a DEX protocol designed for efficient and low-slippage
trading of stablecoins. It focuses on providing low-risk and low-cost
trading by utilizing specialized bonding curves and liquidity pools
with low volatility.
UNISWAP
Uniswap is a DEX protocol built on the Ethereum blockchain. It
enables users to trade ERC-20 tokens directly from their wallets,
utilizing automated liquidity pools instead of traditional order books.
LENDING PROTOCOLS
SHORT DESCRIPTION
AAVE
Aave is a decentralized lending and borrowing protocol on
Ethereum. It enables users to deposit their crypto assets and earn
interest on them or borrow assets by providing collateral. Aave
utilizes smart contracts to automate the lending and borrowing
process.
COMPOUND FI
Compound is a decentralized lending and borrowing protocol that
allows users to lend and borrow various crypto assets. It operates
through algorithmically determined interest rates and utilizes
collateralized loans.
INSURANCE PROTOCOLS
SHORT DESCRIPTION
NEXUS MUTUAL
Nexus Mutual is a decentralized insurance protocol designed to
provide coverage for smart contract risks. Users can purchase
insurance against the failure or vulnerability of specific smart
contracts and receive compensation if a valid claim is made.
UNSLASHED
Unslashed is a decentralized insurance protocol that focuses on
providing coverage for risks in the DeFi space. It allows users to
purchase coverage against smart contract hacks, oracle failures,
and other DeFi-related risks.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 13 of 125
AGGREGATION
/COMBINATION
PROTOCOL
DESCRIPTION
1INCH
1inch is a DEX aggregator that combines multiple liquidity sources
to provide users with the best possible trading rates. It scans various
DEXs and executes trades across multiple platforms to ensure
optimal prices and minimal slippage. 1inch aims to improve liquidity
and reduce the complexity of trading on DEXs. The protocol's
algorithm splits, routes, and deploys orders across different liquidity
sources to achieve better overall rates for users.
MAKERDAO
MakerDAO is a decentralized autonomous organization responsible
for the development and governance of the Maker Protocol. The
protocol enables users to create and manage the stablecoin DAI,
which is collateralized by a variety of crypto assets.
Annex 10.2 presents in detail the methodology used, the resulting assessment according to
each criterion and the detailed description of each assessed protocol.
Challenge 1: Number of smart contracts
At the protocol level, the number of smart contracts can widely vary due to factors such as
updates, versioning, expansion to other networks, and the addition of new features or
services. To give a sense of scale, each selected protocol may have from 10 to 100+ smart
contracts live on Ethereum. For example, Uniswap today contains over 70 smart contracts,
ranging from executing specific transactions to providing information and data to its users
when executed.
As regards its analysis, the use case of a 'simple token exchange' i.e. a regular transaction
on a DEX was actually represented in DeFi by the orchestration of several smart contracts
that needed to be retrieved by Promontory.
To address this challenge, IBM Promontory studied all ERC-20 smart contracts of each
protocol and then focused on assessing the latest versions of those smart contracts that cover
use cases equivalent to TradFi, to make the exercise meaningful (e.g., smart contracts
designed to collect data from the ledger and not executing transactions were not relevant in
the context of this pilot project). As a result, for a protocol like Uniswap, Promontory analyzed
slightly less than ten smart contracts. The same approach was applied to the other protocols.
5.2. Benchmarks selection and adaptation
a) Initial benchmarks selection
For each of the four identified use cases, IBM Promontory undertook a comprehensive
benchmarking process as follows:
1. Identification of potential benchmarks: an examination of relevant legislation was
conducted to compile a list of potential benchmarks tailored to each specific use case.
This involved considering the unique characteristics of DeFi and ensuring
comparability with traditional financial frameworks.
2. Assessment of identified benchmarks: each potential benchmark underwent
evaluation based on predefined assessment criteria. These criteria included the type
of data collected, the presence of structured data models, and the proximity of the
benchmark to the regulatory objectives of the use case. Additionally, benchmarks were
graded and ranked according to their alignment with DeFi's decentralized structure and
the effectiveness of their data collection methods.
3. Engagement with regulatory authorities: IBM Promontory engaged with the three
ESAs through dedicated interviews to solicit their perspectives on the relevance of
various benchmarks. Concrete examples of each use case were presented, and
feedback was gathered to ensure alignment with regulatory standards and objectives.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 14 of 125
4. Final selection of benchmarks: based on the assessment criteria and input from
regulatory authorities, the final selection of benchmarks was determined. This selection
aimed to ensure that each benchmark chosen was well-suited to its respective use
case and could facilitate both micro and macro supervision as needed.
For the DEX, lending, and insurance use cases, benchmarks were evaluated based on the
following criteria:
• Type of data collected: assessing whether data collection methods were granular or
aggregated, with preference given to granular data collection to align with DeFi's
decentralized nature.
• Existence of data models: prioritizing benchmarks with structured data models to
enhance effectiveness for future project phases.
• Presence of structured data: ensuring proper reporting structures were in place for
meaningful benchmarking exercises.
• Proximity to the use case: selecting benchmarks closely aligned with the specific
characteristics and regulatory objectives of each use case.
• Micro and macro supervision: ensuring a balanced selection of benchmarks to
facilitate both granular (micro) and aggregated (macro) supervision where applicable.
For the fourth use case, involving data aggregation, IBM Promontory employed a mapping
approach to align criteria with relevant benchmarks from the preceding three use cases. This
ensured that the benchmarks chosen for the aggregated scenario were comprehensive and
relevant to the combined data context.
Following this approach, the final list of benchmarks was curated to effectively support
regulatory oversight and monitoring within the realm of DeFi.
Use Case
Benchmark
Data Set
DEX
MiFIR/MIFID
RTS 22
RTS 1
AML/TFR
Specific data set extracted from the legislation
Lending
CRR/CRD IV
COREP FINREP
Template Collateral used in derivative transactions,
concentration of funding by counterparty and concentration
of funding by product type.
Guidelines on loans origination and monitoring
Metrics for lending to customers
SFTR
RTS on SFTR Reporting
AML/TFR
Specific data set extracted from the legislation
Insurance
Solvency II
Template on premiums, claims, and expenses by lines of
business.
EMIR
RTS on EMIR Reporting
AML/TFR
Specific data set extracted from the legislation
Annex 10.3 develops in detail the methodology criteria and assessment used to define those
benchmarks.
b) Composite Benchmark Methodology
Once the benchmarks were selected, IBM Promontory consolidated all data into a single
database to facilitate comparisons. This step was necessary because several data points were
redundant across multiple benchmarks, which could affect the accuracy of the comparisons.
These duplicate data points were merged.
Creating this central repository, which integrated all benchmark data sets, enhanced efficiency
by simplifying the review process, aiding in the formation of statistics, and providing a
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 15 of 125
comprehensive audit trail that traces the origin of the data sets and the methodology used for
data review and mapping.
This consolidated repository was further utilized to map each chosen data point to the results
obtained from data collection across the selected protocols for each respective use case.
Following the removal of XML headers, which are technical data elements used in XML to
structure information, the first metric extracted from this new composite benchmark is the
number of data points per benchmark, as shown in the table below:
Use Case
Benchmark
Number of data points
DEX
MiFIR/MIFID
401
All use cases
AML7
110
Insurance
EMIR8
107
Solvency II
462
Lending
CRR/CRD IV
421
SFTR
185
TFR
9
Total
1695
Given the extensive number of data points, IBM Promontory identified the necessity to assess
these data points thematically. For instance, it may happen that, in a single transaction, most
data on instrument identification and buyer/seller information is missing, while the timestamp
and core transaction data (price, quantity) are available.
To address this, IBM Promontory decided to group the data points into thematic blocks. This
approach facilitates the identification of missing data types at a thematic level rather than per
individual data point, considering their large number (over 1500).
The following methodology was implemented:
I. Initial review: each data point underwent an initial review. The names and definitions
of these data points were used as inputs for general remarks, facilitating their initial
aggregation into cohesive data sets.
II. Grouping into refined blocks: data points were then grouped into "Refined Blocks"
as shown in the table below. These refined blocks aimed to cluster homogeneous data
sets within the overarching benchmark categories, inspired by MiFIR RTS 22. For
example, IBM Promontory defined a refined block called "MiFIR Buyer Identification"
from the MiFIR benchmark, consolidating several data points under this objective.
III. Further grouping into blocks: given the number of refined blocks, IBM Promontory
further grouped them into "Blocks," each consisting of several refined blocks.
According to the ESMA guideline, 12 such blocks were delineated. To comprehensively
address all data points of the benchmarks, IBM introduced five additional blocks.
For detailed information on the methodology described above, please refer to Annex 10.4.
In the analysis process, IBM Promontory delineated a total of 17 distinctive blocks, each
accompanied by a succinct description provided in the subsequent table:
7
AML: this data set is applicable for all uses cases. A such, the same data points will be reviewed for each Use Case.
Reminder: the AML data set is based on TRACFIN website declaration, and all the data points are in the Appendix 6.7
Benchmark AML pdf file, as indicated in the appendix 6.4.4 of the Inception Report.
8
EMIR benchmark number of detailed data points is about 19 629 data. IBM Promontory proposed to focus on higher level
data concepts. Based on the appendix 6.9 EMIR Reporting excel file (Appendix 6.4.6 in the Inception Report), only Data
points of grouping level 0 to 5 were selected for review due to high volume of data points. As result, 158 data point were
selected for review among 19 629 data points.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 16 of 125
Blocks
Block 1: Buyer/Seller identification
Block 2: Decision-maker for Buyer/Seller
Block 3 (combination of 1 and 2): Buyer/Seller and decision-maker specific scenarios
Block 4: Investment decision within the firm
Block 5: Execution within the firm
Block 6: Trading date time
Block 7: Venue
Block 8: Short selling flag
Block 9: Waiver, OTC (over the counter) post-trade and commodity derivative indicators
Block 10: Branches
Block 11: Status of transaction reports and corrections
Block 12: Change in notional
Block 13i Core transaction data
Block 14i Financial instrument identification
Block 15i Traditional finance specific data
Block 16i Funding related data
Block 17i Insurance premium and claim
Please note that the blocks numbered with an i (13i to 17i) indicate the blocks created by IBM
Promontory, the other blocks come from ESMA guidelines.
Those blocks served for the data analysis to identify the areas where core data may be
missing.
c) Refine benchmarks and the concept of equivalent transaction
The developed repository contained 1,695 entries, of which 511 pertained to the DEX use
case. Upon reviewing the repository's details, IBM Promontory observed the following:
• A significant portion of the data points related to the DEX use case are concentrated
in financial product identification and physical person identification, representing
almost 56% of the total data points.
• The benchmarks, derived from TradFi regulation, are designed to cover a wide range
of complex transactions and products. These fields are often left empty when
intermediaries report simple transactions using these benchmarks.
• Numerous data points aim to collect the chain of events before and after the
transaction to identify the ultimate buyers, sellers, and decision-makers.
These elements do not apply equally to DeFi, which has a different nature:
• The instruments involved are always simple, namely tokens.
• The identification of buyers and sellers is limited to wallet ID identification (see
Challenge 2 below).
• Any financial transaction is broken down into a series of simple asset exchanges
between two addresses.
• When transactions are executed on a blockchain, each one is individually recorded in
a block and timestamped.
This results in much simpler transaction schemes compared to the complex transactions
described in the benchmarks. In DeFi, complex transactions are represented by a series of
simpler transactions from a ledger perspective.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 17 of 125
Based on these considerations, IBM Promontory concluded that comparing data collected
from the ledger to the extensive dataset identified in the benchmark was not an adequate
process. Therefore, IBM Promontory undertook a final step to rework the benchmark by
identifying the fields that would be expected in a similar, simpler transaction for the four use
cases: DEX, lending, insurance, and combination/aggregation.
Challenge 2: Wallet ID limitations
In the DeFi ecosystem, wallet IDs represent the accounts and users. These IDs indicate where
assets are stored and are used to settle transactions. Wallet IDs in DeFi are pseudonymous,
meaning they do not directly reveal the identity of the owner. This pseudonymity is a core
feature of blockchain technology. While wallet IDs allow for tracking all transactions made by
a particular wallet and following transaction chains, they do not enable the collection of further
information from public sources regarding the identification of entities and individuals using
these wallet IDs.
This poses challenges for supervisors, as the identification of transacting parties is essential
for supervisory purposes. Additionally, in DeFi, users typically have full control over their wallet
IDs, unlike traditional banking where institutions hold customer funds. This self-custody aspect
presents an additional challenge, as it eliminates the involvement of a financial institution to
perform due diligence as part of the Know Your Customer (KYC) process.
The significant gap in the identification of transacting parties in DeFi compared to TradFi
prompted IBM Promontory to explore alternatives to address this challenge. Consequently,
IBM Promontory engaged with Chainalysis, a leading company in the market, to analyze
financial flows across different blockchains. Based on this collaboration, it appears that
financial flows are often converted into fiat currencies via centralized crypto service providers
such as Coinbase. Leveraging these centralized entities, which already implement KYC
processes and serve as bridges to fiat currencies, presents a practical approach to identifying
transacting parties in the DeFi ecosystem.
In conclusion, IBM Promontory determined that, from a supervisory perspective, all on-chain
information about transacting parties is limited to the wallet ID. Therefore, supervisors should
consider using ecosystem players that can analyze and track fund flows to crypto asset service
providers when relevant.
5.3. Definition of equivalent transaction
Benchmarks are designed to cover a broad spectrum of simple and complex transactions.
However, DeFi transactions, as recorded on the ledger, are typically very simple.
Consequently, it was apparent, even before analyzing the data, that a large proportion of the
benchmark data points would be irrelevant to the DeFi space.
To address this challenge, IBM Promontory decided to study what a DeFi transaction would
look like for each use case and to identify an equivalent transaction in the TradFi space. This
approach allowed IBM Promontory to pinpoint the data points expected for such simple
equivalent transactions, thereby eliminating all other data points that would be irrelevant.
These irrelevant data points are often associated with different instrument types,
intermediaries, or characteristics of complex instruments and would remain unfilled even in a
TradFi reporting scheme.
For each selected protocol, IBM Promontory defined a regular, typical transaction and
developed a brief description of this example transaction. Then, it identified a comparable use
case in TradFi. At the ledger level, all use cases are reduced to standalone simple token
exchange transactions.
For the DEX use case, which relies on token exchanges, it was necessary to identify a proxy
transaction in TradFi to focus the data mapping on the relevant subset of the composite
benchmark. IBM Promontory determined that the most relevant proxy in TradFi would be a
regular cash equity transaction. The concept of token exchanges in DeFi, where two assets
are exchanged directly, differs from TradFi transactions, which usually involve an asset being
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 18 of 125
exchanged for cash (fiat currency). To define an equivalent transaction, IBM Promontory made
the following assumptions:
• The most liquid token was considered equivalent to a currency (e.g., ETH, DAI).
• The less liquid token was considered equivalent to an equity instrument.
It is important to note that this was only a proxy, constrained by the current MiFIR reporting
scheme, and was intended to facilitate assumptions. However, IBM Promontory is confident
that this approach is relevant for assessing data availability, particularly for data that are crucial
for accurately describing a transaction in the DeFi space.
For the lending use case, IBM Promontory determined that the closest equivalent transaction
in TradFi is a collateralized asset exchange. This comparison is based on the requirement in
DeFi to provide a collateral token when borrowing a token. Correspondingly, when providing
a loan, a liquidity provider token is generated and distributed by the liquidity pool's smart
contract, which is governed by an automated market maker (AMM) algorithm.
For the insurance use case, IBM Promontory identified the closest equivalent transaction as
policies providing coverage against cyber exploits, which could lead to various financial losses.
In DeFi, acquiring such insurance requires membership, with most transactions mediated
through a liquidity pool. The process of claim assessment is both discretionary (taking place
off-chain) and incentivized, with the liquidity pool's capital being allocated for claim payouts.
Challenge 3: Liquidity pools
Despite resembling traditional financial services, the functioning of DeFi services differs
significantly due to the prevalent and systematic use of liquidity pools. These pools, briefly
described below, are essential to understanding this report.
Investors store their tokens in liquidity pools to earn returns. In TradFi, liquidity pools can be
compared to automated funds and are central to all protocols examined in this analysis.
For instance, in TradFi, executing a transaction on an exchange using an order book requires
matching two orders. However, in the two protocols identified for DEX, the transaction process
is fundamentally different. Sellers deposit their tokens (or instruments) into a liquidity pool, and
buyers asynchronously purchase tokens from this pool, exchanging other tokens stored in an
equivalent liquidity pool. The price is determined by the size of the liquidity pools and
mathematical formulas designed to ensure liquidity and accurate price formation.
Below is a simplified example illustrating the role of a liquidity pool:
IBM Promontory faced the challenge of mapping DeFi's operations to TradFi to compare
transactions offering similar services in both spaces. An equivalent transaction in TradFi is
represented by several token exchange transactions in DeFi, all facilitated by a liquidity pool.
These pools effectively act as market makers, employing an AMM algorithm to continuously
set trading prices for any transaction and counterparty. The autonomous nature of liquidity
pools, operating entirely as smart contracts, marks a significant departure from conventional
financial transaction processes, highlighting the innovative shift DeFi introduces to the
financial landscape.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 19 of 125
Additionally, bots, comparable to trading algorithms, play a crucial role in executing arbitrage
between different liquidity pools, maintaining price equivalence and liquidity across various
pools, similar to multi-listed securities in TradFi.
To address this challenge, IBM Promontory mapped a single TradFi transaction into multiple
transactions between buyers/sellers and liquidity pools to reconstruct the same transaction.
This involved mapping the execution of several smart contracts and collecting data from all
these smart contracts on the ledger to compare with the equivalent TradFi transaction.
The process of defining the fields that would be filled for an equivalent simple transaction in
TradFi reduced the number of data points substantially to the following numbers:
Use Case
Benchmark
Number of data points
DEX
MiFIR/MIFID
18
All use cases
AML
5
Insurance
Solvency II
6
Lending
CRR/CRD IV
1
SFTR
10
TFR
1
Total
41
5.4. Data mapping and analysis approach
For each data point required in the composite benchmark, IBM Promontory initially planned to
assess the criticality of the data requirement and the quality of the actual mapped or missing
data. To offer a more comprehensive analysis, data quality criteria were also evaluated at the
block level. This block evaluation was integrated for each defined block, enabling the
computation of statistics to assess data quality at the block level.
a) Criticality assessment
Initially, the criticality metric was designed to represent the priority level of data concerning
both financial stability objectives (i.e., macro supervision) and market integrity/investor
protection (i.e., micro supervision), based on the nature of the originating benchmark. This
assessment was conducted prior to the data mapping exercise and was rooted in the TradFi
context.
However, the introduction of the concept of equivalent transactions in the DeFi space, as
discussed earlier, indicated that a comparable transaction in TradFi would yield only limited
information (a few dozen fields). Consequently, the criticality criterion became less relevant
for the analysis and was replaced by a more qualitative assessment at the data point level.
b) Quality assessment
The quality metric assesses the equivalent data in the DeFi context. This evaluation is
conducted after the data mapping exercise and reflects the quality of the data retrieved from
the ledger. The quality ranking is as follows:
• Fields where data is missing;
• Fields where data is partially available;
• Fields where data is available with reasonable quality, meaning that the data collected
meets the supervisory objectives of the related benchmark data.
This quality criterion was maintained and utilized in the analysis.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 20 of 125
6. Phase 2: Software Development
The second phase of the project focused on developing and implementing a software solution
for the retrieval and processing of data available on the Ethereum ledger.
This section assesses data collection from both on-chain and off-chain sources, discusses the
challenges encountered by the team, and highlights the primary deliverables of the technical
activities. Additionally, it provides an estimated sizing for the infrastructure—specifically the
number and capacity of virtual machines—required to support ledger synchronization and
seamless application execution.
To ensure optimal results, a series of IT architecture workshops were conducted to propose
the most efficient and scalable architecture, tailored to the project’s requirements. Given the
complex nature of the project, it was essential to anticipate and address two distinct types of
data collection:
• On-chain data: Accessing and processing information directly from the ledger.
• Off-chain data: Obtaining information from third-party sources (e.g., APIs, external
databases) or deriving it from advanced calculations based on raw ledger data.
This dual approach ensured a comprehensive understanding of the data landscape and
enabled the project to achieve meaningful results.
6.1. Build an application to collect data from the ledger
a) Technical components
During the second phase of the project, IBM Promontory implemented several key
components to enhance the functionality and efficiency of the solution:
• GETH
9
Node: this node acts as a gateway
10
to the decentralized network, enabling the
solution to operate in a private, self-sufficient, and trust less manner. It allows the
retrieval of all events linked to a smart contract and serves as the core Ethereum node
for the project, facilitating both historical and real-time data retrieval.
• Message Queue Service: integrated to store messages (i.e., relevant transactions)
from the ledger to the database, this service sits between the node and the database.
It ensures no transaction is lost and maintains the throughput. The implementation also
allows for the exchange of asynchronous messages from the GETH node to the
database, handling both real-time and historical data collection mechanisms.
• Database: this database was chosen to store transactions and relevant data from
smart contracts and DeFi protocols. Its flexibility in modifying the data structure makes
it particularly suitable for this context.
• Set of Applications: Developed to ensure the following activities:
o Storage of events captured from the ledger and pushed into the message
queue. This application assesses real-time ledger events and decides which
transactions should be stored. Relevant transactions are then transferred into
the message queue.
o Storage of external data collected from third-party sources.
o Collection of transactions transferred by the message queue system,
formatting the data correctly, and storing it in the database.
9
GETH node (for “Go Ethereum”) is the main gateway to the Ethereum ledger. It is required to host an Ethereum node.
10
A gateway, in this context, refers to an access point that connects external applications and users to the Ethereum blockchain.
Geth, which stands for Go Ethereum, is an implementation of an Ethereum node in the Go programming language. A Geth
Node provides APIs and interfaces that allow external applications to interact with the Ethereum network for tasks such as
sending transactions, querying balances, and managing smart contracts.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 21 of 125
• Configuration Files: created to enable the solution to support different protocols or
smart contracts associated with various data sets and formats.
The following diagram provides a high-level overview of the solution's architecture:
Fig. High-level overview of the architecture for the technical solution
To develop this solution, the development team leveraged the following technologies:
• Golang: this programming language was chosen for its efficient management of
events through its lightweight concurrency model, goroutines. It was particularly
relevant for the real-time application requirements to efficiently extract Blockchain
events. Additionally, Golang's ease of deployment and well-designed standard libraries
facilitate fast and easy maintenance.
• MongoDB: this NoSQL database was selected for its fast data recording capabilities
and flexibility in handling unstructured data. The technical team preferred this storage
solution for its lightness, speed, and simple replication features.
• RabbitMQ: a standard technology for message queue services, RabbitMQ was
necessary to decouple data production and consumption, i.e., filtering relevant
transactions from the ledger and reformatting and storing them. This queuing service
ensures that the solution can handle large spikes in incoming data without saturation,
thereby preventing data loss.
• Docker: this containerization technology was used for every service in this stack,
except for RabbitMQ, which is a Platform as a Service (PaaS
1
). Containerization
facilitates running the entire application in a container on a cloud infrastructure,
ensuring maintainability, ease of deployment, security, and resource optimization.
Each container runs only one service to enhance security and resource management.
This technical stack enabled IBM Promontory to support various DeFi protocols in a timely,
secure, and performant manner.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 22 of 125
b) Technical challenges
Throughout the development phase, the team encountered various technical challenges,
which are elaborated upon in this section.
The first challenge IBM Promontory faced was on the Ethereum Ledger synchronization itself,
as it proved to be difficult.
Challenge 4: Ledger synchronization
Synchronizing the Ethereum ledger on IBM Promontory’s infrastructure proved to be a
complex endeavour due to the substantial size of the Ethereum ledger, which currently
exceeds 1272.52 GB, and its slow synchronization process. Achieving complete
synchronization with the Ethereum ledger using GETH's full synchronization default setting
necessitates high-performance machines and sufficient storage capacity. Further technical
requirements are elaborated upon later in this section.
Fast disk drive read/write access, also known as "I/O speed," is crucial for this task.
However, speedy I/O is a scarce and expensive resource in cloud computing environments,
and the level of I/O speed required to copy the entire ledger may not be available in all cloud
environments.
Once the Virtual Machine (VM) was configured, the next step involved retrieving the entire
ledger, spanning six years. Even segmenting this data further, such as analyzing data for
just one year or one month, was a time-consuming and resource-intensive process.
However, it was deemed essential to obtain accurate and relevant information, particularly
over an extensive period.
While ledger synchronization was eventually successful, a process typically taking several
days to weeks depending on hardware and network conditions, maintaining the updated
ledger posed challenges. The ledger experienced multiple desynchronizations due to
factors like network latency or node failures, necessitating reinitialization and additional
lengthy synchronization processes. In cases of desynchronization, the GETH node
attempted to reconstruct the entire ledger rather than retrieving the most recent missing
blocks, which is a common issue in full ledger synchronization. This highlights that while the
infrastructure is highly resilient and fully decentralized, it is not yet mature enough for high
availability in local usage scenarios.
Due to hardware limitations, including I/O speed and network speed, synchronizing the
entire ledger took slightly over 13 days, which was a significant drawback. The continuous
synchronization process, involving addition of new entries to the replicated ledger, also
imposes hardware requirements, especially the ability to keep up with the creation of new
blocks and entries. A key takeaway from this experience is the importance of configuring a
high-performance VM for such activities (refer to Section 6.3. for the proposed
configuration).
To address these challenges, IBM Promontory employed a third-party solution called Infura
to collect data from the ledger, alleviating the need to host a node and working with a lighter
machine configuration. This option facilitated rapid development of the solution within the
project timeframe and expedited data collection. However, as the Commission mandated
avoiding third-party solutions, IBM studied the optimal configuration and architecture (as
described in Section 6.3) to deliver the solution without Infura. Once the optimal sizing was
determined, IBM Promontory established the necessary infrastructure to collect data via the
self-hosted node approach, aligning with the intended objective. A switch was then
developed within the delivered solution to offer both options (with and without Infura),
enhancing flexibility to accommodate various constraints.
Regarding supervisory options, IBM Promontory considers both approaches viable.
Comparative analysis confirmed that data from both options are identical, instilling trust in
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 23 of 125
the Infura tool while alleviating the operational burden of maintaining a node. The primary
disadvantage is that Infura could potentially manipulate the data returned to the end-user,
which supports the argument for deploying and maintaining one's own node.
The subsequent set of challenges stemmed from the smart contracts themselves, which
proved to be numerous and complex to comprehend.
Challenge 5: Smart contracts data
The ledger exclusively encompasses data resulting from the execution of smart contracts.
These data are consistently confined to a limited number of fields, typically ranging from 10
to 20, and are often intricate due to their highly technical nature.
To address these challenges, IBM Promontory undertook the meticulous examination of
each smart contract individually, encompassing their inputs, outputs, and other pertinent
characteristics, in order to identify, extract, and comprehend the relevant data. This
endeavour proved to be demanding, necessitating expertise across various domains. While
time-consuming, it was imperative to ensure an accurate outcome.
The primary challenge of the project lay in the necessity to delve into the internal logic of
smart contracts, surpassing a mere examination of their transaction history. Analyzing smart
contracts entails scrutinizing their underlying code, encompassing the rules, conditions, and
triggers that dictate their functionality.
This comprehensive analysis facilitated recognizing and comprehending the
interrelationships and dependencies among different smart contracts. Moreover, it enabled
the evaluation of their specific roles within the protocol and, more broadly, within the DeFi
ecosystem when integrated collectively.
While not directly posing a challenge for the development team, the next observation highlights
a potential future concern: the need to continually update the solution as new smart contracts
are periodically released.
Challenge 6: Versioning of smart contracts
The landscape of DeFi is in a constant state of evolution, with new iterations of smart
contracts emerging regularly. Despite the adoption of newer versions, older iterations
persist, along with associated liquidity pools, resulting in the coexistence of numerous smart
contracts and liquidity pools concurrently.
IBM Promontory's efforts focused on the most recent iterations of smart contracts as of
summer 2023. However, subsequent versions have since been introduced, while older
versions remain active.
Effective protocol monitoring necessitates the development of tools capable of
encompassing all live iterations of smart contracts within a protocol. Additionally, it requires
continuous adaptation to accommodate these evolving versions.
To tackle this challenge, IBM Promontory suggests that supervision should initially prioritize
protocols and smart contracts based on defined criteria, such as TVL, and monitor the
evolution of TVLs across various iterations of smart contracts. This approach ensures a
systematic and structured method for overseeing the dynamic DeFi landscape.
Lastly, handling on-chain data posed significant challenges. It required the team not only to
capture this data but also to conduct real-time computations by integrating supplementary
logic or utilizing alternative data sources. This method was crucial for generating pertinent
data not directly accessible on the ledger, proving invaluable for monitoring and supervisory
endeavours.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 24 of 125
Challenge 7: Computation
Certain data necessary for supervision are not readily accessible on the ledger but can be
derived from other ledger data. For instance, information such as transaction prices or the
top exposures of liquidity pools are not directly accessible and thus require computation.
To tackle this obstacle, the development team, for instance in the case of transaction prices,
identified pertinent smart contracts capable of collecting the necessary data. Subsequently,
they implemented a method to compute the transaction price based on the transaction's
timestamp and the prevailing price at that specific moment. This approach offers an
approximation of the transaction price without disclosing exact data.
Transaction prices serve as just one illustration of the numerous computations the team
undertook to gather information on liquidity pools and other intricate data sets.
6.2. Technical Deliverables
This section offers a comprehensive overview of the technical deliverables that the
development team has prepared for the project.
The technical deliverables contain two archives, one for the monitoring service and the other
one for the data collection and processing service. Those two archives will be described in the
next sections.
a) Monitoring Service
The monitoring service is an essential component designed to listen to smart contract events
from configured protocols and push the data to a dedicated, automatically created message
queue, as described in the introduction of this chapter. The service is built using Golang and
is designed to work with Ethereum Smart Contracts.
The readme file provides information on prerequisites, configuration, and usage of the service.
It explains the process of obtaining the sources, configuring the environment variables, and
running the service using Docker and Docker-Compose.
Additionally, it lists the supported protocols and their descriptions, as well as various resources
and tips for hosting your own Ethereum node.
The readme file guide contains:
• Prerequisites: a running Ethereum node, Docker, and Docker-Compose;
• Configuration: copy and edit the .env file with necessary environment variables;
• Usage: clone the repository, configure the environment, and run the service using
Docker-Compose;
• Supported Protocols lists the supported protocols and their descriptions; and
• Additional Resources: provides resources and tips related to Ethereum nodes and
Smart Contracts
b) Data Collection & Processing Service
The Data Collection & Processing (DCP) service is responsible for consuming events from the
queue created by the Monitoring service, processing additional data if required, and storing
the relevant data in a MongoDB collection. It plays a critical role in handling data from various
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 25 of 125
protocols and interacting with oracles or other APIs
11
for additional information. The DCP was
not used to query off-chain data, which was done manually, in the context of this project.
The readme file guides users through the setup and execution of the project. It explains how
to set up environment variables, generate a smart contract package using abigen, and run the
project using Docker-Compose.
Furthermore, it provides a brief description of the DCP service's responsibilities, and a diagram
illustrating the overall process.
The content of the readme file is the following:
• Environment variables setup: for backend, MongoDB, and MongoDB Explorer
respectively;
• Generating smart contract package: use of abigen to generate a package for easier
interaction with the smart contract ABI
12
;
• Running the project: use Docker-Compose to run the project;
• DCP service responsibilities: lists the key responsibilities of the DCP service; and
• A few diagrams that aim to provide a visual representation of the DCP service process.
6.3. Estimates of the technical requirements to run the full
solution
A dedicated Virtual Machine (VM) is recommended. The technical team has shared estimates
for two different setups: (i) light participation and (ii) full Ethereum node.
Light participation
In this setup, a lighter VM could support the workload. The recommended specifications are
the following:
• 2 vCPU
• 4Go RAM
• 200Go of standard storage
• No requirement on bandwidth
Note that this is not suited for extensive data retrieval, as the light node will rely on a full
Ethereum node to fulfil the request.
Full Ethereum node (recommended)
The fully synchronized Ethereum node requires a much more robust VM. The recommended
specifications are the following:
• 8 vCPU
• 32Go RAM
• Up to 3To of SSD storage with high I/O (>100K IOPS)
• 500Mbps to 1Gbps for the Network (bandwidth)
Assessing the man-days needed to operate such a network with the technical solution running
remains challenging.
The current implementation could be managed by a small team of 2-3 persons for a few
months with a thorough understanding of the solution and the functioning of the assessed
smart contracts.
11
“Application Programming Interface”, a set of rules and protocols that enables software applications to communicate and
share data, allowing developers to access pre-built functionalities and streamline the development process.
12
“Application Binary Interface”, ABI acts as an interface that allows users and applications to communicate with and execute
functions within smart contracts on the Ethereum network.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 26 of 125
Implementing robust DevOps management, coupled with monitoring and enhanced resilience,
could potentially lead to reduced maintenance and minimal effort from the technical team.
However, it should be noted that a larger-scale implementation of this solution would
necessitate substantial additional effort to ensure its continuous and smooth operation.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 27 of 125
7. Phase 3: Data Collection and Analysis
Using the software developed in Phase 2 and the benchmarks, IBM Promontory analyzed and
mapped all collected data from the ledger.
This section covers the data mapping and the analysis of the results for the four use cases:
DEX, lending, insurance, and aggregation/combination of protocols. It also provides
conclusions at the level of each of the use cases, that are further used in section 8.1.
7.1. DEX use case
a) Protocols comparison
Uniswap and Curve Finance exhibit similarities, serving as DEXs facilitating token exchanges
for users. Consequently, IBM Promontory initially evaluated these two protocols individually
and determined that the datasets for both platforms, particularly regarding supervision and
information derived from the ledger, are comparable.
Although the specific data fields may vary between the two protocols, the availability of data
remains consistent across both platforms. This observation prompted IBM Promontory to
analyze and treat Uniswap and Curve Finance as a singular entity, given the uniformity in data
availability and quality.
However, it is important to recognize that while Uniswap and Curve Finance share similarities,
this does not necessarily imply that the same approach will be applicable to other DeFi
protocols. Each DEX protocol may possess unique features, use cases, and data
requirements, necessitating distinct analysis and consideration.
b) Analysis
For DEXs use case, the starting point was the selected benchmarks that are composed of 511
data points. Below is the breakdown of those benchmarks by data set and block:
Data Set
Blocks
Total
RTS 22
Block 1: Buyer/Seller identification
21
Block 2: Decision-maker for Buyer/Seller
16
Block 4: Investment decision within the firm Field
5
Block 5: Execution within the firm field
5
Block 6: Trading date time
1
Block 7: Venue
1
Block 8: Short selling flag
4
Block 9: Waiver, OTC post-trade and commodity derivative indicators
19
Block 10: Branches
10
Block 11: Status of transaction reports and corrections
19
Block 12: Change in notional
2
Block 13i Core transaction data
34
Block 14i Financial instrument identification
200
Block 15i Traditional finance specific data
44
AML
Block 3 (combination of 1 and 2): Buyer/Seller and decision-maker
specific scenarios
60
Block 6: Trading date time
1
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 28 of 125
Data Set
Blocks
Total
Block 11: Status of transaction reports and corrections
7
Block 13i Core transaction data
5
Block 15i Traditional finance specific data
37
RTS 1
Block 7: Venue
20
Total
511
Before executing the analysis, several observations were made:
• Financial product identification represents 39% of the data set.
• Blocks 1 through 4 are dedicated entirely to the identification of transaction parties,
accounting for 20% of the data set related to DEXs data points.
• 16% of the data points are related to TradFi specifics that do not have any direct
equivalence in DeFi, such as branch identification, OTC post trade indicator, etc.
Part of the information that is required from the benchmark has very limited or no relevance
for DeFi and is thus not available on the ledger. For example:
• Block 1: Buyer/Seller identification beyond wallet ID is non-existent. Same as for Block
2: Decision-maker for Buyer/Seller and Block 4: Investment decision within the firm. All
those fields remain limited to the wallet ID only.
• Block 10: The concept of branches does not exist in DeFi, and the wallet ID remains
the sole identifier from a DeFi perspective.
• Block 11: Status of transaction reports and corrections are not relevant in a context
where blockchain transactions are irrevocable and immutable. It is not possible to
modify or cancel a transaction. This concept is also developed in the benchmarks in
terms of reporting from financial firms, which is not relevant when collecting data
directly from the ledger.
• Block 12: Change in notional is also irrelevant as such functionality does not exist in
DeFi (but would be addressed by additional transactions).
As explained in Section 5, DeFi transactions, whatever their complexity, are finally broken
down into simple token swap transactions on the ledger. The equivalent transaction used for
this exercise relies on a user exchanging two tokens (selling one liquid token acting as a
currency against another token acting as an asset).
At this point, the 511 data points from the benchmark were reviewed one by one, to identify
the data which would be relevant to the specific transaction being considered for this exercise.
Applying the above-described approach led to the pinpointing of 21 data points that would be
the fields filled in to describe the same type of transaction in TradFi i.e. a simple equity vs cash
transaction, with two entities purchasing as principal, and without any additional intermediary,
decision-maker, branch etc. The distribution of these 21 data points across the various blocks
is detailed further in the table below:
Data Set
Blocks
Total
RTS 22
Block 1: Buyer/Seller identification
2
Block 4: Investment decision within the firm
3
Block 6: Trading date time
1
Block 7: Venue
1
Block 11: Status of transaction reports and corrections
1
Block 13i Core transaction data
10
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 29 of 125
Data Set
Blocks
Total
AML
Block 6: Trading date time
1
Block 13i Core transaction data
4
Total
23
The detailed mapping by block is as follows:
Data
Set
Blocks
Fields where the data
is available with
reasonable quality
Fields where
data is partially
available
Fields
where data
is missing
Total
RTS
22
Block 1:
Buyer/Seller
identification
2
2
Block 4:
Investment
decision within
the firm Field
3
3
Block 6: Trading
date time
1
1
Block 7: Venue
1
1
Block 11: Status
of transaction
reports and
corrections
1
1
Block 13i Core
transaction data
7
1
2
10
AML
Block 6: Trading
date time
1
1
Block 13i Core
transaction data
3
1
4
Total
12
5
6
23
The key findings from the benchmark analysis for this use case are as follows:
• Identification of buyers and sellers (Block 1) is partially available, due to the inherent
limitations of wallet IDs.
• Transaction report status and corrections (Block 11) is not available since DeFi
transactions cannot be altered once validated.
• Core transaction data (Block 13i) aligns well with DeFi, all the key data which are
needed to describe the transactions are available.
• Out of scope data (Block 18i) features three data points. One has been selected to
host the paid (sold) token identifier, as it is necessary to describe the transaction. The
two other data are related to the concept of trading capacity which is not applicable in
DeFi as all wallets act as principals.
• Data on investment decisions within a firm (Block 4) is absent because DeFi currently
does not facilitate the identification of user or investor beyond the wallet ID.
• Trading date and time (Block 6) is available: it is the timestamp to the mining of the
block on the Ethereum blockchain.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 30 of 125
• Venue identification (Block 7) is equated to the used protocol but is only a partial match
because the 'venue' can vary depending on the perspective: the Ethereum platform,
the initiating protocols, the pricing process of AMMs, or the liquidity pool.
c) Conclusion
From the above, the following conclusions can be drawn:
• 52% of the data is available and is of reasonable quality. This data primarily
encompasses fundamental transaction details like amount, quantity, and asset names.
• 22% of the data partially aligns with DeFi data when compared to the benchmark and
is related to the identification of stakeholders.
• 26% of the data is missing mainly given the DeFi specifics as compared to TradFi (e.g.
venue, investment decision, transactions status). Indeed, the identification of buyer
and seller is a significant part of benchmark data and as already mentioned, this type
of data is so far limited to wallet ID.
7.2. Lending use case
a) Protocols comparison
AAVE and Compound stand as prominent figures in the DeFi landscape, primarily serving as
decentralized lending platforms where users can borrow and lend various cryptocurrency
assets. At the core of their operations lie money markets established through algorithmically
derived interest rates, responding to supply and demand dynamics.
Much like Uniswap and Curve Finance in the DEX domain, AAVE and Compound play crucial
roles in decentralized lending. Both platforms leverage smart contracts to manage assets and
interest rates, facilitating lending and borrowing activities without intermediaries. This
operational similarity implies that the datasets for AAVE and Compound, especially
concerning loan origination, collateral management, and interest rate mechanisms, are highly
analogous.
IBM Promontory's concurrent analysis of AAVE and Compound recognizes the parallel
behaviours of both protocols in terms of data accessibility and relevance for supervisory
purposes.
However, despite these similarities, it's essential to acknowledge that AAVE and Compound
possess distinct features and operational nuances. For example, AAVE offers unique products
like flash loans and different collateralization options, whereas Compound boasts its
community-centric governance structure and engaging token distribution strategy. These
disparities underscore the necessity for separate, comprehensive analyses of each protocol
to fully grasp and appreciate their unique characteristics and implications within the DeFi
ecosystem.
b) Analysis
For the lending use case, the starting point is the selected benchmarks that are composed of
615 data points. Below the breakdown by data set and block:
Data Set
Blocks
Total
RTS on SFTR
Reporting
Block 3 (combination of 1 and 2): Buyer/Seller and decision-maker
specific scenarios
50
Block 13i Core transaction data
37
Block 6: Trading date time
3
Block 11: Status of transaction reports and corrections
94
Block 12: Change in notional
1
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 31 of 125
Data Set
Blocks
Total
COREP
FINREP
Block 3 (combination of 1 and 2): Buyer/Seller and decision-maker
specific scenarios
171
Block 13i Core transaction data
23
Block 15i Traditional finance specific data
134
Block 16i Funding related data
76
Consumer
detriment
Block 15i Traditional finance specific data
3
Metrics for
credit granting
and
monitoring
Block 15i Traditional finance specific data
14
Transfer of
Funds
Regulation
Data
Block 1: Buyer/Seller identification
9
Total
615
The detailed approach for the benchmark selection is provided in appendix 10.3.
Before conducting the analysis, several observations were noted:
• Data pertaining to the status of transaction reports and corrections (Block 11i)
constitute 15% of the total. These data are associated with the reporting party (TFR
reporting) and do not have any relevance to DeFi.
• Data related to Block 15i, specific to TradFi, account for 25% of the total. However,
they are not applicable to the use case as they concern traditional financial
instruments.
• Data linked to Block 3 (a combination of 1 and 2), covering scenarios involving buyers,
sellers, and decision-makers, represent 28% of the total. These have minimal
correspondence to DeFi since they predominantly involve counterpart nature, which is
typically limited to wallet IDs in DeFi.
• Data associated with Block 16i (12% of the total), focusing on funding, are also
irrelevant to the use case as they pertain to conventional banking concepts like deposit
funding.
• Core transaction data (Block 13i) comprises 10% of the total. Although exposure data
is crucial, COREP FINREP aggregates data by counterparties, unlike the ledger, which
identifies transactions solely by wallet IDs. Moreover, SFTR provides extensive
collateral information, yet it fails to clearly link borrowing records with their collateral
counterparts on the ledger. It's important to note that collateral levels may fluctuate
during the lifespan of a lending/borrowing agreement. Borrowers can adjust collateral
levels in response to margin calls, and if there is no response or insufficient collateral,
an automatic liquidation process is initiated. Consequently, much of the data within this
block becomes inapplicable.
The application of COREP FINREP reporting to the liquidity pool, likened to a "bank" in this
scenario, further complicates matters. Moreover, COREP/FINREP exposure calculations are
associated with various types of entities that lack equivalents in DeFi, rendering most of the
data irrelevant to equivalent transactions.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 32 of 125
The review of each benchmark data point to assess the data applicable to a simple transaction
resulted in 12 data points from the benchmarks. The distribution of these 12 data points across
the various blocks is elaborated in the table below:
Data Set
Blocks
Total
RTS on SFTR
Reporting
Block 13i Core transaction data
8
Block 3 (combination of 1 and 2): Buyer/Seller and decision-
maker specific scenarios
1
Block 6: Trading date time Block 3 (combination of 1 and 2):
Buyer/Seller and decision-maker specific scenarios
1
COREP
FINREP
Block 13i Core transaction data
1
Transfer of
Funds
Regulation Data
Block 1: Buyer/Seller identification
1
Total
12
The subsequent mapping process achieved the following results:
Data Set
Blocks
Fields where the
data is available
with reasonable
quality
Fields where
data is
partially
available
Fields where
data is
missing
Total
RTS on
SFTR
Reporting
Block 3
(combination of
1 and 2):
Buyer/Seller
and decision-
maker specific
scenarios
1
1
Block 6: Trading
date time
1
1
Block 13i Core
transaction data
1
5
2
8
COREP
FINREP
Block 13i Core
transaction data
1
1
Transfer of
Funds
Regulation
Data
Block 1:
Buyer/Seller
identification
1
1
Total
4
6
2
12
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 33 of 125
The key findings from the benchmark analysis for this use case are as follows:
• All the data points, except two, are successfully directly retrieved, either with a perfect
correspondence or with some interpretation (required when the correspondence is not
perfect due to difference in concept between TradFi and DeFi).
• One data point (Concentration by counterparty) is retrieved via computation based on
data extracted from the ledger. However, this data cannot be computed at any other
level than wallet ID (no aggregation per counterpart or type of counterpart possible).
• The variation of received margin (Trade Data/Report/New/Received Margin or
Collateral/Variation Margin Received) is not retrievable in the ledger since there is no
link between the borrowing record and the collateral record.
c) Conclusion
In DeFi, liquidity pools can become imbalanced due to various factors, which can adversely
affect investor returns. Key concerns include impermanent loss resulting from fluctuations in
token prices, arbitrage opportunities exploited by traders, and slippage caused by large token
swaps due to concentration. Moreover, liquidity migration driven by better incentives, market-
wide events, protocol exploits, and reward-driven incentive programs can all contribute to
destabilizing pools.
These imbalances can diminish investor value through internally calculated prices (each pool
has a formula) that may no longer align with the broader market, underscoring the importance
of effective risk supervision in DeFi activities.
A DeFi liquidity pool's balance sheet includes assets and liabilities. On the asset side, the pool
holds loans and liquidity tokens. Loans are funds lent to borrowers, generating interest income.
Liquidity tokens, given to liquidity providers, represent their share of the pool and its accrued
fees. On the liability side, the balance sheet includes collateral posted by borrowers to secure
their loans and liquidity provided by investors, which supports the pool's operations. This setup
ensures the pool can meet its obligations to both borrowers and investors, maintaining a
balanced and secure financial structure.
In line with supervisory objectives, IBM Promontory examined the liquidity pool’s flows to
assess if basic data enabling understanding of flows in and out of liquidity pools were
available. The investigation confirmed that data on all flows is accessible from the ledger. This
implies that real-time supervision of liquidity pool balance sheets is feasible. Such an approach
could be piloted and should be based on an aggregation process of transaction data (as all
transactions since the creation of a liquidity pool are available on the ledger).
This aspect is further elaborated upon in the report’s conclusions, as it is deemed a significant
finding by IBM Promontory, indicating the potential for supervisors to monitor the financial
health of liquidity pools from a macroprudential perspective.
7.3. Insurance use case
a) Protocols comparison
Nexus Mutual and Unslashed Finance hold significant positions within the DeFi insurance
sector, offering users avenues to hedge against risks associated with smart contracts and
DeFi protocols. While they may be smaller in size and volume compared to previous DEX and
lending protocols, their role is vital in providing decentralized insurance coverage, primarily
addressing risks like smart contract failures, exchange hacks, and custody risks.
Both Nexus Mutual and Unslashed Finance employ blockchain technology and smart
contracts to facilitate the provision and management of insurance policies, aligning with
decentralized principles that ensure transparency in policy management, a departure from
traditional insurance systems.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 34 of 125
In terms of data, both platforms generate similar datasets, encompassing policy issuance,
claims, premiums, payouts, and risk assessment. However, despite these broad similarities,
Nexus Mutual functions akin to a mutual insurance society, where members (token holders)
govern the protocol, influencing key decisions such as risk and claims assessment, as well as
governance changes. Moreover, Nexus Mutual mandates users to undergo Know Your
Customer (KYC) processes.
In contrast, Unslashed Finance offers a range of insurance products with quicker cover
activation and potentially expedited claims processing. Unslashed prioritizes user-friendliness
and accessibility, aiming to simplify the insurance process within the DeFi realm.
It's worth noting that Unslashed Finance's website ceased operations in Q3 2023, during the
project period. However, the smart contracts remain active on the Ethereum ledger, ensuring
continuity of operations despite the website closure.
b) Analysis
For the Insurance use case, the starting point is the selected benchmarks that are composed
of 619 data points. Below is the breakdown by data set and block:
Data Set
Blocks
Total
EMIR Reporting
Block 15i Traditional finance specific data
107
Solvency II
Block 13i Core transaction data
6
Block 17i Insurance premium and claim
456
Total
569
Before executing the analysis, several observations were made:
• By reviewing the Solvency II non-life template, IBM Promontory observed that the “Line
of business for non-life insurance and reinsurance obligations” (BL) had no similarities
with the activities covered by Insurance protocols in DeFi. For example, the 16 types
of BL are representative of the traditional insurance business (e.g. medical insurance,
transport insurance), while the DeFi insurance business is focused on specific DeFi or
crypto asset risks (e.g. wallet hacking). To perform the mapping exercise, IBM
Promontory decided to use the “Miscellaneous financial loss” BL to a selected
Uniswap’s ETH slashing cover.
• Regarding the data that are expected in Solvency II report, a significant part of them is
not relevant by nature to Defi, for instance:
o Premium written is not relevant since in DeFi the payment of the insurance is
upfront.
o Reinsurer related data are not relevant since there is no reinsurance in DeFi.
• Regarding EMIR reporting, which was targeted to be used as a transaction level
(micro) benchmark, the analysis of the data found on the blockchain led to the
conclusion that the correspondence of concepts between TradFi derivatives and DeFi
insurance contracts was too low to reasonably perform a mapping: as for a traditional
insurance contract, there is no correspondence with the instruments covered in EMIR,
even the ones that could be considered relatively close to an insurance such as credit
default swap. This is also due to the way those insurance work i.e. by executing a
transaction upfront to a liquidity pool, and having a claim system based on governance,
and therefore not corresponding to the functioning of derivatives under EMIR. Further
information on the EMIR benchmark is provided in Annex 10.3.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 35 of 125
Based on the outcomes of the preceding analysis, IBM Promontory explored use cases that
present similarities with traditional insurance policy contracts in terms of premium payments,
claim declaration process, and of claim payouts mechanisms.
The review of each benchmark data point led to identify five data points that would find their
equivalent in a basic insurance transaction: Premium paid, claim amount, deposit fees, claim
paid, protocol fees (or liquidity pool).
For the data mapping, IBM Promontory identified six on-chain data points, and noted six off-
chain data points, culminating in a total of 12 data points.
The subsequent mapping process achieved the following results, considering that some data
points correspond to both on-chain and off-chain categories simultaneously: the 6 relevant
data were successfully mapped.
The detailed mapping by block is as follows:
Data Set
Blocks
Fields where the data is
available with reasonable
quality
Non-Life Template on
premiums, claims, and
expenses by lines of
business - S.05.01.02.01
Block 13i Core transaction
data
6
The key findings from the benchmark analysis for this use case are that it was possible to find
those six data points with proper accuracy.
c) Conclusion
While the advertised products on the front pages of relevant protocol websites may resemble
traditional insurance products, the similarities between these DeFi products and conventional
insurance are limited. For instance, the Nexus Mutual DAO operates a risk-sharing pool
funded by its members, utilizing these funds to settle claims. Nexus Mutual engages its
community in assessing and accepting coverage proposals, as well as funding the pools
ensuring coverage, with additional rewards offered through the NXM token.
In terms of supervisory objectives, IBM Promontory's findings indicate that basic transaction
information can be technically extracted from the ledger and consolidated to provide an
accurate macro view of the studied protocol. Furthermore, the Nexus Mutual protocol
mandates Know Your Customer (KYC) checks for all members.
However, it's essential to note that the Unslashed protocol has encountered internal disputes
among developers, leading to the shutdown of its website mid-project. This highlights the
potential risks associated with the use of such protocols.
7.4. Combination and Aggregation use case
a) Protocols comparison
The "1inch" Network serves primarily as a DEX aggregator within the DeFi ecosystem. Its
main purpose is to optimize trades across various DEXs, ensuring users achieve the most
advantageous trade execution. This is accomplished through a sophisticated algorithm that
scans multiple exchanges for the most favorable exchange rates and lowest slippage. By
aggregating liquidity and pricing information from different sources, 1inch offers users a single
platform to access a wide range of trading options.
Data generated by 1inch pertains to trade execution, liquidity depth, price slippage, and DEX
performance.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 36 of 125
On the other hand, "MakerDAO" is renowned for its endeavor to establish a currency for DeFi
through the creation of the DAI stablecoin. It combines aspects of lending and stablecoin
issuance and management. Users can collateralize assets in smart contracts to generate DAI
as debt against this collateral, a process crucial for maintaining the stability of DAI.
b) Analysis
IBM Promontory's observations on the protocols are as follows:
i. 1inch aggregates functionalities from various DEXs to offer users the best prices and
lowest fees for their transactions. Its core feature involves advanced smart contracts
that scour multiple DEXs and liquidity protocols to find the most efficient swap routes
for orders. Transactions are executed by DEXs and recorded in the ledger by these
exchanges.
ii. MakerDAO's primary mechanism allows users to lock collateral, typically Ether, in
smart contracts and create DAI stablecoin against it. DAI is maintained at a 1:1 peg
against the US Dollar to serve as cash for transactions in DeFi. The system endeavors
to maintain stability by adjusting interest rates and creating or destroying DAI based
on market demand. MakerDAO offers lending transactions where DAI serves as
currency, as well as token swap transactions. These transactions are recorded in the
ledger similarly to the lending protocols studied earlier in this report.
The analysis of 1inch and MakerDAO has been conducted separately from each other.
Regarding 1inch, it was observed that the data presented were akin to those of the underlying
protocol since 1inch primarily executes transactions on DEX protocols such as Uniswap and
Curve. When a user initiates a trade on 1inch, the platform does not directly generate new
data or transactions on the blockchain ledger itself. Instead, it aggregates prices from various
DEXs and identifies the optimal trading path. Once the user confirms the transaction, 1inch
dispatches it to the selected DEX that executes the trade. 1inch acts as a routing mechanism,
directing transactions to various endpoints (DEXs) based on efficiency.
However, 1inch utilizes its own set of smart contracts to interact with these DEXs. When a
user confirms a transaction, they effectively grant permission to a 1inch smart contract to
execute trades on their behalf across selected DEXs. IBM Promontory could identify the
contract ID in the transaction pointing to the 1inch protocol, allowing the identification of 1inch's
role as a broker in the transactions executed.
As for MakerDAO, a combination of lending and DEX, IBM Promontory mapped the collected
ledger data with both benchmarks and obtained the following results:
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 37 of 125
Data Set
Blocks
Fields where the data
is available with
reasonable quality
Fields where
data is partially
available
Fields
where data
is missing
Total
RTS 22
Block 1: Buyer/Seller
identification
2
2
Block 4: Investment
decision within the
firm Field
3
3
Block 6: Trading date
time
1
1
Block 7: Venue
1
1
Block 11: Status of
transaction reports
and corrections
1
1
Block 13i Core
transaction data
7
1
2
10
RTS on
SFTR
Reporting
Block 3 (combination
of 1 and 2):
Buyer/Seller and
decision-maker
specific scenarios
1
1
Block 6: Trading date
time
1
1
Block 13i Core
transaction data
1
5
2
8
COREP
FINREP
Block 13i Core
transaction data
1
1
Transfer of
Funds
Regulation
Data
Block 1: Buyer/Seller
identification
1
1
Grand Total
13
9
8
30
MakerDAO functions as a stablecoin management system. Aside from considering DAI as a
regularly issued token, there are no additional data available. Therefore, it is possible to
assess the balance sheet of the pool and monitor the outstanding tokens, level of
collateralization, and exposure through the assessment of the liquidity pool, as demonstrated
for the lending use case.
The key findings from the benchmark analysis for this use case indicate that the combination
of both protocols yields identical results for each protocol individually. In other words, the same
data is available, leading to the same conclusion for the combined protocols as for each
protocol separately in terms of data availability. Additionally, it is feasible to identify the
Contract ID of the protocol that executed the combination of smart contracts, aiding in
overseeing smart contract composability.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 38 of 125
8. Data Analysis Results
The table below summarizes the number of data points initially identified in the benchmarks
and those identified for equivalent transactions. It also indicates the percentage availability of
relevant data for each use case, focusing on the equivalent transaction data points, which are
highlighted in green:
This analysis underscores the varying degrees of data availability across different use cases,
providing a clear view of the effectiveness and completeness of the data retrieval process for
supervisory purposes.
Use Case
Benchmarks
Number of
TradFi
Data
points
Number of
data points
for an
equivalent
transaction
%
missing
%
partially
available
%
available
DEX
RTS 22
AML
RTS 1
511
23
52%
22%
26%
Lending
RTS on SFTR
Reporting
COREP FINREP
Consumer
detriment
Metrics for credit
granting and
monitoring
TFR
615
12
33%
50%
17%
Insurance
EMIR Reporting
Solvency II
569
6
100%
0%
0%
Combination
RTS 22
RTS on SFTR
Reporting
COREP FINREP
TFR
1123
30
43%
30%
27%
8.1. Qualitative analysis of the results
a) Ledger data analysis
This section aims to provide a qualitative analysis of the data availability retrieved from the
ledger. More general conclusions are elaborated in Section 9.
IBM Promontory has drawn the following conclusions regarding data availability:
1. Micro-Supervision
• Essential data requirements to understand the nature and terms of transactions are
generally met without significant gaps.
• Data requirements related to the identification of entities or persons are not met since
no information beyond the wallet ID is retrievable from the ledger. This presents
challenges in identifying the individuals or entities behind wallet IDs, especially in
cases of potential market manipulation. It also hampers the quality of trade monitoring,
as a single entity could control multiple wallets, engaging in collusive activities.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 39 of 125
• Certain data, typically associated with TradFi features, such as the update or
cancellation of transactions, is not available in the DeFi environment.
2. Macro-Supervision
• Data availability related to the nature, terms, and conditions of transactions allows for
the computation of aggregated figures at the level of each liquidity pool. Although
challenging, this approach could enable real-time monitoring of liquidity pools as they
are updated each time liquidity is provided or withdrawn.
• This data could also be useful for monitoring stablecoins issued based on
collateralization through liquidity pools. However, assessing the complete exposure of
each participant remains difficult due to the challenge of identifying the entities behind
wallet IDs. Supervision aims to evaluate the financial health of liquidity pools, including
susceptibility to failure, liquidity risks, and interconnectedness, to assess potential
contagion effects.
3. Investor Protection
• Investor protection, which relies on providing fair information to customers regarding
transaction costs and risks, and on protecting their interests in all circumstances, is
discussed in Section 9. This aspect does not depend on ledger data collection but
rather on off-chain information.
IBM Promontory confirms that ledger technologies offer real-time access to core transaction
information, enabling the potential development of supervisory tools. Through the analysis of
four use cases and eight protocols, IBM Promontory gathered data to understand, follow, and
monitor transactions. While data on buyers, sellers, or instrument identification remains
limited, core transaction data (price, quantity, time, etc.) is available, allowing for minimal
supervision. In comparison to the 500+ data fields collected in TradFi, DeFi transactions
typically involve 15-25 data points.
These considerations should be evaluated in light of two factors: the evolving maturity of DeFi
and the inherent complexity of TradFi transactions compared to the simpler and more
transparent nature of DeFi transactions. For example, in TradFi, a retail investor placing an
order via an intermediary would report a single transaction. In DeFi, this would be represented
by two transactions: one between the investor and the intermediary and another between the
intermediary and the counterparty. Each transfer of ownership is recorded on the ledger.
IBM Promontory is convinced that monitoring liquidity pools from a macro-supervision
perspective (assets vs liabilities) could provide valuable insights into the risks and exposures
associated with the largest liquidity pools, offering a starting point for macro-supervision
initiatives. To achieve this, supervisors would need to collect all data from the ledger since the
inception of the liquidity pool. For example, in the lending use case, supervisors could compute
the liquidity pool’s balance sheet by comparing the amount of tokens lent to the total amount
of assets collateralized, taking into account the current exchange rate. Additionally, evaluating
exposure to different wallets would allow for the assessment of various risks (exposure, credit,
liquidity) associated with the liquidity pools.
b) Challenges
Despite the potential opportunities within the DeFi ecosystem, several challenges and
drawbacks must be addressed to effectively implement embedded supervision:
1. Lack of standardization: the diverse DeFi ecosystem lacks standardization, requiring
monitoring tools to adapt to each protocol, smart contract, and their respective
versions. This process is both costly and time-consuming. A risk-based approach
targeting the largest protocols and liquidity pools may be a more feasible starting point,
allowing regulators and industry stakeholders to focus efforts on areas with the highest
potential impact.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 40 of 125
2. Technological and supervisory expertise: extracting and understanding data from
the ledger demands a combination of technological, legal, and economic expertise in
both DeFi and TradFi. This expertise is essential for navigating the unique
characteristics and complexities of DeFi. Additionally, the reliance on both on-chain
and off-chain data, which is often expensive to collect and may require manual efforts,
further complicates supervision.
3. Pseudonymization of wallets: the pseudonymization of wallets poses a significant
challenge as it obscures the identities of transaction participants, making it difficult to
evaluate their positions and assess potential risks. Addressing this issue would likely
require tracking financial flows through Crypto Asset Service Providers, which may not
always be feasible due to jurisdictional limitations and the global nature of DeFi
transactions.
Ultimately, embedded supervision in DeFi will differ substantially from TradFi supervision.
Despite the differences in dynamics, methods, and maturity, IBM Promontory believes there
is potential for developing effective DeFi supervision as the sector matures over time.
8.2. Other takeaways
While conducting the aforementioned data analysis, IBM Promontory also considered several
other topics related to the functioning of DeFi, all of which are important for supervision:
• Governance;
• Public information disclosure;
• Evolution and availability of protocols;
• Oracles; and
• Misalignment between the advertised business model and the smart contract setup.
a) Governance
The governance structure observed in the eight DeFi protocols is described in Annex 10.5 b)
Governance structure of this document. Governance tokens, issued by the decentralized
autonomous organization (DAO), can be traded like any other token. They provide a source
of funding for the DAO managing the protocol, which can issue new tokens to fund itself and
its teams through seed rounds.
These governance tokens can become concentrated in the hands of a few holders who
actively participate in decision-making and voting processes, effectively controlling the
protocol. This creates a risk of concentration within the governance framework of DeFi
protocols.
Additionally, issuing new governance tokens with new versions of protocols can increase
power concentration among founders. For instance, a protocol might initially distribute
thousands of governance tokens to over 100 users. Later, when launching a new version (V2),
it might create new tokens that grant more power to a few users or issue many new tokens
only to a few wallets, diminishing the influence of the original tokens. Such practices by the
DAO lead to a tendency towards centralised governance of protocols.
This risk is particularly heightened in the insurance use case, where governance tokens are
used to decide on reimbursing holders in case of claims, impacting the daily functioning of the
protocol.
Finally, since governance tokens are also Ethereum tokens, it is possible to see which wallets
hold them. However, it is impossible to identify the owners of these wallets or if a single person
or entity controls multiple wallets, making it difficult to identify potential conflicts of interest.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 41 of 125
b) Public Information Disclosure
In assessing the documentation available to the public on the protocols, the following
observations were made:
• A substantial amount of documentation is available to the public, including white
papers, yellow papers, and other disclosure documents.
• The documentation, while well-developed, is highly technical, requiring a certain level
of expertise in DLT and DeFi to fully understand. The mathematical formulas related to
price formation, interest rates, and premiums are particularly detailed. Thus, while
there is transparency on how the protocol works, expertise is required to comprehend
it fully.
• However, the documentation on the smart contracts themselves is inconsistent. It is
extensive for the most-used smart contracts but sparse or non-existent for others. This
inconsistency necessitates relying on minimal documentation to understand the smart
contract's function or assessing the smart contract code directly.
Regarding this last point, it is important to note that some protocols comprise over 50 different
smart contracts providing various services, resulting in very uneven associated
documentation.
c) Evolution and Availability of Protocols
During its work, conducted from June 2023 to January 2024, IBM Promontory observed two
significant events related to the protocols in scope:
• A major evolution of the Uniswap protocol (new major version), resulting in new smart
contracts and liquidity pools. When a protocol is updated, the old and new versions
typically coexist. As observed in Annex 10.5 c) Study on liquidity behavior when an
upgraded version of a protocol is released of this document, liquidity takes months to
transition from one version to another, with the liquidity pools of the previous version
remaining larger than those of the recent version for months. Adapting supervision
software to each new protocol and smart contract requires ongoing awareness,
development and updates, entailing additional costs for development and maintenance
of embedded supervision tools.
• The website and Dapp of Unslashed were unavailable for months. Although the
liquidity pools and smart contracts continued to function, these other elements were
not accessible.
d) Oracles
Oracles play a pivotal role in the DeFi ecosystem, collecting and disseminating data external
to the blockchain for use in DeFi transactions. These oracles can be automated (software or
hardware-based) or human-operated, interacting both inbound (importing information into the
DeFi system) and outbound (exporting data from the DeFi environment to external entities).
Oracles can also be internal, using platform-specific data like Uniswap's activity-based oracle,
or external, drawing data from various sources for broader accuracy, as seen with Chainlink's
integration in protocols like Aave and Nexus Mutual. The protocols assessed were using
oracles; for example, Uniswap uses an internal oracle based on its extensive activity, while
Curve Finance provides a mechanism for estimating the value of its LP tokens.
According to the Chainalysis Crypto Crime Report 2023
13
, criminals typically carry out oracle
manipulation attacks by using substantial amounts of cryptocurrency to rapidly increase the
trading volume of low-liquidity tokens on the targeted DeFi protocol, leading to significant price
increases not reflective of the wider market. These initial funds are often sourced through flash
13
Report can be found requested here: https://go.chainalysis.com/crypto-crime-2024.html
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 42 of 125
loans if the attacker does not have the funds on hand. Once an asset’s price is driven up, the
attacker can exchange their artificially inflated holdings for other tokens at a higher price than
the market or use them as overvalued collateral to borrow assets, never to be repaid.
A recent paper by the Bank for International Settlements (BIS) titled “The Oracle Problem and
the Future of DeFi
14
” highlighted the challenges of implementing fully decentralized oracles.
While consensus mechanisms can be resource-intensive and inefficient, highly centralized
oracles are prone to manipulation.
The oracle risk remains important from a supervisory perspective as it may impact the quality
of data available to the public. Incorrect data provided by oracles can unduly influence
transactions.
e) Misalignment between the Advertised Business Model and the
Smart Contract Setup
During its study, IBM Promontory observed that what is presented on a protocol’s web
interface often aligns with what is executed in the smart contract setup. For example, DeFi
protocols display prices to users that match what is seen on the interface. Unlike TradFi, DeFi
transactions do not have fixed prices; instead, users are given a price or range valid for a short
period, usually less than 10 seconds. In the protocols studied, IBM Promontory confirms that
these displayed and executed prices were aligned.
8.3. Additional data to be considered for supervision
As explained above, the dynamic data available on the ledger remains limited. IBM
Promontory also worked on identifying and collecting additional DeFi specific data that would
be useful from a supervisory perspective.
In this respect, IBM Promontory identified two sets of data that could be added to what is
immediately available on the ledger:
• Manually extracted data from protocols website, documentations, and available public
statistics set by third providers; and
• Computation of different data collected from the ledger itself to create a new, useful
set of data.
These data points allowed IBM Promontory to develop an “ID card” for each protocol and with
a detailed description provided in the appendices and therefore an understanding, from a
supervisory perspective, of the smart contracts, protocols, and financial instruments behind
each transaction. To a certain extent, this ID card corresponds to the needed reference data
about instruments and venues that is used in current supervisory practices.
Below is a non-exhaustive list of those data points that IBM Promontory believe should be
collected manually off-chain to support proper supervision. During the project, Promontory
collected those data mostly from the web sites and documentation provided by the DAO. It is
therefore indeed expected, to allow collection of those data, that there is documentation and
information provided by the DAO on the protocol’s web site.
14
https://www.bis.org/publ/bisbull76.htm
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 43 of 125
Concept
Data Point
Description
Potential supervisory
objectives
Protocol Identification
Protocol Name
The official name of the DeFi protocol.
Market Integrity
Version Number
Version of the protocol to identify updates and changes over time.
Market Integrity
Developer(s)
Entities or individuals who have developed the protocol.
Market Integrity, Investor
Protection
Source Code Repository
A link to where the protocol's source code is publicly stored, e.g.,
GitHub.
Market Integrity, Investor
Protection
Token Identification
Token Name
Official name of the token used within the DeFi protocol.
Market Integrity, Investor
Protection
Token Symbol
Abbreviation or ticker symbol for the token.
Market Integrity
Token Standard
The standard which the token adheres to, e.g., ERC-20 or ERC-721.
Market Integrity
Total Supply
The total number of tokens created.
Financial Stability, Market
Integrity
Liquidity Pool Identification
Pool Identifier
Unique identifier for the liquidity pool.
Market Integrity
Tokens Involved
Tokens that are pooled together.
Market Integrity
Total Value Locked (TVL)
The total value of assets locked in the liquidity pool.
Financial Stability
Fee Structure
Fee model for liquidity providers and users.
Investor Protection
Smart Contract Characteristics
Contract Address
The blockchain address of the smart contract.
Market Integrity, Investor
Protection
Contract Creator
Entity or individual who deployed the smart contract.
Market Integrity, Investor
Protection
Functionality Description
A description of the core functionalities provided by the smart
contract.
Market Integrity, Investor
Protection
Dependencies
Other smart contracts or external systems the smart contract
interacts with.
Market Integrity
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 44 of 125
Concept
Data Point
Description
Potential supervisory
objectives
Governance Structure
Governance Token
Token used to participate in governance decisions.
Market Integrity, Investor
Protection
Voting Mechanism
The mechanism through which proposals are voted on and
implemented.
Market Integrity, Investor
Protection
Proposal Submission
Process
Process for submitting and reviewing governance proposals.
Market Integrity, Investor
Protection
Historical Governance
Decisions
Record of past decisions made through the governance process.
Market Integrity, Investor
Protection
Key Metrics
User Base
Number and demographics of users.
Investor Protection
Transaction Volume
The volume of transactions over a specified period.
Market Integrity, Financial
Stability
Market Capitalization
The total value of the protocol's native token(s).
Financial Stability
Growth Rate
Metrics indicating the growth or decline over a specified period.
Financial Stability
Audits Put in Place
Audit Firm
Firm(s) that conducted the audit.
Market Integrity, Investor
Protection
Audit Report
Document detailing the findings of the audit.
Market Integrity, Investor
Protection
Identified Vulnerabilities
Vulnerabilities identified during the audit.
Market Integrity, Investor
Protection
Remediation Steps Taken
Steps taken to address the vulnerabilities identified in the audit.
Market Integrity, Investor
Protection
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 45 of 125
9. Phase 4: Conclusions
Focusing on the core question, i.e. whether embedded supervision of DeFi activity based on the
available public data can be developed, this concluding section develops two elements:
• A conclusion for each of the supervisory objectives:
o Investor protection;
o Market integrity;
o Financial stability;
• Options identified by IBM Promontory for policymakers.
During the final stage of the project, IBM Promontory also met several stakeholders, ranging
from regulators to DAO or Blockchain experts, to validate the following conclusions
15
.
9.1. Conclusion per supervisory objective
To assess the different angles of possible supervision of DeFi, IBM Promontory developed the
below conclusions for each supervisory objective.
a) Investor Protection
The assessment in terms of transparency and disclosure of the protocols led to the following
conclusions:
• Availability of information: the studied DeFi protocols had a fair amount of information
available to their users on their websites. Protocols’ websites were easily accessible and
organized in a way so that information on each smart contract can be found easily.
Nevertheless, one protocol’s website went down during the project and remains
unavailable several months later, whereas the protocol and smart contracts remained
accessible. This example raises the risk of long-term availability of the information.
• Clarity and accuracy of information: as a protocol can publish dozens of smart
contracts, clarity of information can be uneven. Some protocols and contracts are
extremely well documented while others are not documented at all. Therefore, we
conclude that the information documentation differs substantially from one protocol to
another or from a smart contract to another. Regular updates of information could not be
assessed but should also be considered as a potential risk, i.e., there is no clear
guarantee that information is up to date.
• Accessibility of information to users: overall, the documentation provided is very
technical, with a vocabulary that is specific to DeFi, and cannot be understood by regular
users. In addition, the usage of a vocabulary that is close to that of TradFi, although
concepts are different, ultimately leads to confusion.
• Harmonization of documentation: the documentation is of different format, structure,
and organization across the protocols and is therefore not harmonized.
• Risk identification and assessment: the documentation provided does not identify,
assess, or rank risks associated with the use of the different protocols.
As a conclusion, regarding transparency and disclosure, investor information is available and
up to date, but generates risks for investors as it is uneven, heterogeneous, and very technical.
15
Stakeholders met: Stéphanie Cabossiaras (magistrate at court), Chainanalysis, Kaiko, AMF and Uniswap.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 46 of 125
b) Market Integrity
Micro-supervision focuses on the conduct of individual DeFi actors. In this respect, the key
elements of micro-supervision for DeFi pertain to market abuse and anti-money laundering
activities:
• Market manipulation: as stated earlier, essential data requirements to understand the
nature and the terms of the transactions are generally met, apart from the wallet
ID/customer identification, which is a core issue. If off-chain data is added to the relevant
information collected to the ledger, a minimal degree of micro-supervision could be
envisaged on some key protocols (for example, the top five protocols with the highest
TVL) to detect market manipulation. Nevertheless, the amount of off-chain data that
would need to be collected manually and its lack of standardization would prompt limiting
such supervision to some protocols for cost containment purposes. In addition, where
instances of market manipulation would be detected with such a framework, the
pseudonymity of the wallet ID would hamper further investigations to identify
perpetrators.
• Know Your Customer (KYC): the main gap in terms of data access remains the
identification and assessment of entities or persons involved in DeFi transactions, since
only the wallet ID is retrievable in the ledger. This lack of information hampers the quality
of trade monitoring as it is difficult to identify who is behind a wallet ID in case of market
manipulation, including with a collusive pattern since there could be several wallets
owned by the same entity/person. It is important to note that out of eight protocols
assessed, one of them (in insurance) claims to conduct KYC before accepting new
members/users.
• Insider trading prevention: without information on the individuals or entities associated
with a wallet ID, insider trading cannot be effectively prevented. The only possible
preventative measure would be to monitor the activity of the wallet IDs belonging to the
main governance actors, specifically those holding the largest number of governance
tokens for a given protocol. Although these actors may not be identifiable, monitoring
their activity would allow for the detection of potential misconduct. If significant holders
of governance tokens engage in behaviour that could harm the protocol or compromise
investor protection, it would trigger a warning for the entire protocol.
• Price Discovery Efficiency: price formation is usually executed by complex
mathematical formulas based on the size of liquidity pools and eventually oracles. It has
the advantage of being transparent and understandable, with some expertise. In
addition, the liquidity pool system is also dependent on bots or AMMs who are executing
arbitrage between different liquidity pools of different protocols. Ultimately, this system
seems to allow the provision of transparent price data.
• Fair competition and market access: this criterion is at the heart of DeFi’s stated
raison d’être, i.e., the absence of intermediaries should facilitate market access to
anybody and therefore foster competition.
MiCA covers today several of the above elements such as market access, market abuse
detection, etc. but does not apply to DeFi. In addition, the complexity of the DeFi systems would
make it difficult for intermediaries to address challenges of, for example, market manipulation
across several protocols. It is therefore important to consider additional tools to support market
integrity as described in Section 9.2.
c) Financial Stability
It is difficult to consider actual financial stability for DeFi given the numbers at stake without also
assessing the interlinkage between DeFi and TradFi. Nevertheless, in a system based on
liquidity pools, macro-supervision of such liquidity pools to assess the systemic risks associated
with them should be considered as a possible priority for supervisors.
This supervision of liquidity pools could be considered as an opportunity in two areas:
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 47 of 125
• Systemic risk identification and mitigation: IBM Promontory has not assessed the
systemic risk across the different liquidity pools during its analysis. Nevertheless, all
required data to assess the systemic risk of a single liquidity pool, i.e., its exposure, the
quality of its collateral management, and the balance between its assets and liabilities,
is available. Data is therefore available to evaluate the liquidity, credit, and stability risks
of liquidity pools and their likelihood to fail on extreme events. In addition, available data
allows exposure and liquidity flow analysis to assess interlinkage between different
liquidity pools, linked exposures, and therefore potential contagion effects.
• Liquidity risk: based on the above assessment, IBM Promontory also considers that it
is possible to address and assess potential liquidity risks within specific liquidity pools.
This would involve assessing the depth and resilience of DeFi liquidity pools. Again, such
analysis could not be conducted across the board given the heterogeneity of the different
smart contracts and protocols but could be done on a subset of targeted liquidity pools
with high TVL.
To conclude, based on the accessible data, there is room for supervisors to develop supervision
on a target number of liquidity pools, macro-supervision analysis to assess their robustness (in
particular under stress events), their exposure, and possible contagion effect.
9.2. Options for Policymakers
As the DeFi environment continues to evolve and mature, policymakers face numerous
challenges in adapting to this rapidly changing landscape. In this section, IBM Promontory
presents short-term and mid-term options for policymakers to consider in addressing these
challenges.
a) Short Term
i. Coordination
The analysis conducted above demonstrates that the DeFi space has continually and
substantially evolved over the past months and years and will continue to do so. For instance,
the transition of all DEXs from an order matching system to a liquidity pool mechanism illustrates
the evolution in terms of the ecosystem's functioning.
It is therefore crucial for policymakers to establish a forum to exchange information on these
evolutions, understand their functioning, and set up coordination mechanisms among various
stakeholders. Such forums are essential for facilitating education, understanding, monitoring,
and exchange within the DeFi space. The scope should be global or, at a minimum, European,
and this coordination should include all relevant actors, such as supervisors, users, DAOs, and
legal professionals. Coordination could take the form of an observatory, for example, serving as
a platform for promoting the development of standards, exchanging ideas on regulatory needs,
and discussing supervision challenges.
ii. Supervision Proof of Concept
In light of the findings of this report, implementing a supervision proof of concept (PoC) focused
on a few selected protocols based on specific criteria, such as TVL, could be another viable
step. Building on the tool that IBM Promontory developed, it would be possible to set up a
database that is continuously updated with data from the ledger on the eight identified protocols.
This PoC would need to involve not only a technical provider but also actual supervisors
analysing and monitoring the data to assess whether such analysis could serve as a basis for
potential supervisory findings. A possible next step would be extending the system to new
protocols and eventually focusing on the top five DEXs or lending protocols in terms of TVL, for
both market manipulation and liquidity pool exposure. This would require studying new smart
contracts and manually collecting off-chain data. Lastly, a robust framework should be
established for managing the tools in a run mode (including execution and incident management
procedures). This PoC would enable the commencement of both micro-supervision (e.g.,
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 48 of 125
market manipulation) and macro-supervision (e.g., liquidity risk) with supervisors from National
Competent Authorities (NCAs) or European Supervisory Authorities (ESAs). In addition to the
tool, the objective of this PoC would be to start training and educating supervisors on the topic
and develop assessment methodologies specific to DeFi. According to IBM Promontory, macro-
supervision of liquidity pools is of higher interest for supervisors, given that micro-supervision
will face the constraint of wallet pseudonymity.
iii. Partnership and Additional Tools
The PoC would also provide an opportunity to evaluate various supporting tools and
technologies for supervision. Emerging data providers that collect and process data from
blockchains could assist regulators in obtaining relevant information and potentially develop
supervisory modules for direct data provision, which could replace some tools developed by
IBM Promontory. Examples of existing tools are provided in Appendix 10.5. Such data providers
should be able to follow financial flows across wallet IDs, as it would be a core component to
support investigations and should be considered as part of a final solution for supervisors.
Working on their usage and capabilities should be an important task in setting up a potential
future supervision system. Without being exhaustive, IBM Promontory considers that the
following tools should be assessed to support future supervision:
• Blockchain analytics software: tools like Chainalysis or Elliptic could be crucial for
analysing transactions and identifying patterns that may indicate fraudulent or suspicious
activities, as well as for following financial flows and supporting proper investigations.
Those tools present high promises to overcome the wallet ID limitations.
• Smart contract auditors: firms such as Consensys, OpenZeppelin, and Quantstamp
provide essential services by auditing the smart contracts that underpin DeFi
applications, ensuring they are secure and free from vulnerabilities.
• AI and machine learning platforms: technologies like TensorFlow, IBM Watson, and
Google AI could support the processing and analysis of large datasets, monitoring DeFi
markets in real-time, predicting trends, and alerting on potential issues.
• Risk management software: solutions including AxiomSL and Riskalyze offer
frameworks to assess and model the unique risks that DeFi presents under various
market conditions.
• APIs: platforms like CoinAPI, CoinGecko, or Blockchair facilitate the integration of data
from various DeFi platforms into a central regulatory system, allowing for streamlined
monitoring and analysis.
b) Mid to Long-Term
As the DeFi ecosystem continues to grow and mature, it is essential to strike a balance between
fostering innovation and ensuring adequate regulation and supervision. IBM Promontory argues
that three key areas require attention: standardisation, tools, and legislation.
i. Standardisation
Standardisation could encompass various elements, such as transparency, security, and
alerting, to facilitate the development of embedded supervision. IBM Promontory identified,
during its work, four areas of standardisation that it would consider valuable for supervision:
additional standard data to be written on the ledger, circuit breakers, KYC tokens, and audit and
security.
IBM Promontory is of the view that the first element of such standardisation is to require or agree
on additional data that should be written into the ledger and in what format. Each smart contract
can control what is written in the ledger when executing a transaction. In this respect, proposing
standard data to be written by each smart contract on what is today off-chain data, or data
requiring compute, would significantly reduce the supervisory burden and facilitate assessment.
Examples of such data are described in Section 8.3., such as the protocol name, version
number, token symbol, price, pool identifier, contract address, and name. If there were a
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 49 of 125
standard agreed upon to write this data on the ledger in a common format, it would greatly
enhance transparency and supervisory capabilities. In this context, the smart contract would
write in the ledger, together with its specific data set in the Patricia Merkle tree, the agreed
reference data that would make better understanding of the executed transaction. The data
would be stored on the ledger and accessible to everyone.
Additionally, the concept of "circuit breakers" or "pause functions" could be standardised,
allowing developers or governance to halt activities in case of anomalies or suspicious
behaviours. IBM Promontory observed that, even when the web interfaces are no longer
available, protocols continue to run as long as they can be used, as is the case for former
versions of protocols. Those protocols having obvious flaws identified can, therefore, continue
to be used, posing a risk to potential investors who may not be aware of those flaws.
Standardising circuit breaker capacities could allow for the organised 'closing' of protocols via
specific smart contracts managed by governance tokens, thereby avoiding potential future risks.
Unfortunately, those additional circuit breakers may be subject to hacks and should therefore
be well secured when developed.
Similarly, the development of KYC tokens could present a viable solution for addressing
pseudonymization concerns within the DeFi space. A KYC token would be issued by a KYC
company, which would conduct due diligence on the token holder and contain the relevant
holder’s information. This KYC token could be linked to a wallet ID and required by standard
smart contracts to execute certain transactions. By mandating KYC tokens for safer smart
contract execution, a more secure and transparent DeFi environment can be envisioned.
This approach would involve a dual structure, where secure smart contracts necessitate KYC
tokens and third-party providers carry out KYC procedures on relevant actors, issuing signed
and accredited tokens. There are currently technical solutions available to attach such tokens
to wallets and verify the identity of the token holder. This would facilitate the involvement of
institutional investors in DeFi, as they would be assured of proper identification and traceability
of participants in the ecosystem.
Furthermore, the development of coding and development standards related to smart contract
security could also help reduce the incidence of hacks and flaws in smart contracts. Developing
such standards will require a governance system, which could initially be industry-led or jointly
led by regulators and industry, before transitioning to a more comprehensive legislative
framework. As previously mentioned, the DeFi space is a rapidly evolving ecosystem, and only
joint initiatives can drive its evolution effectively.
ii. Legislation
Regarding the potential legislative actions to enhance supervision, it currently seems
premature, as DeFi is still maturing and evolving rapidly. For example, the shift to liquidity pools
has fundamentally changed the DeFi landscape, and further transformations may happen in
the near future. Given the rapid pace of these changes and their potential significant impact on
the DeFi ecosystem, designing legislation in this dynamic environment is challenging.
First, any legislation would need to address the issue of territoriality to ensure it captures the
relevant actors. Previously, this has been achieved by targeting entities marketing services and
distributing products in the EU, which is not yet happening with DAOs.
Next, it would be necessary to establish a regulatory framework developing the fundamentals
on investor protection, market integrity, and financial stability, so that supervision can effectively
build on this foundation.
In conclusion, it seems more appropriate at this stage to work closely with industry actors to
build exchange forums and develop best practices together before considering potential
legislative initiatives.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 50 of 125
10. Appendices
10.1. Annexes of Section 1: DeFi functioning
A DeFi application is a code (also known as a smart contract) that operates on a public
blockchain, which provides the computational layer on which transactions are executed and
recorded. The execution of a smart contract is triggered when that smart contract is “called” by
a transaction on the blockchain. If triggered, the smart contract is executed through the
blockchain’s network of computers and will produce a change in the blockchain’s “state.” Smart
contracts can be used, for example, to issue and manage tokens, escrow tokens, or carry out
any number of “if/then”-type computations. In DeFi, financial products and services are created
using smart contracts operating in a multilayered stack of technologies that interact with each
other. Various products and services are offered at each level of this stack. According to the
OICV IOSCO Decentralized Finance Report (March 2022), the DeFi multilayered technology
stack can be presented in four distinct “layers”, as listed below:
• An “application” layer – Front-end user interfaces, APIs, and other code that allow
participants to interact with smart contracts. Our project will also aim to manually collect
some data from this layer whenever possible. Today, these applications are primarily
hosted off chain.
• An “asset” layer – Crypto assets (coins and tokens) that participants and smart contracts
create and transfer on a blockchain.
• A “smart contract” layer – Smart contracts (and auxiliary software) used to provide
functionality to DeFi products and services.
• An “asset” layer – Crypto assets (coins and tokens) that participants and smart contracts
create and transfer on a blockchain.
• A “settlement layer” – Where the consensus state of the blockchain is maintained, i.e.,
transactions are recorded. This is the main layer where information will be collected for
this pilot project.
The following scheme, from the recent Institute of International Finance report, presents the four
layers:
Source: Decentralized Finance: Use cases, challenges, and opportunities
Originally, there were simple smart contracts that allowed a simple transaction of assets (e.g.,
ether against bitcoins); however, within the last few years, more complex smart contracts have
emerged and have been developed to create an entire financial ecosystem, DeFi, covering
lending, derivatives/synthetics, trading, clearance activity, settlement activity, asset
management and advisory.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 51 of 125
One core characteristic of these smart contracts is that they are open to all users. Therefore, a
company/programmer could develop a smart contract (i.e., a piece of code), which can be
executed by anybody peer-to-peer, independently from the company that developed it (if there
are no governance limitations), everywhere on the DLT/blockchain (usually Ethereum). In
addition, anyone can build further on an existing smart contract and modify/change it. This is
named composability. There are, for example, currently existing DeFi and smart contract
insurance protocols that enable participants to obtain protection against a specific event (e.g.,
the hack or failure of a particular DeFi protocol or centralized trading platform with which
participants have crypto assets on deposit, a stablecoin price crash, etc.) in exchange for a fee
(or “premium”), which goes to the participants who assume the risk of the event coming to pass
by depositing the crypto assets that would be used to cover a claim. DeFi increases the overall
complexity of the crypto-asset market, which could further exacerbate existing risks.
Source: OECD - Why-Decentralized-Finance-DeFi-Matters-and-the-Policy-Implications
a) Introduction to Ethereum
The Ethereum project was conceived by Vitalik Buterin, a Russian Canadian, to add
programmability to Bitcoin. Vitalik found Bitcoin’s scalability and flexibility limitations to be
significant challenges to the variety of use cases that could be enabled. In response, he
developed his own project and unveiled the first Ethereum whitepaper in late 2013, which
outlined the entire protocol across 36 pages. It is important to distinguish between the Ethereum
network and the ETH cryptocurrency, which is runs on the Ethereum network.
Following the publication of the whitepaper, the Ethereum project was officially founded in
January 2014 by eight individuals: Vitalik Buterin, Anthony Di Iorio, Mihai Alisie, Amir Chetrit,
Joseph Lubin, Gavin Wood, Charles Hoskinson, and Jeffrey Wilcke. In July 2014, Ethereum
conducted its Initial Coin Offering (ICO), selling 60 million Ether (ETH) at a unit price of $0.31.
This fundraising effort collected over 31,259 Bitcoins, equivalent to more than $15 million at the
time of the ICO, which served to finance the project. After more than a year of development,
Ethereum officially became public in July 2015. Since then, the Ethereum network has played
a crucial role in the development of many use cases, including the DeFi sector, as a vast majority
of DeFi projects are developed using the Ethereum network. The following are some key
statistics about Ethereum:
Transactions per day: around 1 million every day (source: etherscan.io)
Number of nodes: 6749 (as of 20/10/2023, source: etherscan.io)
ETH market capitalization: 182€ million (as of 20/10/2023, source: coinmarketcap.com)
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 52 of 125
b) Core components of the Ethereum ecosystem
i. Smart contracts
Smart contracts are self-executing, programmable agreements between two or more parties
that are written in code and deployed on a blockchain, such as Ethereum. This decentralized,
trust less environment ensures the immutability of smart contracts, meaning that once they are
deployed, they cannot be altered. This ensures that the terms and conditions remain consistent
and tamper-proof.
As autonomous computer programs, smart contracts execute automatically based on
predefined rules and conditions, eliminating the need for intermediaries, and reducing the
potential for human error or manipulation. The transparency provided by blockchain technology
allows all transactions and contract executions to be recorded, offering full visibility into the
contract's history and actions, which in turn helps build trust among participants. The
decentralized nature of blockchain technology helps that smart contracts are protected against
single points of failure and potential attacks. By automating processes and removing
intermediaries, smart contracts streamline operations and reduce transaction costs, increasing
efficiency. Nevertheless, smart contracts can still be vulnerable to bugs or security flaws in the
code, so it is crucial to thoroughly audit and test the code before deployment. Smart contracts
can be applied to various industries and applications. In financial services, they can be used for
lending, derivatives, insurance, and asset management, automating processes, and enhancing
efficiency. Supply chain management can benefit from smart contracts by tracking and verifying
the movement of goods, ensuring transparency, traceability, and compliance throughout the
supply chain. They can also help manage and verify digital identities, granting or restricting
access to services based on predefined criteria. Secure and transparent voting processes can
be created using smart contracts, ensuring the integrity of the results, and reducing the risk of
fraud. Additionally, intellectual property rights can be managed through smart contracts for
licensing, distribution, and royalty payments for content creators.
EVM (Ethereum Virtual Machine)
The Ethereum Virtual Machine (EVM) is a core component of the Ethereum platform, serving
as a decentralized, Turing-complete (capable of simulating any computer algorithm, given
enough resources) computing environment that enables the execution of smart contracts. The
EVM acts as a global, shared runtime environment that isolates smart contracts from the
underlying hardware and software, ensuring consistent execution across all network nodes. The
EVM plays a crucial role in maintaining the security, transparency, and decentralization of the
Ethereum network.
ii. DApps
Decentralized applications, or DApps, are software applications built on blockchain platforms
like Ethereum. They function autonomously, without a centralized authority or single point of
control, and make use of smart contracts to perform various functions and provide services.
DApps’ decentralized nature allows them to operate on a distributed network of nodes, which
ensures no single entity has control over the application or its data, enhancing security,
resilience, and censorship resistance.
DApps are typically open source, though some may choose to keep certain parts of their
codebase proprietary for competitive or security reasons. The open-source nature of many
DApps is often seen as a strength, as it allows for community scrutiny, collaborative
improvements, and fosters trust among users. To foster user engagement and maintain a
healthy ecosystem, DApps often incorporate incentive mechanisms, such as a native token or
cryptocurrency, to reward users and developers for their participation in the network. These
incentives can take various forms, such as token rewards for completing tasks, contributing
value to the network, or voting mechanisms that allow users to have a say in the direction of the
project. Furthermore, DApps follow specific protocols and consensus mechanisms, like Proof of
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 53 of 125
Work (PoW) or Proof of Stake (PoS), to maintain the integrity of the underlying blockchain and
ensure the validity of transactions. There are numerous potential use cases for DApps across
various industries. In DeFi, DApps enable the creation of financial services such as lending,
borrowing, trading, and asset management without traditional intermediaries like banks.
A substantial amount of powerful DApps run on the Ethereum blockchain; they are also referred
to as protocols. In DeFi in particular, prominent protocols include Uniswap, MakerDAO, Aave,
Lido and Curve Finance.
iii. ERC-20 Tokens
ERC-20 is a widely used technical standard for creating and managing tokens on the Ethereum
blockchain. The ERC-20 standard provides a common set of rules and guidelines for developers
to follow, ensuring their tokens are compatible with other projects, wallets, and exchanges in
the Ethereum ecosystem. This promotes a higher degree of compatibility and simplifies the
process of integrating new tokens into existing infrastructure. Developers can create ERC-20
tokens with unique properties and use cases, such as utility tokens for accessing specific
platforms or services, governance tokens for decentralized decision-making, or asset-backed
tokens representing real-world assets.
ERC-20 tokens are managed by smart contracts, which automate various aspects of token
management, like minting, burning, and distributing tokens. This enables a higher level of
security, transparency, and efficiency compared to traditional, centrally managed tokens, as the
smart contracts are tamper-proof and transparent, and can be audited by anyone. The ERC-20
standard has become the de facto standard for creating and managing tokens in the Ethereum
ecosystem, playing a critical role in the growth of the blockchain industry. By providing a clear
and consistent framework for token development, the ERC-20 standard has facilitated
innovation and interoperability within the blockchain industry. One of the key features of ERC-
20 tokens is the implementation of standardized functions that enable users to perform basic
operations like checking balances, transferring tokens, and approving the use of tokens by third-
party smart contracts. This ensures consistent behaviour across all ERC-20 tokens, making it
easier for developers to integrate them into applications and platforms. The ERC-20 standard
is not the sole standard to create tokens on the Ethereum blockchain: others exist, such as the
ERC-721 and ERC-1155 that enable the creation of Non-Fungible Tokens.
Ethereum’s features constitute the Ethereum ecosystem. Its permissionless nature enables
anyone with the appropriate technical acumen to contribute to the ecosystem, such as by
developing smart contracts (which we explain afterward). The ecosystem is a genuine
differentiating factor when comparing with other blockchains like Bitcoin, which do not support
features as smart contracts.
This ecosystemic approach gave birth to new use cases for the Ethereum blockchain, the advent
of DeFi, or DeFi. Other blockchains like Solana or Cardano also serve as platforms for DeFi;
however, Ethereum remains the leader, which a few numbers suffice to illustrate:
• 19,5€ billion of TVL[1], the most of any blockchain involved in DeFi and representing
54% of all DeFi’s TVL[2] (source: Defillama, accessed on 20/10/2023).
• 1565 DApps, the most of any blockchain (source: alchemy.com).
c) Relevant extracts from the Chain analysis Crypto Crime Report 2023
Source: Chainanalysis Crypto Crime Report - The Chainalysis 2023 Crypto Crime Report
P24 on sanctions
The case of a decentralized service like Tornado Cash is more complicated. While its front-end
website was taken down, its smart contracts can run indefinitely, meaning anyone can still
technically use it at any time. That suggests sanctions against decentralized services act more
as a tool to disincentivize the service’s use rather than cut off usage completely. In the case of
Tornado Cash, those incentives appear to have been powerful, as its inflows fell 68% in the 30
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 54 of 125
days following its designation. That is especially important here given that Tornado Cash is a
mixer, and mixers become less effective for money laundering the less funds they receive
overall.
P44 on money laundering
Source: The Chainalysis 2023 Crypto Crime Report
More illicit funds were sent to DeFi protocols than ever before, a continuation of a trend that
began in 2020. Cybercriminals send funds to DeFi protocols not because DeFi is useful for
obscuring the flow of funds. In fact, quite the opposite is true, as unlike with centralized services,
all activity is recorded on-chain. Keep in mind too that DeFi protocols do not allow for the
conversion of cryptocurrency into fiat, so most of those funds moved next to other services,
including fiat off-ramps. And as we see below, all usage of DeFi protocols for money laundering
is carried out by one criminal group: hackers stealing cryptocurrency. Hackers holding stolen
cryptocurrency are the only criminal category sending most funds to DeFi protocols, at a
whopping 57.0%. 2022 was an enormous year for hacking, hence why these cybercriminals
were single-handedly able to drive the overall increase in the usage of DeFi protocols for money
laundering. The fact that DeFi protocols themselves were the biggest target of hacks in 2022
also influences these numbers. In DeFi hacks, attackers often end up with tokens that are not
listed on other exchanges, so they need to use DEXs to swap them for more liquid crypto assets.
DEXs have historically been used to convert funds to Ether, which can then be sent to
Ethereum-based mixers. DEXs have also been used to convert to assets that will be more likely
to hold their value, or in the case of stablecoins, to swap to an asset that cannot be frozen by
the stablecoin issuer. However, as noted previously, DEXs do not enable the conversion of
funds from cryptocurrency to fiat currency — this must still be done through a centralized
exchange or other fiat off-ramp. Aside from hackers, crypto criminals send most of their funds
directly to centralized exchanges, but there are some notable exceptions. For instance, darknet
market vendors and administrators send most of their funds to other illicit services — primarily
other darknet markets, some of whom may offer money laundering services like those of the
now-shuttered Hydra Market. Darknet market addresses also sent a large share of funds to
high-risk exchanges, such as Bitzlato, a Russia-based exchange shut down in an international
law enforcement action recently for its money laundering activity. Ransomware attackers are
another interesting case. Addresses associated with them send a disproportionately large share
of funds to mixers and make heavy use of illicit services. Fraud shop vendors and administrators
are also notable for their outsized mixer usage. In total, we see that over half of all funds sent
from illicit addresses travel directly to centralized exchanges, both mainstream and high-risk,
where they can be exchanged for fiat unless compliance teams act. However, over 40% of illicit
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 55 of 125
funds move first to intermediary services — primarily mixers and illicit services or DeFi protocols
— with most of those funds coming from ransomware, darknet market, and hacker addresses.
Source:
The Chainalysis 2023 Crypto Crime Report
P57 – Victims of attacks
Source: The Chainalysis 2023 Crypto Crime Report
DeFi protocols as victims accounted for 82.1% of all cryptocurrencies stolen by hackers — a
total of $3.1 billion — up from 73.3% in 2021. And of that $3.1 billion, 64% came from cross-
chain bridge protocols specifically. Cross-chain bridges are protocols that let users port their
cryptocurrency from one blockchain to another, usually by locking the user’s assets into a smart
contract on the original chain, and then minting equivalent assets on the second chain. Bridges
are an attractive target for hackers because the smart contracts in effect become huge,
centralized repositories of funds backing the assets that have been bridged to the new chain —
a more desirable honeypot could scarcely be imagined. If a bridge gets big enough, any error
in its underlying smart contract code or other potential weak spot is almost sure to eventually
be found and exploited by bad actors. How do we make DeFi safer? DeFi is one of the fastest-
growing, most compelling areas of the cryptocurrency ecosystem, due to its transparency. All
transactions happen on-chain, and the smart contract code governing DeFi protocols is publicly
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 56 of 125
viewable by default, so users can know exactly what will happen to their funds when they use
them. That is especially attractive now in 2023, as many of the market blowups of the past year
were due to a lack of transparency into the actions and risk profiles of centralized cryptocurrency
businesses. But that same transparency is also what makes DeFi so vulnerable — hackers can
scan DeFi code for vulnerabilities and strike at the perfect time to maximize their theft.
P59 – how to make DeFi Safer?
DeFi code auditing conducted by third-party providers is one remedy to this. Blockchain security
firm Halborn is one such provider and is notable for its clean track record — no DeFi protocol to
pass a Halborn audit has subsequently been hacked. We spoke with Halborn COO David
Schwed, whose background includes stints in risk and security at large banks like BNY Mellon,
about how DeFi protocols can better protect themselves. He emphasized that many of the
issues in DeFi come down to a lack of investment in security. “A big protocol should have 10 to
15 people on the security team, each with a specific area of expertise,” he told us. He indicated
that the core issue is that DeFi developers prioritize growth over all else, and direct funds that
could fund security measures to rewards to attract users. “The DeFi community is not
demanding better security — they want to go to protocols with high yields. But those incentives
lead to trouble down the road.” Schwed told us that DeFi developers should look to traditional
financial institutions for examples of how to make their platforms more secure. “You don’t need
to move as slow as a bank, but you can borrow from what banks do.”
Some measures he recommends include:
Test protocols with simulated attacks. DeFi developers can simulate different hacking
scenarios on testnets to test how their protocol stands up to the most common attack vectors.
Take advantage of crypto’s transparency. One huge advantage of a blockchain like
Ethereum is that transactions are visible in the mempool before they are confirmed on the
blockchain. Schwed recommended that DeFi developers monitor the mempool closely for
suspicious activity on their smart contracts to detect attacks as early as possible.
Circuit breakers. DeFi protocols should build out automated processes to pause their protocols
and halt transactions if suspicious activity is detected. “It’s better to briefly inconvenience users
than to have the entire protocol get drained,” said Schwed. Schwed also told us that regulators
have a role to play here and can help make DeFi safer by setting minimum security standards
that protocol developers must follow. The data on DeFi hacks makes one thing clear: Whether
achieved through regulation or voluntary adoption, DeFi protocols will benefit from adopting
better security for the ecosystem to grow, thrive, and eventually penetrate the mainstream.
P66 on oracles
As we covered in our section on stolen funds, 2022 was the biggest year in crypto hacking
history, with more than $3.8 billion stolen. However, not all those attacks were what one may
think of as hacks in the traditional sense. In some cases, bad actors were able to drain DeFi
protocols of funds without taking advantage of an error in the protocol’s code. These attackers
were able to do this by manipulating the price oracles DeFi protocols use to ensure the assets
available on their platforms are priced in accordance with the wider cryptocurrency market. As
such, we will refer to these unique instances as oracle manipulation attacks. Bad actors typically
carry out oracle manipulation attacks by using substantial amounts of cryptocurrency to quickly
increase the trading volume of low-liquidity tokens on the targeted DeFi protocol, which can lead
to fast, significant price increases not reflective of the wider market. Those initial funds are often
sourced through a flash loan if the attacker does not have the funds on hand. Once an asset’s
price has been driven up, the attacker can then exchange their artificially inflated holdings for
other tokens with greater liquidity and a more consistent value or use them as (worthless)
collateral to borrow assets, never to be repaid. Overall, we estimate that in 2022, DeFi protocols
lost $386.2 million in 41 separate oracle manipulation attacks.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 57 of 125
Source: Chainalysis yearly report 2023
Some attackers have tried to argue that oracle manipulation attacks are not criminal in the same
way a more straightforward hack is. In fact, Avraham Eisenberg, the individual behind one of
the biggest oracle manipulation attacks of the year, claimed that his actions were perfectly legal
and represented nothing more than a “profitable trading strategy.” However, the SEC and CFTC
both filed charges of market manipulation against him, with the DOJ also bringing a formal
accusation. While the trial has not occurred yet, the complaint suggests that authorities will not
allow these attackers to evade responsibility, even if the targeted protocol technically behaved
as designed. Below, we will look at Eisenberg’s infamous million attack on Mango Markets as
an example of how oracle manipulation attacks can work. Breaking down the Mango Markets
exploit, one of the biggest oracle manipulation attacks of last year was the October 2022 attack
of Mango Markets, a DEX on the Solana blockchain, which saw $117 million in assets drained
from the protocol. The Mango Markets exploit was particularly interesting in that the perpetrator,
Avraham Eisenberg, identified himself publicly afterwards and argued that his actions did not
constitute a crime.
Here is how the exploit occurred from an on-chain perspective: 1.) Eisenberg started with $10
million USDC (it is possible he also used funds not attributable to him on-chain to manipulate
asset prices on other exchanges), split across two separate accounts at Mango Markets. 2.)
Eisenberg used one account to short 488 million MNGO (MNGO, or Mango, is the governance
token for Mango Markets) — effectively selling 488 million MNGO on leverage — while the other
account took the opposite side of that trade, using leverage to buy the same amount. 3.)
Eisenberg’s leveraged purchase of MNGO, combined with further buying of MNGO on other
DEXs, pushed the price of MNGO up very quickly on spot exchanges. This was possible
because MNGO was a low-liquidity asset without much trading volume. The account used to
purchase MNGO immediately profited roughly $400 million in paper gains because all of
Eisenberg’s buying activity significantly boosted the asset’s price. 4.) With such a high portfolio
value, Eisenberg was able to borrow against his artificially inflated MNGO holdings and remove
all the assets held by Mango Markets. This activity caused MNGO’s price to drop immediately,
so his long positions were liquidated due to loss of collateral value, but it was too late —
Eisenberg had already “borrowed” all of Mango Market’s assets with any real value.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 58 of 125
10.2. Annexes of section 5: Protocols
a) Protocols selection methodology
The objective of this sub-section is to describe in more detailed the approach and the
methodology developed to select the two protocols for each of the four use cases.
i. Data sources
The first step was to identify the candidate protocols for selection. This involved the identification
of DeFi information sources, i.e., the prominent actors responsible for gathering data on DeFi
protocols that would facilitate the collection of relevant data nourishing the selection process.
The table below lists the sources IBM Promontory selected to feed its study. Given the potential
uncertainty around some of those sources’ reliability, IBM Promontory tried, whenever possible,
to cross-check data across various sources at each step of the process.
SOURCE TYPE
SOURCE DETAILS
DATA AGGREGATORS
CoinMarketCap, EtherScan, DefiLlama, Ethereum, DefiPrime, Alchemy,
Binance, Coinbase
NEWS & INSIGHTS ON
PROTOCOLS
Bitcoinmarketjournal, Cointribune, Cryptonews, Cryptoast, Cointribune,
Coindesk and JournalDuCoin.
Medium, Dune, Messari, AnalysticsInsight, Glassnodeinsights, Defiprime,
Crypto.com, Linkedin
REPORTS
Crypto, tokens and DeFi: navigating the regulatory landscape (BIS)
Crypto-assets and DeFi - Systemic implications and policy options (ESRB)
Why Decentralized Finance (DeFi) Matters and the Policy Implications
(OECD)
“Decentralized” or “disintermediated” finance: what regulatory response?
(ACPR)
Finance décentralisée (DeFi), protocoles d'échange et gouvernance
(AMF)
Decentralized Insurance Alternatives: Market Landscape, Opportunities
and Challenges (SOA research institute)
The State of DeFi Insurance Alternatives (DeFi Cover) 2023 (Open Cover)
DeFi Risk, Regulation, and the Rise of DeCrime (Elliptic)
Decentralized Finance (DeFi) (EU Blockchain Observatory and Forum)
Decentralized Finance (DeFi) Internet Banking Beyond Borders
(Grayscale)
Finance Décentralisée (Innovation center/Hub 612 and Caisse d’Epargne)
Among the various sources available, the DefiLlama website emerged as the most structured
and comprehensive data source and presented relevant categories despite their subjective
nature. It is worth noting that each data aggregator establishes its own classification, as a
standardized taxonomy for DeFi services is still to be established in this emerging and still
unstructured domain. DefiLlama presents the widely recognized metrics employed within the
DeFi ecosystem which is the TVL. The TVL serves as an indicator to gauge the total value of
digital assets that are secured or staked within a specific DeFi platform or distributed application
(“DApp”). These assets encompass cryptocurrencies, stablecoins, and other tokens used as
collateral for loans or providing liquidity. TVL offers valuable insights into the overall adoption
and growth of DeFi platforms or DApps. A higher TVL signifies a platform's greater popularity.
Moreover, it indicates the level of liquidity available on the platform, providing users with an
understanding of its capacity to facilitate trading volumes without compromising liquidity. In
addition to the TVL indicator, the categories in DefiLlama assisted IBM Promontory in identifying
the key participants relevant to each defined use case in this project.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 59 of 125
ii. Representative use cases
DG FISMA defined 4 representative uses cases for the scope of project:
• DEXs, which is a type of exchange operating smart contracts that can be used to buy or
sell digital assets without the need of a centralized third party to manage it.
• Lending, which are protocols operating smart contracts to enable users to lend or
borrow various crypto assets.
• Insurance, which covers various DeFi related risks such as smart contracts failures or
hacks, but also real-life risks, even if this use is emerging currently.
• Combination/Aggregation of protocols, which relies on other smart contracts to
provide a specific service. Thanks to composability nature of those protocols and their
underlying smart contracts, they integrate their smart contract on top of existing smart
contracts to provide services such as:
o Aggregating access to various liquidity pools in one unique user-friendly interface;
o Gathering price data from various exchanges and sources to provide users with the
best possible prices for assets;
o Optimizing the routes to minimize transaction costs, by split orders, for example; and
o Maximizing their returns on investments by intelligently allocating funds across
different yield farming or staking opportunities.
For each of those four use cases, a selection of two relevant protocols was required. To meet
this target, IBM Promontory undertook the following approach:
Study of a sample of the most traded and/or most relevant protocols for each of the use cases:
• Identification of the selection criteria;
• Mapping of the selection criteria;
• Definition of a selection methodology, for the first three use cases (DEX, Lending and
Insurance); and
• Definition of a specific selection approach for the fourth use case only
(Aggregation/Combination of protocols).
iii. Methodology for DEX, Lending and Insurance
The selection of key protocols within the Ethereum platform is challenging due to the vast
number of players in the ecosystem. Each protocol has its own unique features, strengths, and
weaknesses. Based on the objectives of the European Commission (EC) project to explore
public data collection on key protocols based on Ethereum platform, IBM Promontory defined
the methodology below to reach the project’s target.
For the DEX, Lending, and Insurance use cases selection, the applied methodology relied on
three consecutive steps:
• Step 1: pre-selected a set of candidate protocols;
• Step 2: selected the first protocol of each of the three above mentioned use cases based
on the TVL; and
• Step 3: selected the second protocol for each of the three use cases based on various
additional criteria.
The first step included performing a pre-selection of candidate protocols for each of the three
use cases. The criterion used to build the list of candidate protocols was the TVL, which
represents the amount locked in each protocol, calculated in US dollar. This criterion ascertains
the success thus the usage spreading of each protocol and allowed our teams to identify four
candidates for each use case. Subsequently, IBM Promontory ran an analysis to gather a set
of information related to each pre-selected candidate protocols that was further used in the
selection process. The second step consisted of directly selecting every top TVL protocol.
Since the TVL is the best proxy criteria for the usage and popularity of the protocol, it was
decided to include this criterion for each use case to have proper representation. The third step
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 60 of 125
consisted of selecting the second protocol by applying a mix of four qualitative and quantitative
criteria:
• Volume criterion: Given the different nature of each of the three use cases, specific
metrics were used to assess this criterion, as follows:
o For DEX, IBM Promontory used the annualized volume;
o For Lending, IBM Promontory used the annualized revenue; and
o For Insurance, IBM Promontory used the market capitalization.
• Dynamism of the ecosystem criterion: This criterion further relied on four metrics that
were relevant to assess the dynamism of the ecosystem, as well as a qualitative
criterion:
o Number of users;
o Twitter community size;
o Discord community size;
o Github community size; and
o Presence of feeds from Oracles. This last criterion is in fact binary: Yes or No.
• Similarity with instruments or service from the TradFi space: This qualitative
criterion acted as a proxy for the potential development of the protocol, since it indicated
the potential to satisfy the needs of a larger audience.
• Proximity with the use case: This criterion considered how close from the use case
the protocol was, which ensured that the selection matched the objective.
The objective of this mix of criteria was to go beyond the popularity/usage of the protocol and
choose a protocol that would be useful for this exercise, while being close to the TradFi space
and use case.
The aim was to choose two protocols with two different angles: a popular protocol based on the
TVL and a meaningful protocol for our assessment. This combination aimed to ensure the best
result for the study.
Note: Initially in its response, IBM Promontory planned to select the second protocol according
to the following criteria
Volumes traded on the exchange – To identify the main actors in terms of volume of transactions
and therefore volume of data;
• Type of instrument traded;
• Complexity of the protocols – To potentially identify other types of relevant data;
• Level and type of activity; and
• Dynamism of the ecosystem (e.g., number of applications).
After gathering the data and performing an in-depth study of the protocols, IBM Promontory
adjusted the list of above criteria. As the “Type of Instrument Traded” and “Complexity of the
protocol” criteria was difficult to quantify in practice, IBM Promontory replaced them by two new
and more relevant qualitative criteria:
• Similarity with TradFi features criteria, to help ensuring a better comparability with the
benchmarks;
• Proximity with the use case to allow ensuring the relevance of the selection.
The methodology to combine those criteria and rank each protocol was finally a ranking
established for each of the four criteria. For each criterion, the protocol who had the best
assessment earned 4 points, the second 3 points, the third one 2 points and the last one 1
points. The ranking was determined by of the sum of all points.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 61 of 125
Example ranking :
CRITERIA
PROTOCOLS
A
B
C
D
VOLUME CRITERION
4
3
2
1
DYNAMISM OF THE ECOSYSTEM
2
3
1
3
SIMILARITY WITH TRADITIONAL FINANCE
FEATURES
3
1
2
4
PROXIMITY WITH THE USE CASE
2
3
1
4
SUM OF POINTS
11
10
6
12
RANKING
2
3
4
1
In this example the Protocol D is selected since it has the greatest sum of points.
iv. Health check
An additional step has been run to ensure that the selection for each use case was diverse
enough and not somehow a duplication.
This “health check[1]” relied on a multi factors analysis (based on information mapped in step
1) to confirm that the selection is diverse enough and that the two protocols used for the
benchmark had.
The health check analyzed the two chosen protocols based on the following criteria: purpose,
liquidity pool, token swaps, trading fees and use cases. This analysis confirmed that the
selection had for each use case had two protocols which were different enough and therefore
adequate for the project.
The details of the health check analysis are developed in Appendix 6.3.
v. Methodology for Aggregation/Combination
Once the first three sets of protocols were defined for the use cases on DEX, lending and
insurance, the next step of the methodology was to decide on the DeFi applications that combine
and/or aggregate various protocols. Given the specifics of this use case, a more open approach
was undertaken.
First it was decided to select one aggregation protocol and one combination protocol to achieve
both use cases.
For the aggregation protocol, IBM Promontory and the European Commission aimed to find a
protocol that provided simple and like TradFi use cases. The use case of a broker dealer was
chosen, i.e., a protocol that would receive potential orders, rout, and split them across different
trading platforms (DEX), i.e., aggregating smart contracts across different DEX platforms.
For the combination protocol, IBM Promontory took another approach and asked the various
protocols that would be interesting to be studied to the European Commission (EC) and to the
European Supervisory Authorities (ESAs), including the European Securities and Markets
Authority (ESMA), the European Banking Authority (EBA), and the European Insurance and
Occupational Pensions Authority (EIOPA). Those protocols were a mix of protocols ranging from
specific use cases to protocols receiving specific attention from the public or regulators given
their particularities in the DeFi space.
This created a list of candidate protocols which grew up to 11 protocols, as compared to four in
the previous three use cases. After a review, the choice was then made to select the protocol
which represented the highest mix of a combination of use cases, received attraction from the
public, and impacted the current DeFi environment.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 62 of 125
vi. Summary of the protocol’s selection methodology
USE CASE
1ST PROTOCOL
2ND PROTOCOL
DECENTRALIZED
EXCHANGES (DEXS)
Based On TVL
Volume Criterion (Annualized Volume)
Dynamism of Tte Ecosystem Criterion
Similarity with Instruments or Service from the
TradFi Space
Proximity with the Use Case
LENDING PROTOCOLS
Based On TVL
Volume Criterion (Annualized Revenue)
Dynamism of the Ecosystem Criterion (Users, X,
Discord, Github, Oracles)
Similarity with Instruments or Service from the
TradFi Space
Proximity with the Use Case
INSURANCE PROTOCOLS
Based On TVL
Volume Criterion (Market Cap)
Dynamism of the Ecosystem Criterion (Users,
Twitter, Discord, Github, Oracles)
Similarity with Instruments or Service from the
TradFi Space
Proximity with the Use Case
AGGREGATION &
COMBINATION
PROTOCOLS
Aggregation
Based on Specific
Use Case
Combination Based on High TVL, Special Use
Case and Impact in the DeFi Space
Mixing at least Two of Three Previous Use Cases
b) Pre-selection of protocols
This pre-selection is based on the methodology described in the previous section, and mostly
on the key metric TVL. The tables below list the four pre-selected protocols for each use case
that were further ranked and selected using the methodology outlined.
i. DEX pre-selected protocols
The following four protocols were the top four protocols in terms of TVL under the category
‘DEX’ on DefiLlama during the inception phase:
DEX PROTOCOLS
SHORT DESCRIPTION
CURVE FI
Curve is a DEX protocol designed for efficient and low-slippage trading of
stablecoins. It focuses on providing low-risk and low-cost trading by utilizing
specialized bonding curves and liquidity pools with low volatility.
UNISWAP
Uniswap is a DEX protocol built on the Ethereum blockchain. It enables users to
trade erc-20 tokens directly from their wallets, utilizing automated liquidity pools
instead of traditional order books.
BALANCER
Balancer is an automated portfolio management protocol that allows users to create
and manage self-balancing token pools. These pools can contain multiple tokens
with different weights, enabling more customizable and flexible liquidity provision.
SUSHISWAP
Sushiswap is a DEX protocol built on the Ethereum blockchain. It was created as a
fork of Uniswap and introduced additional features and incentives to attract users
and liquidity providers. Sushiswap introduced the concept of "yield farming," where
users can stake their tokens to earn rewards in the form of sushi tokens. It also
includes features like token swaps, liquidity provision, and governance through
sushi token holders.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 63 of 125
ii. Lending pre-selected protocols
The following four protocols were the top four protocols in terms of TVL under the category
‘Lending’ on DefiLlama during the inception phase:
LENDING PROTOCOLS
SHORT DESCRIPTION
AAEVE
Aave is a decentralized lending and borrowing protocol on Ethereum.
It Enables Users to Deposit their Crypto Assets and earn interest on
them or borrow assets by providing collateral. Aave utilizes smart
contracts to automate the lending and borrowing process.
COMPOUND FI
Compound is a decentralized lending and borrowing protocol that
allows users to lend and borrow various crypto assets. It operates
through algorithmically determined interest rates and utilizes
collateralized loans.
MORPHO
Morpho is a decentralized options trading protocol built on ethereum.
It allows users to create, trade, and exercise options contracts on a
range of underlying assets, providing opportunities for risk
management and speculation.
FRAXLAND FI
Frax protocol is a decentralized algorithmic stablecoin protocol
designed to maintain its value close to the us dollar. It achieves this
stability through a combination of collateralized and algorithmic
mechanisms. Frax stablecoin is collateralized by a combination of
cryptocurrencies and, if necessary, can be partially algorithmically
adjusted to maintain its peg. The protocol employs an on-chain
governance system for decision-making and allows users to earn
additional rewards through yield farming and other mechanisms.
iii. Insurance pre-selected protocols
The following four protocols were the top four protocols in terms of TVL under the category
‘Insurance’ on DefiLlama during the inception phase:
INSURANCE PROTOCOLS
SHORT DESCRIPTION
NEXUS MUTUAL
Nexus mutual is a decentralized insurance protocol designed to provide
coverage for smart contract risks. Users can purchase insurance against
the failure or vulnerability of specific smart contracts and receive
compensation if a valid claim is made.
UNSLASHED
Unslashed is a decentralized insurance protocol that focuses on providing
coverage for risks in the DeFi space. It allows users to purchase coverage
against smart contract hacks, oracle failures, and other defi-related risks.
EASE.ORG
Ease.org is a protocol that aims to simplify the deployment and
management of decentralized applications (dapps). It provides a user-
friendly interface and tools to help developers create and launch their
dapps more easily.
SHERLOCK
Sherlock is a protocol that aims to provide decentralized, privacy-focused
analytics for blockchain data, including cover against smart contract
hacks. It allows users to explore and analyze data from various
blockchains while maintaining privacy and security. Sherlock employs
zero-knowledge proofs and cryptographic techniques to enable users to
query and gain insights from blockchain data without revealing specific
details about their queries or identities. The protocol is designed to
empower users to conduct sophisticated analytics without compromising
their privacy.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 64 of 125
iv. Aggregation/Combination pre-selected protocols
For this use case, with the ambition to cover as much as possible key players and features of
DeFi space, IBM Promontory extended the analysis to 11 protocols to strengthen the selection.
Indeed, the composability nature of DeFi protocols allows a wild range of possibilities for
protocols/smarts contracts which made the selection challenging.
The below table is a short selection of interesting and well positioned protocols in DeFi
landscape, based on the interviews with the ESAs and the EC:
AGGREGATION /COMBINATION
PROTOCOL
DESCRIPTION
INSTDAPP
INSTDAPP refers to Instant Decentralized Application, which
is a term used to describe decentralized applications that
provide immediate and seamless user experiences without
sacrificing security or trustiness (lending, borrowing,
leveraging, and swapping). It acts as a middleware,
aggregating multiple DeFi protocols into one upgradable smart
contract layer.
1INCH
1inch is a DEX aggregator that combines multiple liquidity
sources to provide users with the best possible trading rates.
It scans various DEXs and executes trades across multiple
platforms to ensure optimal prices and minimal slippage. 1inch
aims to improve liquidity and reduce the complexity of trading
on DEXs. The protocol's algorithm splits, routes, and
deploys orders across different liquidity sources to
achieve better overall rates for users.
YEARN FINANCE
Yearn Finance is a protocol that offers lending aggregation,
yield generation, and insurance services on the Ethereum
blockchain. Yearn Finance's main product is its Vault, which
automatically optimizes yield farming strategies for users. The
protocol utilizes smart contracts to automate the process of
seeking the highest yields across various DeFi platforms.
LIDO
Lido is a decentralized platform that allows users to stake
their Ethereum and participate in Ethereum 2.0's proof-of-
stake consensus mechanism. It provides a liquid and
transferable representation of staked Ethereum tokens (ETH)
called stETH.
MAKERDAO
MakerDAO is a decentralized autonomous organization
responsible for the development and governance of the
Maker Protocol. The protocol enables users to create and
manage the stablecoin DAI, which is collateralized by a variety
of crypto assets.
WBTC
WBTC (Wrapped Bitcoin) is an ERC-20 token backed by
Bitcoin. It brings Bitcoin's liquidity and value to the Ethereum
ecosystem, allowing users to utilize Bitcoin on the Ethereum
network for decentralized applications and DeFi purposes.
CONVEX FINANCE
Convex Finance is a decentralized platform that optimizes
yield generation in DeFi by incentivizing users to lock their
staked assets from other protocols. It focuses on enhancing
yield farming strategies and optimizing returns for users.
DYDX
dYdX is a decentralized trading and lending platform that
operates on Ethereum. It offers various financial services,
including margin trading, perpetual contracts, and lending,
allowing users to engage in sophisticated trading strategies.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 65 of 125
AGGREGATION /COMBINATION
PROTOCOL
DESCRIPTION
SYNTHETIX
Synthetix is a decentralized synthetic asset issuance
protocol built on Ethereum. It enables users to create and
trade synthetic assets that mirror the value of real-world
assets, such as currencies
AURA FINANCE
Aura Finance is a protocol built on top of the Balancer system
to provide maximum incentives to Balancer liquidity providers
and BAL stakers (into veBAL) through social aggregation of
BAL deposits and Aura's native token.
IDLE FINANCE
Idle is a decentralized yield aggregator that optimizes and
manages users' funds across various lending protocols to
maximize yield generation. It automatically allocates funds
to the most profitable lending platforms based on market
conditions. Idle aims to simplify the process of yield
generation and increase the efficiency of capital allocation in
the DeFi ecosystem. Users can deposit their funds into Idle's
smart contracts, and the platform takes care of the rest,
dynamically reallocating assets to different lending
protocols.
c) Selection of protocols
This section continues presenting the implementation of the methodology described above
related to the selection of protocols.
i. DEXS, Lending and Insurance use cases
After consolidating data from the various sources, IBM Promontory devised a comprehensive
matrix to assess and quantify specific criteria. Through this approach, IBM Promontory was able
to identify for the initial first three use cases that are DEX, Lending and Insurance.
DEXs protocols
For the first use case, DEXs, presented below is a concise table comprising key metrics
employed to evaluate the ranking of each protocol.
In terms of quantitative analysis, the collected data enables the ranking of TVL, Volumes, and
Dynamism for each protocol. In relation to the qualitative aspect, an overall assessment of each
protocol was conducted to establish rankings based on their resemblance to TradFi and
relevance to the specific use case. Additional pertinent details can be found in Appendix section,
with regards to the health check (section 6.3). In the landscape of DEXs, Curve Finance
emerges as the leading protocol, commanding a noteworthy TVL of approximately $3.8 billion
as of June 2023. It is important to note that the TVL of Curve Finance is subject to the influence
of market conditions and volatility. Another significant player in this field is Uniswap, not only
due to its TVL of around $3.4 billion in June 2023, but also its annualized volume of
approximately $417 billion and a community of active users, totaling 5.4 million individuals.
Qualitatively, Uniswap resembles traditional exchanges, facilitating liquidity provision for trading
activities and granting investors the ability to engage in transactions at their convenience.
However, unlike traditional exchanges, it utilizes a trading system unique to DeFi – the AMM.
Uniswap aligns closely with our designated use case centered around the concept of DEXs.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 66 of 125
PROTOCOL
OVERALL
RANKING
QUANTITATIVE CRITERIA
QUALITATIVE
CRITERIA
TVL
Criterion
Volume criterion
Dynamism of the ecosystem criterion
Similarity
with
TradFi
features
Proximity
with the use
case
TVL
($)
R1
Annual
Volume
Annual
Revenue
Market
Cap.
R2
Number
of users
Twitter
Discord
Github
Feed
from
Oracles
R3
R4
R5
CURVE FI
1
3,8 B
1
72,96 B
14,52 M
538 M
1
88,6 K
346 K
36 K
401
Yes
2
1
3
UNISWAP
2
3,41 B
2
417,14 B
417 M
3,42 B
2
5,4 M
1 M
100 K
2.7
Yes
1
1
1
SUSHI
3
476 M
4
6,8 B
2,3 M
126 M
4
648 K
270 K
74 K
94
Yes
3
1
2
BALANCER
4
991 M
3
67,9 B
3,8 M
191 M
3
329 K
146 K
53K
48
Yes
4
1
3
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 67 of 125
Lending protocols.
For the lending use case, presented below is a table comprising of key metrics employed to
evaluate the ranking of each protocol as per the methodology retained.
In terms of quantitative analysis, the collected data enables the ranking of TVL, Volumes, and
Dynamism for each protocol. Regarding the qualitative aspect, an overall assessment of each
protocol was conducted to establish rankings based on their resemblance to TradFi and
relevance to the specific use case. Additional pertinent details can be found in Appendix
section. In the significant realm of lending, our analysis reveals that the AAVE Protocol holds
the leading position in terms of TVL, with an approximate value of $5.6 billion as of June 2023
(value subject to the influence of market conditions and volatility). Coming in as the second
player in this domain is Compound Finance, which boasts an annualized revenue of $1.9
million, along with a substantial Total Locked Value of $1.8 billion. Moreover, Compound
Finance boasts a strong community of 346,000 active users and enjoys a considerable
following on Twitter, Discord, and 201 repositories on GitHub. The functioning of Compound
closely resembles that of TradFi, particularly in the areas of lending, making it an apt protocol
in our selection.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 68 of 125
Overall
Ranking
Quantitative Criteria
Qualitative criteria
Protocol
TVL Criterion
Volume
criterion
Dynamism of the ecosystem criterion
Similarity
with
traditional
finance
features
Proximity
with the
use case
TVL
(in $)
R1
Annualized
Revenue
R2
Number
of users
Twitter
Discord
Github
Feed
from
Oracles
R3
R4
R5
AAVE
1
5,66 B
1
8,4 M
1
161,6 K
536 K
50 K
974
Yes
2
1
1
COMPOUND
FINANCE
2
1,8 B
2
1,9 M
2
346 K
247 K
17 K
201
Yes
1
1
2
MORPHO
3
323 M
3
1,2 M
3
< 100
15 K
N/A
24
Yes
3
3
3
FRAXLAND
FI
4
137 M
4
Not available
4
N/A
73K
9,6 K
36
Yes
3
2
4
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 69 of 125
Insurance protocols
For the third use case, Insurance, presented below is a table comprising key metrics employed
to evaluate the ranking of each protocol by IBM Promontory.
In terms of quantitative analysis, the collected data enables the ranking of TVL, Volumes, and
Dynamism for each protocol.
Regarding the qualitative aspect, an overall assessment of each protocol was conducted to
establish rankings based on their resemblance to TradFi and relevance to the specific use
case. Additional pertinent details can be found in Appendix section.
In the activity of insurance, the foremost protocol that emerges as the clear leader is Nexus
Mutual, with a total locked value of $264 million as of June 2023 (subject to valuation
fluctuations influenced by market dynamics and volatility).
Our analysis indicates that the Unslashed protocol follows closely as a competitor in the
insurance space, boasting a market capitalization of $456,000 and securing $32 million within
its smart contracts (TVL). Unslashed, with a modest yet engaged presence on Twitter,
Discord, and GitHub, underscores its distinct claim process based on parametric evaluation
and community consensus. In contrast, Nexus Mutual implements a discretionary claim
process that hinges on the voting of its members. Importantly, the Unslashed protocol aligns
harmoniously with conventional risk mitigation practices, fully addressing the objectives
outlined in our third use case.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 70 of 125
Overall
Ranking
Qualitative criteria
Qualitative criteria
Protocol
TVL Criterion
Volume
criterion
Dynamism of the ecosystem criterion
Similarity with
traditional
finance
features
Proximity
with the use
case
TVL
(in $)
R1
Market
Cap.
R2
Number
of users
Twitter
Discord
Github
Feed
from
Oracles
R3
R4
R5
NEXUS
MUTUAL
1
264 M
1
348 M
1
9 K
41 K
9 K
27
Yes
1
1
1
UNSLASHED
2
32 M
2
456 K
2
2,2 K
9,7 K
3,6 K
2
No
3
1
2
EASE.ORG
3
7 M
3
4K
4
19,7 K
7,5 K
1 K
18
No
2
1
4
SHERLOCK
3
3 M
4
11K
3
N/A
11 K
4,7 K
17
Yes
4
1
3
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 71 of 125
Aggregation and Combination use case
In relation to the Aggregation and Combination use case, our objective was to identify two
protocols: one aggregation protocol and one combination protocol to get both use cases.
For the aggregation protocol, the approach was to identify a simple use case that represents
close to a broker dealer, i.e., a protocol that would receive potential orders, split, route, and
execute them across different trading platforms (DEX), i.e., aggregating smart contracts
across different DEX platforms.
In this context, the selection process concluded on the selection of the 1inch protocol based
on its ability to seamlessly amalgamate multiple liquidity pools, thereby ensuring users access
the most favorable trading rates attainable.
The 1inch platform successfully developed advanced algorithms and intelligent contract logic,
which facilitate the efficient routing of trades across diverse DEXs, consequently optimizing
prices and diminishing associated trading expenses.
By studying 1inch smart contracts, one can acquire profound insights into the technical facets
of aggregation, encompassing the sourcing of liquidity, comparison of prices, and execution
of trades across multiple platforms. Indeed, the platform employs intelligent routing and
splitting techniques to minimize slippage and enhance price execution for traders. Additionally,
1inch provides a user-friendly interface that streamlines the decentralized trading process,
ensuring ease of use for all participants involved.
For the combination protocol, a list of potential candidates was submitted to the ESAs (EBA,
ESMA, EIOPA) and the EC, with 11 pre-selected protocols.
From those 11 protocols, MakerDAO has been finally retained. MakerDAO’s significance lies
in its pioneering role in the decentralized minting (issuance) of stablecoins, specifically the
creation of the DAI stablecoin. The protocol is at the forefront of DeFi innovation, particularly
in areas such as staking and assets/currency minting.
As a protocol, MakerDAO enables users to collateralize their assets and generate DAI. It
effectively combines two use cases, namely DEX and Lending, which led to significant traction
within the DeFi ecosystem.
Moreover, MakerDAO boasts a considerable TVL of $6.2 Billion, indicating its prominence
within the space.
Below the final selected protocols and rationale for those not retained:
AGGREGATION / COMBINATION
PROTOCOL
OUTCOME OF IBM PROMONTORY ANALYSIS
INSTDAPP
Not chosen due to too many features and high inherent complexity.
1INCH
Selected.
YEARN FINANCE
Not chosen due to its strong focus on yield, which is too far from
the use cases.
LIDO
Not chosen due to its strong focus on liquid staking which is too far
from the use cases.
MAKERDAO
Selected.
WBTC
Not chosen due to its strong focus on bridge between platforms
and on one underlying: BTC, which is too far from the use cases.
CONVEX FINANCE
Not chosen due to its strong focus on yield optimization, which is
too far from the use cases.
DYDX
Not chosen due to its complexity and advanced features dedicated
to sophisticated trading strategies.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 72 of 125
AGGREGATION / COMBINATION
PROTOCOL
OUTCOME OF IBM PROMONTORY ANALYSIS
SYNTHETIX
Not chosen due to its strong focus on synthetics minting and
trading. In addition, layer 2 protocols used bring more complexity.
AURA FINANCE
Not chosen due to its strong focus on optimization of Balancer
protocol liquidity, which is too far from the use cases.
IDLE FINANCE
Not chosen due to its strong focus on yield and lending
optimization, which is too far from the use cases.
ii. Final list of protocols
The below table presents the final list of protocols for the DeFi Pilot project:
USE CASE
PROTOCOLS
DECENTRALIZED EXCHANGES
Curve Fi
Uniswap
LENDING
Aave
Compound Fi
INSURANCE
Nexus Mutual
Unslashed
AGGREGATION AND COMBINATION
1inch
Maker Dao
d) Detailed description of the selected protocols
i. Curve Finance ID Card
Curve Finance Protocol Description
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 73 of 125
Curve Finance is a distinct player in the DeFi ecosystem, operating as a DEX with a focus on
stablecoin trading and is built on the Ethereum and Polygon networks and utilizes an AMM
mechanism to facilitate trading and liquidity provision. Unlike Uniswap, which caters to a broad
range of tokens, Curve Finance zeroes in on stablecoins and wrapped assets, aiming to
provide efficient and low-slippage trading for these types of assets. Its unique selling
proposition lies in optimizing for low fees and slippage through liquidity pools that comprise
assets with comparable price behaviors, like stablecoin pairs or ETH-WETH pairs. Curve
Finance, founded by Michael Egorov (a physicist with a background in software development,
previously contributed to projects such as MakerDAO, Uniswap, and NuCypher) in 2020, is
an innovative DEX and AMM protocol operating on the Ethereum network. It is a platform
primarily designed for the seamless exchange of ERC-20 tokens, with a particular focus on
stablecoins. This novel approach allows investors to trade with high liquidity, low slippage, and
minimal fees, which constitutes an attractive alternative to traditional centralized exchanges
(CEX). The primary version of Curve, Curve v1, focused on pools of stablecoins assets. The
innovation introduced here was an optimized slippage mechanism (StableSwap invariant),
which ensured an equal swap when a pool was balanced within a certain range. This
significantly reduced the slippage experienced in transactions, around 100 times less
compared to some traditional models.
Curve v2, on the other hand, introduced a notable change by allowing pools to hold assets
with different prices, breaking free from the constraints of stable pools. This model
concentrated liquidity around current prices, improving efficiency, and was conceptually like
Uniswap V3. However, it outperformed Uniswap by managing position adjustments for the
liquidity providers (LPs) without their intervention. The functionality of Curve can be
segmented into four core categories:
• StableSwap: This represents the exchange contracts and the heart of the protocol's
operation.
• The DAO: This deals with protocol governance and value accrual.
• The Factory: This allows for the permissionless deployment of Curve meta pools.
• The Registry: This provides a standardized API and on-chain resources for third-party
integrations.
Curve is a leading DEX providing deep liquidity across all chains, specializing in stablecoin
trading. It is known for low fees, high liquidity, and incentives for liquidity providers. With the
introduction of Curve V2, the platform has expanded its efficient pricing model beyond stable
pools and is now available on various EVM-compatible networks. Liquidity providers can earn
yield through trading fees, interest from lending protocols, and CRV token incentives. This
report will focus on Curve v2, providing a look at its features, business model, governance,
and risk factors.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 74 of 125
ii. Uniswap Short ID Card
UniSwap protocol description
Unlike centralized exchanges, Uniswap and other DEXs facilitates the direct trading between
investors without the need for an intermediary, thereby offering a high degree of censorship
resistance and eliminating unnecessary forms of rent extraction.
Investors could benefit from DEXs in several ways. First, they offer access to a broader array
of tokens and trading pairs. Uniswap, for instance, facilitates the swapping of up to 444 coins
and 943 crypto-crypto trading pairs. Furthermore, DEXs provide an opportunity to earn yields
through liquidity provision. AMMs, like the one used by Uniswap, allow users to provide
liquidity to the platform and earn returns on their assets, democratizing market making and
liquidity provision. Despite their advantages, DEXs have faced challenges, particularly with
liquidity, which has been a longstanding issue. However, the advent of AMMs has been a
game changer, addressing liquidity concerns to a significant extent. Uniswap v3, the current
version since May 2021, brought about a significant shift with the introduction of concentrated
liquidity, flexible fees, and contract factory for multiple pools per pair and flexible governance.
This allowed liquidity providers to choose specific price ranges for their capital allocation,
thereby enhancing the efficiency of capital usage for example. This protocol review will focus
primarily on Uniswap v3, providing an in-depth look at its key features, business model,
governance, risk factors and regulatory considerations.
The Uniswap Protocol offers a value proposition by two primary functions, Swapping and
Providing Liquidity, while maintaining complete self-custodial control of user assets.
Tokens Swapping: As a DEX, Uniswap facilitates the direct swapping of tokens without the
need for intermediaries or third parties. The unique self-custodial feature of this protocol
ensures that users always retain full control of their assets, mitigating the risk of unauthorized
access or misuse of funds.
Providing Liquidity: Beyond its function as an exchange, the Uniswap Protocol relies on
Liquidity Providers (LPs), which are third-party users who deposit tokens into liquidity pools.
These pools act as reserves for tokens pairs, providing readily available assets for trading.
LPs are rewarded with trading fees generated by the pool for their contribution of liquidity. This
approach has democratized participation in decentralized financial markets as anyone can
become a liquidity provider.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 75 of 125
To facilitate interaction with the protocol and enhance user experience, Uniswap Labs team
has developed a suite of tools, including:
• The Uniswap Web App, which is a user-friendly interface that allows users to perform
swaps on the Uniswap Protocol seamlessly;
• Uniswap Wallet, which is a dedicated mobile wallet for the purchase, transfer, and
swapping of cryptocurrencies. This tool also facilitates the exploration of Non-Fungible
Tokens (NFTs).
• And Uniswap NFT Aggregator, which is a marketplace that offers users the
opportunity to discover, purchase, and sell NFTs at competitive prices.
iii. Aave short ID Card
Aave protocol description
Aave is a decentralized non-custodial liquidity protocol where users can participate as
depositors or borrowers, creating liquidity markets to earn interest on supplied and borrowed
assets in a variable or stable interest rate fashion without the need for traditional
intermediaries, using smart contracts on the Ethereum blockchain. The protocol functions via
a set of persistent, non-upgradable smart contracts, implying that the operation of its codebase
is not subjected to external control or modifications.
Users can be depositors with providing liquidity to the market, they lend their assets to liquidity
pools and earn a passive income. On the other hand, the borrowers can borrow assets in an
overcollateralized or undercollateralized fashion. the Aave Protocol’s open-source nature
ensures that its code is publicly accessible, thereby promoting transparency and trust.
Furthermore, the protocol’s contracts can be deployed on any blockchain, reinforcing its
decentralized nature. Aave's decentralized nature also allows users to earn interest on their
deposits as lenders, and borrowers can leverage their crypto holdings to access loans without
cumbersome paperwork. The protocol's flexibility, innovation, and open-source nature have
contributed to its prominence within the DeFi space. It functions as a decentralized
marketplace for liquidity, where individuals can efficiently manage their assets and financial
needs in a trust less manner.
Aave v3, the most current version as of March 2022, brought about a significant enhancement
to optimize yield. This report will focus primarily on Aave v3, providing an in-depth look at its
features, business model, governance, and risk factors. It will also explore Aave’s performance
metrics, its role within the DeFi ecosystem, its regulatory considerations, and potential
upgrades or evolutions.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 76 of 125
iv. Compound short ID Card
Compound protocol description
Compound Finance is a decentralized non-custodial lending protocol running on Ethereum. It
enables users to lend and borrow cryptocurrencies without a without the need for traditional
intermediaries. Users can participate as depositors or borrowers, creating liquidity markets to
earn interest on supplied and borrowed assets. The protocol functions via a set of persistent,
non-upgradable smart contracts, implying that the operation of its codebase is not subjected
to external control or modifications.
Users can be depositors with providing liquidity to the market, they lend their assets to liquidity
pools and earn a passive income. On the other hand, the borrowers can borrow assets in an
overcollateralized or undercollateralized fashion. Borrowers can access loans instantly,
The Compound Finance’s open-source nature ensures that its code is publicly accessible,
thereby promoting transparency and trust. Furthermore, the protocol’s contracts can be
deployed on other blockchains like Polygon or Abitrum.
Compound's decentralized nature allows users to earn interest on their deposits as lenders,
and borrowers can leverage their crypto holdings to access loans without cumbersome
paperwork. The protocol's flexibility, innovation, and open-source nature have contributed to
its prominence within the DeFi space. Compound finance is the second biggest lending
protocol on Ethereum after Aave protocol with a TVL of $1.83b in August 2023.
Compound III is the most current version as of August 2022. This upgrade aimed to provide a
better user experience and improve the efficiency of the platform's operations. This report will
focus primarily the latest version of Compound finance, providing an in-depth look at its
features, business model, governance, and risk factors. It will also explore 1inch's
performance metrics, its role within the DeFi ecosystem, its regulatory considerations, and
potential upgrades or evolutions.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 77 of 125
v. Nexus Mutual short ID Card
Nexus Mutual protocol description
Nexus Mutual is a decentralized insurance alternative built on Ethereum. Members can secure
insurance coverage by locking their Nexus Mutual (NXM) tokens into a smart contract. This
action demonstrates their confidence in the smart contract's reliability. Additionally, members
can opt to become risk assessors by staking their tokens. In the event of a covered incident,
such as a smart contract vulnerability resulting in financial loss, affected members can file
insurance claims.
This system is a decentralized approach to risk management and insurance within the
blockchain and DeFi space, where individuals contribute NXM tokens to a common pool, and
those who stake tokens are involved in assessing and mitigating risks for the community. The
use of NXM tokens in this manner promotes trust in the security of smart contracts and ensures
that members can seek compensation in case of unforeseen events, enhancing the overall
safety and functionality of the ecosystem.
The decentralized nature of Nexus mutual means that the system is operated and governed
by the community of NXM token holders, making it less reliant on centralized control. The
protocol's flexibility, innovation, and open-source nature have contributed to its prominence
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 78 of 125
within the DeFi space. Nexus Mutual is the biggest insurance protocol on Ethereum with a
TVL of $238.18m in August 2023.
vi. Unslashed short ID Card
Unslashed protocol description
Unslashed Finance is a decentralized insurance platform built on Ethereum. Members can
secure insurance coverage for various DeFi protocol and other Blockchain-based assets and
risks. The core idea behind Unslashed Finance is to offer insurance products that are
transparent, flexible, and tailored to the specific needs of the DeFi space.
This coverage and protection are purchased by the user and is insured through another
protocol participant that supplies the capital. The protocol is based on the Unslashed DAO for
various policy and protocol settings, it also leverages integration with Enzyme for the asset
management side, and integration with Kleros for independent assessment of claims.l
l
The insurer is capital suppliers who contribute to different buckets or different capital pool.
They earn through to insurance premiums, DeFi returns through asset management. This
asset management is done in Partnership with Enzyme an Ethereum-based protocol who
manage client assets within a customizable and safe environment.
The insured are cover buyers who will pay an insurance premium to be insured against a wide
variety of potential risks. Kleros is a decentralized dispute resolution protocol which has been
implemented on Ethereum who evaluates all disputed claims and their rulings, when
favourable, automatically trigger the payouts to claimants.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 79 of 125
The decentralized nature of Unslashed Finance means that the system is operated and
governed by the community of USF token holders, making it less reliant on centralized control.
The protocol's flexibility, innovation, and open-source nature have contributed to its
prominence within the DeFi space. Unslashed Finance is the second biggest insurance
protocol on Ethereum with a TVL of $29.62m in August 2023.
vii. V short ID Card
1inch protocol description
1inch Network is a DEX aggregator designed to optimize trading on DEXs. It combines the
functionalities of various DEXs to provide users with the best prices and lowest fees for their
transactions. By utilizing smart contract technology, the network leverages an advanced
algorithm to search over multiple DEXs and liquidity protocols to find the most efficient swap
routes for orders.
1inch network is an open-source, decentralized marketplace established for the purpose of
cryptocurrency swapping on the Ethereum blockchain. The protocol functions via a set of
persistent, non-upgradable smart contracts, implying that the operation of its codebase is not
subjected to external control or modifications.
The open-source nature of 1inch network ensures that its code is publicly accessible, thereby
promoting transparency and trust. However, new versions of the network can be developed
by the 1inch team with de vote of the community. Therefore, new smart contracts are
published on the Ethereum Blockchain. Users can use the latest version and depose their
money on the new smart contracts to take advantage of new features. 1inch Router v5 is the
most current version released in November 2022, offers enhanced benefits for users'
swapping activity on the Ethereum network. This report will focus primarily the latest version
of 1inch network, providing an in-depth look at its features, business model, governance, and
risk factors. It will also explore 1inch's performance metrics, its role within the DeFi ecosystem,
its regulatory considerations, and potential upgrades or evolutions.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 80 of 125
viii. Maker DAO short ID Card
Maker DAO protocol description
Maker DAO is a decentralized autonomous organization also called DAO that operates on the
Ethereum Blockchain. It is an organization that operates through smart contracts on a
blockchain, without the need for a central authority or intermediaries. In a DAO, decisions and
actions are often made through a consensus mechanism, where participants who are often
token holders have a say in the organization's activities. This can include voting on proposals,
allocating funds, and determining the direction of the organization.
It is designed to facilitate the creation of a stable cryptocurrency called DAI, which is pegged
to the value of the US Dollar. The Maker DAO system uses a two-token model:
• DAI is the stablecoin created within the Maker DAO ecosystem. It is intended to
maintain a 1:1 peg against the US Dollar, achieved through a system of smart contracts
and collateralization.
• MKR is the governance token of Maker DAO. Holders of MKR have the power to
participate in the decision-making process for changes and improvements to the Maker
DAO protocol.
The main mechanism behind MakerDAO's stability is its collateralized debt position system
also called CDP. Users lock up collateral, typically Ether in smart contracts and create DAI
against it. The system attempts to maintain stability by adjusting interest rates and creating or
destroying DAI based on market demand.
The decentralized nature of MakerDAO means that the system is operated and governed by
the community of MKR token holders, making it less reliant on centralized control. The
protocol's flexibility, innovation, and open-source nature have contributed to its prominence
within the DeFi space. Maker is the biggest CDP protocol on Ethereum with a TVL of $5.15b
in August 2023.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 81 of 125
10.3. Annexes of section 5: Benchmarks
a) Benchmarks selection methodology
One of the objectives of the pilot project – Embedded supervision of decentralized financial
institutions and activities – is to assess regulators’ ability to collect data from DeFi protocols
and compare them with the existing regulatory framework (i.e. from TradFi and insurance).
Benchmarks are data sets issued from regulatory reporting requirements that are used in
TradFi to collect both surveillance and supervisory information from the regulated entities by
regulators. For example, the MiFID 2 transaction reporting regime contains a data set to be
provided by financial firms to regulators for market abuse surveillance purposes. The objective
of this sub-section is to describe the approach and the methodology developed to select the
benchmarks for each of the four use cases for the scope of project:
• DEX;
• Lending;
• Insurance; and
• Combination/Aggregation of protocols.
i. Approach
For each of those four use cases, one or several benchmarks were needed to be identified.
To meet this target, IBM Promontory undertook the following approach:
• Build the list of potential legislative benchmarks through the identification of all
benchmarks that could be relevant to the use case, given its characteristics and
comparability with TradFi and insurance space;
• Assessment of each benchmark of the list: definition of criteria for assessment,
grading of each criterion and ranking of benchmarks according to the criteria;
• Collect the views from three ESAs, thanks to dedicated interviews and collecting the
relevant technical data set. For this purpose, IBM Promontory presented to each ESA
the different uses cases (illustrated with concrete examples and use cases) and then
collected their views regarding the relevance of the various benchmarks for each of
the use cases; and
• Final selection of benchmarks.
ii. List of potential legislative benchmarks
The first step was to identify the list of possible legislative benchmarks for selection. This
selection was initially performed at the level of the legislation. In this respect, IBM Promontory
used the report from the Commission on fitness check on EU supervisory requirements. This
document has the advantage to list all existing supervisory regulatory requirements as well as
their reporting formats at EU level.
The table below is an extract of this relevant document.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 82 of 125
Source: European Commission – Fitness Check of EU Supervisory Reporting Requirements
Since this source document is dated 2019, IBM Promontory assessed whether new regulatory
reporting requirements were issued since the creation of this table and noted the following:
Amendments to the above regulations have been issued, such as EMIR Refit.
This list did not contain any element related to Anti Money Laundering Regulation and Transfer
of Funds Regulation.
Those last four reporting regimes were therefore added to the list of potential benchmarks. In
addition, this source document did not consider the PRIIPS Regulation nor the Prospectus
Regulation. These two regulations were also considered for inclusion to the list of potential
benchmarks. However, since they do not cover actual supervisory activities, they were not
added to the list of potential benchmarks.
The final list of potential benchmarks was therefore the following:
• Capital Requirements Regulation (CRR) and the Capital Requirements Directive23
(CRD IV);
• Bank Recovery and Resolution Directive (BRRD);
• Solvency II;
• Markets in Financial Instruments Regulation (MiFIR) and Markets in Financial
Instruments Directive25 (MiFID II);
• European Market Infrastructure Regulation (EMIR);
• Regulation on settlement and central securities depositories26 (CSDR)
• Securities Financing Transactions Regulation (SFTR);
• Short-Selling Regulation (SSR);
• Market Abuse Regulation (MAR);
• Alternative Investment Fund Managers Directive (AIFMD);
• Undertakings for the Collective Investment in Transferable Securities (UCITS)
Directive;
• Credit Rating Agencies Regulation (CRAR) and Credit Rating Agencies Directive
(CRAD);
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 83 of 125
• Regulation on statutory audit of public-interest entities (SAR) and Directive on statutory
audits of annual accounts and consolidated accounts36 (SAD);
• Regulation on wholesale energy market integrity and transparency (REMIT);
• Money Market Funds Regulation (MMF);
• Corporate Sustainability Reporting Directive (CSRD);
• Sustainable Finance Disclosure Regulation (SFDR);
• Anti-Money Laundering or Terrorist Financing (AML); and
• Transfer of Funds Regulation (TFR).
iii. Benchmarks assessment methodology
To identify the relevant benchmarks from the established list of 19 potential legislative
benchmarks, IBM Promontory undertook the following approach:
• Identification of the selection criteria;
• Mapping of the selection criteria;
• Defining a selection methodology, for the first three use cases (DEX,
Lending/Borrowing and Insurance); and
• Assessing the fourth use case.
For the DEX, Lending Borrowing and Insurance use cases selection, IBM Promontory
assessed each benchmark according to the following criteria:
• Type of data collected: Given the quite different nature of supervision, collected data
are performed in terms of supervision either at granular or aggregated level. Granular
data is more adequate for micro supervision and appears to be more aligned with the
way DeFi is structured as all single transactions are recorded in the ledger, and as
central aggregation is less aligned with the decentralized nature of DeFi.
• Level of structure of the format developed: To be able to be a meaningful
benchmark, it is required that a proper structure of data be developed, with a mature
format. On the other hand, unstructured collection of data would not represent a good
benchmark for the exercise.
• Existence of data models: With a proper data model, the benchmark would be more
effective in its usage for the next phases of the project.
• Proximity with the use case: This criterion considered how close from the use case
the benchmark is, allowing to ensure that the selection matched the relevance
objective.
• Micro and macro supervision. To render the exercise meaningful, it was necessary
to have at least a micro supervision benchmark for each use case, which would look
at granular data, and potentially a macro supervision benchmark when possible.
The aim was to choose benchmarks with three different angles: a properly structured data set,
a proximity with the use case, and a proper micro/macro supervision view.
IBM Promontory decided to combine those criteria and rank each benchmark to establish a
ranking for each of the first four criteria. For each criterion, the benchmark was assessed on
a scale from 1 to 4.
At the end of the exercise, the criteria ‘Proximity with each use case’ led the choice for each
case, and other criteria helped ranking/filtering amongst the leading benchmarks.
Example of ranking:
CRITERIA
BENCHMARKS
A
B
C
D
TYPE OF DATA COLLECTED (1 AGGREGATED – 4
GRANULAR)
4
3
2
3
LEVEL OF STRUCTURE (1 LOW – 4 HIGH)
2
3
1
3
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 84 of 125
CRITERIA
BENCHMARKS
A
B
C
D
DATA MODELS (1 LOW – 4 HIGH)
3
1
2
4
PROXIMITY WITH EACH USE CASE (1 LOW – 4 HIGH)
2
3
1
4
MICRO(M)/MACRO (M)
M
M
M
M
RANKING
2
3
4
1
In this example, the Benchmark D is selected since it is the closest in for the relevant use
case.
Aggregation/Combination protocol
Regarding the fourth Use Case, the combination and aggregation protocols, it was proposed
to map the criteria against all benchmarks for which the use case is a combination/aggregation
of the previous use cases. Thus, the benchmarks for the fourth use case are the sum of
relevant benchmarks as regards the aggregation /combination case of the first three use
cases.
b) Selection of benchmarks
i. Benchmarks Assessment
After identifying the possible benchmarks, IBM Promontory devised a comprehensive matrix
to assess and quantify specific criteria. Through this approach, IBM Promontory defined the
benchmarks for the initial first three use cases that are DEX, Lending/Borrowing and
Insurance.
To execute this assessment, Promontory used Commission staff working document - Fitness
check of EU supervisory reporting requirements (europa.eu) to collect the relevant data for
each assessment criteria. Presented below is a table comprising pertinent information that
was used to execute the assessment of the benchmarks.
BENCH-
MARK
ENTITIES
MAIN CONTENT OF
SUPERVISORY REPORTING
# OF DATA
POINTS
COLLECTED
DATA
MODEL
REPORT
FORMAT
CRR/
CRD IV
Credit
institutions &
investment
firms
Reporting of capital adequacy,
solvency, liquidity position,
exposures (credit, operational,
market risk), etc.
43641
DPM
XBRL/
PDF/XLS
BRRD
Credit
institutions &
investment
firms
Information about critical
functions, assets and liabilities
divided by critical
counterparties, etc.
424
DPM
XBRL
SOLV. II
Insurance &
reinsurance
undertakings
Solvency capital requirement,
minimum capital requirement,
balance sheet, own funds, intra-
group transactions, etc.
23001
DPM
XBRL/
PDF/XLS/
DOC
MIFIR/
MIFID II
Investment
firms &
trading
venues
Reporting of transactions in
financial instruments which are
traded on a trading venue or
where an underlying instrument
is traded on a trading venue,
reporting of Financial Instrument
Reference Data, reporting of
1158
ISO
20022
XML
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 85 of 125
BENCH-
MARK
ENTITIES
MAIN CONTENT OF
SUPERVISORY REPORTING
# OF DATA
POINTS
COLLECTED
DATA
MODEL
REPORT
FORMAT
positions in commodity
derivatives or emission
allowances or derivatives
thereof.
EMIR
Counterparties
trading in
financial
derivatives and
central
counterparties
(CCPs)
Reporting of OTC and exchange
traded derivatives transactions.
254
ISO
20022
XML
CSDR
Central
securities
depositories
(CSDs)
Information about securities
recorded in settlement systems,
periodic events, etc.
1577
ISO
20022
XML
SFTR
Counterparties
involved in
securities
financing
transactions
(SFTs)
Reporting of SFTs (e.g.,
counterparty data, collateral data,
margin data).
244
ISO
20022
XML
SSR
Entities
involved in
short selling
transactions
Reporting of details of the net short
position in a particular instrument
(e.g., position holder, volume, and
notional amount of the position).
88
None
XML/DPC/
CSV/XLS
MAD/
MAR
Market
operators,
investment
firms that
operate a
trading venue
and issuers of
financial
instruments
Reporting of suspicious behavior,
trades, or orders in financial
instruments, to prevent insider
trading and market manipulation.
Instrument Reference Data
174
ISO
20022
XML/XLS
AIFMD
Managers of
alternative
investment
funds
Details of the funds managed by a
particular alternative investment
fund manager (e.g., investment
strategy, net asset value, leverage,
main markets, and instruments in
which a fund manager trades on
behalf of the fund).
517
XSD
XML/
PDF/DOC/
XLS
UCITS
DIRECT-
IVE
UCITS and
management
companies
Data sets which are subject to
public disclosure (e.g., provision of
the annual and semi-annual report
and other documents for public
disclosure), notifications and
registration applications.
171
None
PDF/DOC
CRAR/
CRAD
Credit rating
agencies
(CRAs)
Pricing policies, procedures and fee
data, information about ratings,
rating outlooks issued or endorsed,
etc.
1116
None
PDF/
Other
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 86 of 125
BENCH-
MARK
ENTITIES
MAIN CONTENT OF
SUPERVISORY REPORTING
# OF DATA
POINTS
COLLECTED
DATA
MODEL
REPORT
FORMAT
SAR/
SAD
Audit firms or
statutory
auditors
Notifications and reports related to
audit activities.
5
None
None
REMIT
Participants in
the energy
market
Reporting of wholesale energy
market transactions and
fundamental data of instruments
subject to those transactions.
206
Other
CSV
MMF
Managers of
Money Market
Funds
Details of the funds managed.
Not available
ISO
20022
XML/PDF/
DOC/
XLS
CSRD
All large
companies
and all listed
companies
Information on what they see as the
risks and opportunities arising from
social and environmental issues,
and on the impact of their activities
on people and the environment.
1100
ISO
20022
XML/PDF
SFDR
Financial
market
participants
Sustainability information, to help
investors who seek to put their
money into companies and projects
supporting sustainability objectives
to make informed choices.
Not available
ISO
20022
XML/PDF
AML
Obliged
entities i.e.,
credit
institutions,
financial
institutions,
and defined
entities in the
legislation
Suspicious transactions
Not available
None
None
TFR
Payment
Service
Providers
Information accompanying transfer
of funds
Not available
None
None
Based on the above information, IBM Promontory assessed each benchmark
according to the defined criteria. The table below summarizes the results.
Bench-
mark
Type of
data
collected
Level
structure
Data
Model
DEX
Lending
Borrowing
Insuranc
e
Micro/
Macro
CRR/CRD
IV
1
4
4
1
3
1
M
BRRD
1
4
4
1
1
1
M
Solvency II
1
4
4
1
1
3
M
MiFIR/MIFI
D II
4
4
4
4
2
1
m
EMIR
4
4
4
3
1
2
m
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 87 of 125
Bench-
mark
Type of
data
collected
Level
structure
Data
Model
DEX
Lending
Borrowing
Insuranc
e
Micro/
Macro
CSDR
4
4
4
2
1
1
m
SFTR
4
4
4
2
3
1
m
SSR
4
4
2
2
1
1
m
MAD/MAR
4
4
4
2
1
1
m
AIFMD
2
4
4
1
1
1
M
UCITS
Directive
2
1
1
1
1
1
m
CRAR/CRA
D
1
1
1
1
1
1
M
SAR/SAD
2
1
1
1
1
1
m
REMIT
4
3
2
2
1
1
m
MMF
2
4
4
2
1
1
m
CSRD
2
4
4
1
1
1
m
SFDR
2
4
4
1
1
1
m
AML
1
1
1
4
4
4
m
TFR
1
1
1
4
4
4
m
Legend
Type of data collected
(1 Aggregated – 4
Granular)
Level of structure
(1 Low – 4 High)
Data Models
(1 Low – 4 High)
Proximity with each
use case
(1 Low – 4 High)
From the above assessment, IBM Promontory identified a preliminary set of conclusions:
• In the landscape of DEXs, MiFIR/MiFID could be considered as the closest
benchmark, ensuring proper data models and structure. EMIR could also be
considered, ranking slightly behind. No macro supervision benchmark could be
identified. AML/TFR would also apply to this case, without a proper data set to use.
• In the landscape of Lending, SFTR and CRR/CRD IV could be considered as potential
candidates, with the CRR/CRD IV being at macro level and aggregated data. AML/TFR
would also apply to this case, with the same limitations in terms of proper set of data
to use.
• In the landscape of Insurance, Solvency II is the closest benchmark, despite that it is
only at very aggregated level. EMIR (i.e., Credit Default Swaps) could be considered
as a further micro benchmark, even so far from the case. AML/TFR would also apply
to this case again with limitation on data.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 88 of 125
ii. Views from three ESAs
To get input from the three ESAs, IBM Promontory went through the following steps:
• Organization of a training session with the ESAs (European Supervisory
Authorities): ESMA (European Securities and Markets Authority), EBA (European
Banking Authority) and EIOPA (European Insurance and Occupational Pensions
Authority) and the European Commission on the functioning of DeFi protocols to
ensure a level playing field across the project’s stakeholders;
• Organization of a dedicated workshop with each ESA aiming at:
o Discussing in depth the different protocols;
o Exchanging on the candidate legislative benchmarks; and
o Collecting information on the potential data set level benchmarks and the ESAs
views on their relevance in the specific context of this project (legal texts,
regulatory technical standards, guidelines, and data models).
IBM Promontory conducted a training session[2] focused on protocols on 13 June 2023, with
DG-FISMA, as well as representatives from the three ESAs.
The objective of this training session was to ensure a mutual understanding of the use cases
and to ease the selection of the benchmarks for each use case, through an introduction of four
different and representative DeFi protocols (Uniswap, AAVE, Nexus Mutual and MakerDAO).
During this training, IBM Promontory presented the functioning of the smart contracts for each
of those four protocols (Uniswap, AAVE, Nexus Mutual and MakerDAO), use cases and user
stories, the protocols’ governance, and whenever analogies with examples coming from
TradFi and insurance spaces.
IBM Promontory then subsequently organized specific workshops to determine the relevant
benchmarks that should be used, with each of ESA:
• EIOPA on 16 June;
• ESMA on 14 June and 21 June; and
• EBA on 14 June and 22 June.
For the ESMA workshops, IBM Promontory developed a presentation with examples of
protocols relevant to the use case to ease the discussion and ensure a sound benchmark
identification.
This approach was specific to ESMA, as EIOPA and EBA are concentrated on
macroprudential data, i.e., they concentrate on the risks related to the financial system as a
whole and therefore the data they collect from supervised entities concentrate on balance
sheet information. On the other hand, ESMA has several regimes focusing on micro level of
data (i.e. related to transaction data). Those meetings allowed IBM Promontory to enrich its
analysis by gathering the benchmarks vs. use case views from each ESA, as well as receiving
the related information, that will further greatly facilitate the mapping exercise in phase 3. They
also allowed discussing and collecting the relevant reporting requirements for each
benchmark considering the use case. Detailed discussions were then engaged with ESAs for
each use case to determine their potential characteristics and features.
After identifying the key aspects of each use case, the supervision process was discussed,
including data collection methods and the regulatory framework. With the ESAs, discussions
focused also on how they supervise each use case in TradFi, what data they gather, and
under which regulatory regime.
Below is a summary of the views of each ESA according to the relevant use case and the
potential benchmark, as well as the relevant data set:
• Regarding the DEX Use Case, ESMA was of the view that the best and closest
benchmark was MiFIR/MiFID 2 and the data set to be used should be the transaction
reporting under RTS 22 (approximately 200 data points). This data set is provided in
the Template MIFIR RTS 22.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 89 of 125
• Regarding the Lending Use Case, EBA was of the view that CRR/CRD IV would be
the closest benchmark possible, even if at macro level. It provided:
o An extract of COREP FINREP will be used as a benchmark (approx. 80 data
points out of 46,000) covering concentration of funding by counterparty and
concentration of funding by product type. Those data are the relevant data
covering credit/lending in COREP FINREP, the other data being not relevant
for the specific use case.
o Metrics for lending to customers (approx. 15 data points) from the guidelines
on loans. Both data sets are provided in the Template COREP FINREP fields
to consider.
o In addition, ESMA indicated that SFTR reporting could also be considered as
a benchmark (200 data points). This data set is provided in the template SFTR
RTS.
• Regarding the Insurance Use Case, EIOPA indicated that the closest benchmark
possible would-be Solvency II reporting, template premiums, claims, and expenses
by lines of business (template S.05.01.02) (approx. 20 data points). This template is
the relevant template as regards the activity of insurances related to the use case. The
other data from Solvency II concentrate on other activities of the Insurance Company,
further away from the use case.
At the end of these meetings, IBM Promontory subsequently requested documentation, laws,
and technical standards from the respective authorities. This included obtaining their data
model, which serves as the basis for their supervisory activities. Below is the comprehensive
list of documents and data models acquired, establishing the reference point for the
benchmark, the use case to which the data model would apply and a classification on whether
this would fall within macro or micro supervision.
ESAS
DOCUMENTATION COLLECTED
COMMENTS
USE CASE
MACRO/MICRO
SUPERVISION
EBA
COREP Reporting
Exposure value and related
investors/consumers, Risks
quantification, Collateral data, and
Concentration of funding by counterparty
and by product.
More specifically, identify and collect
data related to Segment, Geography,
Borrower type, Type of product (secured
vs unsecured), Large exposures
(concentration risk), breakdown by
counterparties, Asset quality indicators
(NPL, forborne), Risk parameters for
corporates on a borrower basis, Credit
registers for corporates, ECB's Anacredit
also only for corporates.eAny data giving
insights on the trend of lending activity is
welcomed.
Link to the main
guideline
document:
https://www.eb
a.europa.eu/re
gulation-and-
policy/supervis
ory-
reporting/guidel
ines-on-
common-
reporting-2011-
Lending &
Borrowing
(L&B)
Macro
Guidelines on loans origination and
monitoring – Annex 1,
A. Lending to consumers Items
Loan to income, Loan service to income,
Debt to income, Debt service to income,
Loan to Value (LTV)
Guidelines on
loans
Lending &
Borrowing
(L&B)
Micro
Guidelines on loans origination and
monitoring – 8
Guidelines on
loans
Lending &
Borrowing
Micro
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 90 of 125
ESAS
DOCUMENTATION COLLECTED
COMMENTS
USE CASE
MACRO/MICRO
SUPERVISION
Monitoring framework: 245. The credit
risk monitoring framework Items:
The payment behaviour of borrowers,
including any deviations from the
requirements of credit agreements,
including late, missed, or partial
payments.
Credit risk associated with both the
borrower and the transaction in relation
to:
Individual credit exposures and loss
given default, when applicable including
individual borrowers, their exposure
value, probability of default (PD) and
credit rating, when applicable as well as
group of connected clients and portfolio.
Credit risk per geographical location and
economic sector of ultimate exposure,
when applicable.
Impairments, reversals of impairments,
write-offs, and other decisions regarding
value adjustments for a credit exposure,
when applicable.
(L&B)
ESMA
MiFIR RTS 22
MiFIR_Transaction_Data.xls
MiFIR RTS 1
RTS on
transaction
reporting
RTS on
Transparency
(RTS 1)
DEXs
Micro
SFTR
SFTR auth.071.001.02_E.xls
SFTR auth.052.001.02.E.xls
SFTR Securities auth.070.001.02.E.xls
TSs below:
RTS
ITS
Lending &
Borrowing
(L&B)
Aggregation
&
Combination
Micro
EMIR
TSs below:
RTS:
ITS:
Insurance?
Micro
EIOPA
Solvency 2
EIOPA_SolvencyII_DPM_Annoted_T.xls
Templates for
the submission
of information
to the
supervisory
authorities:
Insurance
Macro
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 91 of 125
iii. Final considerations
After the initial assessment and input from the meetings with the ESAs, a draft list of potential
benchmarks was initiated:
USE CASE
BENCHMARK
DATA SET
DEX
MIFIR/MIFID
RTS 22
LENDING
CRR/CRD IV
Corep Finrep
Template collateral used in derivative transactions,
concentration of funding by counterparty and
concentration of funding by product type.
Guidelines on loans origination and monitoring
metrics for lending to customers
SFTR
RTS on SFTR reporting
INSURANCE
Solvency 2
Template on premiums, claims, and expenses by lines
of business
EMIR
RTS on EMIR reporting
Nevertheless, the above draft list of potential benchmarks list raised two concerns:
• While TFR and AML were identified during the assessment, no European structured
data set could be used as a benchmark for the exercise and were identified by EBA;
and
• The DEX Use case did not contain any information on pre-trade transparency as
identified in MiFIR.
IBM Promontory therefore identified two solutions to address the above:
• Use a national reporting system of AML/CFT suspicious transactions, even so at
descriptive manner and the description of TFR data as defined in the regulation; and
• Use the description of MiFIR of pre-trade transparency as a benchmark (without having
a proper data model).
The following three set of data (not structured, using only description) were also added as
benchmarks:
• For AML, using the user manual to declare suspicious transaction to the French
Ministry of Finance (Tracfin) and the relevant requested data set. This is described in
Appendix 6.4.7 of this document;
• For TFR, using the description in Article 4 of TFR, provided in Appendix 6.4.7 of this
document;
• For MIFIR, using the Table 1 of Annex 1 of RTS as benchmark for the DEX.
iv. Final list of Benchmarks
After the above considerations, the final list of proposed benchmarks is the following:
1. RTS 22 data set: See “Template MIFIR RTS 22” set excel file.
2. COREP FINREP data set: See “Template - COREP FINREP fields to consider” excel
file.
3. SFTR RTS: See “Template SFTR RTS” excel file.
4. Benchmark AML: See “Template AML” pdf file.
5. Solvency II: See “Template Solvency II” word file.
6. EMIR data set: See “Template EMIR Reporting” excel file.
7. TFR data set “Template TFR” word file.
8. RTS data set “Template RTS 1 MIFIR” word file.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 92 of 125
10.4. Annexes of section 5: Composite repository setting
a) Methodology to refine the composite Benchmark for all use cases
Once the benchmarks were selected, it became essential to compile all the data into one Excel
sheet. This central collection tool simplifies the review process and helps in forming statistics,
ensuring efficiency and a comprehensive audit trail of various procedures and phases.
For each of the eleven datasets related to the selected benchmarks, the same analytical
process was replicated:
• Establishing a dedicated Excel file.
• Inputting the benchmark identification from the inception report.
• Incorporating the necessary data for analysis and mapping.
Constructing a single repository increased efficiency, for instance, by regrouping the
numerous data that were present in several datasets at a time. IBM Promontory was also able
to keep an audit trail (e.g. datasets where the data are originated) during its analysis.
From a technical point of view, the establishment of this repository commenced with the
manipulation of benchmark files. During this process, multiple challenges surfaced, all of which
are outlined in this table:
USE CASE
BENCH
-MARK
DATA SET
APPENDIX
UNIQUE REPOSITORY SET UP
CHALLENGES
DEX
MiFIR/
MIFID
RTS 1
6.4.8
Unstructured data points extracted
from the column "Information to be
made public" of the word document
RTS 22
6.4.1
XML file from where all lines are
extracted, to make sur that all data
points were captured. Many
"headers" data points do not
correspond to a collected data and
generate many duplications in the
final repository
DEX &
INSURAN
CE
AML
AML
6.4.4
Unstructured data points extracted
from a PDF document from
TRACFIN web site
https://www.economie.gouv.fr/tracfin.
The data are extracted manually from
the operating model to complete a
declaration to TRACFIN when
suspicious transaction is discovered.
INSURAN
CE
EMIR
RTS on
EMIR
Reporting -
Level 5
6.4.6
XML file from where all lines are
extracted, to make sur that all data
points were captured. Many
"headers" data points do not
correspond to a collected data and
generate many duplications in the
final repository
Solvenc
y II
Life
Template -
S.05.01.02.
02
6.4.5
Structured data points extracted from
tables of "S.05.01.02" template
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 93 of 125
USE CASE
BENCH
-MARK
DATA SET
APPENDIX
UNIQUE REPOSITORY SET UP
CHALLENGES
Non-Life
Template -
S.05.01.02.
01
6.4.5
Structured datapoints extracted from
tables of "S.05.01.02" template
LENDING
CRR/
CRD IV
Consumer
detriment
6.4.2
Unstructured data points extracted
from COREP/FINREP Excel
dashboard
COREP
FINREP
6.4.2
Structured data points extracted from
COREP/FINREP Excel dashboard
Metrics for
credit
granting
and
monitoring
6.4.2
Unstructured data points extracted
from COREP/FINREP Excel
dashboard
SFTR
RTS on
SFTR
Reporting
6.4.3
XML file from where all lines are
extracted, to make sur that all data
points were captured. Many
"headers" data points do not
correspond to a collected data and
generate many duplications in the
final repository
TFR
Transfer of
Funds
Regulation
Data
6.4.7
Unstructured data points extracted
from a word document
Upon aggregating the data within a single file, it became obvious that a more detailed step-
by-step methodology was necessary.
A comprehensive breakdown of each field used to construct the global benchmark reference
is provided below:
DATA SOURCES
DATA BASE FIELDS
DESCRIPTION
INCEPTION
REPORT DATA
Use Case
List of Use Cases selected for the project
Benchmark
List of Benchmark selected for the project
Data Set
First level of data set naming based on the
benchmark source
Appendix
Refer to the appendix in the Inception report
BENCHMARKS
DATA
Publisher
Information located in the benchmark files when
available + Additional information added by IBM to
help filtering
Collection
Information located in the benchmark files when
available + Additional information added by IBM to
help filtering
Usage Guideline
Name
Information located in the benchmark files when
available + Additional information added by IBM to
help filtering
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 94 of 125
DATA SOURCES
DATA BASE FIELDS
DESCRIPTION
Name
Name of the data point
Type code
Type code of data point when available (data
format)
Definition
Description of the data points when available +
Additional information added by IBM to help
filtering
IBM
PROMONTORY
ANALYSIS
Comments on data
points
Based on benchmark data, comment representing
first level of analysis for each of 1 968 data points
Refined blocks
For each homogeneous data sets, IBM
promontory propose a naming with the benchmark
and synthetic name
Blocks
Aggregated level based on blocks from ESMA
guidelines “Transaction reporting, order record
keeping and clock synchronization under MiFID II”
and on IBM promontory proposition in grouping
Criticality Financial
stability
(0=NA, 1=Low,
2=Medium, 3=High)
This indicator is built in 2 steps:
1- For each data point, define if it is relevant for
the framework of Financial Stability objective
2- Assess the criticality based on the name of the
data point, description and leveraging IBM
promontory expertise on supervisory and
regulation topics.
Criticality Market
integrity/ Investor
protection
(0=NA, 1=Low,
2=Medium, 3=High)
This indicator is built in 2 steps:
1- For each data point, define if it is relevant for
the framework of Market integrity and Investor
protection objectives
2- Assess the criticality based on the name of the
data point, description and leveraging IBM
promontory expertise on supervisory and
regulation topics.
Data Point Quality
after mapping
(0= missing,
1=Partially available,
2=Poor, 3=High)
This indicator, as indicated in the IBM RFP
answer, after the data mapping between DeFi data
and benchmark data will allow to assess the
quality of the mapping with the followings:
- Fields where data is missing
- Fields where data is partially available
- Fields where the data is available with very low
or low quality
- Fields where the data is available with
reasonable quality
Financial Stability:
Criticality * Quality
This indicator will help to discriminate the
importance of each data point by a product of
criticality and quality for Financial Stability
objective. The higher the score is, the higher is the
requirement to have the data point for supervisory
purpose.
Market integrity/
Investor protection:
Criticality*Quality
This indicator will help to discriminate the
importance of each data point by a product of
criticality and quality for Market integrity and
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 95 of 125
DATA SOURCES
DATA BASE FIELDS
DESCRIPTION
Investor protection objectives. The higher the
score is, the higher is the requirement to have the
data point for supervisory purpose.
IBM
PROMONTORY
MAPPING
Protocols Data
Name of the protocols
Off-chain data name
Name of data provider
Computed data name
Name of data computed from other data or
parameters
On-chain data name
Data’s name
Description
Description of data
Mapping Results
Fields where data is
missing
Fields where data is
partially available
Fields where the data
is available with
exceptionally low or
low quality
Fields where the data
is available with
reasonable quality
Results Analysis
Mapping
Equivalent
New Concept
No Equivalent
Justification
Justification of New concept and No equivalent
Source
Source of data mapped
Comparability across
the two assessed
protocols for each of
the use cases.
Verify if each data points studied is similar in the 2
protocols
b) Analysis phase illustrated by extraction from the composite
benchmark
The analysis methodology employed entailed a review of each data point. A four-step process
was devised. This ensured a comprehensive understanding of the benchmark data points and
facilitated the development of metrics that are crucial for drawing later conclusions.
The primary components of this methodology were highlighted to DG FISMA on 28 September
2023. Discussions about the methodology took place during dedicated workshops. DG FISMA
offered no further commentary or concerns on the presented approach. Nevertheless,
subsequent inquiries regarding the criticality and quality of the data points arose. To address
these, an in-depth rationale is explained below.
Step 1: An initial in-depth review was conducted for each data point. The names and
definitions of these data points were used as input for the general remarks to facilitate the
initial aggregation into cohesive data sets. This primary phase was instrumental in shaping
the data sets outlined in Step 2. .Below is an example:
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 96 of 125
USE
CASE
BENCH
-MARK
DATA
SET
APPENDIX
COMMENTS
ON DATA
POINTS
NAME
DEFINITION
DEX
MiFIR/
MIFID
RTS
22
6.4.1
Data points
focused on
reporting
aspects rather
than
transactions
aspects
Envelope
Technical
element
wrapping the
supplementary
data.
Place And
Name
Unambiguous
reference to
the location
where the
supplementary
data must be
inserted in the
message
instance.
In the case of
XML, this is
expressed by
a valid XPath.
Receipt
Date Time
Defines the
date and time
when the
report was
originally
received by
the national
competent
authority.
Step 2: Building on the insights and comments from Step 1, data were grouped into blocks
named “Refined blocks” in the table below. Those refined blocks aimed to group the
homogeneous data sets with the overarching benchmark categories.
For instance, we defined a refined block called "MiFIR Buyer identification" from the MiFIR
Benchmark. In the context of RTS22, "MIFIR Buyer identification" consolidates several data
points for this objective.
This stage of data aggregation and naming is pivotal as it paves the way for a more advanced
level of aggregation in Step 3.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 97 of 125
An illustrative example is provided below:
USE
CASE
BENCH-
MARK
DATA
SET
APPENDIX
REFINED
BLOCKS
COMMENTS ON DATA
POINTS
DEX
MiFIR/
MIFID
RTS
22
6.4.1
MiFIR Buyer
identification
Account in TradFi can be
assimilated to Wallet ID in DeFi
MiFIR
Physical
person
identification
Unique identification of a
person/entity is not yet defined
in DeFi. All other data captured
via the KYC process in the
TradFi may exist in DeFi
space, mostly hold by private
entities - to be investigated
further to this project
MiFIR algo
identification
Algo location and currency
under the compliance with ISO
4217.
Step 3: Drawing from the findings and analyses of Steps 1 and 2 and anchored in the ESMA
guidelines on financial transactions (available at "ESMA Guidelines on MiFID II Transaction
Reporting"), data sets were grouped into distinct "Blocks", which consisted of several refined
blocks. The ESMA guideline delineated 12 such Blocks. To comprehensively address the core
themes identified in the benchmarks, IBM introduced five additional Blocks.
Below is an illustrative example:
USE
CASE
BENCH
-MARK
DATA
SET
APPENDIX
BLOCKS
REFINED
BLOCKS
COMMENTS ON
DATA POINTS
DEX
MiFIR/
MIFID
RTS
22
6.4.1
1:
Buyer/Seller
identification
MiFIR Buyer
identification
Account in TradFi can
be assimilated to
Wallet ID in DeFi
Legal entity identifier
is not yet defined
within DeFi.
MiFIR
Physical
person
identification
Unique identification
of a person/entity is
not yet defined in
DeFi. All other data
captured via the KYC
process in the TradFi
may exist in DeFi
space, mostly hold by
private entities - to be
investigated further to
this project
MiFIR algo
identification
Algo location and
currency under the
compliance with ISO
4217.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 98 of 125
Now in the analysis process, IBM Promontory delineated a total of 17 distinctive Blocks, each
accompanied by a succinct description provided in the subsequent table:
DEFINED BLOCKS
DESCRIPTION
BLOCK 1: BUYER/SELLER
IDENTIFICATION
Please refer to the following document: "ESMA
Guidelines on MiFID II Transaction Reporting"
BLOCK 2: DECISION-MAKER FOR
BUYER/SELLER
BLOCK 3: (COMBINATION OF 1 AND
2): BUYER/SELLER AND DECISION-
MAKER SPECIFIC SCENARIOS
BLOCK 4: INVESTMENT DECISION
WITHIN THE FIRM
BLOCK 5: EXECUTION WITHIN THE
FIRM
BLOCK 6: TRADING DATE TIME
BLOCK 7: VENUE
BLOCK 8: SHORT SELLING FLAG
BLOCK 9: WAIVER, OTC POST-TRADE
AND COMMODITY DERIVATIVE
INDICATORS
BLOCK 10: BRANCHES
BLOCK 11: STATUS OF
TRANSACTION REPORTS AND
CORRECTIONS
BLOCK 12: CHANGE IN NOTIONAL
BLOCK 13I: CORE TRANSACTION
DATA
Data points fully focused on the transaction
identification. Example: quantity, price, amount, etc.
BLOCK 14I ; FINANCIAL INSTRUMENT
IDENTIFICATION
Data points describing the financial instrument from
TradFi perspective. Example: notional, multiplier,
ISIN…
BLOCK 15I: TRADITIONAL FINANCE
SPECIFIC DATA
Data point relevant only under the current TradFi
structure. Example: SIRET, registration number, VAT
EU identifier…
BLOCK 16I: FUNDING RELATED DATA
Data points focused on funding phase before a
transaction. Example: Concentration of funding by
counterparty, product type, country, code of
counterparty…
BLOCK 17I: INSURANCE PREMIUM
AND CLAIM
Data point focused on insurance specificities.
Example: Premium written, claims, premium earned…
Please note that the Blocks numbered with an i (13i to 17i) identify the blocks created by IBM
Promontory.
Step 4: After the identification of homogeneous data sets among benchmark data points, IBM
Promontory assessed the criticality and quality of each data point as defined in its proposal to
the call for tender.
In its response, IBM Promontory highlighted that every data point would be ranked based on
its supervisory significance, using a scale from one to five. Nevertheless, IBM Promontory
identified that this large scale was unnecessary and reduced it to one to three. While key fields
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 99 of 125
such as identity, price, and asset type are anticipated to score higher, others like transaction
time might receive a lower rank. To fine-tune this grading, several and different criticality levels
are tethered to supervisory objectives: market integrity, investor protection, and financial
stability. This yields three potential criticality ranks for each data field, culminating in a
weighted data model based on individual point criticality. aDuring the 28 September 2023
workshop, IBM proposed a tri-tiered ranking system for criticality: 3 as High, 2 as Medium, and
1 as Low, eschewing a five-point scale. This was proposed since intermediary nuances do not
significantly enhance the analysis. The goal is to assist DG FISMA in discerning if collected
DeFi data are sufficient for DeFi space supervision. During this workshop, it was also decided
to group Market Integrity/Investor protection into a single criticality pillar. The criteria for this
ranking are:
• High: A data point deemed indispensable for supervisory tasks.
• Medium: A data point deemed of moderate importance but could become vital when
paired with others.
• Low: A data point deemed non-essential for supervisory purposes.
IBM's approach to criticality assessment is systematic:
• Financial Stability Criticality: Each data point's relevance is first determined in the
context of the Financial Stability objective. Then its criticality is gauged, influenced by
its name, description, and IBM Promontory's regulatory expertise.
• Market Integrity/Investor Protection Criticality: Similarly, the relevance of each data
point is evaluated in the purview of Market Integrity and Investor Protection objectives.
The subsequent assessment also leans on the data point's name, description, and
IBM's regulatory knowledge.
• Data Point Quality Post-mapping: After mapping DeFi-collected data with
benchmark data, the quality of this mapping is scrutinized, focusing on:
o Missing data fields
o Partially available data fields
o Low-quality data fields
o Reasonable quality data fields
• Impact Assessments (Criticality x Quality): Two indicators, one for Financial
Stability and another for Market Integrity/Investor Protection, determine the
assessment of each data point. A higher score denotes increased supervisory
importance and availability of the field. A low data point is low availability for a non-
important field.
c) Methodology to integrate off-chain data
The methodology is completed with a specific integration of off-chain data that are gathered
mostly in the DEXs protocols websites. This allowed enriching the data collection with “static”
data that are not available on the ledger but are necessary to complete the data set.
Based on IBM Promontory knowledge of DeFi practices and associated vocabulary, a non-
exhaustive list of off-chain data point was established based on the following criteria:
• Common vocabulary used in the DeFi universe (e.g. Token, source code, TVL…);
• Concept that are key in DeFi (e.g. Smart Contract address, Governance token…) to
understand the behind-the-scenes processes;
• Used metrics to monitor DeFi activity; and
• Specific to DeFi space technical vocabulary (e.g. Token standard, Functionality
description…).
The selected off-chain data was added to the global repository and the following changes were
introduced:
• An additional Block was created – “Block 18i DeFi specific data”. This block is
dedicated to Off-chain data which was not mapped to an existing benchmark data
point.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 100 of 125
• For each Off-chain data point for which no equivalent is found in the benchmark data
points, the following assessments was conducted:
o Assess and define to what extent the data point is close to Financial Stability
or to Market Integrity/Investor protection;
o Assess and define the quality of each data point;
o Calculate the criticality and quality metrics for Financial Stability and for Market
Integrity/Investor protection;
o Each data point has a description and is provided with the following fields:
▪ Mapping results;
▪ Mapping equivalence;
▪ Justification;
▪ Source;
▪ Comparability across the two assessed protocols for each of the use
cases; and
▪ Additional comment.
Furthermore, six additional off-chain data point are mapped with the benchmark datapoints.
These data points are visible in the column T “Off-chain data name.”
d) Methodology to map benchmark data points with DeFi collected
data
The initial proposal centered on mapping all data directly to the benchmark model using
corresponding collected information. However, certain challenges emerged.
First, benchmark data points are tailored to mirror the organizational makeup of TradFi. Given
the distinctive nature of DeFi's organizational structure, it became apparent that direct
mapping might not be as efficient or productive for the project's objectives. This concern was
communicated to DG FISMA in September.
During the workshop on 28 September 2023, a revised mapping strategy was discussed and
agreed upon by both IBM Promontory and DG FISMA. Instead of trying to correlate each
benchmark data point with a DeFi equivalent, IBM Promontory implemented a two-phase
approach:
Primary Mapping: Start by examining all data gleaned from DeFi protocols. Where feasible,
map to the benchmark data points. Any data not mapped is then treated as a potential addition
to the global repository, subject to evaluations of criticality and quality.
Block Evaluation: For every defined Block, quantify the mapped data per criticality grade.
Subsequently, employ statistics to assess the depth of coverage a Block provides for
supervisory purposes, using DeFi data as the benchmark.
An essential aspect of this project is the alignment process between two data sets. This
alignment is aided by IBM Promontory's in-depth comprehension of benchmark data points –
both in terms of naming and description. On the other side, there is the generalized
understanding of DeFi data points, which presents its own challenges, given the absence of
any standard documentation. It is worth emphasizing is that DeFi data currently lacks a
universally accepted taxonomy. The experience of DeFi experts, together with research,
helped mitigating this issue.
* AML: this data set is applicable for all uses cases. A such, the same data points will be reviewed for each Use
Case. Reminder: the AML data set is based on TRACFIN website declaration, and all the data points are in the
Appendix 6.7 Benchmark AML pdf file, as indicated in the appendix 6.4.4 of the Inception Report.
EMIR benchmark number of detailed data points is about 19 629 data. IBM Promontory proposed to focus on
higher level data concepts. Based on the appendix 6.9 EMIR Reporting excel file (Appendix 6.4.6 in the Inception
Report), only Data points of grouping level 0 to 5 were selected for review due to high volume of data points. As
result, 158 data point were selected for review among 19 629 data points.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 101 of 125
10.5. Annexes of section 8
a) Collected off-chain data points
Concept
Data Point
Description
Potential Supervisory Objectives
Covered
Similarity To TradFi
Applicable
To
Activity Analysis
Community Sentiment
The general sentiment of the
protocol community, typically
gauged from social media and
forums.
Market Integrity, Investor Protection
No
All
Stablecoin Interest
Rate Correlation
The correlation of Curve’s yields
with broader market interest rates.
Financial Stability
Yes (e.g. Correlation of bank
interest rates with central
bank rates)
Curve
Protocol Revenue
Growth
Growth in revenue generated by a
protocol from fees.
Market Integrity, Financial Stability
Yes (e.g. Revenue growth in
financial services
companies)
All
Historical Interest
Rate Trends
Trends in interest rates over time on
lending and borrowing protocols.
Market Integrity, Financial Stability
Yes (e.g. Historical interest
rate trends in banking)
All
Average Claim
Resolution Time
Average time taken to resolve and
pay out claims.
Investor Protection
Yes (e.g. Claim processing
time in traditional insurance)
Insurance
Historical Claim
Trends
Trends in insurance claims filed and
resolved over time.
Market Integrity, Financial Stability
Yes (e.g. Historical claims
data in traditional insurance)
Insurance
24-hour Trading
Volume
The total trading volume on a
protocol in the last 24 hours.
Market Integrity, Financial Stability
Yes (e.g. Daily trading
volume of a stock)
All
Average Pool Yield
Average yield generated by liquidity
pools.
Investor Protection, Financial
Stability
Yes (e.g. Average return
rate of a bond fund)
All
Top Traded Pairs of
tokens
Most traded token pairs on DEXs.
Market Integrity
Yes (e.g. Most traded
currency pairs in forex)
all
Token Market Cap
Market capitalization of a protocol.
Market Integrity, Financial Stability
Yes (e.g. Market
capitalization of a publicly
traded company)
ALL
Stablecoin Trading
Volume of stablecoin trades on
Market Integrity, Financial Stability
Yes (e.g. Trading volume in
Curve
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 102 of 125
Concept
Data Point
Description
Potential Supervisory Objectives
Covered
Similarity To TradFi
Applicable
To
Volume
Curve.
forex markets)
Growth in Cover
Demand
The rate of growth in demand for
insurance covers offered by
insurance protocols
Market Integrity, Financial Stability
Yes (e.g. Growth in policy
sales in insurance
companies)
Insurance
Claim Approval and
Denial Rates
Rates of claims approved and
denied in an insurance protocol.
Investor Protection
Yes (e.g. Claim settlement
rates in traditional
insurance)
ALL
Premium Income
Total income from premiums paid
by policyholders.
Financial Stability
Yes (e.g. Premium income
in traditional insurance)
Insurance
Trends in Coverage
and Claims
Historical trends in insurance
coverage provided and claims
made.
Market Integrity, Financial Stability
Yes (e.g. Historical claims
and coverage data in
insurance)
Insurance
Adoption Rate of DAI
Rate of growth in the adoption and
usage of DAI.
Market Integrity, Financial Stability
No
MakerDAO
Claim Statistics
Claim Approval Rate
Percentage of insurance claims
approved versus filed.
Investor Protection
Yes (e.g. Claim approval
rates in traditional
insurance)
Nexus
mutual
Ecosystem
Number of DApps
Integrated
Count of DApps that have
integrated Uniswap.
Market Integrity
No
Uniswap
Number of Integrated
DEXs
The count of DEXs aggregated by
1inch for optimizing trades.
Market Integrity
No
1Inch
API Accessibility and
Usage
Availability and usage data of
protocol’s API for third-party
integrations.
Market Integrity
No
All
Role in DeFi Trade
Optimization
1inch's specific role and influence in
optimizing DeFi trades.
Market Integrity, Financial Stability
No
1Inch
System Upgrade
Frequency
Frequency and impact of system
upgrades and improvements.
Market Integrity
Yes (e.g. Software upgrade
cycles in financial systems)
MakerDAO
Ecosystem
Level of integration
Measure the integration to DeFi
Financial Stability
No
All
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 103 of 125
Concept
Data Point
Description
Potential Supervisory Objectives
Covered
Similarity To TradFi
Applicable
To
Integration
with DeFi
ecosystem with number of
partnerships
Financial
Innovation
Unique Financial
Products
Specialized financial products
offered by a protocol
Market Integrity, Investor Protection
Yes (e.g. Innovative
financial products in banks
or financial institutions)
Aave
Governance
Number of
Governance
Proposals
Count of proposals in a protocol’s
governance system.
Market Integrity
Yes (e.g. Number of
shareholder proposals in a
corporation)
Uniswap
Token Governance
Influence
The influence of tokens holder on
protocol governance decisions.
Market Integrity
Yes (e.g. Voting power of
shares in corporate
governance)
ALL
Insurance
Metrics
Total Cover Amount
The total value of insurance cover
provided by an insurance protocol
Financial Stability
Yes (e.g. Total insurance
coverage in traditional
insurance companies)
Insurance
Number of Active
Covers
Total number of active insurance
covers issued.
Investor Protection, Financial
Stability
Yes (e.g. Number of active
policies in an insurance
company)
Insurance
Lending &
Borrowing Data
Total Loans Issued
Cumulative value of all loans issued
through protocols.
Financial Stability, Investor
Protection
Yes (e.g. Total loans issued
by a bank)
All
Total Borrowing
Volume
The total volume of assets
borrowed from protocols
Financial Stability
Yes (e.g. Total borrowing
volume in traditional lending
institutions)
All
Liquidity Data
Number of Liquidity
Pools
Total number of active liquidity
pools on a protocol.
Financial Stability
Yes (e.g. Number of
different mutual funds
offered)
All
Historical Liquidity
Trends
Trends showing liquidity changes
over time.
Financial Stability
Yes (e.g. Historical asset
value trends in investment
funds)
All
Average Duration of
Liquidity Provision
Average time users provide liquidity
in pools.
Investor Protection, Financial
Stability
No
All
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 104 of 125
Concept
Data Point
Description
Potential Supervisory Objectives
Covered
Similarity To TradFi
Applicable
To
Cross-Protocol
Liquidity
Liquidity available through a
protocol's integration with other
DeFi protocols.
Financial Stability
No
All
Number of Liquidity
Providers
Count of unique addresses
providing liquidity on a protocol.
Market Integrity
Yes (e.g. Number of account
holders in a bank)
All
Pool Concentration
(size)
The concentration of liquidity in
specific pools in a protocol.
Financial Stability
Yes (e.g. Concentration of
assets in particular mutual
funds)
All
Liquidity Pool
Composition
Composition of the liquidity pools in
a protocol.
Financial Stability
Yes (e.g. Asset composition
in mutual funds)
All
Capital Pool and
Solvency
Size and health of the capital pool
for claim payouts.
Financial Stability, Investor
Protection
Yes (e.g. Solvency and
reserve levels in traditional
insurance)
Insurance
DAI Liquidity in
Markets
Liquidity of DAI across various
exchanges and DeFi protocols.
Financial Stability
No
MakerDAO
Incentives for Liquidity
Providers
Incentives for users providing
liquidity
Financial Stability
Yes (e.g. Incentives for
liquidity providers in
financial markets)
All
Operational
Efficiency
Transaction
Throughput
The number of transactions Curve
can handle in each period.
Market Integrity
Yes (e.g. Transaction
processing capacity in
online banking)
Curve
Protocol
Identification
Protocol Name
The official name of the DeFi
protocol.
Market Integrity
Yes (e.g., venue)
All
Protocol Version
Version of the protocol to identify
updates and changes over time.
Market Integrity
Yes (Software version in
banking systems)
All
Developer(s)
Entities or individuals who have
developed the protocol.
Market Integrity, Investor Protection
Yes (e.g., Company
Founders)
All
Source Code
Repository
A link to where the protocol's source
code is publicly stored, e.g.,
Market Integrity, Investor Protection
No
All
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 105 of 125
Concept
Data Point
Description
Potential Supervisory Objectives
Covered
Similarity To TradFi
Applicable
To
GitHub.
Token Name
Official name of the token used
within the DeFi protocol.
Market Integrity, Investor Protection
Yes (e.g., Stock Ticker)
All
Token Symbol
Abbreviation or ticker symbol for the
token.
Market Integrity
Yes (e.g., Stock Ticker
Symbol)
All
Token Standard
The standard which the token
adheres to, e.g., ERC-20 or ERC-
721.
Market Integrity
No
All
Token Supply
The total number of tokens created.
Financial Stability, Market Integrity
Yes (e.g., Total Shares
Outstanding)
All
Tokens Involved
Tokens that are pooled together.
Market Integrity
Yes (e.g., Mutual Fund
Assets)
All
Total Value Locked
(TVL)
The total value of assets locked in
the liquidity a pool or at protocol
level.
Financial Stability
Yes (e.g., Total Assets
Under Management, Total
deposits in a bank)
All
Risk
Management
Unique Cover
Products
Specialized insurance products
offered, unique to DeFi risks.
Market Integrity, Investor Protection
Yes (e.g. Specialized
insurance products in niche
markets)
Insurance
Types of Risks
Covered
Several types of crypto-related risks
covered.
Investor Protection
Yes (e.g. Types of coverage
in general insurance)
Insurance
Smart Contract Audit
Status
The status and results of any smart
contract audits.
Market Integrity, Investor Protection
No
All
Transaction
Details
Average Transaction
Fee
The average fee charged per
transaction on a protocol
Market Integrity, Investor Protection
Yes (e.g. Brokerage fee per
trade)
All
Token Price
Current market price of Native
token
Market Integrity, Investor Protection
Yes (e.g. Share price of a
company)
All
Gas Fees for
Transactions
The cost in terms of gas fees for
executing transactions on Curve.
Market Integrity
No
All
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 106 of 125
Concept
Data Point
Description
Potential Supervisory Objectives
Covered
Similarity To TradFi
Applicable
To
Default Rates
Rate of defaults on loans based on
liquidations (proxy)
Financial Stability, Investor
Protection
Yes (e.g. Default rates of
loans in traditional banks)
All
Collateralization
Ratios
Required collateral ratios for
borrowing
Financial Stability, Investor
Protection
Yes (e.g. Loan-to-value
ratios in mortgage banking)
All
Trading Fee Details
Details on the fee structure for
using a protocol
Market Integrity, Investor Protection
Yes (e.g. Fee structure in
online trading platforms)
All
Collateral Types and
Ratios
Types of assets accepted as
collateral and their required ratios.
Financial Stability, Investor
Protection
Yes (e.g. Collateral
requirements in traditional
banking)
All
Stability Fee Rates
Interest rates charged for
generating DAI against collateral.
Market Integrity, Investor Protection
No
MakerDAO
DAI Stability Fee
Trends
Trends and changes in the stability
fees over time.
Market Integrity, Investor Protection
Yes (e.g. Interest rate trends
in banking)
MakerDAO
DAI Peg Stability
Historical data on DAI’s
performance in maintaining its peg
to the USD.
Market Integrity, Financial Stability
No
MakerDAO
User Base
Number of
Policyholders
The count of users holding
insurance policies in an insurance
protocol.
Market Integrity
Yes (e.g. Number of
policyholders in a traditional
insurance company)
Insurance
User Activity
Number of Active
Users
The count of unique addresses
interacting with a protocol
Market Integrity
Yes (e.g. Number of active
brokerage accounts)
All
User Growth Rate
The rate at which new users are
joining a protocol
Market Integrity, Investor Protection
Yes (e.g. new account
growth rate in a bank)
All
Number of Mutual
Members
Count of unique members or
policyholders in Nexus Mutual.
Market Integrity
No
Nexus
mutual
User Participation in
Governance
The level of active user participation
in a protocol governance.
Market Integrity
Yes (e.g. Shareholder
participation in corporate
governance)
All
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 107 of 125
b) Governance structure
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 108 of 125
c) Study on liquidity behaviour when an upgraded version of a
protocol is released
Following discussions with the European Commission in July 2023 regarding protocol
evolution and the impact of upgrades during the ongoing DeFi Pilot project, IBM Promontory
conducted a study to examine liquidity behavior within protocols upon the release of an
upgraded version.
For this study, we reviewed four protocols and the findings from our observations are
presented below.
i. Uniswap versioning
Uniswap V1 was launched in November 2018.
TVL on Uniswap v1 decreased starting 16 May 2020 when Uniswap v2 is released. Uniswap
v1 is stabilized around 7 million $ afterwards.
Source: DefiLlama
Uniswap V2 was released in May 2020.
Source: DefiLlama
TVL on Uniswap v2 decreased strongly starting 16 May 2021 when Uniswap v3 is released.
Uniswap v2 TVL is stabilized around 1 billion $. Uniswap V3 was launched in May 2021.
TVL on Uniswap v3 increase from May 2021 to stabilize around 3billion $.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 109 of 125
Source: DefiLlama
Takeaways: Each recent version of Uniswap bring new features and expand the size of
liquidity. A migration to upgrade version was fast from v1 to v2 (few months) and it took almost
1 year from v2 to v3.
ii. Curve versioning
Created begin 2020, Curve v1 has been focused on pegged stablecoins only.
In January 2022, Curve v2 factory pools release aims to provide the Curve protocol
infrastructure for highly efficient non-pegged asset swaps. This version also allowed access
to new feature such as gas optimization, liquidity concentration, pools management
customization and better incentivization of the stakeholders.
Source: DefiLlama
Takeaway: No migration observed as Curve v1 focuses on pegged stablecoins and Curve v2
expand the pool logic to others crypto assets and opened the trading possibilities with new
features.
iii. Aave versioning
Launched in 2017 under the name ETHLend, the platform was rebranded as Aave in 2018,
introducing a new set of features.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 110 of 125
Source: DefiLlama
V2: The migration began in February 2021, with a decrease observed in V1 and an increase
observed in V2. The process took approximately four months to complete.
Source: DefiLlama
V3: Between 19 April and 23 April, almost 1 billion $ TVL moved from v2 to v3. Then the
migration continues for two additional months.
Source: DefiLlama
Takeaways: The migration between 2 different version of AAVE can be brutal (1 billion $ TVL
moved if few days) as it can be smooth during months. Many factors explain the behaviors of
holders (new trading opportunity, new features to exploit, new rewards or incentives to
catch…).
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 111 of 125
iv. Compound versioning
v1: launched in February 2019 (white paper) and the TVL was stabilized around 100 million $.
Source: DefiLlama
V2: Launched in mid-July 2020, featuring the COMP token. The total value locked experienced
a significant increase from $100 million to $500 million in less than 10 days. Rather than being
a migration, this presented a new opportunity for investors. By the end of 2022, the TVL
stabilized at around $2 billion.
It's worth noting that the TVL decreased from $3 billion to $2 billion within one month between
August 15th and September 15th, 2022. There are no indications to suggest that this decrease
was correlated with the V3 upgrade, as another decrease occurred in November 2022,
resulting in a TVL of $1 billion.
Source: DefiLlama
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 112 of 125
v3: released 25 august 2022.
Source: DefiLlama
Takeaway: The v3 seems linearly increasing since the release, but without clear link with the
previous versions.
v. Conclusions of the study
Across various DeFi protocols, the release of new versions often brings about shifts in TVL.
• Uniswap: Each subsequent version of Uniswap has introduced new features, leading
to an expansion in liquidity. The migration from v1 to v2 took a few months, while the
transition from v2 to v3 spanned almost a year. This suggests that the adoption rate
and migration speed can vary between versions.
• Curve: Unlike other protocols, Curve did not experience a migration between its
versions. The focus of Curve v1 was on pegged stablecoins, while v2 expanded its
pool logic to include other crypto assets and additional features. This indicates that not
all protocol upgrades necessitate migrations or shifts in TVL.
• AAVE's migrations between versions have varied in nature. While some migrations
have been abrupt (almost 1 billion $ TVL moved from v2 to v3 in few days), others
have been more gradual, spanning several months. This variability can be attributed
to a range of factors, including new trading opportunities, feature enhancements, and
new incentives.
• Compound: The release of Compound's v2 version, accompanied by the COMP
token, led to a significant surge in TVL (from 100 million $ to 500 million $ in less than
10 days) in a short span. However, the relationship between the release of v3 and
changes in TVL is less clear. The TVL for Compound has experienced fluctuations, but
it is challenging to directly attribute these changes to the release of v3.
In summary, while new protocol versions often introduce novel features and opportunities that
can influence TVL allocation, the nature and speed of migrations vary widely. External factors,
beyond just protocol upgrades, play a significant role in shaping user behavior and
TVL/liquidity dynamics.
As a result of this review, the new protocol versions will have limited impact on the DeFi Pilot
project since each version is standalone and additional versions bring new features which do
not affect fundamentally the core smart contract corpus of each protocol. At liquidity level,
each protocol is the sum of the liquidity of all versions. Indeed, the TVL of outdated version
may continue to be competitive from governance or other incentivized stakes perspective.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 113 of 125
11. Glossary
TERM
DEFINITION
Aave Token
Aave's native governance token, used for voting and
protocol safety.
Active Cover Amount (Aca)
The total value of insurance coverage currently in effect.
Actuarial Committee
Experts responsible for assessing the statistical
probabilities of risk.
Aggregators
Platforms or services that combine and consolidate data or
services from multiple sources into a single interface.
Algorithmic Stablecoin
A type of cryptocurrency designed to maintain a stable
value through algorithmic mechanisms, often without direct
collateral backing.
Application
A software program or platform that serves a specific
purpose or provides a service to users.
Arbitrage
The practice of taking advantage of price differences
between different markets or exchanges to make a profit.
Asset-Backed Token
A cryptocurrency or digital token that represents ownership
or rights to a specific underlying asset, such as real estate
or commodities.
Atokens
Interest-bearing tokens representing the stake of the lender
in the pool.
Automated Market Maker
(Amm)
A type of DEX protocol that relies on mathematical formulas
to price assets instead of using an order book.
Automated Market Maker
(Amm)
A DEX mechanism that uses algorithms to determine prices
based on the ratio of assets in liquidity pools.
Automated Policy
Management
Using smart contracts for efficient management and
execution of insurance policies.
Automated Rebalancing
Automatic adjustment of assets in a pool to maintain
balance and reduce impermanent loss.
Autonomous Interest Rate
Models
Self-adjusting models for setting interest rates based on
pre-defined rules.
Best Trade Routes
Algorithmically determines the most efficient paths for
trades across different DEXs.
Block Validation Protocols
Consensus mechanisms used in blockchain networks to
validate and confirm transactions and maintain the integrity
of the blockchain.
Blockchain
A decentralized and distributed digital ledger that records
transactions across multiple computers or nodes.
Bonding
Process of staking NXM as a form of security, necessary
for certain roles within the system.
Borrow Cap
Maximum limit on the amount of an asset that can be
borrowed from the protocol.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 114 of 125
TERM
DEFINITION
Bridge
A connection or interface between two different blockchain
networks, allowing the transfer of assets or data between
them.
Capital Buckets
Pools of capital that are allocated to cover specific types of
insurance risks.
Capital Pool
The aggregated funds used to pay out claims and other
expenses.
Chi Gastoken
A token designed by 1inch to reduce transaction fees on
the Ethereum network.
Claim Assessment
The process of evaluating the validity and extent of an
insurance claim.
Claim Payout
The disbursement of funds or compensation to the
policyholder or beneficiary based on the terms of an
insurance claim.
Claim Validation
Process of verifying and validating insurance claims made
by policyholders.
Claims Assessment
The process where NXM holders vote to approve or deny
claims.
Collateral
An asset or property pledged as security for a loan or other
financial obligation.
Collateral Auctions
Auctions used to sell off collateral from liquidated CDPs.
Collateral Factor
Determines how much can be borrowed against a specific
collateral type.
Collateral Swap
Feature allowing users to switch collateral types without
closing their debt positions.
Collateralized Coverage
Insurance coverage backed by collateral to ensure claim
solvency.
Collateralized Debt
Positions (Cdps)
Smart contracts where collateral is locked to generate DAI.
Community-Based
Insurance
Insurance products developed and maintained by the
Nexus Mutual community.
Comp Governance Token
Compound's native token, granting holders governance
rights in the protocol.
Composability
The ability of different protocols and applications in the
DeFi ecosystem to seamlessly interact and integrate with
each other.
Comptroller Contract
The central smart contract that oversees various activities
within Compound.
Consensus Mechanism
The method by which participants in a blockchain network
agree on the validity of transactions and reach a
consensus.
Constant Product Formula
The formula Uniswap uses to maintain asset value in
liquidity pools (x*y=k).
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 115 of 125
TERM
DEFINITION
Cover Capacity
The maximum amount of cover that the mutual can sell for
a particular risk.
Cover Expiry
The duration for which the cover remains active before
needing renewal.
Cover Pricing Mechanism
Algorithmic determination of insurance cover prices based
on risk and demand.
Coverage Liquidity
Incentives
Rewards for providing capital to coverage pools.
Coverage Tokens
Tokens that represent a stake in an insurance pool.
Credit Delegation
Allows users to lend their credit to others, allowing them to
borrow without collateral.
Cross-Asset Swaps
Enabling trades between several types of assets with low
slippage.
Crv Token
Curve’s governance token, used for voting and staking.
Crypto-Asset
A digital or virtual asset that utilizes cryptography for
security and operates on a blockchain or distributed ledger.
Cryptoasset Trading
Platform
A platform or exchange where cryptocurrencies or digital
assets can be bought, sold, or traded.
Ctokens
Tokens representing a user's stake in a Compound liquidity
pool, which accrue interest over time.
Curve Dao
Decentralized Autonomous Organization governing
Curve’s protocol.
Curve Finance Pools
Pools consisting primarily of stablecoins or similarly
behaving assets.
Dai Direct Deposit Module
Allows users to directly deposit DAI to earn the DAI Savings
Rate.
Dai Savings Rate (Dsr)
Interest earned by holding DAI in a DAI Savings Rate
contract.
Dai Stablecoin
A decentralized, collateral-backed cryptocurrency
stablecoin pegged to the US dollar.
Dao Treasury
A pool of funds controlled by 1inch's decentralized
autonomous organization.
Debt Tokenization
Conversion of debt into tradeable tokens, allowing for
flexible debt management.
Decentralized Applications
(Dapps)
Applications that run on a decentralized network or
blockchain, typically with no central authority or control.
Decentralized Autonomous
Organization (Dao)
A governance model where decisions are made by token
holders, not a central authority.
Decentralized Claims
Committee
A group of stakeholders responsible for assessing and
approving claims.
Decentralized Governance
System where token holders have a say in the protocol’s
development and changes.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 116 of 125
TERM
DEFINITION
Decentralized Insurance
Provides insurance cover against smart contract failures in
a decentralized manner.
Defi
Short for "Decentralized Finance," it refers to the
ecosystem of financial applications and protocols built on
blockchain networks, aiming to provide open and
permissionless financial services.
Defi Cover
Insurance protection or coverage for risks associated with
using DeFi protocols and services.
Defi Cover Policy
An insurance policy that provides coverage against
specific risks associated with utilizing DeFi protocols.
Defi Cover Provider
A company or platform that offers insurance coverage
specifically tailored for risks in the DeFi space.
Defi Protocol
A set of rules and smart contracts that govern specific
decentralized financial applications or services.
Deflationary Token Model
A token model where the supply decreases over time,
potentially increasing value.
Delegated Voting
Allowing veCRV holders to delegate their voting power to
others.
Depeg
The process of uncoupling or detaching a stablecoin from
its pegged value, resulting in a change in its price.
Dex (Decentralized
Exchange)
A type of exchange that operates on a decentralized
network, allowing users to trade cryptocurrencies directly
with each other.
Dex Aggregator
Aggregates liquidity from various DEXs to find the best
trade routes for users.
Digital Asset
A virtual or digitized representation of an asset, which can
be tangible (e.g., artwork) or intangible (e.g., tokens).
Discretionary Claims
Assessment
A system where claims are evaluated and voted upon by
the mutual's members.
Distributed Governance
Governance distributed across COMP token holders,
allowing for decentralized decision-making.
Distributed Ledger
Technology (Dlt)
A broader term encompassing blockchain technology,
referring to the decentralized and distributed storage of
data across multiple nodes or computers.
Dynamic Pricing Model
Adjusting insurance premiums based on the changing risk
environment.
Ethical Hacking
Utilizing white hat hackers to identify potential security
issues in smart contracts.
Fee Structure
A dynamic fee system adjusted according to the
composition and stability of the pools.
Fiat On-Ramp Solutions
Provides users with options to buy cryptocurrency using fiat
money directly through the platform.
Flash Loans
Unsecured loans that must be borrowed and repaid within
a single blockchain transaction.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 117 of 125
TERM
DEFINITION
Flash Loans
A type of uncollateralized loan that allows users to borrow
funds for a short duration, often within a single transaction
block.
Flash Swaps
A feature allowing users to withdraw an unlimited number
of tokens, if they are returned within one transaction block.
Gas Cost Optimization
Techniques and algorithms to minimize transaction fees for
users.
Gas Fee Rebates
Incentives to offset transaction fees for users who
participate in key protocol functions.
Gas Fees
Fees paid for transactions on the Ethereum network, where
Uniswap operates.
Gas Optimization
Technical improvements to reduce the cost of transactions
on the network.
Global Settlement
The final settlement of all outstanding DAI and CDPs at the
end of MakerDAO’s lifecycle.
Governance Participation
NXM holders participate in decisions regarding the future
of the protocol.
Governance Proposals
Community-driven proposals for protocol upgrades and
changes.
Governance Security
Module
Delays the implementation of governance decisions to
mitigate risk.
Governance Token
Native tokens used for governance decisions.
Impermanent Loss
A temporary loss experienced by liquidity providers in AMM
pools due to the price divergence of assets.
Instant Governance
A mechanism for rapidly implementing changes in the
protocol based on community consensus.
Instant Liquidity
Providing immediate liquidity to policyholders and
stakeholders.
Insurance Policies
Specific contracts that cover diverse types of risks in the
crypto space.
Insurance Policy Nfts
Non-fungible tokens representing ownership of insurance
policies.
Interest Accumulation
The process of accruing interest on supplied and borrowed
assets over time.
Interest Rate Models
Algorithms determining the interest rates for lending and
borrowing based on supply and demand.
Interoperability
Curve’s ability to interact and integrate with various other
DeFi protocols.
Isolation Mode
Restricts borrowing against certain assets to manage risk
and exposure.
Keeper Network
Participants who help maintain the system, e.g., by bidding
in auctions.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 118 of 125
TERM
DEFINITION
Layer 1 Solutions
Refers to the base layer or primary blockchain network,
such as Ethereum or Bitcoin.
Layer 2 Solutions
Scalability solutions built on top of layer 1 blockchains to
improve transaction throughput and efficiency.
Leveraging Liquidity
The process of using borrowed funds or assets to increase
the potential returns or exposure in trading or investment
activities.
Limit Order Protocols
Allows users to place orders that are executed when the
market reaches a specific price.
Liquidation Incentive
Incentives given to users who liquidate undercollateralized
loans.
Liquidation Mechanism
The process of selling collateral in a CDP to cover its
debts.
Liquidation Penalty
Additional cost incurred when a loan is liquidated due to
insufficient collateral.
Liquidation Ratio
The minimum required collateralization ratio for a CDP.
Liquidity Gauge
A system to measure and reward liquidity providers in
Curve pools.
Liquidity Incentives
Rewards and incentives provided to encourage liquidity
provision.
Liquidity Mining
The act of providing liquidity to receive rewards, often in the
form of additional tokens.
Liquidity Mining For
Coverage
Incentives for providing liquidity to insurance pools.
Liquidity Pools
Pools of tokens locked in a smart contract used to facilitate
trading by providing liquidity.
Liquidity Provider (Lp)
Tokens
Tokens given to liquidity providers that represent their share
of the pool.
Loan Origination Fee
A small fee charged when a loan is taken out, contributing
to the protocol’s reserves.
Ltv (Loan To Value) Ratio
The maximum percentage of collateral value that can be
borrowed.
Membership System
Users must become members by owning NXM tokens to
participate in the ecosystem.
Minting
The process of creating new tokens or coins, typically
through a smart contract, often associated with inflationary
or expansionary monetary policies.
Mkr Token
Governance token of MakerDAO, used for voting on
protocol decisions.
Modular Smart Contracts
Flexible contract architecture that allows for easy updates
and upgrades.
Mooniswap Integration
Incorporation of the Mooniswap DEX’s features into the
1inch platform.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 119 of 125
TERM
DEFINITION
Multi-Chain Accessibility
Availability of 1inch services across different blockchain
networks.
Multi-Chain Expansion
Curve’s availability on various blockchains beyond
Ethereum.
Multi-Collateral Dai (Mcd)
An upgrade allowing DAI to be backed by multiple types of
collateral.
Multi-Cover Policies
Policies that provide coverage for multiple types of risks.
Multi-Sig Administration
A security feature requiring multiple signatures for critical
changes in the protocol.
Multi-Sig Governance
A governance approach requiring multiple signatures for
significant changes.
Mutual Model
A model where members jointly own the insurance pool and
share in its profits and losses.
Mutual Reserve
A reserve fund to enhance the financial stability of Nexus
Mutual.
Native Token
The primary or native cryptocurrency of a particular
blockchain network.
Non-Custodial Trading
Ensures users retain control of their funds during the
trading process.
Nxm Token
Native token used for membership rights, claims
assessment, and governance in Nexus Mutual.
Oracle
A trusted source of data that provides information to smart
contracts on the blockchain, enabling them to interact with
external data or systems.
Oracle Price Feeds
Provide real-time price information for collateral assets.
Oracles
Services that feed real-world data into the blockchain for
smart contracts to use.
Pathfinder Algorithm
An API developed by 1inch for finding the best trading paths
across multiple markets.
Peer-To-Peer Network
A network where participants communicate and interact
directly with each other without the need for intermediaries
or central authorities.
Policyholder Governance
Involvement of policyholders in governance decisions.
Polygon Integration
Expansion of Aave onto the Polygon network to offer faster
and cheaper transactions.
Pool Factory
Enables users to create their own liquidity pools on Curve.
Pool Fees
Fees charged for token swapping, paid to liquidity
providers.
Pool Of Liquidity
A collective pool of funds or assets available for trading or
lending within a specific platform or protocol.
Premium Collection
The process of collecting payments from policyholders for
providing coverage.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 120 of 125
TERM
DEFINITION
Price Discovery
The process of determining the best available prices across
multiple DEXs.
Price Feed Oracles
Services that provide reliable asset price information to the
protocol.
Price Impact
The effect a trade has on the market price of a token in a
liquidity pool.
Price Oracles
Providing price data feeds for assets traded on Curve.
Proof Of Stake (Pos)
A consensus mechanism in which the ability to validate
and create new blocks in a blockchain is based on the
amount of cryptocurrency held or "staked" by a participant.
Proof Of Work (Pow)
A consensus mechanism in which miners compete to solve
complex mathematical puzzles to validate and add new
blocks to the blockchain.
Protocol Layer
The underlying smart contract layer that powers the
MakerDAO system.
Protocol Liquidity
The overall availability of funds in the Compound
ecosystem for lending and borrowing.
Rate Stabilization
Mechanism
Adjusts stability fees to maintain DAI’s peg to the US dollar.
Rate Switching
Ability for borrowers to switch between stable and variable
interest rates.
Redeem Mechanism
Allows NXM token holders to redeem their tokens under
certain conditions.
Referral Programs
Incentive programs for referring new users to the 1inch
platform.
Repay With Collateral
Feature allowing borrowers to directly repay loans using
their collateral.
Reserve Factor
A portion of interest earned that is set aside as reserves for
the protocol.
Reservoir
A system to accumulate and distribute the COMP token to
users of the protocol.
Risk Assessment
Evaluating the risk associated with different smart contracts
for insurance purposes.
Risk Parameters
Set of parameters governing loan-to-value ratios,
liquidation thresholds, etc.
Risk Pooling
Aggregating risks across various policies to minimize
overall risk.
Risk Sharing Pools
Pools where members share risk collectively, a
fundamental principle of mutual insurance.
Risk-Based Pricing
Pricing insurance covers based on the assessed risk of the
underlying smart contract.
Routing
The process of finding the most efficient path for a trade to
minimize slippage and maximize returns.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 121 of 125
TERM
DEFINITION
Safety Module
Part of Aave's protocol serving as a collateralized insurance
pool to cover deficits.
Scalable Coverage Limits
Ability to offer higher coverage limits as the protocol grows.
Security Token
A digital token that represents ownership or shares in a
real-world asset, such as equity in a company or ownership
of a property.
Self-Liquidation
Feature allowing borrowers to close their loan positions by
themselves before liquidation.
Shield Mining
Incentive program to encourage liquidity provision for
specific smart contract covers.
Slippage
The difference between the expected price of a trade and
the actual executed price, often caused by market volatility
and liquidity constraints.
Slippage Tolerance
User-set limit on price movement from the quoted price to
the executed price.
Smart Contract
Self-executing contracts with predefined conditions and
actions encoded in computer code, automatically executing
when conditions are met.
Smart Contract Audits
Security audits conducted to ensure the safety and
reliability of the protocol.
Smart Contract Cover
Insurance cover protecting against flaws in smart contract
code.
Smart Contract Platform
A blockchain network that supports the execution of smart
contracts, allowing developers to build decentralized
applications.
Smart Contracts
Self-executing contracts with the terms of the agreement
directly written into code.
Stability Fee
An interest rate charged on DAI generated from CDPs.
Stablecoin
A type of cryptocurrency designed to maintain a stable
value, often pegged to a specific fiat currency or
commodity.
Stablecoin Arrangement
The set of mechanisms and protocols used to maintain the
stability of a stablecoin's value.
Stablecoin Trading
Specializes in efficient and low-slippage trading of
stablecoins.
Stableswap Algorithm
Curve’s specialized algorithm designed for stablecoin
pools.
Staking
The process of holding and locking up cryptocurrency in a
wallet or smart contract to support the operations or
security of a blockchain network.
Staking Rewards
Rewards given for staking the protocol’s tokens to provide
coverage.
Supply Cap
Limits on the total amount of each asset that can be
supplied to Compound.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 122 of 125
TERM
DEFINITION
Swap Optimization
Ensures trades are executed in the most efficient manner,
considering price and gas costs.
Synthetic Assets Trading
Support for trading synthetic assets, which mimic other
assets’ price movements.
System Reserves
Reserves held to ensure the stability and security of the
protocol.
Token Burning
Mechanism where a portion of the NXM tokens is burned,
affecting the overall supply.
Token Listing Process
The procedure for adding new tokens to the Compound
market for lending and borrowing.
Token Pair
Two different cryptocurrencies that are traded against each
other in a liquidity pool.
Token Swap
The process of exchanging one cryptocurrency for another
on the Uniswap platform.
Token Swap Splitting
Divides a trade across various exchanges to minimize price
impact and slippage.
Tokenization
The process of converting real-world assets or rights into
digital tokens, enabling them to be traded and transferred
on a blockchain.
Tokenized Insurance
The representation of insurance policies as tradeable
tokens.
Tokenized Traditional Assets
Digital tokens that represent ownership or rights to
traditional assets, such as real estate or stocks.
Total Value Locked (Tvl)
The total amount of assets, typically measured in
cryptocurrency, locked, or held in DeFi protocols.
Transparent Accounting
Open and transparent record-keeping of financial
transactions within the protocol.
Treasury
The pool of funds reserved for the development and
sustainability of the Compound ecosystem.
Unbacked Crypto-Asset
A digital asset or cryptocurrency that does not have a direct
underlying asset or collateral supporting its value.
Underlying Asset
The actual asset (like ETH, DAI, etc.) that is deposited into
Aave.
Underwriting Consensus
Collective agreement on underwriting and pricing
insurance risks.
Uniswap Interface
The user interface for interacting with Uniswap's protocol.
Utility Token
A type of cryptocurrency or token that provides access to
specific services or functions within a blockchain
ecosystem.
Vault Types
Several types of CDPs in the MCD system, each with
specific parameters.
Vecrv Model
“Vote-escrowed CRV,” where locking CRV tokens boosts
rewards and governance power.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 123 of 125
TERM
DEFINITION
Wallet
A software application or digital tool used to store, manage,
and interact with cryptocurrencies and digital assets.
Wallet Provider
A company or platform that offers wallet services, allowing
users to securely store and manage their cryptocurrencies.
Wrapped Tokens (E.G,
Weth)
Tokens representing other assets on different blockchains,
enabling them to be traded on Uniswap.
Yield Farming
A process in DeFi where users provide liquidity or assets
to protocols in exchange for rewards, typically in the form
of additional tokens or interest.
Yield Optimizer
Tools or platforms that maximize yield for liquidity providers
in Curve pools.
EMBEDDED SUPERVISION OF DECENTRALIZED FINANCE
Page 124 of 125
GETTING IN TOUCH WITH THE EU
In person
All over the European Union there are hundreds of Europe Direct information centres. You can find the
address of the centre nearest you at: https://europa.eu/european-union/contact_en
On the phone or by email
Europe Direct is a service that answers your questions about the European Union. You can contact
this service:
– by freephone: 00 800 6 7 8 9 10 11 (certain operators may charge for these calls),
– at the following standard number: +32 22999696, or
– by email via: https://europa.eu/european-union/contact_en
FINDING INFORMATION ABOUT THE EU
Online
Information about the European Union in all the official languages of the EU is available on the Europa
website at: https://europa.eu/european-union/index_en
EU publications
You can download or order free and priced EU publications from: https://op.europa.eu/en/publications.
Multiple copies of free publications may be obtained by contacting Europe Direct or your local
information centre (see https://europa.eu/european-union/contact_en).
EU law and related documents
For access to legal information from the EU, including all EU law since 1952 in all the official language
versions, go to EUR-Lex at: http://eur-lex.europa.eu
Open data from the EU
The EU Open Data Portal (http://data.europa.eu/euodp/en) provides access to datasets from the EU.
Data can be downloaded and reused for free, for both commercial and non-commercial purposes.
ISBN : 978-92-68-24313-8
Doi: 10.2874/1217286
EV-01-25-000-EN-N
