BIP 000X: Babelfish Basket Balancing

Governance Draft BIP's
1

Introduction:

Following the successful vote of BIP-0001 to empower BabelFish protocol stakers with FISH, it is now time to proceed with one of the most important value propositions that the protocol set out to do: Hedge stablecoin risk.

To hedge risk, we will need to have frequent votes on the proper parameters of each collateral based on industry developments, this could be done monthly following calls dedicated to evaluating stablecoin risk. To commence balancing the collateral, we propose a simple initial weighting of stablecoins that is equal across all of XUSD’s collateral.

Reasoning:

Stablecoins can and often lose their peg (and some frequently do so) to the USD. If a stablecoin that is part of XUSD’s underlying basket loses its peg, so too would XUSD. To avoid this scenario, a curve needs to be implemented which provides incentives and penalties on withdrawals and deposits to maintain the desired allocation.

A sufficiently diversified and balanced basket of collateral will also enable XUSD holders to redeem their preferred stablecoin at any time, and reward them for maintaining the collateral’s balance.

Detailed info:

A withdrawal fee will be used to discourage extracting the entire balance of any one asset. Only assets that are below their desired minimum ratio will incur a fee, in order not to discourage legitimate trading of one asset for another.

If this vote is approved, all stablecoins will have the same target weight to start, and will subsequently be re-evaluated on a periodic basis.

Use cases:

  • deposit(a)

  • send token a

  • convert to XUSD at 1:1

  • calculate reward in XUSD

  • receive XUSD

  • withdraw(a)

  • send XUSD

  • calculate reward in XUSD

  • convert to token a at 1:1

  • receive token a

  • every tx should have an allowed margin to prevent slippage

Formula:

bbbf
bbbf1290×1272 44.7 KB

T - minimum weight of a token in the basket

C - current ratio

N - new ratio

M is calculated so that the area under the curve is 100%, so:

M = 2 * 100 / T

and

y = M * (T - x) / T = 200 * (T - x) / T^2

Bringing the ratio from C to N should incur a fee which is equal to the area under the curve between the two values, so:

total_fee = ( (T - N) * y(N) - (T - C) * y(C) ) / 2

For example, when T = 10%, bringing the ratio from 7% to 5%:

T = 10

M = 20

N = 5

C = 7

total_fee = 7^2 - 5^2 = 24%

2 Likes
2

I think that it would be cool to check how it works the testnet.

I would like to learn more a bout the calculate reward in XUSD case - cold You expand on that a bit?

1 Like
3

The use case should be also penalizing certain withdrawals - so adding a fee.

4

is this set separately for each Stablecoin or fixed amount for all of the aggregated stables?

5

Please check this github link to run your own simulation with different numbers than those in the written examples.

1 Like
6

What does ‘calculate reward in XUSD’ mean? Are you implying rewarding users with additional xUSD if they contribute to under-weight pools?

I’ve asked this question a couple times on disparate channels and it’s possible I am not comprehending but why wouldn’t we just fork Curve’s stable swap mechanism?

Couldn’t xUSD just be one large CurvePool that trades amongst its self. That would auto balance the pools, it would generate fees and we wouldn’t have to worry about added risk of lending stablecoins and insurance funds, etc.

7

I think that part of the answer might be that we are still relatively early on RSK and that there is no deep enough liquidity. To be able to do that we would have to have the XUSD also on other chains.

It could be only possible if we have some fees collected to use those to reward users in specific situations. XUSD in relation to other stables will be 1 to 1. We cannot create more XUSD than stables provided to the protocol.

@dolarcripto - we’ve discussed it directly on some occasion - but my memory is a bit blurry. Could You please throw a bit more light on that?