Protocol Users are people or organisations who use a DeFi Protocol as "customers", whether by exchanging tokens, staking, investing, or providing liquidity. The term also covers their agents acting on their behalf, including accountants, legal advisers, and so on.
Protocol Investors are those who take a stake in the governance of a Protocol. They may aim to play a role in managing its operation, or behave as a passive investor hoping that the value of their stake will increase.
Protocol Operators are those who can make decisions regarding the operation of a Protocol. This can include Protocol Investors, Protocol Developers, and anyone else who has been granted the ability to make decisions on how the Protocol operates.
Protocol Developers actively contribute to the code of a Protocol.
Lack of Standardization: The lack of standardization in data formats, protocols, and APIs in DeFi poses interoperability challenges for DeFi software. Integrating and normalizing software or data from diverse suppliers or sources can be complex and error-prone.
Any software distributed over a network has to deal with Latency, the time that can elapse while the system synchronises across the network. In a Defi context, this introduces a risk of acting on outdated information, or of planned actions not being executed in a sufficiently timely manner.
In DeFi, each type of software component can involve some specific risks due to its role in DeFi or to the nature of the software itself:Oracles and Bridges, common components in DeFi protocols, are susceptible not only to Software Risk but also to other risks.
Smart Contract code is publicly visible when the contract is deployed on the blockchain. This allows hackers to look for bugs or configuration errors that they can exploit to attack the DeFi system and steal or destroy value.
On most Blockchains transactions can be read by anyone, it is usually very obvious when a Smart Contract used in DeFi is managing a large amount of value. This makes it easy to calculate the potential returns for a successful attack, drawing more attackers to high-value targets.
Smart Contracts are often immutable when deployed, so conventional security techniques based on upgrading vulnerable programs are not always available.
Upgradeable Smart Contracts introduce additional security risks and complications.
The size of the risk is exacerbated by the speed at which funds can generally be moved in DeFi, the difficulty of reversing transactions, the automation of processes, and the pseudo-anonymity of the blockchain.It is possible for any user to interact directly on the blockchain with a Smart Contract. Inaccurate or insufficient documentation of the Smart Contracts introduces a risk that users interacting directly will do so in a manner that causes mistakes to happen.
Blockchain Risk is the risk that during DeFi transactions, the base blockchain does not operate properly. This does not include Bridge Risk (moving value between blockchains) which is a separate risk described in .
Overall, blockchains work as designed, and Blockchain Risk in the period 2019-2023 has been very small. Most blockchains are reliable in both execution and uptime, and record keeping has normally been perfect on blockchains. Of all risks within the DeFi ecosystem, Blockchain Risk is generally amongst the smallest. There are four key ways a blockchain can compromise the functionality of a DeFi protocol deployed on that blockchain.The blockchain stops working. Blockchains by design are expected to offer "24/7/365" service. This risk is real, but usually small in practice.
A blockchain loses transaction records.
Fundamental to all DeFi is the expectation that the blockchain retains the records of every transaction. These transactions prove your ownership of an item and that a transaction occurred. Blockchain explorers generally provide the relevant information to end users. Only on the Solana blockchain has this risk been evident, where sometimes new transaction records cannot be found quickly, leading to a risk of high Latency.The blockchain does not execute a contract's code correctly, resulting in incorrect balances.
This would be catastrophic for trust in DeFi on that blockchain. However here are no records of this risk being realized.Where a blockchain can be controlled by a malicious actor or set of actors, digital assets could be stolen or destroyed by "brute force", such as a 51% attack.
While such attacks have occurred in practice, for example on the Ethereum Classic blockchain, the community of users on that blockchain managed to revert the effects of the attack.DeFi projects often offer Web-based systems, for users to interact with them. Some projects offer specific applications as well, or instead. These are all subject to known risks, including java script injection, DNS spoofing and others.
A key risk of all user-facing software is that the interface design or user experience is confusing, leading users to take actions that have consequences they did not expect. This risk can be amplified for users who rely on less common tools to access the interface, including users with disabilities who rely on assistive technology.
Note that in many jurisdictions, interfaces that are not useful for users with disability is also a Compliance Risk, as described in .Data Accuracy and Manipulation: DeFi oracles rely on data sources from outside the blockchain to provide information to Smart Contracts that can act automatically on the information. Inaccurate data can lead to Smart Contracts producing unexpected or undesired outcomes.
External data sources, such as APIs or websites, that oracles rely on for data, are potentially vulnerable to security breaches, hacking, or data tampering. If an attacker gains control over a data source, they can manipulate the data fed into DeFi protocols. This can lead to unexpected outcomes and potential financial losses, for example maliciously triggering liquidations,"Single" Point of Failure: DeFi oracles that rely on too few or insecure data sources introduce a risk that manipulation or malfunctioning of that oracle can have significant adverse effects.
Governance and Upgradability: The governance mechanisms of DeFi oracle protocols play a vital role in determining how data sources are selected, managed, and upgraded. Inadequate governance can lead to biased or compromised data feeds, impacting the reliability and integrity of the protocol relying on such oracles.
Bridges allow the transfer of tokens between different blockchains. Bridges generally come in two forms: Trusted (or Centralized) Bridges, and Trustless (or Decentralized) Bridges. All bridges come with Software Risk. With Trustless Bridges, and there is also potential .
Trusted Bridges depend on a central entity or system to operate. The wBTC bridge, for example, allows users to use their Bitcoin to fund operations on the Ethereum blockchain. Because the Bitcoin blockchain doesn’t have smart contract functionality, a third party entity takes custody of the Bitcoin deposits, and mints an equivalent amount of wBTC (a Wrapped Token representing Bitcoin) on Ethereum.
The key risks with a Trusted Bridge are : users trust that the bridge operators will always process their transactions (see also Censoring and MEV), and that they will not steal or lose funds they control ().Trustless Bridges operate using smart contracts, that are monitored through software like Oracles. Users commit funds to a smart contract on one chain, which is detected by an Oracle on the destination chain that mints the equivalent amount there.
Typically the funds committed on the source chain are held there in escrow, as collateral for the tokens on the destination chain. They can be used to provide liquidity for a transfer of tokens back from the destination chain.
A large pool of funds can act as a Honeypot, attracting attacks trying to steal the funds.
An alternative approach to Bridge implementation Burns the funds on the source blockchain, relying on sufficient market interest to provide liquidity for a transfer back to that blockchain. This increases Liquidity Risk for users who rely on being able to move back and forth between blockchains.The risk created by MEV is that a malicious actor distorts pricing in the protocol to maliciously extract value.
This can reduce trust in the fair functioning of the DeFi protocol in question, introducing .Governance Risk varies with each protocol design. There are several common attack vectors:
If a small number of actors have significant control over governance votes, there is a risk they will execute a Rug Pull, stealing users' funds including the protocol treasury.
In less severe cases of token concentration, those with a controlling share of governance can introduce protocol changes that disadvantage a particular group of token holders.
For example, governance that requires constant attention can effectively penalise investors by repeatedly shifting the value held in the protocol to those who have time to keep up a certain activity levelTreasury Attacks are where an attacker attempts to control the keys to the treasury.
This type of attack does not usually take user funds in the protocol. The direct impact is usually a drop in the governance token price, however this can singificantly increase the risk of, and can be a precursor to, other governance attacks. Governance is also subject to Custodial Risks, for example a single critical key being lost, rendering the Protocol inoperable, or multiple keys being stolen in phishing or other external attacks.If governance is excessively reliant on a single account e.g. because it has a key role as a Protocol Operator, and the key to that account is compromised (e.g. stolen by hacking or other means), an attacker can control the protocol.
An attacker can compromise the computer or smartphone of the owner of the account via phishing, and then steal the key from the owner.A similar risk can arise where the governance processes require a complex set of approvals, that there are insufficient incentives to participate in governance decisions, effectively paralysing governance because it becomes practically impossible to execute even necessary changes to the protocol.
Mismanagement of Private Keys by all users is a risk.
That risk can be compounded by the of an irresponsible or malicious custodian. Using blockchain technology, there are 2 general options for how to hold and access your digital assets: - self-custody, and - third party custody. The decision to select self-custody or third-party custody depends on multiple factors such as cost and efficiency to transact, capacity to protect funds from loss or theft, and potentially regulation such as SEC requirements for advisors to use Qualified Custodians.Self-custody in the context of digital assets means you control your Private Keys, used to access and transfer your assets on the blockchain.
Third Party Custody in the context of DeFi refers to the practice of entrusting the custody of a Private Key, and thus the ability to control the assets, to a third party responsible for their security and protection.
Providers of Third Party Custody are often referred to as Custodians, and they can offer a range of services designed to secure users' assets, such as storing private keys in cold storage, providing Multi-signature Wallets, and implementing various security measures to prevent hacks and theft. The use of third party custody in DeFi allows users to rely on the expertise and experience of professional custodians to safeguard their assets. However, it also involves entrusting control of assets to another entity, which can introduce counterparty risk and limit the decentralization that is a key feature of DeFi. Few institutional Custodians currently offer “DeFi as a service” at scale. There have been several high-profile failures of Third Party Custody in the digital asset space.Tokenomics refers to the economic incentives provided by a given DeFi protocol, DAO, or other blockchain system, through its distribution of tokens and other incentives. Tokenomics risk can arise from various flaws in the economic design of a Protocol, including token supply distribution, lock-ups, degree of decentralization, incentive structures, and more.
Token Issues that result in supply distortions can reduce the circulating supply, impact liquidity, or dilute the value of tokens, potentially limiting market participation
Some possible examples are where investors receive and try to sell a large percentage of the total supply, or a very high proportion of tokens are locked or staked. Similarly, rewarding users with new tokens can increase the circulating supply, potentially reducing token value through inflation. Note that for example in the lead-up to and for some time after the Ethereum "Merge" all staked Eth was effectively locked, with no apparent ill effect; the risk needs to be considered based on the specific situation.Tokens with limited utility beyond speculation can face unstable demand, and a higher chance they are considered a security, with concomitant .
Inability to adjust tokenomics to changing market conditions and user needs can result in suboptimal performance.
Regulators can consider it to be a violation of laws and regulations to interact with DeFi protocols as an activity, or with a given DeFi protocol or its Protocol Operators.
Tokens considered as securities, rather than as utilities, are generally subject to different and stricter regulatory frameworks.
Unclear tax implications for DeFi introduce a risk that tax treatment can be considered in violation of laws and recommendations.
A Protocol might be considered in violation of AML regulation.
Protocol governance can enable blocking participants who have been proscribed. However, if anonymous wallets are able to engage with DeFi protocols and are only blocked "on demand", the lack of KYC ("Know Your Customer") and AML Anti-Money Laundering procedures can expose DeFi participants to the risk of interacting with money coming from illicit activities, or engaging in trade with entities that are subject to local sanctions regimes such as OFAC [[ofac]].Operational Accounting Risks are the risks arising from inaccuracies in accounting procedures:
Mismatches between on-chain positions and reported financial positions can arise due to failing to account for open positions such as liquidity pool tokens that are staked in a protocol.
Deliberate fraud, or incompetence, on the part of accounting staff or contractors can lead to direct losses, failure to recognise growing problems, and legal penalties.
Weak internal standards for accounting can give rise to inconsistencies.
Fixed valuation for assets that can in fact vary in price, whether Stablecoins or more volatile asset classes, can introduce arbitrage opportunities that can drain the value of a Protocol. This risk is more acute for assets other than Stablecoins, and can be compounded.
Stablecoins are intended to hold a value equivalent to some external measure, such as a Euro. However their market value often varies very slightly from the Peg, and they can become "untethered" in various ways, leading to a significant difference between their Fair Market Value and their Book Value.
Credit Risk typically represents a probability of loss to a lender due to Bad Debt, when a loan is liquidated and the collateral is insufficient to repay the outstanding debt to the lender, or insufficient payment so the lender's cashflow and liquidity creates a situation the lender cannot sustain.
Many risks already described in this discussion paper contribute to Credit Risk: Software risk, tokenomics risk and governance design, and the risk of collapse of the liquidation market. Banks implement credit risk management analyzing the credit risk of each of their customers (5 Cs), and are heavily regulated around credit risk, provide assurance for lenders, and in turn in many cases are insured against defaulting. However, in traditional finance (TradFi) lenders still face certain risks of fraudulent activities within the bank and externally, as well as potential inadequacy of capital reserves during events such as a run on the bank. In Decentralized Lending it is possible for lenders to interact with anonymous borrowers. Because lenders as Liquidity Providers invest in a pool, creditworthiness of individual borrowers is often considered relatively unimportant.In a fast moving market, like a market crash, insufficient demand from liquidators can mean liquidation fails to repay the lender in full, in other words creates Bad Debt. This risk is exacerbated by rehypothecation of collateral or high leverage.
Counterparty risk is the danger that another party to a transaction will cause you to lose money.
The most common Counterparty Risk in traditional finance, as described in the previous section , is that a borrower is not capable of paying their loan, whether it is an individual failing to make repayments, or a bank or similar organisation that fails to return deposits. Some might argue that a DeFi protocol is itself a counterparty, because a user transacts with the Protocol. Protocol Operators and as relevant Custodians are effectively counterparties. In this document risks they introduce are treated respectively as and . If Investors and Users are counterparties, there are related to requirements for KYC or AML procedures to be in place so as not to deal with sanctioned individuals or organisations.Market Risk is the risk of losses due to unexpected changes in the value of underlying assets, such as cryptocurrencies or tokens. This is typically due to a loss of confidence in the DeFi Protocol.
In DeFi, this can be a result of general market forces like economic and monetary influences and market sentiment, but also as a directly consequence of the digital nature and design of DeFi protocols.Prices of crypto assets can be highly volatile. This creates the risk of Impermanent Loss. This risk is usually exacerbated by perceptions of Liquidity Risk in a market.
Because DeFi is still a largely unregulated space, the absence of legal certainty can increase market risk based on expectations of regulatory changes that affect participating in DeFi projects.
Hacks, exploits of vulnerabilities discovered, or actions by Protocol Operators that is considered unethical or damaging, can rapidly and deeply undermine market confidence in a Protocol or Digital Asset. In the most serious case, these can also literally drain the value from a Protocol.
Manipulative practices, such as wash trading, spoofing, or pump and dump schemes are a risk to Defi Protocols. Generally there is less protection against such manipulation than in TradFi, and the pseudonymous nature of DeFi means it can be more difficult to identify if a market is being manipulated.
If the design of automated market makers (AMMs) on DEXs is unable to manage the volatility that they are exposed to appropriately, this can exacerbate Market Risk.
Many DeFi systems, particularly Decentralized Lending Platforms, rely on sharing risk among many participants as a strategy to minimize it.
In a situtation where the risk is spread too narrowly, or where the effects of a market change cannot be sustained by too many investors, this strategy becomes a systemic risk.Liquidity Risk arises when a lack of available liquidity means users are unable to convert tokens at their Fair market Value.
As noted in , without a centralized exchange or counterparty, DeFi services often rely on incentivizing market-makers to liquidate undercollateralized loans.Fixed liquidity adjustment mechanisms are often hard-coded into the structure of the DeFi Protocol. This limits the ability of DeFi applications to respond to unanticipated market conditions or user behavior.
This can in turn leave liquidity providers and lenders with unanticipated default risk stemming from an inability to meet their own liquidity obligations. The decentralized nature of these applications also increases the risk of an asset-liability mismatch, which would typically be managed in TradFi through intermediaries. While Overcollateralization in lending DeFi applications helps mitigate Liquidity Risk, it might not function as an effective failstop in certain situations like sudden prices shocks and fast moving markets. With insufficient timely demand from liquidators in the market, the liquidation mechanism can fail.DeFi can be susceptible to excessive leverage of cryptocurrencies or stablecoins used as collateral on DeFi trading platforms.
Because assets used as collateral in Defi are generally unregulated and pseudonymously owned, they can be rehypothecated or otherwise increase leverage to levels that are unsustainable in situations such as liquidation or major price change, inceasing the systemic risk of a liquidity crisis during adverse events.In DeFi markets liquidity is generally fragmented, posing heightened Liquidity Risk in individual liquidity and lending pools.
This can mean that in any given market there are not necessarily enough buyers and sellers at any given time to provide an effective price discovery mechanism. As a result, investors can find it difficult to enter and exit positions in a timely and efficient manner.Protocol Reports SHOULD be publicly available.
This allows stakeholders to review the security measures in place, and ensure that known vulnerabilities have been tested. It helps increase confidence in Protocol Operators, which in turn helps mitigate Market Risk. This paper divides important reports into:Protocol Reports SHOULD cover up-to-date (i.e. as far as possible live) relevant financial figures (similar to those for a comparable TradFi business) covering at least:
Protocol Reports SHOULD outline current . Important information includes Total Value Locked, the number of transactions and number of holders, yields and liquidation rates.
Protocol Reports SHOULD provide historical price volatility data for underlying assets.
Cryptocurrencies and tokens can be highly volatile. Providing historical volatility data, market analysis, and risk warnings helps inform Protocol Users about potential risks to the Protocol.Protocol Reports SHOULD cover liquidity pools' composition, including depth and diversity of liquidity providers.
Metrics related to pool utilization, reserves, and historical liquidity patterns give users insight into the overall liquidity health of the protocol.Protocol Reports SHOULD detail the results of stress tests and analyses related to liquidity shocks and adverse market conditions, including any identified vulnerabilities and proposed mitigations.
Protocol Reports SHOULD include any security breaches or exploits that lead to fund losses, as well as any attacks that were detected and nullified.
A detailed incident report, including the impact, how existing mitigation measures worked, and plans for preventing similar incidents in the future is important to understandProtocol Reports SHOULD provide Technical Security updates for all software used by the Protocol, including all of:
Protocol Reports SHOULD cover accessibility and usability asessment of frontend software or interfaces regularly, and specifically for any upgrades or new software deployed.
Protocol Reports SHOULD cover centralization tendencies of oracle networks the Protocol relies on.
Highlight governance mechanisms, consensus models, and any potential risks associated with centralizationProtocol Reports SHOULD detail monitoring of bridge infrastructure and Smart Contracts used for token transfers between blockchains.
Protocol Reports SHOULD describe the history of the underlying blockchain for any DeFi protocol.
Key points to include are whether there are reliable archives and block explorers that are maintained for the blockchain, and whether it has been subject to notable outages for example to respond to hacks or other failures.Protocols SHOULD describe the distribution and concentration of governance tokens.
This is important to assess concerns such as the possibility of a Rug Pull or other governance attacks.Protocol Reports SHOULD describe what is known of investors with a significant holding of tokens
What returns have private investors and team members realized? This is loosely related to AML practices.Protocol Reports SHOULD describe any updates or adjustments made to the tokenomics design.
Adjustments to tokenomics, including Protocol Operators changing parameters that are designed to be managed, are important information to assess ongoing preformance of a Protocol and of its governance.Protocol Reports SHOULD describe ongoing research efforts and collaborations with industry partners, for example in standards development organisations, focused on combating risks.
Protocols reports SHOULD describe user education and awareness-raising efforts.
Protocol Reports SHOULD detail measures taken to ensure compliance with relevant regulatory standards and guidelines, including at least:
Protocol Reports SHOULD provide a detailed overview of changes to the legal and regulatory landscape governing the specific jurisdictions in which the protocol operates.
Analysis of relevant laws, regulations, and guidance that can impact the protocol and its users, identifying potential legal challenges and vulnerabilities, such as the risk of violating securities laws, anti-money laundering (AML) regulations, or consumer protection laws, are all important information that helps assess whether Protocol Operators are managing Compliance Risk effectively.Protocol Reports SHOULD provide a detailed overview of the protocol's operations relevant to taxes that Protocol Investors or Protocol Users might be liable to pay.
Addressing the tax implications of using the protocol and engaging in various DeFi activities, and providing clear and accurate guidance to users on the flows of control of digital assets, and on the ways their value changes will help investors assess the potential tax obligations they could face, including the classification of transactions, recognition of taxable events, and reporting requirements.Protocol Reports SHOULD describe insurance cover for business interruption and/or loss of assets.
It is important to describe any insurance cover that is available to Protocol Operators, Protocol Users, or Protocol Investors as well as cover for the Protocol itself.Protocol Reports SHOULD outline the frequency of reporting, and how up-to-date reports are.
This information is important for all reporting available for a Protocol. Given the theoretical and often practical ability for Protocols to operate at very high speed, and the risks introduced by Latency, it is important to understand any delays to information that is available.Protocol Reports SHOULD describe market depth and price discovery mechanisms for the Protocol.
Protocol Reports SHOULD decribe the governance structure in detail, including
- decision-making processes, - mechanisms for community involvement, - emergency procedures, - how Protocol changes are decided and implemented, - the role of governance tokens, - third parties the Protocol relies on, and - [Non-voting Governance Mechanisms](#rep-struct-nonvoting-governance) such as the privileges held by Protocol Operators.Protocol Reports SHOULD outline a roadmap.
Protocol Reports SHOULD describe the protocol's ability to adapt the tokenomics design.
Changing market conditions and user needs are common. Optimal performance can be dependent on contonuous realignment with evolving industry trends. Good roadmaps include milestones, that as far as possible are tangible and trackable. It is important to describe how the protocol creates sustainable value beyond “ouroboros” practices like buybacks, burns and taxes, or very limited supply of total emission at TGE.Protocol Reports SHOULD describe policies for the issue of new tokens.
Clarity around ongoing supply and the way it is governed helps investors and users maintain approriate expectations around issues such as inflation, as well as concentration or decentralization of ownership and governance. This is also related to [Distribution of Governance Tokens](#rep-ops-token-distribution)Protocol Reports SHOULD describe governance mechanisms not based on voting
This covers any cases where specific accounts or Protocol Operators have autonomous control over operations, and is especially important for critical operations such as the ability to pause a protocol, censor transactions, or update software.Protocol Reports SHOULD detail all third parties who perform important services.
As well as Protocol Operators and contracted services such as accounting, monitoring of the Protocol or regulatory environments, this includes important dependencies such as operators of Oracles or Bridges, and developers of third-party software that is commonly used by Protocol Operators, or Protocol Users and Protocol Investors.Protocol Reports SHOULD detail mechanisms to ensure compliance with relevant regulatory standards and guidelines, including
Protocol Reports SHOULD describe the measures implemented by the protocol to mitigate MEV risks, including at least:
Protocol Reports SHOULD describe incident response and recovery plans for blockchain-related disruptions or failures.
This includes measures taken to ensure the timely detection, containment, and resolution of incidents, as well as procedures for restoring normal operations.Protocol Reports SHOULD outline the measures in place to protect the protocol's treasury from external attacks.
This includes technical safeguards against attempts to gain control of the treasury's private keys, such as the use of multi-signature, practices such as implementation of [[CCSS]] or similar standards, information security training for individuals, and monitoring for any attempts to concentrate ownership of governance tokens.Protocol Reports SHOULD describe security measures and best practices implemented such as encryption, secure key management, multi-factor authentication, and adherence to industry security standards.
Demonstrating that high-quality software development practices have been followed, and that industry best practices for Security are implemented throughout the protocol, with effective review and maintenance,Protocol Providers SHOULD report on the security measures taken to ensure the reliability and integrity of data sources used by oracles. This includes security reviews and testing, monitoring, and protection against potential security breaches or tampering.Protocol Reports SHOULD cover the timeliness and latency of oracle data delivery, and measures in place to ensure accurate and real-time data feeds for time-sensitive transactions.
Protocol Reports SHOULD describe measures to manage Credit Risk.
Key information includes LTV requirements and policies around collateralization, triggering conditions for liquidation, and other mechanisms designed to ensure repayment of loans.Protocol Reports SHOULD detail liquidity management.
How the protocol manages Liquidity Risk and adapts to unanticipated market conditions and user behavior is important information to understand how it might behave. It is important to describe the mechanisms in place to incentivize market-makers, ensure sufficient liquidity in lending pools, and address potential default risk.Protocol Reports SHOULD disclose any practices or policies related to rehypothecation, or other forms of leveraging collateral.
Explaining how these practices are monitored and controlled to prevent excessive leverage and mitigate liquidity crisis risks helps Protocol Users and Protocol Investors understand expectations placed on their own collateral, as well as assess the overall possibility that a particular Protocol will be exposed given a liquidity crisis elsewhere.Protocol Reports SHOULD explain incentive mechanisms in the tokenomics design.
Describe how rewards, inflation rates, and deflationary mechanisms are structured to ensure long-term viability and avoid economic flaws. Address any potential dilution risks and provide insights into the governance participation incentives for token holders.Protocol Reports SHOULD articulate the utility of the token beyond speculation.
Describe its role within the protocol, potential future use cases, and any plans for expanding utility over time. This helps establish a foundation for stable demand and long-term value.Protocol Reports SHOULD outline key similarities and differences to other well-known Protocols.
Protocol Reports SHOULD describe measures to detect and prevent market manipulation.
Real-time monitoring can help detect manipulation such as wash trading, spoofing, or pump and dump schemes. Third party providers of monitoring services can use Machine Learning to analyse results of monitoring multiple Protocols, which can help detect the first occurrence of a particular type of market manipulation on a given Protocol. Measures to prevent market manipulation can include direct mitigations enforced by the Protocol such as trading limits.Protocols SHOULD maintain channels of communication to address user concerns and inquiries.
User feedback can help identify many kinds of problem, from deficiencies in frontend design that confuse users to the extent that they create risks, to an additional warning channel for notification that something is going wrong.Protocols SHOULD provide educational resources, guidelines, or best practices for users to protect themselves, and encourage responsible participation in the protocol.
Informed users are safer users, and Protocols that help their users understand the risks inherent in DeFi, how the Protocol functions, and how users can protect themselves, are investing in better performance for users.Protocols SHOULD encourage independent audits of all aspects of risk.
This helps ensure confidence in the Protocol as well as validating key aspects, from the accuracy and fairness of the tokenomics implementation to the governance structure, or Compliance Risk minimization.Protocols SHOULD actively develop threat models.
From understanding the potential impacts of changes to liquidity markets, to identifying security vulnerabilities in code, modeling threats a Protocol can face is an important tool in ensuring that it can adequately assess the risk and so take appropriate mitigating action.Software components SHOULD use secure channels to communicate.
Software SHOULD encrypt data storage.
Software SHOULD NOT store private data where it is globally accessible even if encrpyted.
Protocols SHOULD undergo a security review for all Software Components deployed as part of a DeFi protocol.
It is important that security reviews cover the exact code that is deployed. There are many known cases where changes to only one or a few lines of previously tested code introduced a significant new vulnerability. It is important to note that integrating software effectively means developing software, and is a common source of vulnerabilities. Any integration work needs specific review to ensure it has not created vulnerabilities. There are independent security specialists for many kinds of software - where relevant these are specified for the individual software components as additional requirements. Many common software components have already undergone extensive security review. It is reasonable to provide links to assessments rather than repeating them. It is generally a good practice to use widely-used and well-tested software.DeFi Software components SHOULD use automated real-time monitoring to detect attacks or increased risk.
As well as ensuring before deployment that software components have been carefully reviewed and tested for security risks, real-time monitoring can provide warning of attacks in progress, which is important to many mitigation strategies. Machine-learning tools and databases of known attacks can help identify anomalous user behaviour that may be an attack, or preparation for one. They can also help identify the first occurrence of a new class of attack against a specific DeFi Protocol, increasing security compared to reliance on knowledge gained from only that Protocol.Smart Contracts, as well as Bridges and Oracles that use them, are classes of software subject to a steady stream of attacks, whose result can be a sudden and calamitous loss of value.
Software SHOULD have third-party bug bounty programs.
This allows external security researchers to report any identified vulnerabilities, ensuring a proactive approach to risk mitigation. The value of bug bounties on offer can influence the choice between reporting vulnerabilities responsibly and selling them to malicious parties or directly exploiting them.Software SHOULD follow standard best practices for responsible vulnerability disclosure.
There are many ways to manage vulnerability disclosure. To improve the likelihood that vulnerabilities are disclosed in a way that allows them to be fixed before they are exploited, the software industry has long adopted a set of best practices for disclosure. Broadly, these ask that disclosure is initially made privately, allowing a fix to be rolled out before the vulnerability becomes common knowledge. They often allow, or mandate, publication of the vulnerability and fixes applied after a certain time has elapsed, to incentivise fixing the software, enable the discloser to receive credit for their discovery, and demonstrate that the process is active and effective in protecting users.Software SHOULD have security response available "24/7".
Given the potential for rapid exploitation of vulnerabilities discovered in DeFi, it is important that Protocols can respond very rapidly to any announcement or evidence of a vulnerability.Software Security Reviews SHOULD align with industry standards.
Following industry standards helps to maintain consistency and reliability in the assessment, and makes it easier for Security Reviewers to check that Security Reviews follow Best Practices.Protocols SHOULD run Vulnerability Assessments for any upgrades to software components.
Smart Contract Reviewers, commonly known in the blockchain community as "auditors", are teams of smart contract engineers that specialize in assessing the security of smart contracts, producing Security Reviews A Smart Contract Security Review is not an audit as understood by the accounting community, although that is a name often given to it in the blockchain and security communities. Rather, it is a time-limited assessment of the Smart Contract's code, attempting to identify any security vulnerability.
The final output of a Smart Contract Security Review is usually a report, that can be a highly technical document discussing details of software, documentation, and possible abuses. Its intended primary audience is generally the DeFi protocol's smart contract developers. The format and content of the report can vary widely between reviewers.Smart Contract security review, and any necessary rectification, SHOULD be performed before code is deployed to the blockchain.
Once deployed, the code of Smart Contracts is publicly visible. Because vulnerabilities can often be exploited rapidly, it is important to ensure the code is well-tested before it becomes available for hackers to analyse.Smart Contracts in a protocol SHOULD have a security review according to the latest release of the EEA EthTrust Security Levels Specification [[EthTrust]].
There are many organisations that provide specialised security review of Smart Contracts. The EEA EthTrust Security Levels Specification [[EthTrust]] is a standard for Smart Contract security reviews, that ensures testing covers known vulnerabilities. As of 13 December 2023, the latest version of the specification is Version 2.Investors and users SHOULD conduct due diligence on Smart Contract Operators for the Smart Contracts that are part of a DeFi protocol.
There are KYC services that will check the identity and background of Smart Contract Operators.Protocols SHOULD assess the security of the underlying blockchain on which they deploy.
Evaluations of a blockchain can include Formal Verification, assessment of identified vulnerabilities or weaknesses, and explanations of improvement made as a result of issues identified in an assessment.Protocols SHOULD test frontend applications in a controlled environment before deployment or upgrades.
It is important to identify potential vulnerabilities that can be exploited by malicious actors. These vulnerabilities can range from interface design that leads users to do things they did not intend, through technical vulnerabilities in service workers, webp, node modules and other components, to leaking user data to malicious third parties who can then exploit it. Managing these risks for blockchain based products is an essential step in ensuring end-to-end security. By testing the applications in a controlled environment, companies can identify potential vulnerabilities that can be exploited by malicious actors before deploying them. OWASP is one organisation that develops projects industry can use to identify (and address) Web and other application design risks:DeFi front end interfaces SHOULD have a User Experience assessment that includes an accessibility review
It is important to discover whether user experience, or lack of accessibility, can expose users to a higher likelihood of mistakes through a lack of understanding of options offered to them.Web-based interfaces SHOULD conform to level AA or higher of [[WCAG]]
W3C provides the standard Web Content Accessibility Guidelines [[WCAG]], a global standard to ensure access to web content and applications for people with disabilities.Protocols that use Oracles SHOULD ensure that their Oracles have multiple sources of data, or use multiple Oracles, to ensure the redundancy allows for failover when necessary.
Oracles SHOULD use Time-Weighted Average Pricing to detect and if necessary smooth sudden spikes.
Time-weighted Average Pricing (or TWAP) is a common technique that uses a series of data points to generate a smoothed or trend price from a single data source.
It can be used both to set pricing, and as a benchmark to check whether prices are deviating sharply from a trend, which can indicate anamolous behaviour including a security breach in progress.Oracles SHOULD implement real-time monitoring of source information to ensure they are providing current accurate data.
Protocols that use Oracles SHOULD ensure each Oracle can be updated or removed when necessary.
Bridges SHOULD implement real-time monitoring of both sides of the bridge to detect anomalies.
Comparing standard behaviour across a bridge can provide an early clue to when something is going wrong, whether due to a temporary problem such as network latency, or a malicious attack. Real-time monitoring bots can help mitigate bridge risk by sending out an alert, or performing a predetermined action or series of actions automatically, in case of an emergency.Bridges SHOULD follow the suggestions of the EEA Crosschain Security Guidelines [[xchain-sec]].
The EEA Crosschain Security Guidelines describes some risks introduced by operations across blockchains, and describes some possible mitigations. It is not a detailed set of requirements like [[EthTrust]], but it is helpful for the specific case of working across two (or more) blockchains.Protocols SHOULD provide transaction ordering procedures that mitigate the Malicious Extraction of Value from other users' transactions.
Ensuring that transactions are processed in the order received can help mitigate timing attacks such as front-running.Protocols SHOULD enable users to set slippage limits on transactions.
Limiting the amount of slippage compared to the expected value of transactions and reverting where there is too much can help minimise the incentives for MEV attacks.Protocols SHOULD use real-time monitoring to detect and where appropriate block MEV attacks.
Protocols SHOULD work to ensure that ownership of governance tokens is distributed among independent parties, and resistant to concentration.
Many protocols include some form of non-voting governance, or governance by a specially limited group, where one or more accounts are designated as owners or administrators with special powers. These can include the power to block decisions that do not reflect the goals of a Protocol, pause the operation of a Protocol, and other actions that have a significant impact on the Protocol's operations. While these are essentially a limitation on how decentralized a Protocol is, they can be used to manage a number of , although they can exacerbate others.Protocols SHOULD use Multi-Signature Wallets for governance decisions, that require more than one but fewer than all parties to authorise a transaction.
To balance the risks of a single rogue actor, or of one key being compromised for example through a phishing attack, against the risk that some parties are not available in a timely enough manner for normal operation, it is important to set governance parameters somewhere between allowing any signatory to act, and requiring all signatories. Non-voting governors, or Protocol Operators, are likely to be more available than a general governance group of investors, and this is an important consideration in determining voting mechanisms and thresholds for governance decisions.Protocols SHOULD balance voting quorum against governance token supply and distribution.
Ensuring that the requirements for voting match the actual distribution and supply of the token can help protect against governance attacks that rely on unbalancing those requirements, such as flashloan attacks.Protocols, Investors and Users SHOULD ensure key management procedures are compliant with relevant standards to ensure robustness and survivability.
Procedures that can mitigate Custodial Risks are found in general-purpose standards like [[SOC2]], [[ISO27001]]. [[CCSS]] is a standard specifically for securing digital assets, and includes tiered requirements for secure key management by third parties, with a focus on key creation, key storage, and key control, as well as proof that funds are held by a third party.Third-party key custodians SHOULD conform to the requirements of [[CCSS]], at the highest possible level.
Protocols SHOULD ensure that policies for locking, burning and issuing tokens are published and followed.
Because token supply has a fundamental impact on the value of any token, and insufficient transparency in tokenomics structures can erode trust and hinder market confidence, it is important to demonstrate how fundamental processes work. While onchain code can be read in principle, it is helpful to document how it works (see also ), and it is important to demonstrate that published policies not automatically implemented are followed, and that decisions to change the policies or deviate from them are well explained.Protocols, investors and users SHOULD have a robust process in place to assess potentially relevant laws and regulations, and monitor pending legislation and rule-making.
DeFi users, investors and Protocols SHOULD participate in industry groups that focus on managing regulatory compliance and legal risk.
Protocols SHOULD implement KYC/AML procedures appropriate to the jurisdictions relevant to their investors and users, including covering Protocol Operators.
Protocols, investors and users SHOULD have a robust process in place to assess potentially relevant tax laws and regulations, and monitor rule-making and pending legislation.
Protocols SHOULD apply relevant standards, and do so in conformance with those standards.
Participating in, or closely following the development of standards and regulation, helps to understand the situation of a given standard at any given time, and can demonstrate leadership in the field. See also participating in industry groups in .Protocols SHOULD explain why an asset is considered a security or not.
Protocols SHOULD document their accounting practices and the rationales behind specific methods chosen to treat classes of assets and events.
Note that multiple accounting firms have taken the stance that wrapping and unwrapping tokens is a non-taxable event.Protocol Providers SHOULD periodically track reporting data against on-chain positions and document the process.
Best practice is to do this through a subledger product or as a manual internal workflow. Best practice recommendation reports include asset roll forward, a general ledger report and a transaction detail report. The FASB has proposed to require asset roll forward be a part of all digital accounting processes and gives a high level view of wallet and asset balances [[fasb-expodraft]]. Ledger entries will help to reconcile that all activity has been mapped and categorized correctly and transaction detail will ensure completeness on a granular level in a given period. High level transaction monitoring can complement this process as well, and sample checking for inappropriate or unusual transactions can help detect hacks or fraud.The overall reconciliation process SHOULD be well documented at the end of each period to serve as the audit trail for their accounting process.
Policy documentation will help to establish clear internal guidance on the various accounting treatments for business operations and revenue streams. Considerations for the cost basis methodology followed by the company, chart of accounts mapping and third party/internal transfer contacts are a few that will impact the ability for companies to streamline their reporting accurately. Where third parties are involved in preparing financial information (for example fund administrators or digital asset accounting software providers), entities SHOULD evaluate these relationships and obtain a complete understanding of both parties’ responsibilities with regards to designing and implementing relevant internal controls over financial reporting. As third parties’ software can be utilized in consuming and synthesizing information directly from the blockchain and synthesizing into accounting entries, entities SHOULD consider whether a third party is reputable, regulated, insured and audited, and also whether it provides a service organization control (SOC) report, as appropriate. As the crypto asset and blockchain space has matured in recent years, several service organizations — including private key custodians and blockchain data providers — have begun providing SOC 1 Type 2 reports.Protocol Providers SHOULD produce accurate and timely financial information for reporting purposes.
Protocol Providers SHOULD evaluate whether the individuals implementing and performing the controls have the right skills to effectively prevent or detect errors or fraud that could result in material misstatements in the financial statements.
Such controls can include reconciliation of what is presented in a financial statement against on-chain data. Particularly in cases where an on-chain position has been entered and is yet to be closed (for example liquidity pool tokens staked in a protocol), tools to track on-chain positions can be useful for reconciliation.Protocol Providers SHOULD establish internal controls for traditional accounting workflows.
These include segregation of duties, reconciliations, policy documentation, and security controls for assets in their accounting function. Segregation of duties include clear internal policies around authorizing different individuals to oversee the initiation, execution and recording of transactions. Proper permissions rules within ERP and subledger softwares are a good best practice recommendation here alongside authorized signatory documentation.Users SHOULD closely monitor their exposure and setting appropriate risk limits.
Setting risk limits through control on exposure, hedging, and the like are important to ensure that the value at risk is known and acceptable.Users and Investors SHOULD monitor the development of Protocols, especially governance decisions
Users SHOULD have real-time monitoring of core Protocol health metrics.
Protocols SHOULD monitor potential users accumulating stakes in their tokens.
While gathering capital is a fundamental goal in capitalism, and in DeFi, users doing so - especially anonymously - may be a sign that they are preparing an attack on a DeFi protocol.Protocols SHOULD demonstrate Adequate Capital Reserves.
Protocols SHOULD hold reserves for liquidity that are not leveraged.
Protocols SHOULD conduct regular stress tests and scenario analyses to assess the protocol's resilience to liquidity shocks and adverse market conditions, and identify possible mitigations for vulnerabilities found.
Users, protocols and investors SHOULD hold a range of tokens or other hedges against a liquidity problem in a given Protocol.
Decentralized Finance (more commonly DeFi) is a finance system based on blockchain technology. DeFi uses computer programs called Smart Contracts to automate many types of financial interactions. In principle, anyone with an internet connection and the necessary software can write a Smart Contract, deploy it to a blockchain, and likewise can invoke a Smart Contract. This removes the technical need for an intermediary such as a broker or bank to interact with a Decentralized Finance system.
Smart Contracts are programs, stored on the blockchain. Because Smart Contracts can be invoked by other Smart Contracts, it is possible use them as components to construct a complex system. Smart Contracts implement the core functionality of DeFi, most crucially creating, manipulating, transferring, and destroying Tokens, which are digital artifacts used to represent value on a blockchain. Smart Contracts are also used to provide and manage automated market makers, Decentralized Exchanges, Decentralized Lending, insurance protocols, and other automated financial instruments.
Because Smart Contracts can be invoked by other Smart Contracts, it is possible use them as components to construct a complex system.Wallets are programs that allow users to store and manage many kinds of tokens, such as Ether, bitcoin, and other tokens, typically through a simple user interface. A wallet holds the user's private and public cryptographic keys.
The user's Public Key acts as a publicly visible account number, An Externally Owned Account (or EOA) that is controlled by a user, relying on their ability to sign with their private key as proof that they have access to their own address, to validate transactions made from that account. used as an address for individuals and other programs to transact with. The Private Key is a very large number, meant to be known only to the owner of the wallet, that is combined with the Public Key to authorise transactions. This means anyone who knows or learns the private key can control the account, making transactions such as transfers to another EOA or interacting with a Smart Contract. Wallets primarily intended for personal use typically operate on a personal computer or mobile device, with easy-to-use interfaces, but providing limited protection of keys stored on the device or another physical token. These wallets are generally not used by institutions except as part of disaster recovery procedures. Institutional grade wallets for organizations selecting Self-custody commonly have governance policy engines, higher security and risk management controls and can offer both web-based and API interfaces. For example, to prevent single points of abuse Multi-Signature Wallets require multiple keys to transact, meaning no single actor can create a transaction on behalf of the wallet. Similarly, Multi-Party Computation splits the key into shards distributed among multiple parties, where only aggregating the results of computation by a set of those parties with information only they hold, can authorise a transaction. Wallets are often referred to as 'cold' or 'hot'. A Cold Wallet consists of a small storage device that is not connected to the internet or any running machine (also known as Airgapped) which holds a user's private keys and can be used for signing. The tokens are not stored on the device itself, but the private keys' security in this paradigm are considered to be safer than keys stored on a laptop or other device. A Hot Wallet is stored on a running machine, such as a mobile phone or laptop, and usually consists of an app to help users sign transactions. A hot wallet is generally considered more vulnerable to compromise via hacking because it is connected to the internet, A Custodial Wallet is a wallet whose private keys are managed by a third party. This is a common practice for larger DeFi institutions (such as Centralized Exchanges or CEXs) that hold many tokens on behalf of their users. A user accesses their tokens through an account with the institution, and Private Keys are held in the custody of the institution. Though large institutions may become targets of attack, they usually employ advanced security tactics and technologies to enforce the secure storage of these keys beyond that of a typical individual wallet user.Decentralized Lending protocols are blockchain based platforms that allow users to lend and borrow digital assets without the need for intermediaries, such as banks or financial institutions. The protocols are based on self-executing Smart Contracts that encode the terms of the agreement between borrower and lender, for example dynamically adjusting interest rates in response to demand. The terms of the loan are automatically enforced, with collateral typically securely held in escrow until the loan is paid back. Decentralized Lending often uses a shared Liquidity Pool to provide the funds to lend. Lending and borrowing interest rates are generally dynamically adjusted in response to supply and demand for assets in the pool based on mathematical rules that are encoded in Smart Contracts. Borrowers generally provide collateral for their loan by depositing another asset as collateral for that lending protocol. Loans are often Overcollateralized, with collateral deposited to secure the loan that is of higher value than the loan, i.e. an LTV less than 1. The degree of Overcollateralization required (or LTV) typically depends on the volatility of the borrowed asset and the collateral. Typically liquidation is triggered automatically, offering the collateral for sale on the market, in exchange for repaying the loan or in an auction, if the level of collateralization falls below the LTV.
DeFi often relies on a set of utilities, that can facilitate efficient allocation of risk capital:
Yield farming allows individuals to earn rewards by depositing their cryptocurrency or digital assets into a decentralized application (DApp). It encompasses two distinct types: Subsidized Yield and Real Yield.
Subsidized Yield is protocols incentivizing users to provide liquidity or encourage usage by offering rewards from funds controlled by the protocol.
On the other hand, Real Yield farming involves assuming risks to provide a specific service. For example Liquidity Providers for a DEX take on the risk of Impermanent Loss in exchange for providing liquidity and receiving compensation. Similarly, Liquidity Providers for Decentralized Lending Protocols take on the risk of Bad Debt in exchange for interest payments.The following is a list of terms defined in this Specification.