Disclosures

We have secured our contracts tightly against technical attack vectors, but there are still some things you should know before putting your assets in our vaults.

YearnV1

Reaper v1 was built on Yearn.Finance's battle-tested architecture, which allowed us to start up quickly. This means the original contracts underlying Reaper are exactly the same as Yearn's. Of course, they have since been developed to suit our advanced strategies and integrations.

Partners

We can design the best vaults in the world but it would not matter if the underlying farm was a scam. We do our best to vet our potential partners to ensure we do not expose Reaper Farm users to unnecessary risks. To this end, we also evaluate the longevity of a partner. We have no interest in integrating protocols that are designed to shut down or fail after one year.

Strategists

Developers who design new vaults are known as strategists, as they create the strategy contract that will operate inside the vault. Our strategists are committed to the development of secure and functional code. We incentivize this commitment by offering strategists a share of all profits on crypts they have designed. This guarantees that it is in their best interest to produce quality contracts that can stand the test of time.

Upgradable Strategies

While our vaults are not upgradeable, our strategies use UUPS upgradeable proxies that can make changes behind a 2-day timelock. This timelock is controlled by a multisig managed by the Oath Foundation, with each signer doxed and contracted to perform their duties with the highest standards of security.

Everything we release is reviewed extensively by the Byte Masons, and we strive to get as many high-quality opinions from reputable audit firms as possible. Security is our primary focus when building new systems, so expect the best audits we can afford before we deploy any new contracts.

Internal Process

The implementation of a new and relatively simple strategy proceeds as follows:

1. Strategist proposes a strategy to the team and it is either approved or denied.

2. Strategist writes the code, adhering to basic guidelines (make sure every function works).

3. A pull request is made and the team conducts asynchronous reviews. This means team members review the code on their own and report findings later.

4. Once the code has been reviewed by four different security researchers it is passed over to our head of security. If he is unsatisfied, he passes it to the CEO.

5. Once everyone is happy, the strategy may be deployed.

For more complicated strategies everything proceeds as above up to step 3:

4. After asynchronous reviews, the entire team schedules a call to conduct a synchronous review. The code is shared on-screen and everyone goes through the code, line-by-line, together.

5. Upon the head of security’s approval, the strategy is deployed on Pain.Finance for further production testing.

6. If there are no problems with the strategy on Pain.Finance, it is moved to the main site. Note that when a strategy is moved to the main site, the crypt stays the same. Only the front-end moved, meaning users do not need to move their funds between Pain.Finance and Reaper Farm because the crypts are the same.

The most complicated strategies, those with entirely novel features, are also subjected to a Certik audit prior to being posted on Pain.Finance. We retain Certik on a monthly contract for this express purpose.