Copra: Docs
Search
K
🚧

Risk Framework

Comprehensive and In-Depth Credit Risk Analysis of Borrower Protocols
Each protocol that is onboarded as a borrower on Copra goes through an extensive due diligence process that assesses the credit risk of a loan. This due diligence process is currently conducted by Copra's internal team but will be progressively decentralized into a DAO governance process.
Overall credit risk assessment is broken down into four subcategories:
  1. 1.
    Drawdown risk
  2. 2.
    Liquidity risk
  3. 3.
    Future income risk
  4. 4.
    Smart contract risk
Each subcategory is then broken down further into individual question items, and each of these question items is analyzed and researched thoroughly and in-depth. This process includes but is not limited to reviewing the protocol's public documentation, analyzing on-chain contracts and transaction data, reviewing the protocol's Github repositories, and performing background checks to confirm certain claims. The results of this analysis are then graded based on a standardized, well-defined grading chart. These individual item gradings are then weight-averaged into the subcategory gradings, which are then weight-averaged into the overall credit risk grading.
At this time, protocol onboarding as a borrower is still 'permissioned,' effectively gated by Copra's internal team. Only protocols that have gradings of 'B' or above on each of the subcategories of credit risk can raise loans through Copra. This is to ensure the prudence of Copra loans at least in the initial phase of the protocol. That said, as the due diligence process gets decentralized, the future of borrower onboarding will become permissionless.

Drawdown Risk

Drawdown risk is defined as the risk that the pool to which the loan funds are deployed loses its value due to its inherent strategy in the current market conditions, consequently causing the loan to lose its value as well. The drawdown risk subcategory has a weight of 30%.
For each whitelisted pool, extensive research and analysis are to be performed to answer the following questions:
  1. 1.
    By design, how delta-neutral is the pool? (Or for pools where the potential source of drawdown is not price movement, conceptually how likely is drawdown to occur?) [70% weight]
Grade
Requirements
A
Completely delta-neutral. For example, lending pools in a money market protocol, lending vaults in a leveraged yield farming protocol, collateral pools in a synthetic protocol, or DEX AMM pools of pegged pairs.
B
Reasonably delta-neutral. For example, DEX AMM pools with blue chip pairs complemented with hedging positions, or GLP-like pools being the 'house' for both sides of the trade.
C or D
Not delta-neutral. For example, DEX AMM pools of volatile small-cap tokens, or pools that take short positions of options trades without any hedging mechanism.
  1. 2.
    Looking at past performance, how has the pool performed in various circumstances? [30% weight]
Grade
Requirements
A
Over the last 12 months that the pool has been live, the pool has never experienced any drawdown under normal circumstances and experienced less than 3% drawdown in very extreme edge cases.
B
Over the last 6 months the pool has been live, the pool experienced less than a 3% drawdown under normal circumstances and experienced less than a 10% drawdown in very extreme edge cases.
C or D
The pool has been live for less than 6 months, or over the last 6 months the pool has been live, the pool has experienced more than 3% drawdown under normal circumstances or more than 10% drawdown in very extreme edge cases.

Liquidity Risk

Liquidity risk is defined as the risk that, even though the value of the liquidity warehouse exceeds the promised repayment, there is not enough reserved liquidity available at maturity on whitelisted pools to be withdrawn back to fully repay the loan. The liquidity risk subcategory has a weight of 15%.
For each whitelisted pool, extensive research and analysis are to be performed to answer the following questions:
  1. 1.
    By design, would the liquidity deposited in the pool always stay in the pool and always be withdrawable? (70% weight)
Grade
Requirements
A
Yes. For example, DEX AMM pools, collateral pools on synthetic asset protocols, and cross-chain bridge liquidity pools.
B
No, but some mechanism is in place to reasonably ensure reserve liquidity availability. For example, lending pools with dynamic interest rates on money market protocols, or lending vaults with dynamic interest rates on leveraged yield farming protocols.
C or D
No and without any mechanism to incentivize reserve liquidity. For example, lending pools with static interest rates on money market protocols.
  1. 2.
    Looking at past performance, what is the percentage of available liquidity for withdrawal from the pool? (30% weight)
Grade
Requirements
A
For the last 6 months that the pool has been live, more than 90% of liquidity deposited was available for withdrawal on average, and at least 50% of liquidity deposited was available for withdrawal at all times.
B
For the last 2 months that the pool has been live, more than 50% of liquidity deposited was available for withdrawal on average, and at least 20% of liquidity deposited was available for withdrawal at all times.
C or D
The pool has been live for less than 2 months, or the average available deposited liquidity was less than 50% or less than 20% of liquidity deposited was available for withdrawal in the pool's history.

Future Income Risk

Future income risk is defined as the risk that during the duration of the loan, the protocol revenue is too low to be meaningful in buffering up the loan value. This credit risk subcategory becomes irrelevant and will be skipped if revenue escrow is not part of the loan terms. The future income risk subcategory has a weight of 15%.
Extensive research and analysis are to be performed to answer the following questions:
  1. 1.
    Does the protocol have a sound and proven revenue model that could produce enough protocol fees to meaningfully buffer up the loan? (40% weight)
