Proxy Yield Aggregator v1.0.0 - ERC4626 Compatible Deposit Contract

[0x4007]

"Bring Your Own Yield Source"

For the next iteration of the Proxy Yield Aggregator (PYA) program a user should be able to bring their own ERC4626 compatible yield source, and connect it to our deposit contract.

This product is intended for users to be able to stack the total yield that they can receive from their favorite yield bearing sources.

Upon withdrawal, the user interface should present a slider which represents risk tolerance of the user.

Example

1. The user likes a new ERC4626 Compatible Yearn USDC vault that promises 20% APR.
2. The user "connects" the ERC4626 vault to our deposit contract.
   1. Implementation details must be researched, but I hope that we can avoid a contract redeployment, a la deploying a new Uniswap market.
3. The user deposits 1000 USDC, and the USDC is immediately transferred to the underlying yield source.
4. One year later, the user seeks to withdraw their 1200 USDC, and returns to our user interface to withdraw.
5. The user interface presents a slider, which seeks to understand the user's risk/reward tolerance
   1. For example, the user can withdraw with no additional risk (1200 USDC) or the user can withdraw with max risk (2400 uCR)
   2. The idea is that the user can convert the USDC into our uCR for a premium
   3. In exchange, the Ubiquity Dollar is able to raise collateral for the dollar in perpetuity.
6. User withdraws at "25% r/r" netting them something like 900 USDC and 900 uCR (premium curve formula to be determined)
   1. "50% r/r" would be 600 USDC and 1200 uCR
   2. "100% r/r" is 0 USDC and 2400 uCR
   3. "16.7% r/r" is 1000 USDC and 400 uCR // I imagine that many would, in this example go here or lower in order to only convert yield, and to receive the principle back.

Adjustable Parameters

1. uCR Premium, a math formula (default would be a linear calculation, 1 USDC -> 2 uCR)
   1. This would be deployed as a separate smart contract
   2. This gives us flexibility to implement exponential or logarithmic functions which may more efficiently produce our desired economic outcomes!
2. Yield token whitelist (default would be an array with the following contract addresses: USDC, DAI, LUSD)
   1. The idea is that, because the user is able to bring their own yield source, we wouldn't want a situation where they give assets that we do not want (like UST)
   2. Rejection should happen upon deposit, not withdrawal; in case we change our accepted assets after the user already has deposited their tokens.

Remarks

It would be very interesting to match the uCR Premium (math formula) with the bond of the associated asset. That way we are purchasing at the same price premiums ecosystem wide. As long as we're mindful of 1. the interface implementation, and 2. that we architect it so we can associate the uCR Premium PER asset, then I think we can easily share the same formula between our bonds and the PYA.

[seosigoto]

Attached is the question point
1 Is it necessary to have one vault for each of the three assets or is it necessary to deposit three assets in one vault, which causes problems when depositing and withdrawing.
2. As DAO, we can decide the list of stable coins with Whitelist. I think we need to design this DAO as well.
3. It is a problem when receiving a deposited one, but if it can be received with only one usdc, the slippage problem will surely occur, and I think we need to calculate it.
4. Items in the withdrawal should also be fixed. It is considered that slippage should be reduced to a minimum using only fixed plan such as 25, 16.7, 50, 100%.
5. There is a need to design a Strategy contract, which generates APYs, and decide whether this will be a traditional contract or should be made separately
6. Finally, I want to make sure that the purpose of uCR is to do it up to 1USD in the future.

[0x4007]

Attached is the question point
1 Is it necessary to have one vault for each of the three assets or is it necessary to deposit three assets in one vault, which causes problems when depositing and withdrawing.

Without researching I assume we would need to have users mint new vaults like Uniswap markets. I also assume that each vault should support only one asset at a time, as each vault is associated with only one underlying yield bearing source/strategy.

2. As DAO, we can decide the list of stable coins with Whitelist. I think we need to design this DAO as well.

For this version lets focus on easier implementation (centralized, controlled from the admin wallet)

3. It is a problem when receiving a deposited one, but if it can be received with only one usdc, the slippage problem will surely occur, and I think we need to calculate it.

I don't understand your statement.

4. Items in the withdrawal should also be fixed. It is considered that slippage should be reduced to a minimum using only fixed plan such as 25, 16.7, 50, 100%.

I didn't know this is a solution. I actually am not well versed in slippage optimization. Perhaps we can discuss this on a call? Can you cite an example of some other project that does this? I would like to see their product and do some independent research.

5. There is a need to design a Strategy contract, which generates APYs, and decide whether this will be a traditional contract or should be made separately

I don't understand the difference between "traditional contract" or "seperately"

6. Finally, I want to make sure that the purpose of uCR is to do it up to 1USD in the future.

uCR is redeemable for uAD (dollars) when our TWAP is above 1.00

[seosigoto]

