BIP-0009: Add DLLR and Migrate ZUSD Liquidity (draft)

BIP-0009: Add DLLR and Migrate ZUSD Liquidity
Status: Draft

Description

By voting to approve this proposal, FISH Bitocracy approves:

  1. Adding DLLR as a supported bAsset to the BabelFish aggregator

    • Address: 0xc1411567d2670e24d9C4DaAa7CdA95686e1250AA
  2. Authorizing the BabelFish multisig to migrate ZUSD held in the BabelFish aggregator to DLLR via Mynt, then depositing the resulting DLLR into the BabelFish aggregator to restore full backing. See implementation section below for details.

Motivation

The Sovryn community recently launched a new protocol called Mynt that issues a BTC-backed stablecoin called the Sovryn Dollar (DLLR). Mynt is a fork of BabelFish that aggregates multiple stablecoins that are exclusively backed by BTC. By aggregating multiple stablecoins, DLLR is designed to be more resilient and scalable than any individual stablecoin backing it. By exclusively aggregating BTC-backed stablecoins, DLLR comes closer than any other stablecoins to achieving the cash-like, censorship-resistant qualities of BTC. The authors believe these qualities make DLLR an excellent candidate for the BabelFish aggregator.

Currently DLLR supports DOC and ZUSD as collateral. Since DLLR is able to aggregate these stablecoins together, and simultaneously provide liquidity between them and other assets that DLLR trades against, we believe it would be beneficial to the user experience for BabelFish to convert the ZUSD held in its aggregator into DLLR. Additionally it opens the possibility to lend out a portion of aggregated DLLR on Sovryn platform to earn yield.

Implementation

The migration will be implemented as follows:

  1. A new ERC-20 token contract for a token called “MIGRATE2” will be deployed. The MIGRATE2 contract will have the following features:

    • A role called OWNER. Only the OWNER can change the address currently assigned the OWNER role.
    • A mint function that can mint a specified number of tokens to the caller’s address. Only the OWNER can call the mint function.
    • A burn function that can burn a specified number of tokens owned by the caller’s address. Anyone can call the burn function.
    • All other basic ERC-20 token functions e.g. approve, transfer, etc.
  2. DLLR and MIGRATE2 will be added as supported bAssets to the BabelFish aggregator.

  3. An amount of MIGRATE2 equivalent of the current balances of ZUSD held by BabelFish will be minted and deposited into BabelFish in exchange for XUSD. The XUSD will then be redeemed to withdraw ZUSD from the aggregator.

  4. The ZUSD from step (3) will be deposited into Mynt in exchange for an equivalent amount of DLLR. The DLLR will then be deposited into BabelFish in exchange for XUSD.

  5. The XUSD minted in prior step (4) will be used to withdraw the full balance of MIGRATE2, leaving BabelFish with the original supply of XUSD and reserves that it started with at the beginning of this migration process.

  6. MIGRATE2 will be removed as a supported bAsset from the BabelFish aggregator.

  7. The outstanding supply of MIGRATE2 tokens will be burned using the burn function on the MIGRATE2 token contract. Minting capabilities on the MIGRATE2 token contract will also be burned by transferring ownership to the 0x0 address.

I think this will generate caos on Babelfish and DOC users.

  • Most of DOC users do not like to use Mynt, they do not trust in the protocol.

  • Any decision needs to foster competition, so if you want to add DLLR, do that, but do not force users to use Mynt (DLLR).

  • DLLR has several issues, it shows depeg constantly.

  • DOC has no depeg, so pls do not harm DOC users that use Babelfish.

  • There are more than 4.3M ZUSD in Babelfish, something similar could happen to DLLR. Please be carefull with these decisions that are difficult to go back.

2 Likes

@Arab - I really like Your feedback.

I don’t aggre that this would create chaos. It would change some things and patterns that people are used to.

Feel free to correct me on those points, as I might be wrong. But the way I see it:

  • DOC users are a relatively small group with low inflows to the aggregator recently.

  • There is not a high demand for DOC, and it has not achieved much since its establishment in 2019. If not Sovryn - there would be no earning opportunities for DOC users.

  • DLLR is composed of ZUSD and DOC (supposed to be). But there is currently no aggregated DOC in the DLLR/Mynt, so it seems like none of DOC users use Mynt. At this moment the same applies to XUSD/BabelFish - we have 0 DOC aggregated. Not even a fraction of it.

  • If DOC would be provided to Mynt, and DOC deposits to BabelFish would not be paused, it would mean that we are actually aggregating DOC directly and indirectly through DLLR/Mynt.

  • It is odd and surprising that DOC users have no problem using BabelFish’s smart contracts, but not using Mynt’s smart contracts.

  • Yes - DLLR has some issues, but in shorter time it has achieved more than DOC. It has more use cases, it has greater market cap. DLLR peg seems to be stabilized recently. I think that some more observation of it would not hurt - esspecially after the SIP-0061 passed.

  • DOC peg is also not perfect. I have observed arbitrage bot taking advantage of that.

  • Going back with the decision would not be a big problem. It would require unpausing DOC.

But there is other thing that came to my mind while answering You - maybe DLLR deposits to the aggregator should be paused until Balancing Curves are live. We need people to help balance the stablecoin baskets and amount of ZUSD or DLLR (if this finalized proposal would be accepted) is way too significant. Since it is backed by Bitcoin - it is not that big issue, from the security perspective, but from the liquidity and user perspective - it is problematic.

Anyway - let’s keep the discussion rolling. We need to take all the perspectives into consideration, before finalizing the BIP.

