Algorithmic Market Operations for Collateral

[zgorizzo69]

There is the UbiquityPoolFacet where users can:

1. Deposit collateral ERC20 tokens in exchange for Dollar tokens
2. Redem Dollar tokens in exchange for the collaterral

We should put the provided collateral to work and earn some yield.

What should be done:

1. Take any AMO strategy contract (from frax finance or some other well audited protocol)
2. Create an ERC-4626 contract over that strategy so that we could easily add new AMO strategies to the ubiquity protocol
3. Add thorough natspec comments for all of the contracts, methods and mechanics
4. Add unit testing

Good article: https://mirror.xyz/jackchong.eth/iB_teRKgBaKm4OTKFmjf8hFAM55C1_i0Z2kf-KkYz2I

Original description:
we want an AMO for collateral gathered thanks to #609
Algorithmic Market Operations module is an autonomous contract(s) that enacts arbitrary monetary policy so long as it does not change the uAD price off its peg. This means that AMO controllers can perform open market operations algorithmically (as in the name), but they cannot arbitrarily mint uAD out of thin air and break the peg. The aims is to invests idle collateral into various DeFi vaults/protocols

[0x4007]

Can you place a time estimate?

[hashedMae]

so algo farming?

[0x4007]

It just means that we want to have some collateral to be put to work to make some yield. We should use the ERC-4626: Tokenized Vaults interface as discussed in the past. I do think that we need to specify AMO strategies and have them be separate bounties but the intent behind this bounty is to consider this architecture and include AMO capability within the core collateral module.

[ubiquibot]

Deadline	Wed, 30 Aug 2023 07:35:24 UTC
Registered Wallet	0x4007CE2083c7F3E18097aeB3A39bb8eC149a341d

Tips:

• Use /wallet 0x0000...0000 if you want to update your registered payment wallet address @user.
• Be sure to open a draft pull request as soon as possible to communicate updates on your progress.
• Be sure to provide timely updates to us when requested, or you will be automatically unassigned from the bounty.

[ubiquibot]

Updated the wallet address for @zgorizzo69 successfully! Your new address: 0x10693e86f2e7151B3010469E33b6C1C2dA8887d6

[ubiquibot]

You have been unassigned from the bounty @zgorizzo69

[ghost]

/start

[ubiquibot]

Deadline	Wed, 30 Aug 2023 07:35:24 UTC
Registered Wallet	0x4007CE2083c7F3E18097aeB3A39bb8eC149a341d

Tips:

• Use /wallet 0x0000...0000 if you want to update your registered payment wallet address @user.
• Be sure to open a draft pull request as soon as possible to communicate updates on your progress.
• Be sure to provide timely updates to us when requested, or you will be automatically unassigned from the bounty.

[rndquu]

@pavlovcik I removed time and priority labels because we should make the spec more clear

[rndquu]

It just means that we want to have some collateral to be put to work to make some yield. We should use the ERC-4626: Tokenized Vaults interface as discussed in the past. I do think that we need to specify AMO strategies and have them be separate bounties but the intent behind this bounty is to consider this architecture and include AMO capability within the core collateral module.

Questions:

1. So each AMO strategy is an ERC-4626 vault, right?
2. When user deposits collateral ERC20 tokens in exchange for UAD then user should also select an AMO strategy, right? Or user can deposit funds and then, in another transaction, select different AMOs for different deposited amounts?
3. Frax supports the following AMOs: Aave, Compound, Yearn, Curve, Uniswap. Which one we should implement 1st?
4. Who earns the yield? User or ubiquity protocol?

[0x4007]

It just means that we want to have some collateral to be put to work to make some yield. We should use the ERC-4626: Tokenized Vaults interface as discussed in the past. I do think that we need to specify AMO strategies and have them be separate bounties but the intent behind this bounty is to consider this architecture and include AMO capability within the core collateral module.

Questions:

1. So each AMO strategy is an ERC-4626 vault, right?

2. When user deposits collateral ERC20 tokens in exchange for UAD then user should also select an AMO strategy, right? Or user can deposit funds and then, in another transaction, select different AMOs for different deposited amounts?

3. Frax supports the following AMOs: Aave, Compound, Yearn, Curve, Uniswap. Which one we should implement 1st?

4. Who earns the yield? User or ubiquity protocol?

1. Yes
2. We should handle AMOs entirely internally. It is no longer intended to be user facing. This is how FRAX does it for max profit.
3. I'm not sure at the moment. I imagine that they can be pretty quick to put together if we fork other code (like FRAX AMOs?)
4. Ubiquity

[molecula451]

It is current

[sudotx]

@rndquu Nothing concrete in mind yet, i am still getting up to speed on what work has been on it prior

[molecula451]

@rndquu Nothing concrete in mind yet, i am still getting up to speed on what work has been on it prior

checkout closed PR for instances, this task requires a strategy implementation and testing

[rndquu]

@rndquu Nothing concrete in mind yet, i am still getting up to speed on what work has been on it prior

This issue could be solved this way:

1. Create a new AMO minter contract (forked from FraxAMOMinter). We don't need all of the methods there, only the ones that transfer collateral from LibUbiquityPool to a destination AMO strategy.
2. Create a new AMO strategy (example). It should conform either to the ERC-4626 interface either to some custom IUbiquityAmoStrategy interface. I'm not sure why Frax doesn't use a common interface for its AMO strategies, perhaps it's burdensome to implement/maintain a single interface for all protocols (i.e. AMO strategies).

