BIP-0007: Balancing Curves

Governance Final 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

‘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”.’

This only applies when the action takes the aggregator from a state of ‘in balance’ to a state of out of balance, correct? Otherwise it doesn’t make much sense. if the aggregator is already out of balance and your action (either deposit or withdrawal) takes it further out of balance that’s when the penalty or reward takes place. Am I understanding that correctly?

3

The goal is to keep stablecoin allocations balanced in the aggregator without discouraging deposits or incentivizing liquidity removal.

Deposits are not penalized and can even be rewarded. Users can freely deposit stablecoins without facing any penalties, even if they exceed the target allocation. This encourages users to contribute and helps increase the total value locked (TVL). However, it may cause certain stablecoins to deviate from their target allocations. Users are only rewarded when they deposit into a stablecoin pool with liquidity below the target.

On the other hand, users will be charged a penalty when withdrawing stablecoins will bring the sablecoin pools to be out of ballance. No reward is given for withdrawals that bring the allocations closer to the targets.

In our current situation, users are allowed to deposit and withdraw ZUSD without any penalties. However, they will not receive rewards for bringing ZUSD to the aggregator. On the other hand, users will be rewarded for bringing all other stablecoins to the aggregator. If users remove stablecoins other than ZUSD from the aggregator, they will be penalized