Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Algorithmic Market Operations for Collateral #611

Closed
zgorizzo69 opened this issue Mar 19, 2023 · 86 comments · Fixed by #956
Closed

Algorithmic Market Operations for Collateral #611

zgorizzo69 opened this issue Mar 19, 2023 · 86 comments · Fixed by #956

Comments

@zgorizzo69
Copy link
Contributor

zgorizzo69 commented Mar 19, 2023

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
Copy link
Member

0x4007 commented Mar 19, 2023

Can you place a time estimate?

@hashedMae
Copy link
Contributor

so algo farming?

@0x4007
Copy link
Member

0x4007 commented Apr 30, 2023

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
Copy link

ubiquibot bot commented May 11, 2023

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
    Copy link

    ubiquibot bot commented May 12, 2023

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

    @ubiquibot
    Copy link

    ubiquibot bot commented May 12, 2023

    You have been unassigned from the bounty @zgorizzo69

    @ghost
    Copy link

    ghost commented Jun 13, 2023

    /start

    @ubiquibot
    Copy link

    ubiquibot bot commented Jun 13, 2023

    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
      Copy link
      Member

      rndquu commented Jun 17, 2023

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

      @rndquu
      Copy link
      Member

      rndquu commented Jun 30, 2023

      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
      Copy link
      Member

      0x4007 commented Jul 5, 2023

      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

      @0x4007 0x4007 added ping and removed ping labels Aug 9, 2023
      @molecula451
      Copy link
      Member

      @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
      Copy link
      Member

      rndquu commented Apr 9, 2024

      @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
      Copy link
      Member

      @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

      @ubiquibot ubiquibot bot unassigned sudotx Jun 25, 2024
      @0x4007
      Copy link
      Member

      0x4007 commented Jun 25, 2024

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

      @zugdev
      Copy link
      Contributor

      zugdev commented Aug 28, 2024

      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
      Copy link
      Member

      rndquu commented Aug 28, 2024

      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
      Copy link
      Member

      0x4007 commented Aug 28, 2024

      Yeah that's a main planned revenue strategy.

      @zugdev
      Copy link
      Contributor

      zugdev commented Aug 28, 2024

      /start

      Copy link

      ubiquity-os bot commented Aug 28, 2024

      DeadlineThu, 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
      Copy link
      Member

      rndquu commented Aug 28, 2024

      @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
      Copy link
      Contributor

      zugdev commented Aug 28, 2024

      @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
      Copy link
      Member

      0x4007 commented Aug 29, 2024

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

      @rndquu
      Copy link
      Member

      rndquu commented Sep 5, 2024

      @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
      Copy link
      Contributor

      zugdev commented Sep 5, 2024

      @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
      Copy link
      Member

      0x4007 commented Sep 6, 2024

      Diamond is deployed on mainnet

      I thought all the addresses are on the readme?

      @rndquu
      Copy link
      Member

      rndquu commented Sep 6, 2024

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

      It's on prod:

      "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
      Copy link
      Contributor

      zugdev commented Sep 6, 2024

      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
      Copy link
      Contributor

      zugdev commented Sep 7, 2024

      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
      Copy link
      Member

      rndquu commented Sep 10, 2024

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

      Yes

      Copy link

      ubiquity-os bot commented Sep 20, 2024

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

      @zugdev
      Copy link
      Contributor

      zugdev commented Sep 20, 2024

      I think I should be reassigned here

      Copy link

      ubiquity-os bot commented Sep 20, 2024

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

      Copy link

      ubiquity-os bot commented Oct 3, 2024

      Note

      This output has been truncated due to the comment length limit.

       [ 613.173 WXDAI ] 

      @zugdev
      Contributions Overview
      ViewContributionCountReward
      IssueTask1600
      IssueComment613.173
      ReviewComment150

       [ 18.121 WXDAI ] 

      @0x4007
      Contributions Overview
      ViewContributionCountReward
      IssueComment1315.01
      ReviewComment63.111

       [ 0.00375 WXDAI ] 

      @hashedMae
      Contributions Overview
      ViewContributionCountReward
      IssueComment10.00375

       [ 183.6295 WXDAI ] 

      @rndquu
      Contributions Overview
      ViewContributionCountReward
      IssueComment1363.435
      ReviewComment14120.1945

       [ 0.005 WXDAI ] 

      @FibrinLab
      Contributions Overview
      ViewContributionCountReward
      IssueComment10.005

       [ 1.9 WXDAI ] 

      @molecula451
      Contributions Overview
      ViewContributionCountReward
      IssueComment91.9

       [ 0.78225 WXDAI ] 

      @gpylypchuk
      Contributions Overview
      ViewContributionCountReward
      IssueComment40.78225

       [ 0.03075 WXDAI ] 

      @sudotx
      Contributions Overview
      ViewContributionCountReward
      IssueComment10.03075

       [ 55.47 WXDAI ] 

      @zgorizzo69
      Contributions Overview
      ViewContributionCountReward
      IssueSpecification155.47

      Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment