# Security Processes & Risk Management

## Goal

The main goals of this document are:

- Define a security review process to ensure the quality of the code we launch for the users.
- Be as simple as possible to incentivize internal and external developments. Thus, increase our TVL and fees.
- All the community is aware of this, and be able to share this document for the new potential strategists/developers/contributors.
- Keep Yearn Finance as the most secure and trustable protocol in DeFi.

## Introduction

This document is the result of multiple internal iterations and communication between the security team, v3, and strategists.

### Terms & Concepts

- On-chain risk framework (ORF).
- Strategies are single strategies.
- Vaults are meta-vaults or multi-strategy.

## Risk Management

In order to have better risk management, we have defined four categories for the vaults, from 1 to 5, with 1 being the safest, and 1 the less secure.

Based on the scores the strategy gets, it will fit in a category.

> The new score definitions are still in progress here.

Each Github issue created using [this template](https://github.com/yearn/yearn-strategies/blob/master/.github/ISSUE_TEMPLATE/v3-strategy.md) for a security review has a category to set as goal. Depending on the underlying protocol/s, findinds, and others, the security team will set a category that might be different.

## Security Process

The process is very simple, and the main goal is to reduce friction and keep Yearn as the most secure protocol in DeFi.

As the vision for the v3 is to open the protocol to get more strategies from external contributors and developers, the security team is open to help on that dividing the security review process in two parts. One for internal strategies, and other for external ones. Both processes are very similar, and simple to follow.

### Internal Security Review

1. Peer reviews by 1-3 strategists depending on availability and complexity.
* The issue for the v3 strategy must have been created using [this template](https://github.com/yearn/yearn-strategies/blob/master/.github/ISSUE_TEMPLATE/v3-strategy.md). Otherwise, the issue must be updated to include the missing fields/structure.
* After this peer review, the issue is moved to the (security) backlog column.
2. The security team reviews the source code.
3. Strategist fixes the issues found in the security review.
4. After all fixes are done, the security team defines the risk score, thus a category. Then, all the scores are stored in the ORF periodically.
5. Based on the final category, the max cap is defined and reviewed by the security team, and committee.
6. The Strategies Board leadership creates/updates the production card.
7. *Optional*: Security team migth create an issue as a recurrent review if needed or it might be requested by another contributor.

### External Security Review

External strategy reviews:

1. The committee and the strategies board leader define the strategy/ies to be reviewed given their priorities.
* The issue must have been created using [this template](https://github.com/yearn/yearn-strategies/blob/master/.github/ISSUE_TEMPLATE/v3-strategy.md). Otherwise, the issue must be updated to include the missing fields/structure.
2. ***Optional***: The security team will check if a Due Diligence (DD) document is required. This document is *optional* and might be required at the security team's discretion.
* In case it is required, the document will be reviewed before starting the security review itself.
* In case it is required, the document must be created in [this Github repository](https://github.com/yearn/yearn-strategies/tree/master/dd) using a pull request, and reviewed by the security team.
3. The security team reviews the source code.
4. Strategist fixes the issues found in the security review.
5. After all fixes are done, the security team defines the risk score, thus a category. Then, all the scores are stored in the ORF periodically.
6. Based on the final category, the max cap is defined and reviewed by the security team, and committee.
7. The Strategies Board leadership creates/updates the production card.
8. *Optional*: Security team migth create an issue as a recurrent review if needed or it might be requested by another contributor.

> Depending on the availability, the security team will prioritize the internal security reviews over the external ones.

### Differences

## Considerations

- The ORF is updated with the new scores (or updates) periodically, in average once a month. It means, when a score is defined for a strategy in the issue, it might take some days to the tx be sent.
- The [v3 strategy template](https://github.com/yearn/yearn-strategies/blob/master/.github/ISSUE_TEMPLATE/v3-strategy.md) might be updated to add/remove information.
- The UI will need to add clear and precise alerts/warnings to notify users the risks involved in using the vaults, especially the external ones.
- Peer reviews vs Security Review
- Peer review: in-depth, advice on how to build certain features, check if the features work as expected, and other.
- Security review: in-depth, advice on how to avoid exploits, advice on worst case scenarios, and other.

## Conclusion

The security team is open to improving this process and encourages any contributor to give us feedback directly by DM.

Each comment or improvement will be discussed internally with all related teams, and if accepted, the security team will implement it as soon as possible.