1. Ok, Vaults for each asset understand
2. Ok.
3. if problem 1 is fixed, 3 will be fix
4. ok.
5. I mean, in terms of strategy contract, should we cover the mechanism on this stage? or shall we leave it for later. let us call with this.
6. understand, so uCR is the interest baring token and uAD is the stable coin of our project, isn;t it ?

[seosigoto]

1e: ok.

[seosigoto]

3. Oracle is needed for calculating exact TVL;

[0x4007]

1a;

After a user brings a strategy, and the vault interact with the strategy that is already approved by the user.

ex) User select AAVE USDC strategy, and deposit USDC into our Vault.

• then vault will deposit USDC into AAVE. and will get aUSDC.

• this aUSDC can be stored or forwarded to the User. ( depend on the user mind)

So this function have to be deal with.

We should focus on normal assets first because the logic would be different for yield bearing assets in what you describe.

For example: The deposited USDC should be in the custody of our smart contract (technically it should be deployed in the strategy, but it can be withdrawn at any time by our deposit contract)

This way, when the user withdraws, our deposit contract will have the ability to keep the USDC and return uCR.

[0x4007]

3. Oracle is needed for calculating exact TVL;

You may be able to use 3crv for DAI/USDC/USDT or Chainlink for a possibly more robust oracle.

[seosigoto]

1a; got it simple Deposite contract. then clear
3; Ok.

[sergfeldman]

The image from Seo

[0x4007]

Seems handy

https://twitter.com/jameskbh/status/1528862880988536833?s=21&t=q0eTq5voI87HiF_7nRxLVw

[zapaz]

1 Is it necessary to have one vault for each of the three assets or is it necessary to deposit three assets in one vault, which causes problems when depositing and withdrawing.

Without researching I assume we would need to have users mint new vaults like Uniswap markets. I also assume that each vault should support only one asset at a time, as each vault is associated with only one underlying yield bearing source/strategy.

Good solution is to use minimal proxy EIP-1167
With Open Zeppelin library EIP-1167 lib
And one example using this library, with template capabilities added, I made earlier : CloneFactory

[zapaz]

Smart contract overview.

1. Vault contract : only one assets can be deal in this contract. 
	a. Can save interest-bearing assets or forward to users 
	b. Able to connect with several Strategies brought by users
	c. ERC4626 standard and compatible
	d. Based ERC4626 mint uCR and corresponding assets flows into Admin Trusted Wallet
	e. uCR token contract	
2. Vault setting contract
	a. Set Assets whitelist
	b. Interfaces of each Assets
	c. Functions for Admin; Pause, Unpause, Treasury wallet setting, 
3. Oracle and Proxy

