Sam - Security and Monitoring #2

[spalen0]

Scope

The SAM team is dedicated to keeping security and monitoring in place for Yearn projects and strategies.

Old BR: #218

Plan

The team will continue to build and improve a monitoring system for the underlying protocols to ensure strategy safety and conduct all internal security reviews of the Yearn ecosystem. All planned tasks are split into the following 3 categories:

1 - Internal Security Reviews of Yearn

V3 Strategy Reviews:

1. Strategy Security Reviews: Focus on identifying bugs in production and assessing audit quality.
2. Utilization of GitHub Actions: Ensure that GitHub Actions for tests are completed and working before moving to production. Continue to add tests for emergency withdrawals on strategies in production. Tests are run daily on the latest fork to ensure emergency functions can be called.
3. Risk Score Attachment: Attach risk scores to issues based on prepared risk assessments and add comments to justify the scores if necessary.
4. Complex Strategies and High TVL: For strategies marked as complex, having significant TVL in production, or being good candidates for external protocol collaboration, the team will add a "Recurring Review" issue to prioritize later review by other team members. The frequency of the recurring review will depend on the TVL and strategy risk score. A detailed approach will be defined after asset allocation to single-asset vaults.

Ventures (yETH, veYFI, etc.)

The team will do full reviews of other projects from the Yearn ecosystem. Recurring reviews will be done if needed.

Bug Bounty Management

Yearn Finance has an open bug bounty program on Immunefi. Submitted bugs will be checked and verified by the team. Additionally, new contracts will be added to Immunefi as they are deployed and ready for the bug bounty program.

Expand Bug Bounty program to Sherlock, which will cover only strategy-specific code in production.

2 - Yearn Risk Scores

Risk Score Framework values are added to yDaemon for UI presentation. There is a gap between adding a strategy to yDaemon and attaching a risk score to it. Currently, this is done manually. The plan is to have a GitHub Repository with all risk scores, descriptions, values, and automation scripts.

1. The strategy is reviewed by a security team member and gets a risk score.
2. The deployed strategy code is verified by the security team, and this value is stored in the GitHub repo with a deployed address.
3. After the strategy is endorsed and added to the registry, yDaemon is triggered to fill the value. yDaemon will be extended to fetch the risk score and fill the model.
4. We also have strategies that use factories to deploy the same strategy but for different assets. This will be handled by a GitHub Actions cron job, which will monitor the factory contract and assign all strategies the same risk scores.

We will define a new formula for the final risk score that will put more weight on riskExposureScore which defines how much and how often a strategy can be subject to losses. The current formula uses the same weight for all scores, enabling lossy strategies to get the safest score 1.

Account in the collateral assets of the market. If the specific market relies highly on the risky assets, the strategy will get a risker score, e.g. Compound V3 WETH is becoming highly dependent on multiple LRTs that are valued the same as ETH, and oracle value is always 1:1. Some of these assets don't have that much liquidity, even though this is a job of Compound, we would like to lower our risk exposures in level 1 vaults.

3 - Risk Monitoring

The team will work with the strategist on which data should be monitored to ensure strategy safety and help in building the monitoring system. Tenderly will be used heavily for this, with additional custom tools depending on the protocol.

Create and manage Telegram monitoring groups for each protocol. Governance contracts are also monitored and we will keep them up date. Some protocols that are planned to be newly monitored include:

• SKY - Any new changes will be promptly covered.
• LRTs - With LRTs taking a big chunk of the market, we need to monitor them. Lending markets have started to accept LRTs as a big part of collateral. For example, Compound V3 ETH on mainnet accepts 10 assets, of which 5 are LRTs. We have Compound V3 lending. Monitoring LRTs should give us a better look at potential problems. This will be additional monitoring to the current system running for bad debt. Monitoring LRTs will enable us to provide better information for defining risk scores. More lending markets are tapping into LRTs as collateral, such as Euler V2 and Morpho. Only Aave has taken a stance here but is adding isolated markets for this specific case.

LRT monitoring will be more important when EigenLayer starts with slashings. We will analyse all LRT's we have exposure and give them risks cores as well as tight monitoring. For example, if a LRT is securing an AVS that is new, risky or dodgy, we might unwind all our positions related to that LRT sicne risk of slashing for this LRT is high because of its stupid AVS participated

Explore the possibility of using automated actions in the case of bad market conditions. For example, Compound V3 ETH has a large portion of LRTs. By monitoring LRTs' liquidity on DEXes and utilization in the market, we would want to lower our vault's exposure to such strategies and protocols. If some LRT has a lower price, it could limit the possibility of liquidations and accumulate bad debt.

Deadline

2025-01-31

People

• Spalen
• Tapir

Money

• Infrastracture cost is covered with the total amount.
• Tapir will be off from November 14 - December 14 and won't receive a payout for that period.

24 * 3 - 12 = 60

Amount (Total)

60000

Wallet address

0xe5e2Baf96198c56380dDD5E992D7d1ADa0e989c0

Reporting

Once