popcorn-limited/contracts

Overview

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.

Vault Factory

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.

• CloneFactory: A simple factory that clones and initializes new contracts based on a Template.
• CloneRegistry: A minimal registry which saves the address of each newly created clone.
• TemplateRegistry: A registry for Templates. Each Template contains an implementation and some metadata to ensure proper initialization of the clone. Templates need to be endorsed before they can be used to create new clones. Anyone can add a new Template but only the contract owner can endorse them if they are deemed correct and safe.
• DeploymentController: This contract bundles CloneFactory, CloneRegistry and TemplateRegistry to simplify the creation of new clones and ensure their safety.
• PermissionRegistry: A simple registry to endorse or reject certain addresses from being used. Currently this is only used to reject potentially unsafe assets and in the creation of beefy adapters.
• VaulRegistry: This registry safes new Vaults with additional metadata. The metadata can be used by any frontend and supply it with additional informations about the vault.
• VaultController: This contract bundles all previously mentioned contracts. It adds additional ux and safety measures to the creation of Vaults, Adapters and Staking contracts. Any management function in the protocol must be executed via the VaultController.
• AdminProxy: This contract owns any clone and most infrastructure contracts. Its used to make ownership transfers easy in case the VaultController should get updated. This contracts forwards almost all calls from the VaultController.

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.

Vault, Adapter & Strategy

• Vault: A simple ERC-4626 implementation which allows the creator to add various types of fees and interact with other protocols via any ERC-4626 compliant Adapter. Fees and Adapter can be changed by the creator after a ragequit period.
• Adapter: An immutable wrapper for existing contract to allow for ERC-4626 compatability. Optionally adapters can utilize a Strategy to perform various additional tasks besides simply depositing and withdrawing token from the wrapped protocol. PopcornDAO will collect management fees via these Adapter.
• Strategy: An arbitrary module to perform various tasks from compouding, leverage or simply forwarding rewards. Strategies can be attached to an Adapter to give it additionaly utility.

Utility Contracts

Additionally we included 2 utility contracts that are used alongside the vault system.

• MultiRewardStaking: A simple ERC-4626 implementation of a staking contract. A user can provide an asset and receive rewards in multiple tokens. Adding these rewards is done by the contract owner. They can be either paid out over time or instantly. Rewards can optionally also be vested on claim.
• MultiRewardEscrow: Allows anyone to lock up and vest arbitrary tokens over a given time. Will be used mainly in conjuction with MultiRewardStaking.

Additional Context

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.

Security

There are multiple possible targets for attacks.

1. Draining user funds of endorsed vaults
2. Draining user funds with malicious vaults/adapter/strategies or staking contracts
3. Draining user funds with malicious assets
4. Grieving of management functions

Dangerous Attacks

• Attack infrastructure to insert malicious assets / adapters / strategies
  • Set malicious deploymentController
  • Get malicious Template endorsed
  • Get malicious asset endorsed
• Initial Deposit exploit (See the test in YearnAdapter.t.sol)
• Change fees of a vault to the max amount and change the feeRecipient to the attacker
• Exchange the adapter of a vault for a malicious adapter
• Nominate new owner of the adminProxy to change configurations or endorse malicious templates

Grieving Attacks

• Set harvestCooldown too low and waste tokens and gas on harvests
• Add a multitude of templates to make identifing the legit template harder in the endorsement process
• Reject legit vaults / assets
• Pause vaults / adapters of other creators
• Predeploy deterministic proxies on other chains

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.

Inflation Attack

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

Tests

Quickstart command

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

Prerequisites

• Node.js v16.16.0 (you may wish to use [nvm][1])
• yarn
• foundry

Installing Dependencies

foundryup

forge install

yarn install

Testing

Add RPC urls to .env

forge build

forge test --no-match-contract 'Abstract'

contracts's Issues

Abstract Adapter Test - test assumption after increasePricePerShare

The abstract adapter test should expect the usage of more assets / less shares after calling increasePricePerShare. Currently we are only testign that it still deposits/withdraws/mints/redeems.

The affected tests are test_deposit,test_mint, test_withdraw and test_redeem

Research - Leverage Vaults

