Enable LUSD Collateralization

[zgorizzo69]

In the same fashion as FRAX
we want a minting and redeeming uAD mechanism where users can deposit LUSD or sUSD and get uAD in return.
We don't require any gov token to mint.
uAD price should be greater than $1.005 to allow for minting otherwise users must purchase from the market

[0x4007]

To clarify this bounty should be focusing on enabling LUSD collateral support for the Ubiquity Dollar by forking FRAX's relevant contract.

We should handle this initiative iteratively, and turn all the following points into separate bounties. For this particular bounty, to get started, lets just focus on forking FRAX's contract, clean up any issues we find, and switching the accepted collateral to LUSD? Does that sound like a good plan? If so, @zgorizzo69 can you confirm?

Planned/Draft Bounties

@zgorizzo69 I would like your feedback on these planned bounties. If we have a lot of back-and-forth we can open up a discussion but I hope that over a few comments/direct edits to this, we can figure out a sensible plan.

• User interface component to be able to "zap in" using any asset to mint uAD (swap toLUSD then mint.)
• We should have the ability to add/remove collateral support, in case a new decentralized stable makes the cut.
• We should be able to set the mint TWAP threshold (initialized at 1.005) to any number
• We should use an existing or create a new role for AMOs to be able to take some of the collateral and put it to work to make yield.
• We should begin by focusing on LUSD only
  • In order to think through multi collateral support, add sUSD as well, however from an operations standpoint I do not want to make it public that we support any other collateral until it is needed for scaling reasons. In this case we might just want to pause sUSD minting after deployment.
  • Make each collateral type pausable for minting uAD
  • Ideally our collateral type support should be a dynamic length array.
    • If this is too complex, we can consider capping this module to e.g. 8 assets and then replace the entire collateral module with a new one if we need more in the future? This is not preferred because we have time now to think through and do it correctly.

[0x4007]

We should also think through what we will do about LUSD when it is above peg. I think we should allow mints and redemptions based on the current largest liquidity market's TWAP of LUSD instead of just hard coding $1

[hashedMae]

If we're not requiring any UBQ to mint, will it instead work with an assumption that we are always at a 100% collateral ratio?

FRAX also uses the value of each token in USD, ie if LUSD is valued at $1.01 USD and uAD is valued at $1.00 then 1 LUSD can be used to mint 1.01 uAD. Are we keeping that structure?

uAD can only be minted when it is marginally over peg, should the inverse be true for redemption?

What is the expectation of behavior from users with this feature if either LUSD or uAD were to radically fall below peg?

[0x4007]

If we're not requiring any UBQ to mint, will it instead work with an assumption that we are always at a 100% collateral ratio?

Yes we will aim for 100%+ collateralization. We can seed a some excess from the treasury funds. Beyond that, yield is planned to be generated using our vaults (focus on LP.)

FRAX also uses the value of each token in USD, ie if LUSD is valued at $1.01 USD and uAD is valued at $1.00 then 1 LUSD can be used to mint 1.01 uAD. Are we keeping that structure?

Yes

uAD can only be minted when it is marginally over peg, should the inverse be true for redemption?

Yes

What is the expectation of behavior from users with this feature if either LUSD or uAD were to radically fall below peg?

• We will use an oracle to determine the price of LUSD upon mint/redeem for uAD.
• If uAD falls below peg then it should be easily arbitraged back to peg by being redeemable for $1.00 of underlying LUSD collateral. If we make the redemption amount configurable, then we can peg uAD to any amount. If we look at most stablecoins starting out, the first few times it depegs, the market might not trust the stablecoin so they wait until it is eventually repegged by arbitrageurs redeeming. Over time depegs below $1.00 (assuming the collateral is there to support it) are less likely.

[zgorizzo69]

To clarify this bounty should be focusing on enabling LUSD collateral support for the Ubiquity Dollar by forking FRAX's relevant contract.

We should handle this initiative iteratively, and turn all the following points into separate bounties. For this particular bounty, to get started, lets just focus on forking FRAX's contract, clean up any issues we find, and switching the accepted collateral to LUSD? Does that sound like a good plan? If so, @zgorizzo69 can you confirm?

Planned/Draft Bounties

@zgorizzo69 I would like your feedback on these planned bounties. If we have a lot of back-and-forth we can open up a discussion but I hope that over a few comments/direct edits to this, we can figure out a sensible plan.

* User interface component to be able to "zap in" using any asset to mint uAD (swap to`LUSD` then mint.)

* We should have the ability to add/remove collateral support, in case a new decentralized stable makes the cut.

* We should be able to set the mint TWAP threshold (initialized at `1.005`) to any number

* We should use an existing or create a new role for AMOs to be able to take some of the collateral and put it to work to make yield.

* We should begin by focusing on `LUSD` only
  
  * In order to think through multi collateral support, add `sUSD` as well, however from an operations standpoint I do not want to make it public that we support any other collateral until it is needed for scaling reasons. In this case we might just want to pause `sUSD` minting after deployment.
  * Make each collateral type `pausable` for minting `uAD`
  * Ideally our collateral type support should be a dynamic length array.
    
    * If this is too complex, we can consider capping this module to e.g. 8 assets and then replace the entire collateral module with a new one if we need more in the future? This is not preferred because we have time now to think through and do it correctly.

