[Epic] Add Lending Providers

[iafhurtado]

Context

Each vault is linked to a set of lending providers from where the liquidity gets sourced. A provider is a contract implementing the logic of a specific lending protocol. Fuji V2 will be launched on Ethereum, Polygon, Arbitrum and Optimism. For each of these chains, we need a set of provider contracts. We start off with established lending protocols like Aave and Compound but from an aggregation perspective we have to add new ones with a good reputation like Euler and Morpho.

Tasks

1. Copy missing provider contracts from Fuji V1 or testnets and write tests for them

	Ethereum	Polygon	Arbitrum	Optimism
Aave V2	:ballot_box_with_check:	:ballot_box_with_check:	n/a	n/a
Aave V3	n/a	:ballot_box_with_check:	:ballot_box_with_check:	:ballot_box_with_check:
Compound V2	:ballot_box_with_check:	n/a	n/a	n/a
Compound V3	:ballot_box_with_check:	in proposal stage	n/a	n/a

2. Create new provider contracts and write tests for them

	Ethereum	Polygon	Arbitrum	Optimism
Euler	:ballot_box_with_check:	n/a	n/a	n/a
Morpho	todo	n/a	n/a	n/a

linked:

• 48

[brozorec]

@iafhurtado @DaigaroCota fyi this ticket's description got updated with the needed details.

[brozorec]

@DaigaroCota I have a question regarding provider contracts: why do deposit/borrow/repay/withdraw return a value if we don't check it in the Vault?

[brozorec]

@DaigaroCota I have a question regarding provider contracts: why do deposit/borrow/repay/withdraw return a value if we don't check it in the Vault?

@DaigaroCota Another questions that poped up while implementing Compound V2: why do we have to pass in those functions both asset and vault when we can only pass vault and infer from it the asset we are interested in?

[0xdcota]

@DaigaroCota I have a question regarding provider contracts: why do deposit/borrow/repay/withdraw return a value if we don't check it in the Vault?

In general is a good practice, but I think we are not implementing it properly. There is an opcode STATICCALL to run or simulate a call and check its output. For example a function that does a computation and changes the state can return the latest state value. If you want to know the result of this latest-state you can do it with a STATICCALL. However, if you just want to know the action "pass", you can return a boolean. Then you can simulate and make a STATICCALL, and if returns TRUE, action will pass.

UPDATE-- When I wrote the ILendingProvider interface, I recall we were not set on ER4626, that is why it was set-up like that. However for functions like deposit() and withdraw() ERC4626 already specified a return value for a state changing function. For example deposit() returns the amount of shares you will get. That way you can STATICCALL deposit and get share amount expected, instead of just TRUE or FALSE.

[0xdcota]

@DaigaroCota I have a question regarding provider contracts: why do deposit/borrow/repay/withdraw return a value if we don't check it in the Vault?

@DaigaroCota Another questions that poped up while implementing Compound V2: why do we have to pass in those functions both asset and vault when we can only pass vault and infer from it the asset we are interested in?

asset is being used generically in ILendingProvider. Asset can be "collateral" or "debt". Perhaps a better variable term could be erc20? Also check simultaneously different providers. For example, Aave is the simplest to interface because you only call 1 pool address regardless of what erc20(asset) you want to interact with. CompoundV2-and-similars, you need to know the corresponding cMarket to the erc20(asset) you are passing. For Kashi or CompoundV3 isolated markets you need to know collateral-and-debt erc20s to determine the corresponding market you have to interact with, even if you just want to deposit for yield. Since provider-contracts need to work for both Yield and Borrowing vaults there is some complications.

However, if you think it can be simplified and works for all these type of providers/vaults combinations, then propose update.

[brozorec]

New inked tickets:

• [x] #106
• [x] #48
• [x] #105