1a: I don't understand why you're highlighting this. I have not seen yield aggregators work with interest-bearing assets e.g. AAVE USDC and Compound USDC. I have only seen them with normal assets e.g. USDC.
1e. [uAR](https://etherscan.io/address/0x5894cFEbFdEdBe61d01F20140f41c5c49AedAe97) was recently rebranded to uCR
3. There is not enough detail here for me to understand.

same remarks than @pavlovcik :

1a and 1b : seems the purpose of ERC4626 is to hide this complexity, and it seems not part of this smartcontract

1c and 1d : 👍🏻

3 : can you detail the Oracle part ?

[seosigoto]

3: is not so important; we can delete this. but just in case, I thought it would be better if we consider the price of Stable coin can fluctuating.

[seosigoto]

1a, 1b; This is just considering the strategy of other Defi, but if we do not highlight it, we can completely ignore the strategy.
but sometimes other strategies do not support ERC4626, then this project cannot deal with that assets I think.

[seosigoto]

Smart contract overview.

1. Vault contract: only one asset can be dealt with in this contract.
   a. ERC4626 standard and compatible ( assets, time, adress)
   b. Based ERC4626 mint uCR and corresponding assets flow into Admin Trusted Wallet
2. Vault setting contract
   a. Set Assets whitelist (onlyowner)
   c. Functions for Admin; Pause, Unpause, Treasury wallet setting,

[0x4007]

Review Checklist

Let's go through these and explain to me how the current implementation handles these. Ideally there are test cases that correlate with each of these, but unfortunately that does not appear to be the case.

➤ YN0000: Running 7 tests for test/dollar/ProxyYieldAggregator.t.sol:ProxyYieldAggregatorTest
➤ YN0000: [PASS] testDepositWithStrategyAsset() (gas: 188416)
➤ YN0000: [PASS] testDepositWithStrategyAsset_And_Redeem() (gas: 308634)
➤ YN0000: [PASS] testDepositWithStrategyAsset_And_RedeemStrategyAsset() (gas: 319129)
➤ YN0000: [PASS] testDepositWithStrategyAsset_And_RedeemWithSplit() (gas: 308609)
➤ YN0000: [PASS] testDepositWithStrategyAsset_And_Withdraw() (gas: 309726)
➤ YN0000: [PASS] testDepositWithStrategyAsset_And_WithdrawStrategyAsset() (gas: 320398)
➤ YN0000: [PASS] testDepositWithStrategyAsset_And_WithdrawWithSplit() (gas: 309903)
➤ YN0000: Test result: ok. 7 passed; 0 failed; finished in 23.36s

@0xcodercrane @zgorizzo69

• The user likes a new ERC4626 Compatible Yearn USDC vault that promises 20% APR.
• The user "connects" the ERC4626 vault to our deposit contract.
  • Implementation details must be researched, but I hope that we can avoid a contract redeployment, a la deploying a new Uniswap market.
• The user deposits 1000 USDC, and the USDC is immediately transferred to the underlying yield source.
• One year later, the user seeks to withdraw their 1200 USDC, and returns to our user interface to withdraw.
• The user interface presents a slider, which seeks to understand the user's risk/reward tolerance
  • For example, the user can withdraw with no additional risk (1200 USDC) or the user can withdraw with max risk (2400 uCR)
  • The idea is that the user can convert the USDC into our uCR for a premium
  • In exchange, the Ubiquity Dollar is able to raise collateral for the dollar in perpetuity.
• User withdraws at "25% r/r" netting them something like 900 USDC and 900 uCR (premium curve formula to be determined)
  • "50% r/r" would be 600 USDC and 1200 uCR
  • "100% r/r" is 0 USDC and 2400 uCR
  • "16.7% r/r" is 1000 USDC and 400 uCR // I imagine that many would, in this example go here or lower in order to only convert yield, and to receive the principle back.

Adjustable Parameters

• uCR Premium, a math formula (default would be a linear calculation, 1 USDC -> 2 uCR)
  • This would be deployed as a separate smart contract
  • This gives us flexibility to implement exponential or logarithmic functions which may more efficiently produce our desired economic outcomes!
• Yield token whitelist (default would be an array with the following contract addresses: USDC, DAI, LUSD)
  • The idea is that, because the user is able to bring their own yield source, we wouldn't want a situation where they give assets that we do not want (like UST)
  • Rejection should happen upon deposit, not withdrawal; in case we change our accepted assets after the user already has deposited their tokens.

[0x4007]

• Make new manager contract with "minimum split"
• call function on manager to deploy new proxy yield aggregator
• • add to manager array of pyas then we can query from UI to see all "community vaults"

[0x4007]

• on withdrawal what to do with treasury money

  * dumping to eth

  * arbitrage bot that swap when peg > 1$

  * swapping with cowswap

* proxy yield manager

  * a custom calculation per proxy yield address

  * add/remove token allowed to be deposited aka deposit whitelist

  * one transaction call to deploy a proxy yield (factory) with minimum split + grant the UBQ minter right + enforce an underlying asset whitelist

@pavlovcik do you want me to work on the proxy manager/factory yet ?

Yes although I made another issue related to upgrading the UbiquityAlgorithmicDollarManager.sol to the Diamond Standard so perhaps consider building this manager in a way that will be easy for a dev to merge into easily?

[0x4007]

Another cowswap related tech

https://twitter.com/hasufl/status/1594084866370416641?s=46&t=SUuHlxGBxLaLBmhyOiMz9g

https://medium.com/iearn/yearn-cow-swap-371b6d7cf3b3

[0x4007]

I think we should consider TWAMMing into LUSD instead of ETH.

[zgorizzo69]

here is a small report based on our latest discussion

Report swapping treasury yield rewards to $LUSD

CowSwap

Cowswap offers a mechanism to let contracts "signed" a transaction. Indeed by triggering setPreSignature SC can approve a trade by providing its UID.

the problem is that we need to make a call to the api to get that UID and that is what the gnosis frontend is doing.

It is therefore not feasible synchronously onchain

adding reward token to lending pool

we could provide the reward to lending pool that will generate yield and can be used as a collateral to take a loan issued in $LUSD

drawbacks:

• loan needs to be overcollateralized
• need to find the right lending pool for different reward tokens
• we are still exposed to the reward token

thinking outside the box

Here we want to avoid MEV in the event of a large swap so basically we want to avoid being sandwiched by an attacker.
In order to be profitable the swap would need to be large ( IMO > 100k) and gas low. Lately the sandwich activity went down because of these factors and thanks to counter measure like flashbot and MEV proof RPC.

We could have a max amount to be swapped for the treasury and mesure /analyse to detect if we are being scandwich and if we have leftover to be swapped

[0x4007]

we could provide the reward to lending pool

I think the risk/reward on lending is not great. There are better opportunities with LP swap fees on UniV3.

I think it could be cool to "make up for the difference" over many swaps after. For example:

1. a whale dumps $1M
2. We inject an extra $100k on top of every sell transaction that occurs after, until we cover the full deficit.

[0x4007]

These guys are aggregating all the ERC4626 compliant vaults in one place. We should consider building off of it?
https://twitter.com/superformxyz/status/1592527993230225409

[zgorizzo69]

we could add our vault to their permissionless vault listing