There a multiple strategies that we can build for leveraging certain assets but id like to create a protocol to lever any 4626 vault.
Ideally it should allow to onboard any 4626 vault and be permissionless but i can imagine that this wont work.
Otherwise we would create a system that still supports arbitrary 4626 vaults but the dao would onboard specific ones.

We should explore any kind of option here. Maybe we partner with Gearbox, Grail, Midas or other leverage/cdp/lending protocols. Maybe we build our own. So we could either ask gearbox or smth to add our vaults, maybe bring on our vaults as collateral on cdps or lending markets.

Either we build a CDP or a lending market which allows a user to deposit a vault as collateral and borrow a stable so you can loop it to achieve the desired leverage.
If we do a CDP we need to figure out how we create sufficient liquidity in Pools and for lending markets how we get enough TVL for borrowing. We could make a deal with stablecoin like FRAX or incentive normal users to deposit their stables.

Either way we need to figure out the following things:

• How do we achieve sufficient liquidity for leveraging and selling the stable on open markets?
• How do we keep peg?
• How do we liquidate?
• How do we check prices (oracles)?
• Interest rates should be relatively low but mainly stable to allow for save leverage (if interest rates can explode easily that can liquidate positions all of a sudden)

At this stage its all open research. So prepare a document with different options and there pros and cons

Add referall to Idle Adapter

Use depositBBRef and depositAARef instead of the non-ref versions. Use the feeRecipient address from the adapter as the ref recipient.

Adapter - Maker DSR

How To