[molecula451]

@sudotx never opened an PR and it didn't came back to actively communicate update. The bot didn't even unassigned em, @ubiquity/software-development

[0x4007]

We will handle all those odds and ends of bot problems with v2

[zugdev]

EIP-2535 is something I have personal experience with, I've designed facets as adapters to interact with multiple protocols previously. Is this issue still open should I make it alive?

[rndquu]

EIP-2535 is something I have personal experience with, I've designed facets as adapters to interact with multiple protocols previously. Is this issue still open should I make it alive?

@0x4007 Do we still need to make yield on the provided collateral?

[0x4007]

Yeah that's a main planned revenue strategy.

[zugdev]

/start

[ubiquity-os]

Deadline	Thu, Aug 29, 2:27 PM UTC
Registered Wallet	0xbB689fDAbBfc0ae9102863E011D3f897b079c80F

Tips:

• Use /wallet 0x0000...0000 if you want to update your registered payment wallet address.
• Be sure to open a draft pull request as soon as possible to communicate updates on your progress.
• Be sure to provide timely updates to us when requested, or you will be automatically unassigned from the task.

[rndquu]

@zugdev I think it makes sense to make a forked version of FraxAMOMinter a separate diamond facet while keeping separate AMO strategies standalone contracts.

[zugdev]

@rndquu I am still thinking through it, at the end of the day we want to generate yield on Dollar's collateral. Take supplying to Aave markets for example, is supply and withdraw intended to be done arbitrarily by some multisig? If so should I trust managers to correctly manage collateral liquidity for Dollar minters?

In my head the best, trust minimizing, approach is:

1. Every new collateral is auto supplied.
2. On Dollar burn, withdraw necessary amount to cover collateral needed.
3. Yield generated distributed to holders (This is a new feature apart from this one tbh, straightest one would be 100% yield to treasury)

The biggest risk involved is in Aave being breached, which should be very low. The facet would be internal so no external risk as long as we guarantee no arbitrary calls.

[0x4007]

Automated is preferred in the long run. In the beginning stages there is a chance that it might be manual though.

[rndquu]

@rndquu I am still thinking through it, at the end of the day we want to generate yield on Dollar's collateral. Take supplying to Aave markets for example, is supply and withdraw intended to be done arbitrarily by some multisig? If so should I trust managers to correctly manage collateral liquidity for Dollar minters?

In my head the best, trust minimizing, approach is:

1. Every new collateral is auto supplied.
2. On Dollar burn, withdraw necessary amount to cover collateral needed.
3. Yield generated distributed to holders (This is a new feature apart from this one tbh, straightest one would be 100% yield to treasury)

The biggest risk involved is in Aave being breached, which should be very low. The facet would be internal so no external risk as long as we guarantee no arbitrary calls.

For v1 we can keep it simple:

• Supply (to aave for example) and withdraw of collateral (back to UbiquityPool) will be done manually by the owner address

For v2 we can aim for:

• auto supply
• auto redeem on Dollar burn
• yield distribution

If it's simpler to implement FraxAMOMinter as a separate contract (not as a Diamond's facet) then you may go this way. It's less error prone.

[zugdev]

@rndquu I need some more context, I thought the Diamond was in prod, based on the last Foundry broadcast it appears that's not correct. Is the idea to implement an AMO minter or to have the AMO itself? An AMO might not be necessary to have an Aave interacting facet or wrapper. I will write a sketch today and share here for debate.

[0x4007]

Diamond is deployed on mainnet

I thought all the addresses are on the readme?

[rndquu]

I thought the Diamond was in prod, based on the last Foundry broadcast it appears that's not correct.

It's on prod:

ubiquity-dollar/packages/contracts/broadcast/Deploy001_Diamond_Dollar_Governance.s.sol/1/run-latest.json

Line 133 in 0a230f9

"contractAddress": "0xed3084c98148e2528dadcb53c56352e549c488fa",

Is the idea to implement an AMO minter or to have the AMO itself? An AMO might not be necessary to have an Aave interacting facet or wrapper.

The idea is to implement an AMO minter and a real AMO strategy that we would be able to use. ERC-2535 (Diamond) doesn't support equal method identifiers (i.e. facets with the same method signatures). It means that if we move each AMO strategy (by the way original FRAX repository has >100 of them) to facets then chances are that method identifies will collide.

[zugdev]

Ok I understand it all now, thanks for clearing it. I thought this project was on Gnosis, therefore didn't consider the mainnet deployment. I am already working on this, will bring news soon.

[zugdev]

Opened a draft, I would appreciate some feedback on requirements as you have a much broader future view of Ubiquity than I do. For example minting uAD and UBQ to AMOs might not be useful, if so we could cut that out. Else would need to find a more straight forward way of minting to AMO, with no collateral but with external management as FRAX does.

[rndquu]

For example minting uAD and UBQ to AMOs might not be useful, if so we could cut that out.

Yes

[ubiquity-os]

! zugdev you were previously unassigned from this task. You cannot be reassigned.

[zugdev]

I think I should be reassigned here

[ubiquity-os]

@zugdev the deadline is at Sat, Sep 21, 9:00 PM UTC