This protocols goal is to make vault creation easy, safe and all without compromising on flexibility. It allows anyone to spin up their own Yearn in minutes.
Vaults can be created permissionlessly based on any underlying protocol and execute arbitrary strategies. The factory uses only endorsed Adapters and Strategies with minimal user input to reduce complexity for a creator and ensure safety of the created clones. It gives vault creators a quick and easy way to spin up any Vault they need and end users the guarantee that the created Vault will be safe. For some more context checkout the whitepaper
The protocol consists of 2 parts. The Vault Factory and the actual Vaults and Adapters.
The Vault Factory part consists of a mix of Registry and Execution contracts. All contracts are immutable but execution contracts can be swapped out if requirements change or additional functionality should be added.
Note: This system ensures that minimal user input is needed and executions are handled with valid inputs and in the correct order. The goal is to minimize human error and the attack surface. A lot of configurations for Adapters and Strategies is very protocol specific. These are therefore mainly handled in the implementations itself. Adapters should receive all there critical data from an on-chain registry of the underlying protocol. As its nearly impossible to tell otherwise if the passed in configuration is malicious. There is still a need for some kind of governance to ensure that only correct and safe Templates are added and dangerous assets get rejected.
Additionally we included 2 utility contracts that are used alongside the vault system.
Note: The AdapterBase.sol
still has a TODO to use a deterministic address for feeRecipient
. As we didnt deploy this proxy yet on our target chains it remains a placeholder value for the moment. Once the proxy exists we will simply switch out the palceholder address.
All Adapters
, Vaults
, Strategies
and MultiRewardStaking
contracts are intended to be deployed as non-upgradeable clones.
Contracts in src/vault/strategy
are intended as samples of how strategies could look like but are in the current state still wip. They are NOT part of the audit.
There are multiple possible targets for attacks.
deploymentController
Template
endorsedasset
endorsedYearnAdapter.t.sol
)fees
of a vault to the max amount and change the feeRecipient
to the attackerowner
of the adminProxy
to change configurations or endorse malicious templates
harvestCooldown
too low and waste tokens and gas on harvestsReject
legit vaults / assetsPause
vaults / adapters of other creators
Most of these attacks are only possible when the VaultController
is misconfigured on deployment or its owner
is compromised. The owner
of VaultController
should be a MultiSig which should make this process harder but nonetheless not impossible.
EIP-4626 is vulnerable to the so-called inflation attacks. This attack results from the possibility to manipulate the exchange rate and front run a victim’s deposit when the vault has low liquidity volume. A similiar issue that affects yearn is already known. See Finding 3, "Division rounding may affect issuance of shares" in Yearn's ToB audit for the details. In order to combat this we are using virtual shares by a difference of 1e9. This approach was added in the latest release of openZeppelin. OZ PR
export ETH_RPC_URL="<your-eth-rpc-url>" && export POLYGON_RPC_URL="<your-polygon-rpc-url>" && rm -Rf 2023-01-popcorn || true && git clone https://github.com/code-423n4/2023-01-popcorn.git -j8 --recurse-submodules && cd 2023-01-popcorn && echo -e "ETH_RPC_URL=$ETH_RPC_URL\nPOLYGON_RPC_URL=$POLYGON_RPC_URL" > .env && foundryup && forge install && yarn install && forge test --no-match-contract 'Abstract' --gas-report
foundryup
forge install
yarn install
Add RPC urls to .env
forge build
forge test --no-match-contract 'Abstract'