1. Use the AdapterBase as basis
2. Override the init function
   2.1. registry should be the address of MakerDSR (https://etherscan.io/address/0x197e90f9fad81970ba7976f33cbd77088e5d7cf7)
   2.2. Asset must be DAI
   2.3. Set the rest up including naming, approvals and needed state variables... (Use other adapters as reference here)
3. Override totalAssets to ???? (somehow check pie of user and multiply it by the accumulator between the last timestamp and now)
4. _protocolDeposit should call registry.drip() and than registry.join(amount)
5. _protocolWithdraw should call registry.drip() and than registry.exit(amount)
6. Add tests (Use other tests as reference)
   5.1. Override increasePricePerShare, verify_totalAssets, verify_adapterInit

Test Expectations
All tests should be green

Time Expectations
1-2d

CI - Formatting Command

We should create a CI command that uses foundry fmt on commit to make sure that all files are formatted in the same way across contributors.

LeverageStrategy PoC

Create a PoC for a strategy that deposits stETH into aave or compound than borrows eth against it. Than deposits or swaps eth to receive stETH. Last it should redeposit stETH into aave or compound.

• The owner should be able to set a leverage level to control how much eth we borrow against stETH or how often we loop.
• We should think about deposits and withdrawals to not loop on each action. The strategy should stay around the targeted leverage level but doesnt need to follow it precisely.
• Maybe its easier to lever and delever as a controlled harvest function instead of each deposit/withdrawal. Thats up to research

Research - PT / YT

Id like to create a set of smart contracts to split any 4626 vault into a PT (Principal Token) and YT (Yield Token). The holder of the YT will accrue all yield of the vault and PT can be redeemed for the principal value of the vault.
This allows users to bet on the yield of a certain vault. Basically by buying/selling YTs or PTs you either bet on the current rate or on raising rates.

This system was already build by Pendle and Timeless

Id like to utilize probably pendles implementation to allow anyone to create these tokens permissionlessly for our vaults. We should research if this is possible. What kind of collaboration is needed and what kind of changes we would need to make.

Balancer Compounder

Strategy - RewardsClaimer

Docs

Adapter - Sturdy Leverage

How To

1. Use the AdapterBase as the Basis
2. Override the init function
   2.1. registry should be the address of PermissionRegistry
   2.2. Init data should be the right LevSwap-contract
   2.3. Check that the LevSwap-contract is endorsed in the PermissionRegistry
   2.4. Call LevSwap.COLLATERAL() and make sure it matches asset
   2.5. Call LevSwap.VAULT() and store it as the aToken
   2.5. Set the rest up including naming, approvals and needed state variables... (Use other adapters as reference here)
3. Override totalAssets and simply read aToken.balanceOf(address(this)) since its a rebasing token
4. Override _protocolDeposit and _protocolWithdraw
   4.1. Call LevSwap.enterPositionWithFlashloan to deposit
   4.2. Call LendingPool.withdrawWithFlashloan to withdraw

For references search for LevSwap in this file https://github.com/sturdyfi/sturdy-contracts/blob/main/main-contracts.json to get the required addresses. This folder contains all the LevSwap contracts https://github.com/sturdyfi/sturdy-contracts/tree/0af71679fb1597bd77fb6988df51b541af72e370/contracts/protocol/leverage/ethereum.
The really hard part here is to figure out how they build the trade routes. We should probably just use one asset to lever for the moment and figure out a good trade path for that before including more leverage assets or paths.

5. Add tests (Use other tests as reference)
   5.1. Override increasePricePerShare, verify_totalAssets, verify_adapterInit
   5.2. Add a test__claim,

Use the Beefy or Convex or Aura adapter for reference to create the rewardTokens and claim function and tests.

Test Expectations
All tests should be green

Time Expectations
2-4d

Adapter - GMX

Create a 4626 adapter for GMX that allows a user to stake GMX or GLP and read the current balance of those token,

Adapter - Gearbox Leverage

This adapter should use/be a Gearbox Credit Account (https://docs.gearbox.finance/overview/credit-account) and than utilize one of Gearboxes strategies (https://app.gearbox.fi/accounts/strategies/list) with a leverage of X which can be set on initialization

Gearbox V3 Adapter Integration and Design Notes

Gearbox Credit Accounts

Gearbox V3 Credit Accounts was built to be modular. Responsibilities such as checking the health of an account, bundling multiple calls, interacting with adapters, etc are delegated to other components of the credit framework. A credit Accounts can function as a normal smart wallet (where all the funds on the account belong to the account owner) or a leveraged account (in which case, the funds are a combination of owner funds and pool funds). For our integration, we will be using a leverage account as it allows us to borrow funds from the pool and convert them into a leveraged positions, therefore we need to follow the guidelines for opening a leveraged position.

Exiting a position does not close an account any longer, so we can always deposit and withdraw underlying tokens as required without closing our accounts. Also, when opening a credit account, if the credit facade for that credit account is whitelisted, we will be needing a DegenNFT to create an account.

Some of the modules relevant to creating and interacting with a Credit Account include:

• CreditFacade: This is the contract that CA owner directly interacts with. To interact with a credit account, users submit arrays of MultiCall structs that the Credit Facade parses, orchestrating the requested internal and external actions.
• Credit Manager: This contract responsible all Credit Account operations, which performs collateral checks and facilitates execution of both external and internal (account management) calls.
• CreditConfigurator: A contract that is used to change important Credit Manager and Credit Facade parameters. Can only be directly interacted with by the Gearbox DAO and some assigned controllers. There is always a one-to-one relationship between the Credit Configurator and Credit Manager.

The Gearbox V3 has two separate repositories for the core protocol and it's integrations. The Core repository contains the contracts for the core logic that power the protocol:

• Credit: Credit Account, Credit Manager, Credit Facade
• Governance: Timelock, Guage, Staking, PolicyManager
• Pool: Pool, PoolQuotaKeeper, InterestRateModel

The Integrations repository contains the contracts for interacting with the 3rd-party protocols that Gearbox integrates with:

• Adapters: The adapter folder contains a base contract that contains all the generic logic needed to interact with a 3rd-party protocol successfully, including token approval, swapping. Each protocol adapter has to extend the base adapter and provide the implementation for some of the functions in the base adapter contract. There are a number of adapters in the repo, including Aave, Lido, etc.
• Gateway(Helpers): Gateways are where the low-level logic for interacting with 3rd-party protocols live. Adapters send transactions to the protocols through gateways. A Gateway could contain functions that do basic calls to a protocol, or contain a set of strategy logic that can be executed in addition to making calls to the protocol.

The image below shows the interaction between all the core components of the Gearbox V3 protocol.

Gearbots for automating account or position management

Gearbox V3 introduces the concept of bots, which are smart contracts that allow third parties to perform various operations with credit accounts on behalf of users. Bots are designed to be flexible terms of:

• their purpose
• possible users
• and executors.

Bots can interact with credit accounts via multicall guarged function. For bots to successfully execute their functions, they have to get right permission from:

• A user or a DAO if the bot has special permissions
• They must not be forbidden by a DAO

The permissions for bots are encoded in bitmasks where in a series of binary digits (101011, for example), every 1 means the bot has the permission to execute that action and every 0 means the bot does not have the permission to execute that action.

There are different types of bots: private and public bots

• private bots are only limited to a set of accounts
• public bots are avaialable to anyone to execute given certain conditions are met

Bot are very useful for order execution, portfolio rebalancing, account de-risking etc. Before bots are allowed to execute actions, there must be certain number of check to ensure that account are not put at risks after execution. Bots triggers can also be managed by some off-chain infrastructure.

Fix indirect imports & OZ contracts we use

We're using the upgradeable OZ contracts for ERC20, IERC20, SafeERC20, ERC4626, etc throughout the whole codebase. Especially for interface imports that's kind of pointless. We should use the standard IERC20 interfaces for easier integration. This is also the recommended solution by OZ: https://github.com/OpenZeppelin/openzeppelin-contracts-upgradeable/blob/master/CHANGELOG.md#interfaces-and-libraries-in-upgradeable-contracts

Also, there are countless spots where we import structs, interfaces, etc. through files that don't explicitly export them.

For example

https://github.com/Popcorn-Limited/contracts/blob/main/src/vault/adapter/aave/aaveV3/AaveV3Adapter.sol#L6

Only AdapterBase is exported by the file. The rest are indirect exports.

Adapter - Sturdy Pool Adapter

How To

1. Use the AdapterBase as the Basis
2. Override the init function
   2.1. registry should be the address of LendingPool (0xA422CA380bd70EeF876292839222159E41AAEe17, https://github.com/sturdyfi/sturdy-contracts/blob/main/contracts/protocol/lendingpool/LendingPool.sol)
   2.2. We dont need any init data
   2.3. Call LendingPool.getReserveData(asset) and make sure the tuple isnt empty
   2.4. Store ReserveData.aTokenAddress as aToken
   2.5. Set the rest up including naming, approvals and needed state variables... (Use other adapters as reference here)
3. The adapter should inherit WithRewards (https://github.com/Popcorn-Limited/contracts/blob/main/src/vault/adapter/abstracts/WithRewards.sol)
   3.1. Add a supportsInterface function
   3.2. Add a rewardTokens() function that simply returns the STURDY address in an array
   3.3. Add a claim()
   3.3.1 Call StakedTokenIncentivesController.getRewardsBalance (https://etherscan.io/address/0xA3e9B5e1dc6B24F296FfCF9c085E2546A466b883#readProxyContract) with the asset as an array and address(this) for user
   3.3.2 Call StakedTokenIncentivesController.claimRewards with the asset address in an array and the rewards amount returned in the previous view call
4. Override totalAssets and simply read aToken.balanceOf(address(this)) since its a rebasing token
5. Override _protocolDeposit and _protocolWithdraw
   5.1. Call LendingPool.deposit(asset,amount,address(this),0) (https://etherscan.io/address/0xA422CA380bd70EeF876292839222159E41AAEe17#writeProxyContract) to deposit the adapter asset for the adapter.
   5.2. Call LendingPool.withdraw(asset,amount,address(this)) to withdraw the wanted amount of assets

For references you can use https://github.com/sturdyfi/sturdy-contracts/blob/main/contracts/protocol/vault/ERC4626/ERC4626Vault.sol. A lot of the code can simply be copied from here.
Here is part of the LendingPool https://github.com/sturdyfi/sturdy-contracts/blob/main/contracts/protocol/lendingpool/LendingPool.sol (the other parts are in the same folder)
And for Staking: https://github.com/sturdyfi/sturdy-contracts/blob/0af71679fb1597bd77fb6988df51b541af72e370/contracts/incentives/StakedTokenIncentivesController.sol#L147

4. Add tests (Use other tests as reference)
   4.1. Override increasePricePerShare, verify_totalAssets, verify_adapterInit
   4.2. Add a test__claim,

Use the Beefy or Convex or Aura adapter for reference to create the rewardTokens and claim function and tests.

Test Expectations
Using DAI all tests should pass and we should be able to claim some STURDY.

Time Expectations
1-2d

1Inch Compounder

Similar to the existing Curve, UniV3, Velodrome and Balancer Compounder we should create a Compounder using 1Inch to sell reward tokens for an arbitrary other asset.

Balancer LP Compounder

Adapter - GMD Vault

How To

1. Use the AdapterBase as basis
2. Override the init function
   2.1. registry should be the address of SingleStakeVault (0x8080B5cE6dfb49a6B86370d6982B3e2A86FBBb08)
   2.2. gmdInitData should be the pId uint
   2.3. Call registry.poolInfo with pId and make sure its not empty + lpToken is matching asset
   2.4. Set the rest up including naming, approvals and needed state variables... (Use other adapters as reference here)
3. Override totalAssets to gmdToken.balanceOf(address(this)) * GDpriceToStakedtoken(pid)
4. _protocolDeposit should call registry.enter(amount,pid)
5. _protocolWithdraw should call registry.leave(shares,pid) (Make sure to convert adapter shares correctly to gmdShares before calling this function)
6. Take deposit limits of the gmd vaults into account and override the limit functions of the adapter. (registry.poolInfo(pid).vaultcap)
7. Add tests (Use other tests as reference)
   7.1. Override increasePricePerShare, verify_totalAssets, verify_adapterInit

Remember to take the deposit fee into account on previewDeposit and previewMint (registry.poolInfo(pid).glpFees)

Test Expectations
All tests should be green

Time Expectations
1-2d

RewardsClaimer PoC

Create a PoC for a strategy that claims rewards and allows the vault to claim them.
The vault should allow its users to claim these rewards afterwards.

• The strategy should take into account that multiple vaults might claim from it (use an index system like the MultiRewardsStaking)
• The vault should take into account that multiple users might claim from it (use an index system like the MultiRewardsStaking)
• How can vaults take performance fees on these claimed rewards?

(I think we had a PoC of this before so we can probably reuse a lot)

Research - Fee redemption + distribution

Currently all fees accrue in the FeeRecipientProxy on each chain.
These fees are in shares of the vault/adapter.
The FeeRecipientProxy just holds them and allows the owner to approve some other address to withdraw all shares.

Now we need to figure out a system of smart contracts that can redeem these shares for either a base asset or convert them to only one type of vault shares. This base asset/ vault share should than get distributed to POP stakers.
This should be possible automatically or with minimal maintance.

Since we are live on multiple chains we would need to figure out if we bridge all fees back to mainnet or if stakers can decide on which chain they stake.
We can use curve as inspiration to figure out how they distribute fees.

WIP Adapter - Across Protocol

The Across adapter has currently failing tests and we need to figure out whats going on. We might need to change some tests or/and the adapter.
Dont forget to merge main in first.

Adapter - Y2K Options

Integrate with Y2K through and adapter. Get more information from this research: #41 (comment)

Adapter - Level Finance

We should create an adapter for level finance that allows us to deposit into one of levels tranches https://v2.level.finance/liquidity

The adapter should use one of the available assets of the basket as the adapter asset.
On deposit the adapter should buy the tranche lp. On withdraw it should sell the lp for the adapter asset.
The adapter should also claim LVL token.
Total assets should be determined by the amount of assets we would receive by selling or lp token.
Take sell slippage into account on totalAssets, withdraw and redeem + their preview functions.

Add Oeth Adapter

Add an Oeth adapter using their 4626.

Adapter - Morpho

How To

1. Use https://github.com/Popcorn-Limited/contracts/blob/main/src/vault/adapter/abstracts/GenericVaultAdapter.sol as the Basis
2. Override the init function
   2.1. registry should be the address of PermissionRegistry
   2.2. morphoInitData should be the address of the Morpho-42626-Vault (Can be found here: https://developers-vaults.morpho.xyz/index.html)
   2.3. Check that the morpho-vault asset and the input asset are matching
   2.4. Make sure that the morpho-vault is endorsed in the PermissionRegistry
   2.5. Set the rest up including naming, approvals and needed state variables... (Use other adapters as reference here)
3. The adapter should inherit WithRewards (https://github.com/Popcorn-Limited/contracts/blob/main/src/vault/adapter/abstracts/WithRewards.sol)
   3.1. Add a supportsInterface function
   3.2. Add a rewardTokens() function that simply returns the MORPHO address in an array
   3.3. Add a claim() function that calls the claimRewards() function of the morpho-vault with user set to address(this)
4. Add tests (Use other tests as reference)
   4.1. Override increasePricePerShare, verify_totalAssets, verify_adapterInit
   4.2. Add a test__claim,

Use the Beefy or Convex or Aura adapter for reference to create the rewardTokens and claim function and tests.

Test Expectations
Using DAI and this morpho-vault: https://etherscan.io/address/0x8F88EaE3e1c01d60bccdc3DB3CBD5362Dd55d707#writeProxyContract)
All tests should pass and we should be able to claim some MORPHO.

Time Expectations
1-2d

Adapter - Ichi

How To

1. Use the AdapterBase as basis
2. Override the init function
   2.1. registry should be the address of PermissionRegistry
   2.2. ichiInitData should be the address of the ichi-vault (Can be found here: https://docs.ichi.org/home/technical-resources/contracts)
   2.3. Check that the token0 or token1 of the ichi vault match asset
   2.4. Make sure that the ichi-vault is endorsed in the PermissionRegistry
   2.5. Set the rest up including naming, approvals and needed state variables... (Use other adapters as reference here)
3. Add tests (Use other tests as reference)
   3.1. Override increasePricePerShare, verify_totalAssets, verify_adapterInit

Time Expectations
1-2d

UniV3 Compounder Compatibilty

Id like to figure out if our uniV3 compounder is compatible with solidly forks like velodrome solidly, ramses etc.
Additionally id like to know if the compounder works for pancakeswap

Adapter - Gearbox Leverage

Research - Carry Vaults

How can we use fixed term products and renew the term at the end of the latest term to stay in the product continuously?
(Y2k option, gmx option...)

Maybe Ribbons Vaults can give us some insights about that since they sell options continually.

CI - Run tests

Add a CI command to test all contracts (besides Abstract contracts).

Adapter - stNear Adapter

We have two different drafts for the Metapool stNear adapter on aurora. Both fail the current tests. Im not exactly sure why its precisely failing.
The task here is to first run the current contracts and figure out why the contracts are failing and than finishing up one of the two implementations to get the tests to be green and the adapter EIP-4626 compliant.

Time Expectation
2d

Adapter - Pirex

Research - Cross Chain Gauges

We need to figure out how we can deploy gauges cross chain and how we would deal with voting + giving out rewards on other chains. Similarly we would need to figure out how to exercise options cross chain.
Do we deploy the gauges on each chain and users decide on which chain they want to stake? is it all on mainnet? if so how do folks vote on multichain gauges? how do we bridge and distribute oPOP (+ potentially POP) ?

Curve, Balancer and other protocols already have cross chain gauges so we should figure out how they handle this.
On the option token the question is if we allow users to exercise oPOP on all chains or only on mainnet.

The expected result would be a document which explains how we deploy and manage cross chain gauges, how oPOP gets minted on other chains and one or multiple ways on how to exercise them.
The document can either include multiple possible paths with pros and contra or a clearly defined way of how to deal with the problem.

Velodrome Lp Compounder

UniV2 Compounder

Research - Junior/Senior Tranches

Bring over Venus + Midas adapter from monorepo

WIP Adapter - Hop Protocol

The Hop adapter has currently failing tests and we need to figure out whats going on. We might need to change some tests or/and the adapter.
Dont forget to merge main in first.

Adapter - Sommelier

Adapter - Spice

https://vaults.spicefi.xyz/v1/vaults

V2 Vault Infra Contracts Redesign

Having redesigned our strategies and vaults, we are opening this issue to explore the possibilities of resigning the infrastructure contracts that deploy our vaults. These are the contracts that are currently being considered for a redesign:

AdminProxy.sol
FeeRecipientProxy.sol
CloneRegistry.sol
TemplateRegistry.sol
PermissionRegistry.sol
CloneFactory.sol
DeploymentController.sol
VaultRegistry.sol
VaultController.sol

The design considerations we are considering for these contracts are highlight below:

1. Deploying v2 vaults and strategies with the current infrastructure contracts
2. Calling management functions in v2 vaults and strategies with the current infrastructure contracts

To track the conversations around this issue, recommendations will be added as comments.

Veldrome Compounder

Adapter - Lido

Finish up the Lido Adapter so that the tests are green.
This should largely affect the withdrawal side since it would use curve to sell stEth.
The main issue here is to figure out how to trade properly on the stEth / eth pool.

Time Expectation
1d