BIP-0007: Balancing Curves (Draft)

Governance Draft BIP's
1

Background

BabelFish is a smart contract on RSK that enables users to deposit supported stablecoins into an aggregator contract in exchange for XUSD, and burn XUSD in exchange for one of the stablecoins held in the aggregator contract. Currently the exchange ratio is set at 1 stablecoin for 1 XUSD and vice versa.

A problem arises when one or more stablecoin in the aggregator becomes significantly more in-demand for withdrawals than others. This can occur due to, for example, high fees on one network (like Ethereum) driving users to withdraw stablecoins to a network with much lower fees (like BSC). It may also occur because one stablecoin (e.g. rUSDT) takes much longer to bridge than other stablecoins (e.g. all other non-RSK stablecoins in the aggregator).

A mechanism is needed to ensure that when these imbalances happen, users are charged for the privilege of depleting the popular stablecoins beyond some defined balance threshold. Conversely, users should be rewarded for supplying stablecoins that are below their balance threshold, to incentivize rebalancing.

At the same time, we do not want to dis-incentivize deposits and turn away earnest funds, or incentivize removing liquidity from the aggregator. So we will not penalize users’ whose deposits take the aggregator “out of balance”, and we will not reward users whose withdrawals bring the aggregator “(closer to) back in balance”.

Requirements

Smart contract changes

  • BabelFish Bitocracy should be able to add and replace an address with a role entitled the “balancing curve administrator”.

    • Testnet balancing curve administrator: 0x94e907f6B903a393e14Fe549113137ca6483B5eF
    • Mainnet balancing curve administrator: 0xbD687d470A7E8B36C666968bb79376904725E4DD

  • BabelFish Bitocracy should be able to perform all of the same actions as the balancing curve administrator by approving a proposal using the BabelFish timelockAdmin contract.

  • The balancing curve administrator should be able to submit a transaction to the BabelFish contract that, if successful, will result in setting or updating a “target weight” for each stablecoin in the aggregator. The target weight is the proportion, in percentage terms, of the balance of a given stablecoin relative to all others.

    • For example, a target weight of 20% implies that the target proportion of a stablecoin should be 20% of the total amount of stablecoins deposited in the aggregator. A total amount of 100 units of different stablecoins and a target weight of 20% for a given stablecoin implies that the target amount for that stablecoin is 20 units.

  • The balancing curve administrator should be able to submit a transaction to the BabelFish contract that, if successful, will result in setting or updating a “balancing curve” that determines the value of Imbalancing Fees and Rebalancing Rewards.

    • Imbalancing Fee - Fees are charged to users who convert XUSD to stablecoins, bringing the BabelFish aggregator “(further) out of balance” relative to the target weights set.
      • The fee should be deducted from the amount of XUSD that the user is converting into stablecoins.
      • The fee should be able to be split two ways: between FISH stakers and Rebalancers. The exact split should be configurable by the balancing curve administrator. The initial split will be defined as follows.

        • FISH stakers: the fees paid to FISH stakers should be sent to the FISH feeSharingProxy contract.

          • Initial split share: 0%

        • Rebalancers: the fees paid to Rebalancers should be paid into a pool of funds that will in turn be paid out according to the “Rebalancing Reward” section below.

          • Initial split share: 100%

    • Rebalancing Reward - A reward paid to users who convert stablecoins to XUSD and bring the BabelFish aggregator “(closer to) back in balance” relative to the target weights set.
      • The reward should be added to the XUSD that the user is converting their stablecoins into.
      • If there is no reward available to give, then no reward is given and the conversion goes through on a 1:1 basis.

  • The balancing curve administrator should be able to submit a transaction to the BabelFish contract that, if successful, will result in the balancing curve being either “enabled” or “disabled”.

    • If the balancing curve is enabled, then fees will be charged and rewards will be given as determined by the algorithm.
    • If the balancing curve is disabled, then no fees will be charged and no rewards will be given. XUSD will be minted upon deposit of stablecoins, and stablecoins will be released upon burning XUSD, on a 1:1 basis.

Technical specifications

Balancing curve technical specification

A formula is derived to provide an incentive which depends on the balance of the basket before and after a given transaction, in such a way that the incentive is positive for deposit operations that bring the stablecoins closer to their target weights and negative for withdrawal operations that bring stablecoins further from their target weights.

Given:

\sum\limits_{1}^N {w_i}=1

And:

\sum\limits_{1}^N {T_i}=1

We define D as a measure of the basket’s distance from optimality:

D= \frac 1 N\sum\limits_{1}^N ({w_i-T_i})^2

With weights (wi) and target weights (Ti) in [0,1], D is also in [0,1]. We calculate an asymptotic function:

V=C* \frac {D} {1-D}

Where C is a constant used to calibrate the formula to be as shallow or as steep as desired. We calculate the difference between V before and after the transaction:

R=V_n-V_{n+1}

In the case where a withdrawal has a positive reward, or a deposit a negative reward, R is set to 0. Negative rewards are removed in XUSD from a user’s withdrawal prior to conversion to the required stablecoin and kept in a vault. Positive rewards are paid from the vault and added to the user’s minted XUSD after conversion.

Target weight specification

  • BUSDbs:
    • 0%
  • DAIbs
    • 0%
  • USDCbs
    • 0%
  • USDTbs
    • 0%
  • DAIes:
    • 0%
  • USDCes
    • 0%
  • USDTes
    • 0%
  • DOC:
    • 0%
  • RDOC:
    • 0%
  • rUSDT:
    • 0%
  • ZUSD:
    • 0%

Max Reward and Max Penalty parameters are also going to be decided by the voters.

2

Since there is no feedback - we are moving this proposal to final ones.