If you stop accepting DOC, you will generate more risks. DOC is the only Rootstock native stablecoin on Babelfish, that you can redeem 1:1 to RBTC.

is there a native way to redeem DLLR and ZUSD for RBTC? withouth losing capital. Not using an AMM. The problem with DLLR and ZUSD is that you depend on liquidity pools.

You can see the problem right now, XUSD lost the peg. Why? Because there are +4.3M ZUSD on Babelfish that you cannot exchange 1:1.

Babelfish incentive curves are meant to maintain a balance of stablecoins in the BF aggregator. At the moment, we are seeing demand to switch Rootstck native stablecoins for imported, external stablecoins but the mechanism to inceltivize importing an equivalent number of external stablecoins is absent. The incentive curves can help address this imbalance.

Ultimately, this will not only allow BF to grow but also Rootstock BTC-backed stablecoins. If the liquidity to switch out of BTC-stables is more readily available, then they become more useful and reliable.

In the near-term, the best strategy for BF to grow is to specilize in acting as the gateway and marketplace between BTC-backed stablesand external stables. It is much easier to do this efficiently, if the BTC-backed are aggreagted into the Sovryn Dollar. It aggregates BTC-stables into a single weight for the incentive algorithm.

@Arob raises a legitimate concern. However, the DoC users who will use BF are switching out of DoC. Effecitvly, they have taken the decision to stop holding DoC and they will also not be holding DLLR. They are using BF to export value in USDT, USDC etc.
So they don’t need to trust the Mynt or DLLR. Basically, for them, it can and will all happen “behind the scenes”. They deposit DoC and bridge out to their desired stable.

1 Like

If you see a demand to switch Roostock native stablecoins for imported, why there are no native stablecoins in BF pools?

The big problem is ZUSD and could be DLLR too.

Before thinking about that, we should focus on two challenges:

  • Try the BF incentive curves
  • Reduce the amount on ZUSD on BF pool.

The reason is simple, they have been bought out. XUSD was burned for DoC. And DoC inflows stopped because there wasn’t supply of external stables.

1 Like

Exactly. All the DOCs have been bought. DOC inflows stopped because XUSD is iliquid and/or is deppeged. So the problem is not DOC.

Why not all the ZUSD are bought? Because ZUSD and DLLR are iliquid and/or lost their pegs.

It makes sense to DOC to stay in BF, just in case DLLR drains all the liquidity of DOC, as now happens. Now DLLR can be converted only to ZUSD.

In the current situation with Balancing Curves Parameters proposed, it makes sense to change the proposal. How about this version? I’ve updated the first post with it and changed the thread title.

BIP-0006: Add DLLR and Migrate ZUSD Liquidity
Status: Draft

Description

By voting to approve this proposal, FISH Bitocracy approves:

  1. Adding DLLR as a supported bAsset to the BabelFish aggregator

    • Address: 0xc1411567d2670e24d9C4DaAa7CdA95686e1250AA
  2. Authorizing the BabelFish multisig to migrate ZUSD held in the BabelFish aggregator to DLLR via Mynt, then depositing the resulting DLLR into the BabelFish aggregator to restore full backing. See implementation section below for details.

Motivation

The Sovryn community recently launched a new protocol called Mynt that issues a BTC-backed stablecoin called the Sovryn Dollar (DLLR). Mynt is a fork of BabelFish that aggregates multiple stablecoins that are exclusively backed by BTC. By aggregating multiple stablecoins, DLLR is designed to be more resilient and scalable than any individual stablecoin backing it. By exclusively aggregating BTC-backed stablecoins, DLLR comes closer than any other stablecoins to achieving the cash-like, censorship-resistant qualities of BTC. The authors believe these qualities make DLLR an excellent candidate for the BabelFish aggregator.

Currently DLLR supports DOC and ZUSD as collateral. Since DLLR is able to aggregate these stablecoins together, and simultaneously provide liquidity between them and other assets that DLLR trades against, we believe it would be beneficial to the user experience for BabelFish to convert the ZUSD held in its aggregator into DLLR. Additionally it opens the possibility to lend out a portion of aggregated DLLR on Sovryn platform to earn yield.

Implementation

The migration will be implemented as follows:

  1. A new ERC-20 token contract for a token called “MIGRATE2” will be deployed. The MIGRATE2 contract will have the following features:

    • A role called OWNER. Only the OWNER can change the address currently assigned the OWNER role.
    • A mint function that can mint a specified number of tokens to the caller’s address. Only the OWNER can call the mint function.
    • A burn function that can burn a specified number of tokens owned by the caller’s address. Anyone can call the burn function.
    • All other basic ERC-20 token functions e.g. approve, transfer, etc.
  2. DLLR and MIGRATE2 will be added as supported bAssets to the BabelFish aggregator.

  3. An amount of MIGRATE2 equivalent of the current balances of ZUSD held by BabelFish will be minted and deposited into BabelFish in exchange for XUSD. The XUSD will then be redeemed to withdraw ZUSD from the aggregator.

  4. The ZUSD from step (3) will be deposited into Mynt in exchange for an equivalent amount of DLLR. The DLLR will then be deposited into BabelFish in exchange for XUSD.

  5. The XUSD minted in prior step (4) will be used to withdraw the full balance of MIGRATE2, leaving BabelFish with the original supply of XUSD and reserves that it started with at the beginning of this migration process.

  6. MIGRATE2 will be removed as a supported bAsset from the BabelFish aggregator.

  7. The outstanding supply of MIGRATE2 tokens will be burned using the burn function on the MIGRATE2 token contract. Minting capabilities on the MIGRATE2 token contract will also be burned by transferring ownership to the 0x0 address.