A DeFi Protocol (more usually just Protocol) is software to manage financial activities, on blockchains. It is highly automated, without human intermediaries for day-to-day finance management, although there are many different models of governance, from immutability to decentralised or centrally managed change processes. A fuller description of Protocols is provided in the section .
Protocol Users are people or organisations who use a DeFi Protocol as "consumers", 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, and their power typically varies with the value of their stake. However they might behave as a passive investor hoping that the value of their stake will increase to realise a capital gain.
Protocol Operators are those who can make and enforce decisions regarding the operation of a Protocol. This can include Protocol Investors, Protocol Developers, and anyone else who has the ability to make decisions on how the Protocol operates. An important subset of Protocol Operators are Smart Contract Operators: people who have privileged access to administer Smart Contracts used by the Protocol.
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 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.
Smart Contract code deployed hurriedly with inadequate review, or insufficent time spent fixing and the issues discovered in a security review and retesting, can lead to Vulnerable Smart Contracts being exploited.
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 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.
A Bridge is any service that allows the transfer of message between different Blockchains. This can be a simple data transfer (in which case the endpoint where the data is made available will generally be described as an Oracle). It can allow a Smart Contract on one Blockchain to interact with Smart Contracts on other Blockchains to compose applications, and can be used to build applications enabling transfer of assets between Blockchains. All Bridges are subject to Software Risk. At minimum this includes the Smart Contracts on the source and destination Blockchains, and the processing of information occurs off-chain, covered in and above. In a DeFi context, Bridges are most often thought of and used for their ability to enable value transfer between Blockchains. In this context, Bridges are also subject to Market Risk and in particular Liquidity Risk. Typically the funds committed on the source chain are held there in escrow, as collateral for the tokens on the destination chain, to provide sufficient liquidity for a transfer of tokens back from the destination chain. An alternative approach 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. Bridges are often classified as Trustless (or Decentralized) Bridges and Trusted (or Centralized) Bridges.
Trustless Bridges operate using smart contracts and 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. The key risks are Software Risk, particularly those covered in and above.
Trusted Bridges depend on a central entity for some part of their operation.
The key risks with a Trusted Bridge beyond Software Risk are Counterparty Risk, because users trust that the bridge operators will always process their transactions (see also Censoring and MEV) and will not steal or lose funds they control, as well as Custodial Risk and more generally Governance Risk.A large pool of funds can act as a Honeypot, attracting attacks trying to steal the funds.
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, or enabling a single actor or coordinated group of actors to gain control of governance decisions. However that can singificantly increase the risk of, and can be a precursor to, other governance attacks.An obfuscated, or misrepresented change proposal can be used to deceive voters, leading them to vote for a decision they would not support if it were presented clearly.
The details of how a proposal is presented can vary significantly. Where it deploys or changes code, without a careful review of that code it is possible to misrepresent the effects of a change. 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 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 Protocolis 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 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 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 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 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 Liquidity 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 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 a Protocol 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 continuous 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 Protocol 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 and monitor feedback channels 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 someone has observed signs suggesting a Protocol might come under attack. This can help protect against all types of risk.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. Helping Protocol Investors and Protocol Users understand the risks inherent in DeFi, how the Protocol functions, and how users can protect themselves, is an investment in better performance for users. This can help protect against all types of risk.Protocols SHOULD encourage independent audits of all aspects of risk.
There are many ways to encourage independent review, from providing necessary information to directly incentivizing reviews that find problems. In the context of software, this includes bug bounties, but it can also include actively requesting and linking to independent reviews. 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. This can help protect against all kinds of risk.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. This is helpful for all [Software risks](#sec-software-risks)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. This is helpful for all [Software risks](#sec-software-risks)Protocols SHOULD publish policies for locking, burning and issuing tokens.
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, 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. This can help to mitigate [Governance RIsks](#sec-risks-governance) [Tokenomics risk](#sec-risks-tokenomics), and helps understand tokenomics-related [Liquidity risk](#sec-risks-liquidity).Protocols SHOULD document the reconciliation process for 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. This helps mitigate: - [Tokenomics risk](#sec-risks-tokenomics) - [Compliance and Legal Risk](#sec-compliance-risks) - [Tax risk](#sec-risks-tax) - [Accounting Conformance Risks](#sec-risks-accounting-compliance) - [Operational Accounting Risks](#sec-risks-operational-accounting) - [Credit risk](#sec-risks-credit) - [Counterparty risk](#sec-risks-counterparty) - [Market risk](#sec-risks-market) - [Liquidity risk](#sec-risks-liquidity)Protocol Providers SHOULD produce accurate and timely financial information for reporting purposes.
This helps Protocol Users and Protocol Investors to understand and mitigate: - [Tokenomics risk](#sec-risks-tokenomics) - [Compliance and Legal Risk](#sec-compliance-risks) - [Tax risk](#sec-risks-tax) - [Accounting Conformance Risks](#sec-risks-accounting-compliance) - [Operational Accounting Risks](#sec-risks-operational-accounting) - [Credit risk](#sec-risks-credit) - [Counterparty risk](#sec-risks-counterparty) - [Market risk](#sec-risks-market) - [Liquidity risk](#sec-risks-liquidity)protocols SHOULD have incident response available "24/7".
Given the potential for rapid exploitation of vulnerabilities discovered in DeFi, it is important that Protocol can respond very rapidly to any announcement or evidence of a vulnerability. This can help mitigate - all [Software risks](#sec-software-risks) - [Governance risk](#sec-risks-governance) - [Custodial Risk](#sec-risks-custody) - [Liquidity risk](#sec-risks-liquidity)Protocols SHOULD log core events on-chain.
This ensures that a trail of key information is readily available, that can be used to provide better monitoring by Protocol Operators and third parties, potentially including DeFi Users themselves. This information is far more useful when it is demonstrably accurate and timely. This can help mitigate - all [Software risks](#sec-software-risks) - [Governance risk](#sec-risks-governance) - [Custodial Risk](#sec-risks-custody) - [Accounting Conformance Risks](#sec-risks-accounting-compliance) - [Operational Accounting Risks](#sec-risks-operational-accounting) - [Credit risk](#sec-risks-credit) - [Liquidity risk](#sec-risks-liquidity)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. This helps protect against various kinds of risk, particularly: - All [Software risks](#sec-software-risks) - [Governance risk](#sec-risks-governance) - [Custodial Risk](#sec-risks-custody) - [Tokenomics risk](#sec-risks-tokenomics) - [Compliance and Legal Risk](#sec-compliance-risks) - [Operational Accounting Risks](#sec-risks-operational-accounting) - [Credit risk](#sec-risks-credit) - [Counterparty risk](#sec-risks-counterparty) - [Market risk](#sec-risks-market) - [Liquidity risk](#sec-risks-liquidity)DeFi Protocols SHOULD use automated real-time monitoring to detect attacks or increased risk.
Real-time monitoring can provide warning of attacks in progress, which is important to many mitigation strategies.Smart Contracts, Bridges, and Oracles can be subject to a steady stream of attacks, whose result can be a rapid and calamitous loss of value, but also to a constant stream of very small attacks, leaching significant amounts of value over a longer timeframe.
Automated monitoring can also provide crucial information related to MEV attacks, and changes that increase Liquidity Risk. Comparing standard behaviors across a Bridge can provide an early clue to when something is going wrong, whether that is due to a temporary problem such as network latency, or a malicious attack. Real-time monitoring bots can send an alert, or perform a predetermined action or series of actions automatically, in case of an emergency. Identifying either type of attack and taking remedial action can protect a significant proportion of loss. This approach is particularly helpful to mitigate - [Software risks](#sec-software-risks), especially - [Smart Contract Risk](#sec-risks-contracts) - [Blockchain Risk](#sec-risks-blockchain) - [Oracle Risk](#sec-risks-oracles) - [Bridge Risk](#sec-risks-bridges) - [MEV risk](#sec-risks-mev) - [Governance risk](#sec-risks-governance) - [Liquidity risk](#sec-risks-liquidity)DeFi Protocols SHOULD use machine-learning and incident reports to identify attacks in progress or preparation.
Machine-learning tools and databases of known attacks can help identify anomalous user behaviour that may be an attack, or preparation for one. Based on knowledge acquired on a different Protocol, they can also help identify the first occurrence of a new class of attack against a specific Protocol, increasing security compared to reliance on knowledge gained from only that Protocol. Machine-learning systems are based on a training dataset, and inherit limitations in their capabilities from that dataset, just as much as the value of historical databases is intrinsically related to their content sources. This is particularly helpful to protect against - [Software risks](#sec-software-risks) - [Smart Contract Risk](#sec-risks-contracts) - [Blockchain Risk](#sec-risks-blockchain) - [Oracle Risk](#sec-risks-oracles) - [Bridge Risk](#sec-risks-bridges) - [MEV risk](#sec-risks-mev) - [Governance risk](#sec-risks-governance) - [Market risk](#sec-risks-market) - [Liquidity risk](#sec-risks-liquidity)Software components SHOULD use secure channels to communicate.
Various techniques exist to eavesdrop on internet communication. Encrypting information exchanged reduces the possibility that a malicious actor can intercept it and use it in an attack. This can particularly help mitigate: - Most kinds of [Software risks](#sec-software-risks), particularly - [Oracle Risk](#sec-risks-oracles) - [Bridge Risk](#sec-risks-bridges) - [MEV risk](#sec-risks-mev) - [Governance risk](#sec-risks-governance) - [Custodial Risk](#sec-risks-custody)Software SHOULD encrypt data storage.
This helps mitigate: - [Software risks](#sec-software-risks) - [Custodial Risk](#sec-risks-custody) - [Compliance and Legal Risk](#sec-compliance-risks)Software SHOULD NOT store private data where it is globally accessible even if encrypted.
Encryption provides a certain level of protection for data, but all known encryption can be broken given sufficient time and resources. Ensuring private data is protected by measures beyond encryption, such as keeping it Airgapped, is important to protect it long term, helping to mitigate [Custodial Risk](#sec-risks-custody) and [Compliance and Legal Risk](#sec-compliance-risks).Protocols SHOULD undergo a security review for all Software Components deployed as part of a 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. In this context, 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. While it is reasonable to provide links to assessments rather than repeating them, it is important to actively evaluate those assessments, instead of simply assuming their existence proves their quality. It is generally a good practice to use widely-used and well-tested software. A potential exception is where there is a considerable risk due to the public nature of software such as Smart Contracts, or through the use of common Open Source components that expose a so-called Supply Chain Risk, where a common component incorporated in a complex piece of software is exposed to compromise. This helps mitigate all [Software risks](#sec-software-risks), and also [Compliance and Legal Risk](#sec-compliance-risks)Protocols SHOULD run Vulnerability Assessments for any upgrades to software components.
Any time any software is upgraded, there is a risk not only that the upgrade itself introduces a vulnerability, but that a new vulnerability is introduced through the interactions of the upgraded softeware with other parts of the system. This helps mitigate all [Software risks](#sec-software-risks), and also [Compliance and Legal Risk](#sec-compliance-risks)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.
This helps mitigate [Oracle Risk](#sec-risks-oracles)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. This helps mitigate not only [Oracle Risk](#sec-risks-oracles) but is an important mitigation for [MEV risk](#sec-risks-mev) and [Governance risk](#sec-risks-governance)Protocols that use Oracles SHOULD ensure each Oracle can be updated or removed when necessary.
This helps mitigate [Oracle Risk](#sec-risks-oracles)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. This helps mitigate [MEV risk](#sec-risks-mev)Smart Contract Reviewers, commonly known in the blockchain community as "auditors", are individual or 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 Protocol Developers responsible for the smart contracts the Protocl uses. The format and content of the report can vary widely between reviewers.Protocols SHOULD perform Smart Contract security review, and any necessary rectification, 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. This helps mitigate - [Smart Contract Risk](#sec-risks-contracts) in particular.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. This helps mitigate [Blockchain Risk](#sec-risks-blockchain)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. This helps mitigate [User Interface risks](#sec-risks-frontend) in particular, but is also relevant to other [Software risks](#sec-software-risks)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.
This is particularly relevant for [Market risk](#sec-risks-market) and [Liquidity risk](#sec-risks-liquidity), but can also help mitigate: - all [Software risks](#sec-software-risks) - [Governance risk](#sec-risks-governance) - [Custodial Risk](#sec-risks-custody) - [Tokenomics risk](#sec-risks-tokenomics) - [Compliance and Legal Risk](#sec-compliance-risks) - [Operational Accounting Risks](#sec-risks-operational-accounting) - [Credit risk](#sec-risks-credit) - [Counterparty risk](#sec-risks-counterparty)Protocols and users SHOULD Split and Isolate Liquidity Pools.
Segmenting a Protocol's Liquidity Pools so the impact of a successful attack on one is isolated to that segment, and so attacking a different segment of the Liquidity Pool requires changes to the attack, such as using a different set of keys, can enable a Protocol to minimise the effects of an attack. Note that if the implementation of this means that Liquidity Pools are segmented by transactions, EOA / Wallet address or the like DeFi Users will need to spread the number of transactions they use in order to benefit effectively, and that this can increase their cost. This helps mitigate: - [Software risks](#sec-software-risks), especially [Bridge Risk](#sec-risks-bridges), - [Tokenomics risk](#sec-risks-tokenomics) - [Credit risk](#sec-risks-credit) - [Counterparty risk](#sec-risks-counterparty) - [Liquidity risk](#sec-risks-liquidity)Protocols SHOULD apply relevant standards, as specified in those standards.
Closely following the development of standards and regulation, helps to understand the situation of a given standard at any given time. Participation in the development of those standards helps deepen that understanding, and can demonstrate leadership in the field. See also participating in industry groups in . This can help mitigate many types of risk.Software Security Reviews SHOULD align with industry standards.
This can make it easier for Security Reviewers to check that Security Reviews follow Best Practices, and helps mitigate all [Software risks](#sec-software-risks)Smart Contracts used in a protocol written in solidity 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 June 2024, the latest release version of the specification is Version 2. However, an Editors' Draft is also publicly available, that can include some more up-to-date guidance. This helps mitigate [Smart Contract Risk](#sec-risks-contracts) in particular.Protocol Developers SHOULD test software and API security against OWASP standards.
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. This is particularly valuable to mitigate [User Interface risks](#sec-risks-frontend).Web-based interfaces SHOULD conform to level AA or higher of W3C's 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. This is particularly valuable to mitigate [User Interface risks](#sec-risks-frontend). In many jurisdictions it is also important for [Compliance and Legal Risk](#sec-compliance-risks)Bridges SHOULD follow the suggestions of the EEA Crosschain Security Guidelines.
The EEA Crosschain Security Guidelines [[xchain-sec]] describes some risks introduced by operations across blockchains, and describes some possible mitigations. It is not as detailed a set of requirements as [[EthTrust]], but it is helpful for the specific case of working across two (or more) blockchains. This is particularly relevant to mitigating [Bridge Risk](#sec-risks-bridges)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. This helps mitigate [Custodial Risk](#sec-risks-custody) in particular.Third-party key custodians SHOULD conform to the requirements of [[CCSS]], at the highest possible level.
This helps mitigate [Custodial Risk](#sec-risks-custody) in particular.Incident reports SHOULD use the STIX format as far as possible to produce interoperable information.
[[STIX]] is a standardised format for reporting security incidents. Encoding as much information as possible about a security incident in a machine-readable interoperable format enables more efficient comparisons and information compilation. It is important to be careful with the use of such information. Naive automated processing could, if poorly implemented, introduce risks caused by deliberately crafting misleading or false reports to induce a reaction as part of an attack strategy.Protocols SHOULD 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. In practice this is a limitation on how decentralized a Protocol is. It can help mitigate a number of [Governance risks](#sec-risks-governance), although it can exacerbate others.Protocols SHOULD use Multi-Signature Wallets for governance decisions, that require more than one but fewer than all eligible 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. This helps mitigate [Governance risk](#sec-risks-governance).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 attacks that rely on unbalancing those requirements, such as flashloan attacks. This helps mitigate [Tokenomics risk](#sec-risks-tokenomics), [Governance risk](#sec-risks-governance), and other [Counterparty risk](#sec-risks-counterparty) that could encompass [Market risk](#sec-risks-market).Investors and users SHOULD conduct due diligence on Smart Contract Operators for the Smart Contracts that are part of a Protocol.
If there are no KYC services that can vouch for the identity and background of Smart Contract Operators, it is possible that there is a deliberate effort to evade scrutiny. In any event, it makes risk assessment very difficult. This helps mitigate [Governance risk](#sec-risks-governance) and other [Counterparty risk](#sec-risks-counterparty).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. This helps mitigate [Governance risk](#sec-risks-governance) and [Operational Accounting Risks](#sec-risks-operational-accounting)Protocol Providers SHOULD establish internal controls for 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. Because of the importance of accounting in identifying problems, this can help mitigate a variety of risks: - [Governance risk](#sec-risks-governance) - [Custodial Risk](#sec-risks-custody) - [Tokenomics risk](#sec-risks-tokenomics) - [Compliance and Legal Risk](#sec-compliance-risks) - [Tax risk](#sec-risks-tax) - [Standards Conformance Risks](#sec-risks-standards-conformance) - [Accounting Conformance Risks](#sec-risks-accounting-compliance) - [Operational Accounting Risks](#sec-risks-operational-accounting) - [Credit risk](#sec-risks-credit) - [Counterparty risk](#sec-risks-counterparty) - [Liquidity risk](#sec-risks-liquidity)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 - can also be a sign that they are preparing an attack on a Protocol. This can help mitigate: - [Bridge Risk](#sec-risks-bridges) - [Governance risk](#sec-risks-governance) - [Tokenomics risk](#sec-risks-tokenomics) - [Credit risk](#sec-risks-credit) - [Counterparty risk](#sec-risks-counterparty) - [Market risk](#sec-risks-market) - [Liquidity risk](#sec-risks-liquidity)Protocols, investors and users SHOULD have a robust process in place to assess potentially relevant court decisions, laws and regulations, and monitor pending legislation and rule-making.
Regulation of DeFi is in its infancy, and to some extent in a state of flux. Monitoring ongoing development is important to help mitigate [Governance Risks](#sec-risks-governance) and [Compliance and Legal Risks](#sec-compliance-risks) including - [Tax risk](#sec-risks-tax) - [Standards Conformance Risks](#sec-risks-standards-conformance) - [Accounting Conformance Risks](#sec-risks-accounting-compliance)DeFi users, investors and Protocols SHOULD participate in industry groups that focus on managing regulatory compliance and legal risk.
While regulation of DeFi is in its infancy, and in a state of flux, direct participation in discussions that impact regulation can help understand likely changes. Helping regulators understand the mechanics of DeFi markets is important to ensure that regulation is appropriate to meet their goals of fairly balancing the requirements to protect Protocol Users who potentiall include holders of substantial and important public funds,as well as the Protocol Investors and Protocol Developers who make DeFi possible. This helps mitigate [Compliance and Legal Risks](#sec-compliance-risks) including - [Tax risk](#sec-risks-tax) - [Standards Conformance Risks](#sec-risks-standards-conformance) - [Accounting Conformance Risks](#sec-risks-accounting-compliance)Protocols SHOULD implement KYC/AML procedures appropriate to the jurisdictions relevant to their investors and users, including covering Protocol Operators.
This helps mitigate [Compliance and Legal Risks](#sec-compliance-risks) as well as [Governance risk](#sec-risks-governance), [Custodial Risk](#sec-risks-custody), and other [Counterparty risk](#sec-risks-counterparty).Protocols SHOULD explain why an asset is considered a security or not.
With ongoing uncertainty around what kind of DeFi assets are securities, and what should be treated merely as utilities, documenting a clear justification for considering a given asset in one way or another helps mitigate [Compliance and Legal Risks](#sec-compliance-risks).Protocols SHOULD document their accounting practices and the rationales behind specific methods chosen to treat classes of assets and events.
This helps mitigate [Compliance and Legal Risks](#sec-compliance-risks) including - [Tax risk](#sec-risks-tax) - [Standards Conformance Risks](#sec-risks-standards-conformance) - [Accounting Conformance Risks](#sec-risks-accounting-compliance) Note that multiple accounting firms have taken the stance that wrapping and unwrapping tokens is a non-taxable event.Protocols SHOULD document the reconciliation of reporting data against on-chain positions.
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. This helps mitigate [Operational Accounting Risks](#sec-risks-operational-accounting).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 allows users to mitigate [MEV risk](#sec-risks-mev)Protocol Users and Protocol Investors SHOULD closely monitor their exposure and set 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. This helps mitigate [Credit risk](#sec-risks-credit)Protocol Users and Protocol Investors SHOULD monitor the development of Protocols, especially governance decisions.
Many Protocols have the capability to change, either through governance decisions or software upgrades. If Protocol Users or Protocol Investors are not aware of changes, they can be exposed to additional risk. This helps mitigate: - [Governance risk](#sec-risks-governance) - [Tokenomics risk](#sec-risks-tokenomics) - [Compliance and Legal Risk](#sec-compliance-risks) - [Tax risk](#sec-risks-tax) - [Standards Conformance Risks](#sec-risks-standards-conformance) - [Accounting Conformance Risks](#sec-risks-accounting-compliance) - [Operational Accounting Risks](#sec-risks-operational-accounting) - [Credit risk](#sec-risks-credit) - [Counterparty risk](#sec-risks-counterparty) - [Market risk](#sec-risks-market) - [Liquidity risk](#sec-risks-liquidity)Protocol Users and Protocol Investors SHOULD have access to real-time monitoring of core Protocol health metrics.
This helps mitigate most risks.Protocols SHOULD demonstrate Adequate Capital Reserves, including sufficent reserves for liquidity that are not leveraged.
Where reserves held to manage liquidity are leveraged, they are most likely to be unavailable precisely when they are needed. Holding demonstrably unleveraged reserves is an important mitigation for [Liquidity risk](#sec-risks-liquidity), and in certain cases helps mitigate [Compliance and Legal Risk](#sec-compliance-risks).Users, protocols and investors SHOULD hold a range of tokens or other hedges against a liquidity problem in a given Protocol.
This is particularly relevant to mitigating [Liquidity risk](#sec-risks-liquidity).Decentralized Finance (more commonly DeFi) is a finance system based on Decentralized Ledger Technology. In this document we generally use the term "Blockchain" rather than "Decentralized Ledger", as it is far more widely recognized and understood, although strictly speaking a Blockchain is one very common form of Decentralized Ledger Technology.
DeFi uses computer software, (particularly Smart Contracts but also Oracles, Dapps and others), to automate different types of financial interactions, distinguishing it from more traditional financial services (widely known in the DeFi space as "TradFi") by explicitly removing the concept of a human intermediary involved in or overseeing the day-to-day operations of the service. A DeFi Protocol is a particular financial service based on a particular set of software. A Protocol can offer a range of financial services, such as lending/borrowing, trading, yield farming, stablecoin issance, or derivatives.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. (This is known as the principle of "Composability" in software engineering).
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 manage services such as automated market makers, Decentralized Exchanges, Decentralized Lending, and insurance protocols. Users interact with a Protocol through applications called dApps (or Dapps or Ðapps - "decentralized applications"), applications that are often web-based but may be installed on a device, whose purpose is to faciliate smart contract calls.Protocols can be immutable, that is once they are deplyed the code cannot be changed. However, they are often upgradeable, and the two most common appraoches do maintenance are a private organisation or Protocol Operator managing the code, or a DAO that enables Protocol Investors to vote on decisions about the governance, including proposed code changes or hiring developers to perform maintenance or updates.
In principle, anyone with an internet connection, blockchain account, and basic coding skills can write Smart Contracts and Dapps, and deploy them as a DeFi Protocol. There is no formal requirement that must be met, neither by the code nor the coder, and no quality test that is applied before deployment, not even that they are actually functioning code.Wallets are programs that allow users to 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, used as an address for individuals and other programs to transact with, generally known as an Externally Owned Account (or EOA) The user's ability to sign with their private key is considered a proof that they have control over the address, and therefore is reliable evidence to validate transactions made from that account. 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 encode the terms of the agreement between borrowers and lenders, 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 Protocols often use 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 deposit an asset with the Lending Protocol as collateral for a loan. Loans are often Overcollateralized, with collateral required to secure the loan required being 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. If the level of collateralization falls below the LTV, actors monitoring the price variations and the current positions of the system can trigger liquidation and buy the collateral in exchange for repaying the loan (or buy some of it for a partial repayment). Equally, the collateral can be auctioned off automatically.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.