Grade
Requirements
A
The protocol business model has been proven before, potentially by other similar protocols that have already attained blue-chip status such as DEXs, money markets, synthetic infrastructure, etc.
B
The protocol business model is new, but shows reasonable soundness by, for example, relying on organic user activities instead of unsustainable tokenomics to generate revenue.
C or D
The protocol business model is new and does not show reasonable soundness, for example by relying on unsustainable native token-based incentives to generate revenue as opposed to having 'real' traction from users.
  1. 2.
    Extrapolating past performance into the future, including the extra liquidity from Copra loan, how much could the extra buffer provided by escrowed revenue add to the loan value in the liquidity warehouse? (60% weight)
Grade
Requirements
A
Taking the assumption of the average revenue for the last 6 months and adding the projected effect of the extra liquidity from Copra loan, the total revenue would exceed the interest cost of the period window by 5 fold.
B
Taking the assumption of the average revenue for the last 2 months and adding the projected effect of the extra liquidity from Copra loan, the total revenue would exceed the interest cost of the period window by 2 fold.
C or D
The protocol has been live and collecting revenue for less than 2 months, or taking the assumption of the average revenue for the last 2 months and adding the projected effect of the extra liquidity from Copra loan, the total revenue would be less than 2 fold the interest cost of the period window.

Smart Contract Risk

Smart contract risk is defined as the risk that a bug exists in the protocol contracts or in an external place on which the protocol is critically dependent, such that the protocol is exposed to hacks and exploits that could drain some or all of the liquidity in the protocol. The smart contract risk subcategory has a weight of 40%.
Extensive research and analysis are to be performed to answer the following questions:
  1. 1.
    How long has the protocol (particularly the relevant pools) been live without any security incident? (30% weight)
Grade
Requirements
A
More than 12 months
B
More than 6 months
C or D
Less than or equal to 6 months
  1. 2.
    How many times has the protocol been audited, and by which auditors? (25% weight)
Grade
Requirements
A
More than 3 separate audits by 3 different auditors that are all considered as 'tier-1.'
B
More than 2 separate audits by 2 different auditors that are all considered as 'credible.'
C or D
Protocol has been audited 2 or fewer times by less than 2 auditors that are at least 'credible.'
  1. 3.
    What is the audit coverage of the protocol and are deployed contracts identical to the audited code? (25% weight)
Grade
Requirements
A
Protocol code has been 100% fully audited by 2 or more auditors, and the bytecode/commit hash listed in the report is confirmed to be the same one as the contracts deployed on-chain.
B
Protocol code has been 100% fully audited by 1 or more auditors, and the bytecode/commit hash listed in the report is confirmed to be the same one as the contracts deployed on-chain.
C or D
Audit coverage is less than 100% or the bytecode/commit hash listed in the audit report cannot be confirmed to be the same one as the contracts deployed on-chain.
  1. 4.
    Are there privileged roles in the protocol and are those privileged roles' addresses securely managed? (10% weight)
Grade
Requirements
A
All addresses of privileged roles' addresses are multisig contracts with different hardware wallet signers.
B
All addresses of privileged roles' addresses are multisig contracts.
C or D
One or more privileged roles' addresses is an EOA.
  1. 5.
    Are there function calls that could affect the protocol's immutability (e.g. upgrade contract function calls) and are sufficient time-locks implemented in all appropriate places? (10% weight)
Grade
Requirements
A
There is no function call that could affect protocol immutability.
B
Some privileged roles do have access to function calls that could affect protocol immutability, but time-locks with a 12-hour duration or more have been properly implemented on each of those functions.
C or D
Some privileged roles do have access to function calls that could affect protocol immutability, and one or more of those functions does not have time-locks with a 12-hour duration or more.
In the case where the protocol is a fork of another protocol (presumably a 'blue-chip' protocol) that is much more proven in terms of smart contract security, the grading thresholds for items 1 and 2 can be slightly lowered as appropriate. That said, to be graded B or above on these items, the forked protocol still needs to be audited with 100% coverage by a credible enough auditor for the modifications made, and byte code/commit hash matching still needs to be performed to confirm the audit result validity and the modifications made from the forked protocol code.

General

Apart from the four credit subcategories above, some general aspects are also assessed regarding the protocol, to expand the credit risk assessment coverage to be as comprehensive as possible. There would be no grading in this section but instead, the produced information would be used to complement the other credit risk assessment results to provide more context and depth.
Topics that need to be analyzed and researched in this category are:
  1. 1.
    What is their core protocol model and how does it differ from that of other comparable protocols?
  2. 2.
    How credible is the team and whether they are anonymous?
  3. 3.
    Does the project have any investors or has it received grants?
  4. 4.
    What do their TVL and traction look like?
  5. 5.
    Does the project have an active community (Twitter, Discord, etc.) and what is the sentiment around it?
  6. 6.
    How long have they been live for and what are the major events (e.g. new chain deployment, version upgrades, partnership, TGE, liquidity mining program, pivot, exploit) worth noting in their timeline?
Last modified 20d ago