Copra: Docs


How It Works
To enable lending to protocols, there are 3 main components in Copra's mechanism:
  1. 1.
    Liquidity Warehouse: The module where loan is disbursed to, allowing the loan to be both secured and capital-efficient by enforcing boundaries of liquidity deployment to only whitelisted pools (housing the LP tokens) of borrower's protocol and by accruing values from Buffers.
  2. 2.
    Buffers: Setups that allow the loan to be further backed by borrower's protocol resources including
    • Deposits posted by the protocol treasury
    • Revenue that is redirected from protocol treasury to warehouse contract via escrow mechanism
    • Yields collected from the whitelisted pools where liquidity is deployed to.
  3. 3.
    Debt Covenants: Monitoring system that would trigger immediate loan withdrawal if certain conditions about the loan are no longer met in order to protect lenders.

Liquidity Warehouse

While loans in DeFi are typically over-collateralized via token deposits and hence not capital efficient, Copra's liquidity warehouse mechanisms simultaneously secure the loan and ensure capital efficiency (not overcollateralized).
The loan is disbursed to a warehouse contract which allows fund deployment only to pre-defined, whitelisted liquidity pools on the borrower's protocol. This puts gated boundaries on the funds, enabling the warehouse contract to effectively custody the loan principal by holding the whitelisted pools' LP tokens.
The warehouse contract is also where Buffers from protocol-level resources are accumulated.


1. Treasury Deposit

To further buffer the loan, a deposit, typically a low single-digit percentage of the loan principal amount is required from the protocol borrower. The deposit is in the same token currency as the loan principal and is deposited to the warehouse contract by the borrower before the start of the loan in order to buffer up the value of the loan in the warehouse contract.

2. Revenue Escrow

As DeFi matures, more and more protocols will have robust sources of revenue. Thus, similarly to TradFi, escrowing future revenue could be an ideal way to further secure a loan. After all, when one purchases a corporate bond in TradFi, one is, among other things, betting on the borrower being able to generate enough revenue and cash flow to repay the loan when it matures.
The revenue escrow mechanism aims to have the first claim to protocol fees to buffer up the loan further. On the implementation level, this is done by requiring the borrower's protocol to redirect its protocol fee collection destination from the protocol treasury address to the warehouse contract address. As such, protocol fees accumulate on the warehouse contract, helping to further secure the loan by buffering up its value.
This setup has to be maintained throughout the duration of the loan or until a certain threshold amount, the 'revenue escrow ceiling' (typically a low single-digit percentage of the loan principal) is met. Otherwise, as part of the debt covenant trigger system, all deployed funds would be withdrawn back to the warehouse contract and the loan would be suspended. This is to enforce the revenue escrow terms and keep the loan trustless.
Realizing that not all protocols are suitable for this revenue escrow mechanism, this is not a mandatory component of Copra loans. Increasing the treasury deposit amount when this revenue escrow mechanism is not implemented could be an alternative.

3. Pools Native Yield

Given that the borrower's pools to which the warehouse contract deploys liquidity typically have some native yield for their LPs, these yields would be collected and accumulated in the warehouse contract, effectively buffering up the loan value further. It is important to note that the native yields of the pools are not passed to the lenders directly, but would be used to secure the loan further for its repayment to the lenders.

Debt Covenants

Debt covenants are certain conditions that need to be fulfilled or maintained throughout the duration the loan is active, as part of the loan agreement to help protect lenders. These conditions are monitored by a periodic keeper function. If any of the conditions are not met at any point during the loan tenor, then the warehouse contract will automatically and immediately withdraw all deployed funds from the pools back to itself.
Due to the similarities, it could be helpful to think of debt covenant as a 'liquidation' mechanism.
This debt covenant action trigger is implemented to bring more comfort to the lenders by limiting risks throughout the time the loan is active.

1. NAV Trigger

Net asset value (NAV) is the sum of all assets in custody of the liquidity warehouse. This includes both deployed liquidity on all whitelisted pools and idle assets in the warehouse contract. Beyond the loan principal, the value under the liquidity warehouse's custody also increases from the collected pool native yields, escrowed protocol revenue, and treasury deposit.
NAV is monitored throughout the loan tenor. If NAV ever drops below a pre-determined threshold defined as a percentage of the loan principal, automated withdrawal by the warehouse contract will be immediately triggered for all deployed liquidity. This is to ensure that, if there is a significant enough drawdown in loan value due to some undesired or abnormal circumstances, the liquidity warehouse could cut its losses early, reducing drawdown risk.

