Testcases to Cover

• Test swap before depositing using Uniswap V2 router on mainnet fork.
• Test swap before depositing using Uniswap V3 router on mainnet fork.

Update the oracle infrastructure to allow a backup oracle to chainlink.

The gitbook is well made but could benefit from examples on how adaptors are open-source innovations for the ERC4626 standard and projects that use it.

This issue is meant to help organize thoughts on what would be needed as examples. The gitbook is not connected to this repo, though it could be.

Is there a way to pay for gas without calling executeWithToken() on Axelar architecture?

See #118 SendMessageToArbitrum.s.sol line 35

@EricBolten @cbrit :)

Similiar to how it is implemented here: https://github.com/Rari-Capital/vaults/blob/main/src/modules/VaultRouterModule.sol.

The router should never have a non-zero balance of any token.

Scope

This is a general issue for possible extra tests to add to DebtFTokenAdaptorV2.sol, DebtFTokenAdaptorV1.sol, CollateralFTokenAdaptorV2.sol, and CollateralFTokenAdaptorV1.sol.

These adaptors are complete, although there was some extra testing scope that was discussed between Crispy and me. These include:

• Additional fuzzing within testTakingOutLoanInUntrackedPositionV1, testRepayingLoans, testMultipleFraxlendPositions, testLTV, testRepayPartialDebt, testLoanInUntrackedPosition, testBlockExternalReceiver.
• Setting up the interfaces for FraxlendV1 and other versions other than V2 in a different way than V1FToken within v1 adaptors, respectively.

Scope

This issue is tied to PR #112.

adaptorData from strategists must follow guidelines as per Balancer documentation and other resources. This issue is meant to discuss and finalize guidelines on where to get particular params for preparing adaptorData for Strategists using Balancer. I have ideas for the way to generate the callData and will post them over the next day or so.

See "Resources" at the bottom of this scope description for context.

Below are the primary transactions that a strategist is predicted to carry out:

1. join() - joining a balancer pool and getting balancer pool tokens (bpts)
2. exit() - exiting a balancer pool via redeeming their bpt for their underlying assets and fees
3. swap() - includes singular and batch swaps where internal vault accounting is used.
4. deposit() - depositing their bpt into a gauge to gain additional liquidity mining rewards.
5. withdraw() - withdrawing their bpt from a gauge
6. claim_rewards() - claim rewards from the gauge that they have bpt in.

All of these types of transactions could be carried out with separate functions, but instead, we are using the BalancerRelayer.sol that allows chainedReferences. This is particularly useful when strategists want to join a balancer pool that requires some swapping to occur ahead of time.

ex.) If you need to do multiple swaps with DAI then you can actually do that all in one tx and also have it join the respective pool, let’s say bb-a-usd.

Resources

1. Balancer Docs - These are comprehensive, and it's suggested to look through the code-base to better understand everything in tandem.
2. Balancer SDK
3. Balancer Github Monorepo

See: https://www.notion.so/0xmacro/High-Old-stakers-can-run-away-with-all-rewards-of-the-new-reward-cycle-e2b82c87e745439399286fab9a666bc7

[Informational] Rewards can remain un-utilized is a won't fix.

Comment: This is a common issue around many staking contracts and fixing it would require more added complexity to staking/unstaking than benefit. In practice, we don't expect this to happen since during an active reward program there is always an incentive to deposit. If this ever were to occur, any un-utilized rewards could be covered by scheduling a new reward program in notifyRewardAmount to re-distribute them.

[Informational] There is a loss of precision in rewardRate calculation is a won't fix.

Comment: potential loss of precision has been noted in the natspec, on line 571, since the time of implementation. Furthermore, this is a risk to administrators, not users, and administrators are more likely to be aware of the finer details of how the contract works. In practice, the reward amounts and epoch durations we have discussed would not be affected by loss of precision.