# Safety Criteria for Safe Farming Committee Voting

## Contract Safety
1. Are contracts battle tested: managed many millions of dollars worth of assets on mainnet for a long period of time without exploits
- e.g. Compound, Aave, etc
1. Have contracts been audited by a reputable company? If not, are contracts a fork of other audited project?
1. Are contracts immutable or upgradeable by admins?
2. What functions are we using within the contract? How are they controlled (can they be paused, etc.)?
3. Is there an emergency exit option?
4. Even if the pool we are farming is safe, are other parts of the protocol safe?
1. Good example is RULER—even if the rcToken pool is a basic Curve pool, if the lending protocol gets rugged then rcTokens become valueless and it's a rush to swap them out of the Curve pool for stablecoins.

## Multi-sig & Governance Safety
### Components of a "safe" multisig

#### 1. Limited Powers
- What powers does a particular multisig have? E.g.
- Can it steal funds, directly or indirectly?
- Can it upgrade contracts? Not desirable

#### 2. Well-Known Signer Identities
Identity types in order of least to most preferred:
1. **Unidentified / Anonymous** - Signer address is not linked to any known identity. Highest risk because it is not possible to know if it is controlled by same person who controls another address on the multisig.
1. **Pseudonymous** - Address is owned by an individual who has some form of identity and reputation online, but not tied to their real identity
1. **Real life** - Address is controlled by an individual who's identity is known publicly

Goal here is to determine:
- our confidence that no two signers are the same person
- whether signers have a reputation at stake
- what signers' relationship to the project is

#### 3. High Signer Threshold
Multi-sigs require an M-of-N signing threshold.
A higher ratio of M to N is preferred as this promotes consensus. A higher number of N is also preferred as these typically involve signers from outside the core team.

#### 4. Timelock
A timelock enforces a duration of time between when a transaction is approved and when it can be executed. Does the multisig have a timelock? If so, how long is it? Could Yearn reasonably have enough time to monitor for and act upon malicious activity?

#### 5. Composition of the Multisig
Is the multisig composed of only team members? Or are there signers from outside the protocol? Bonus points if they offer to onboard someone from Yearn as a signer.

## Misc
- Is the team willing to work with us? Are they responsive? Any general red flags?