2. Liquidity Trigger

Each whitelisted pool is monitored for the amount of standby liquidity that is available to be withdrawn at any time. If the amount of standby liquidity is below a certain threshold, pre-determined as a percentage of loan principal deployed to that particular pool, then the warehouse contract will immediately try to withdraw all deployed liquidity from that pool and keep on trying to withdraw until all liquidity deployed to that pool has been recovered. This is to reasonably ensure that there is enough withdraw-able liquidity to repay the lenders, reducing liquidity risk.

3. Revenue Escrow Trigger

When revenue escrow is part of the loan terms, certain address variables that determine where the protocol fees are being collected are monitored. These address variables have to point to the warehouse contract until the loan has matured, or until the revenue escrow ceiling threshold is reached, whichever happens first. If this condition is broken, the warehouse contract will immediately initiate an automated withdrawal of all deployed liquidity. This is to enforce proper implementation of the revenue escrow mechanism to further buffer up the loan.

4. Immutability Trigger

There are several potential functions on the borrower protocol's smart contracts that could diminish their immutability. For example, a function to upgrade contract code or a function to change protocol fee structure. On top of ensuring that there are sufficient time-locks in place on these kinds of functions, calls on these functions by privileged callers are also monitored. Using pre-determined presets, it would be automatically determined whether the function call affects immutability, and if so, automated withdrawal by the warehouse contract will be immediately triggered for all deployed liquidity. This is to provide more comfort to lenders by reducing immutability-related risks.


1. Initial Setup

Before the start of the loan:
  1. 1.
    The liquidity warehouse factory would deploy a new warehouse contract with the appropriate loan terms parameters (referenced below)
  2. 2.
    Loan principal has to be deposited by lenders to the warehouse contract.
  3. 3.
    Treasury deposit has to be deposited by the borrower to the warehouse contract.
  4. 4.
    In cases where revenue escrow is utilized, the address where protocol fees are collected has to be changed by the borrower to redirect them to the warehouse contract address.
Loan Term Parameters
Expressed as
Loan principal
Amount in each token currency
Fixed interest rate
Loan tenor
Treasury deposit
Percentage of loan principal
List of whitelisted pools (where funds could only be deployed)
List of functions to deposit to those pools
NAV debt convenant threshold
Percentage of loan principal
Liquidity debt covenant threshold
Percentage of loan principal
Revenue escrow setup debt covenant
List of protocol fees destination variables
Immutable functions debt convenant
List of functions

2. Active

After the loan has been disbursed:
  1. 1.
    Borrowers can call functions to deploy liquidity from the warehouse contract to the pre-agreed whitelisted pools.
  2. 2.
    As per the borrower's request, all lenders can collectively add more whitelisted pools while the loan is active.
  3. 3.
    The native yields from pools that the loan funds are deployed to would accumulate on the warehouse contract.
  4. 4.
    If there is a revenue escrow implementation, protocol fees would accumulate on the warehouse contract.
  5. 5.
    Debt covenants are consistently and programmatically monitored.

3. Maturity

At the end of the loan tenor:
  1. 1.
    All deployed funds are withdrawn back to the warehouse contract.
  2. 2.
    The lenders are given their respective loan principal plus the fixed loan interest.
  3. 3.
    Generally, at this point, there would still be remaining funds in the warehouse contract as a result of the buffers that increased the asset value of the liquidity warehouse. As such, after the lenders have been made whole, those remaining funds in the warehouse contract are returned to the borrower, to be consistent with the fixed interest rate cost.
  4. 4.
    If there is a revenue escrow component, the borrower can freely redirect protocol fee collection back to their protocol treasury (if not already implemented).

4. Rollover

When approaching its maturity, there is an option for the loan to rollover instead if it meets certain conditions including consent from the borrower and from the lenders who whish to stay. When the loan rolls over:
  1. 1.
    The deployed funds will not be fully withdrawn back to the warehouse contract.
  2. 2.
    The loan tenor would be reset starting at the maturity date and the loan would effectively start again along with its original or updated terms.
Note that to ensure that the loan is still well buffered after the rollover, borrowers may first need to post additional treasury deposit funds to the warehouse contract to meet the original treasury deposit percentage, compared to the net loan value with interest accrued from the previous tenor(s).
Last modified 14d ago