> ## Documentation Index
> Fetch the complete documentation index at: https://docs.meteora.ag/llms.txt
> Use this file to discover all available pages before exploring further.

# Risk Management

This section outlines the security measures implemented to mitigate various risk factors.

In addition to executing the algorithm for optimal yield allocations, our keeper program must also assess and address certain risks before determining the final allocation.

Risks are generally categorized into two main types:

* **Operational Risk**
* **Lending Risk**

***

# Operation Risk

Risks that are related to source code such as when a partner protocol or team has a program update, or when lending platforms are not well audited. In minor cases, the source code changes break the integration, users are unable to perform any vault withdrawals or deposits. In major cases, the vault program or lending protocols may be exploited, losing the tokens in the vaults.

We implement a maximum allocation mechanism that the vault can deposit into each lending pool to mitigate this risk.

All lending protocols' maximum allocation starts at 100%. We will assess them across a set of criteria which includes the existence of audits, open-source code, insurance funds, main token pools, program multi-sig / verified & non-updatable status as well as the length of integration with Meteora. This set of criteria will eventually be governed by the DAO.

For every criterion not met, we will reduce the maximum allocation allowed to the protocol according to this matrix:

<div className="overflow-x-auto">
  <table className="w-full border-collapse">
    <thead>
      <tr className="border-b border-gray-300 dark:border-gray-600">
        <th className="text-left py-3 px-4 font-semibold text-gray-900 dark:text-gray-100">Criteria</th>
        <th className="text-left py-3 px-4 font-semibold text-gray-900 dark:text-gray-100">Maximum Allocation Reduction</th>
      </tr>
    </thead>

    <tbody>
      <tr className="border-b border-gray-200 dark:border-gray-700 hover:bg-gray-50 dark:hover:bg-gray-800">
        <td className="py-3 px-4"><strong className="text-gray-900 dark:text-gray-100">Audit</strong></td>
        <td className="py-3 px-4">20</td>
      </tr>

      <tr className="border-b border-gray-200 dark:border-gray-700 hover:bg-gray-50 dark:hover:bg-gray-800">
        <td className="py-3 px-4"><strong className="text-gray-900 dark:text-gray-100">Open-source</strong></td>
        <td className="py-3 px-4">30</td>
      </tr>

      <tr className="border-b border-gray-200 dark:border-gray-700 hover:bg-gray-50 dark:hover:bg-gray-800">
        <td className="py-3 px-4"><strong className="text-gray-900 dark:text-gray-100">Official Insurance Funds?</strong></td>
        <td className="py-3 px-4">20</td>
      </tr>

      <tr className="border-b border-gray-200 dark:border-gray-700 hover:bg-gray-50 dark:hover:bg-gray-800">
        <td className="py-3 px-4"><strong className="text-gray-900 dark:text-gray-100">Main Pool</strong></td>
        <td className="py-3 px-4">10</td>
      </tr>

      <tr className="border-b border-gray-200 dark:border-gray-700 hover:bg-gray-50 dark:hover:bg-gray-800">
        <td className="py-3 px-4"><strong className="text-gray-900 dark:text-gray-100">Existing integration > 1 month</strong></td>
        <td className="py-3 px-4">10</td>
      </tr>

      <tr className="border-b border-gray-200 dark:border-gray-700 hover:bg-gray-50 dark:hover:bg-gray-800">
        <td className="py-3 px-4"><strong className="text-gray-900 dark:text-gray-100">Program multi-sig / or Verified & Non-Updatable</strong></td>
        <td className="py-3 px-4">20</td>
      </tr>
    </tbody>
  </table>
</div>

**Example:** Lending Protocol Xyz (with Audited, Open-sourced, Main Pool, and Program multi-sig)

The score for allocation will be 100-20 (No official insurance funds) - 10 (Existing integration \< 1 month) = 70.

The maximum allocation for Xyz will be 70% of total liquidity.

We also limit max allocation in each lending as 30% of total liquidity.

Hermes is not allowed to withdraw funds from the lending protocols to external wallets. In the event that Hermes is hacked, the hackers will only be able to control the flow of funds to and from between the vaults and lending protocols; the principals are still safe in either of them.

***

# Lending Risk

This risk occurs when depositors are unable to withdraw their funds from the lending pools. This is caused when utilization rates of the reserves reach full capacity at 100% where borrowed amount equals the deposited amount, or when the amount of reserves remaining in the lending pools is less than the vault deposits. When this happens, depositors are unable to withdraw funds on demand.

To avoid lending risks, we have developed the following mechanisms to protect principals:

<CardGroup>
  <Card title="Diversified Allocations" icon="layer-group" iconType="solid">
    Allocations are stretched across multiple lending protocols to diversify and manage risk, reducing exposure to any single platform.
  </Card>

  <Card title="Active Utilization Monitoring" icon="eye" iconType="solid">
    Hermes continuously monitors the utilization rates of each lending pool. If utilization exceeds the 80% threshold, Hermes is ready to withdraw funds, ensuring a buffer for timely action even in high-demand pools.
  </Card>

  <Card title="Lending Reserve Buffer" icon="shield-halved" iconType="solid">
    Vaults always maintain a buffer in the lending reserve, providing Hermes with additional time to react to liquidity movements and protect principal.
  </Card>
</CardGroup>