• Yes we can use frax as we want to follow the same formula with value of the tokens in USD as stated above
• the collateralization mecanism should part of the diamond
• For the implementation we have to be take into account that different collateral can come with different decimals thus the math can be different and different oracle to get the price in USD . so taking that into account having an array of token is possible but to be future proof it would be best to have a registry of collaterallization contract as a a facet of the diamond and deploy external contracts that implement the ICollaterallization interface that we can easily replace/Add/remove

note for the yield we can take a look at that

[0x4007]

note for the yield we can take a look at that

Unfortunately there is a bug loading this link:

Error: missing required session

Based on the url, I'm guessing its staking yield for Liquity (last time I checked it was ~8% APR last week) which is different. What we want to do a little bit more similar to FRAX again with LPing part of the collateral in different assets (e.g. ETH-USDC for ~30% APR as I did with some of the treasury funds during the last year.)

[hashedMae]

/start

[ubiquibot]

Too many assigned issues, you have reached your max of 2

[hashedMae]

FRAX uses Chainlink to get prices in USD. Are we planning on doing the same or do we have another source?

[0x4007]

We will need to use AMM TWAPs I suppose unless anybody has a better idea.

After proof of stake, from what I understand, multi block AMM TWAP exploits are much more possible.

@Draeieg has a complex oracle design which relies on the Curve Registry in the works which we could upgrade to in the future.

[Draeieg]

We will need to use AMM TWAPs I suppose unless anybody has a better idea.

After proof of stake, from what I understand, multi block AMM TWAP exploits are much more possible.

@Draeieg has a complex oracle design which relies on the Curve Registry in the works which we could upgrade to in the future.

full details of the oracle to be here #340 (comment)

[ubiquibot]

Do you have any updates @hashedMae? If you would like to release the bounty back to the DevPool, please comment /unassign

[hashedMae]

work ongoing

[hashedMae]

To use USD value we'd need to use a Chainlink Oracle for ETH:USD then use the LUSD:ETH and UAD:ETH values to get each in USD. We both don't want to use Chainlink Oracles because they're not permissionless and there's insufficient UAD:ETH liquidity to be reliable.

The best option is to price each in 3CRV as that's the only place UAD has significant liquidity depth.

[0x4007]

Perhaps we can brainstorm options in the group chat to get a faster answer?

I think it's a problem for future us to get the liquidity needed? We could proceed with this design assuming that there will be liquidity. We could also seed some liquidity, and eventually do liquidity mining incentives i.e. Curve bribes.

Otherwise, I feel like there must be a way to do this without Chainlink. Perhaps we could try roundabout strategies like checking DAI-USDT ratio and then DAI-LUSD

[hashedMae]

3Curve Pool contract has a .get_virtual_price() function. It returns the price of the LP token relative to the DAI, USDC, and USDT in the pool. This is effectively an approximation of 3crv in USD, and using our TWAPOracle, we can divide price0average() by get_virtual_price to get the value of the token0 in a metapool in USD.

[0x4007]

Sounds promising but if we rely on 3crv doesn't that make our assets under management less pure than only a uAD-LUSD primary market?

Using Curve the users should be able to go from uAD to any other stable assuming that Curve has an order router like Uniswap (I'm actually not 100% sure about this.)

[ubiquibot]

Do you have any updates @hashedMae? If you would like to release the bounty back to the DevPool, please comment /unassign

[hashedMae]

Sounds promising but if we rely on 3crv doesn't that make our assets under management less pure than only a uAD-LUSD primary market?

We're just using the Oracle features of Curve Metapools and the price of the 3crv LP token. It's the closest we can get to prices in USD without using Chainlink.

[0x4007]

Sounds promising but if we rely on 3crv doesn't that make our assets under management less pure than only a uAD-LUSD primary market?

It's the closest we can get to prices in USD without using Chainlink.

I've asked our group chat to provide some alternative proposals here as I'm unable to do a deep dive on research at this time.

[ubiquibot]

Do you have any updates @hashedMae? If you would like to release the bounty back to the DevPool, please comment /unassign

[hashedMae]

nearly finished, just need to fill out the natspec

[ubiquibot]

Do you have any updates @hashedMae? If you would like to release the bounty back to the DevPool, please comment /unassign

[hashedMae]

@ubiquibot shouldn't do this once a PR is published

[0x4007]

@ubiquibot shouldn't do this once a PR is published

I'm not sure the deployment policy @0xcodercrane but this capability has already been merged in ubiquity/ubiquibot#257

[ubiquibot]

Do you have any updates @hashedMae? If you would like to release the bounty back to the DevPool, please comment /unassign

[ubiquibot]

Releasing the bounty back to dev pool because the allocated duration already ended!

[zgorizzo69]

/start

[ubiquibot]

Skipping /start since the issue is closed

[ubiquibot]

Do you have any updates @zgorizzo69? If you would like to release the bounty back to the DevPool, please comment /unassign

[ubiquibot]

[ CLAIM 1200 DAI ]

0x10693e86...dA8887d6