Draft BIP: Balancing Curves Update & Parameters Setup

Governance Draft BIP's
1

Description

This proposal focuses on setting up the parameters for the Balancing Curves in the BabelFish protocol. Building upon the acceptance of BIP-0007, we now have the opportunity to activate the Balancing Curves and make them an integral part of the BabelFish Aggregator. The objective of this proposal is to define the parameters that will bring the Balancing Curves to life and enable them to have a tangible impact on stablecoin swaps.

Motivation

Currently, the Balancing Curves are in a neutral state and do not influence stablecoin swaps within the BabelFish Aggregator. To unlock the full potential of this mechanism, we need to determine the appropriate parameters that will shape the behavior of the Balancing Curves and optimize the allocation of stablecoins. Our proposal aims to establish a more efficient, balanced, and responsive ecosystem for all users.

Currently, more than 99% of the aggregated stablecoins are ZUSD. In order to achieve a diversified stablecoin allocation, we propose targeting 50% of Rootstock native stablecoins and 50% of imported stablecoins. This approach aims to reduce excessive exposure to Rootstock native stablecoins and stimulate inflows for the imported stablecoins. Given the significant demand for BNB Smart Chain (BSC) stablecoins, we propose allocating 30% of stablecoins to BSC, with USDT being the most popular external stablecoin and therefore assigned the highest allocation of 15%.

In addition, we propose setting the rebalancing rewards to 2.5% and imbalancing fees to 10%. These values represent the maximum factors that will influence deposits and withdrawals. As described in the BIP-0007 Balancing Curves proposal, a factor, constant number seen in one of the formulas as C. It is used to determine the steepness of the Balancing Curves. The value of this factor influences the rewards and penalties (imbalance fee). We propose an initial setup of C with a value of 2,000,000, which would make the Balancing Curve moderate. The rebalancing rewards incentivize users to provide stablecoins to the pools which are out of balance, while the imbalancing fees encourage a more balanced inflow of stablecoins into the aggregator.

Considering the dynamic nature of the BabelFish aggregator and the possibility of multiple concurrent users, we added a slippage tolerance parameter for rewards and penalties. This parameter ensures needed flexibility, and if the difference in rewards or penalties exceeds 2.5%, the transaction will not proceed.

It is important to note that these parameters can be readjusted in the future to adapt to changing market conditions and ensure optimal functionality.

We firmly believe that implementing these proposed parameters will establish a more efficient and balanced ecosystem within the BabelFish Aggregator, ensuring smoother stablecoin flow and increased liquidity.

Proposed parameters:

  • Native Rootstock stablecoins:

    • ZUSD: 49%
    • DOC: 0.5%
    • RDOC: 0.5%

  • Stablecoin bridged and used in Rootstock ecosystem:

    • rUSDT: 5%

  • BNB Smart Chain aggregated stablecoins:

    • USDTbs: 15%
    • BUSDbs: 5%
    • DAIbs: 5%
    • USDCbs: 5%

  • Ethereum aggregated stablecoins:

    • USDTes: 5%
    • DAIes: 5%
    • USDCes: 5%

  • Rewards and penalties:

    • Max Reward: 2.5%
    • Max Penalty: 10%
    • Reward and Penalty slippage: 2.5%
    • Factor C = 2000000

Code updates:

  • easier management of the Reward Manager funds by BabelFish Multisig signers
  • improvement of the consistency of small and large rewards and imbalance fees
  • optimisation of gas - preventing 0 value rewards to be sent
  • slippage on the rewards and imbalance fees
  • adding two events onGlobalMaxRewardChanged and onGlobalMaxPenaltyChanged to reflect changes of max reward and max penalty.

Github:

2

why set a max penalty and reward? Shouldn’t those be market driven?

And

What data was used to determine the allocation parameters?

2 Likes
3

Great questions.

Setting a maximum penalty and reward threshold is necessary to prevent extreme situations where users could face excessive penalties or rewards.

If there were no maximum penalty set, the potential penalty could reach almost 100%, which would discourage users from supplying stablecoins. Even a penalty of 20% would be quite high. By setting the maximum penalty at 10%, we aim to strike a balance that is acceptable for users, considering that there are very often higher fees or slippage when interacting with other protocols.

In the current scenario, where ZUSD is over 99% of the stablecoins in the aggregator, supplying ZUSD would result in almost 10% fee penalty (minus a small fraction due to other stablecoins in the aggregator). While this penalty may seem high, it is designed to discourage excessive supply of this particular asset, but on the other hand it shouldn’t cause too significant harm to the users.

In the situation of users who supply other stablecoins and help bring the pools to balance, they will receive incentives of up to a 2.5% bonus. Setting a maximum cap on the rewards is important to ensure the long-term sustainability of the reward pool. Without such a cap, the reward pool would quickly deplete. Our goal is to drive liquidity to the protocol, not just maintain it.

In the future, when we are closer to the desired stablecoin allocations, we may consider adjusting these parameters. If pools in the aggregator would be closer to equilibrium, we could even consider setting the max penalty and max reward parameters free and allow the market to decide.

Regarding the data used for allocation parameters, we base our decisions on observations of user preferences within our aggregator. We aim to ensure sufficient liquidity for the most commonly used stablecoins while reducing or diluting the amount of stablecoins with lower demand.

4

Where is the initial liquidity coming from for the reward pool?

1 Like
5

If we limit the liquidity of stablecoins within a certain one, for example BUSD, could this constantly provoke a situation of high demand and risky liquidity when exchanging with less liquid stablecoins? Is it possible to combine the liquidity of different stablecoins within different types of blockchains? After all, 1 BUSD = 1 USDC, right? Why create precedents of low liquidity and a high probability of fines for users? Is it possible to independently combine the liquidity of different coins in such a decentralized manner? I think this is possible in blockchains with low transfer fees or with approximately equal fees. I am afraid that some blockchains may not have enough interest at the moment, which will result in the exchange user receiving negative feedback from the platform in the “insufficient liquidity to complete the transaction” section. So, the question is whether it is possible to arrange automatic transformation within the Babelfish system for uninterrupted exchange operation during peak loads? There have been many cases of significant slippage due to low liquidity, including in large systems and exchanges, which allowed ordinary users and those who deliberately engage in such actions to buy bitcoins for $1 or other valuable cryptocurrencies at extremely low rates.

6

Do you still feel confident in 30% BSC allocation given the Binance regulatory situation? In particular, I think today they shut down Binance US incoming and outgoing wires.

7

How exactly to you base decisions on the observation of user preference within the aggregator? Its been more or less offline for months, and how do you observe all of the users who intended to use it but couldn’t due to lack of liquidity? I would think anything you would be using as observable behavior would be outdated at best, and perhaps not all that representative of how people actually intended to use the aggregator over the last ~4 months.

I suppose there is an easy solution, launch and adjust after seeing more representative data.

8

Currently, there is no initial liquidity allocated to the reward pool for the balancing curves. However, we are considering the possibility of subsidizing the reward pool to kickstart the Balancing Curves mechanism. This would provide an initial boost to incentivize users to supply stablecoins.

Isn’t it what XUSD is all about?

There are numerous factors that we have to take into consideration. Different stablecoins present different set of risks (which are also constantly changing) and have different demand. The introduction of Balancing Curves serves as a solution to address the challenge of “insufficient liquidity to complete the transaction.”

We need users who want to swap their stablecoins which present lower demand to pay for this privilege, so we could provide rewards for those who bring stablecoins with higher demand. Ultimately - the goal is that the users will be able to exit to any desired stablecoin on any desired chain.

I believe the Binance regulatory situation does not significantly affect the preferences of users who transact with smaller or moderate amounts of stablecoins. Transaction fees play a crucial role in their decision-making process. Due to lower fees, users tend to prioritize withdrawing BSC stablecoins from the aggregators.

It is important to distinguish the regulatory issues faced by Binance from the BSC chain itself. We should keep in mind that tn the BSC chain, users have multiple options for utilizing their funds. While the shutdown of Binance US as an on-off ramp may pose challenges for some users, there are mutliple alternative options avaialable.

The aggregator has been and is consistently online and functional.

There is a noticeable trend of high demand for centralized stablecoins, particularly on the BSC chain. If someone isn’t checking the aggregator regularly (as we do it), might not even notice the transactions taking place. It may appear as if the BSC and ETH stablecoins have not been moved at all, while these stablecoins are being withdrawn shortly after being supplied, often within a few blocks.

Exactly! There is nothing sure, this is also kind of an experiment. We will have to observe closely how the situation with the aggregator will evolve and maybe need to readjust the parameters.

2 Likes
9

Looking forward to this rolling out.

1 Like
10

@Hyde can you confirm my understanding.

If a user bridges in $100 of bUSD, the maximum they can receive in xUSD would be $102.50 xUSDif the pools are maximally out of balance? I suppose that could be a good starting point, but unsure if that will be large enough incentive to move the needle.

2 Likes
11

Yes - in an optimal (from users perspective) situation - user could get 2.50 XUSD extra for every $100 worth of stablecoins that provided to a pool without liquidity.

12

I agree with you. I don’t think that 2.5% is going to move the needle. Bridge fees, etc. It’s going to appeal to whale level deposits only, i would guess.

13

If we’re talking about “penalties” for users who want to exchange their coins for more liquid ones, wouldn’t that discourage those willing to trade from the platform?
Let’s say a FUD on USDT was issued, as it often happens, from the “USDT lost its peg to the dollar” section and here is a huge flow of people will rush to look for an option to dump the usdt they don’t need - in such a case, if the platform by that time will be quite famous for its simplicity and large liquid pool, which eliminates slippage, then a large number of users will come to us with USDT, we will charge a 2.5% penalty for the exchange, but in USDC, for example, or XUSD we will give pluses for those who hold them in the liquidity pool or staking? Or will there be some kind of discount for people who will offer to exchange USDC/XUSD for USDT?
It is clear that the discount on commissions is excluded.
Our platform is essentially a clash of sides - two different blockchains and stablecoins.

  1. Users come here, often to exchange their money 1-1, meaning they are looking for the path of least resistance, the lowest commission. By setting the precedent I described above, wouldn’t it be easier for people to use any other bridge or exchange, of which there are an ever-increasing number?
  2. If we are talking about cheapest commission and a large pool of money that provides zero slippage. A large pool of money is a large number of stakers - to get it you have to attract it. A big bet is an attraction. The question is where to get a big bet? The big bet can be provided by a high commission of the bridge, from where the money will come to the holders, but to scare away new users and limit the use of the bridge, really only to whales. And the second option is a large number of users with a low commission.

So what I’m saying is that we should do a floating rate, as is done with the commission on blockchains, but not depending on the coin (with FUD USDT will still be worth less than 1$), but depending on the pool AND the number of requests for a particular coin.

14

There are some statements that I totally agre with - like that people search for the

But I think that You are missing some things when it comes to the space around Rootstock and Balancing Curves.

  1. There are not many other options to enter or exit Rootstock with stablecoins.
  2. We aim to provide easy to use and safe gateway for users of various stablecoins.
  3. There are no stablecoin “staking” or “liquidity” pools on BabelFish in a traditional, most often perceived in DeFi way. BabelFish is an aggregator.
  4. We have Emergency Deposit Pause Feature in case if an aggregated stablecoin would depeg.
  5. With Balanacing Curves we are establishing a way for users to help to balance the stablecoin allocations in the aggregator.
  6. Penalty/coversion fee was proposed to be up to 10%. The closer the weight of the particular stablecoin allocation is to the desired one - the smaller the fee is. At close to aimed stablecoin allocations - there would be almost no reward or penalty. It would be very close to 1 to 1 exchange.
  7. Penalty/conversion fee will be used to provide rewards for those who bring desired stablecoins which are below target weight.
  8. Rewards will attract people to use our platform, as they will get a bonus for their stablecoins - ergo they will be able to buy more BTC (or other assets), or they will wait in stablecoins for another opportunity presented by Balancing Curves.
  9. Portion of the penalty/conversion fee could be utilized for the rewarding system of the FISH stakers or any other way decided by the community.
1 Like
15

This draft BIP on top of this thread was updated.

Full story to be found here. There are some adjustments in the code and two other parameters added.

16

“Due to the dynamic nature of the BabelFish aggregator, there is one more parameter that was needed to be added to the Balancing Curves. We have to keep in mind that there are possible situations when multiple users are using it at the same time, this would affect the balances and how Balancing Curves would behave. Therefore a slippage tolerance is needed for the rewards and penalties. If the difference in rewards or penalties shown by the UI is greater than the set value, the transaction will not proceed. We believe that 2.5% will be good value to start with.”
I would like to clarify this paragraph. Am I correct in understanding that it is the amount of 2,000,000 from the previous paragraph that is in question? Is this amount calculated on the basis of the amount that the protocol can actually provide at the moment or is it given on the basis of some other considerations?
In the future, it can really just be made dynamic based on the amount of bidding on the protocol and the amount of funds in the protocol. But my question, at this point, is more about how it will work in the moment?
After all, transactions can be made 2 or 3, or 10 - 10 times 100 000 - in this case the protocol can be violated and the next transactions will be penalized? i.e. one user with large volumes, in fact, will decide what currency he will make less liquid on the protocol, and what is more liquid, although it can stop the work of the protocol by these actions and then the amount of 2 000 000 will be just a target for such attacks. Whereas a dynamic value or a gradual increase in the transaction penalty for certain amounts will incentivize the user not to do something that will have a bad effect on the exchange.
I would also add from myself that perhaps increasing the penalty on micro amounts would help rid the protocol of errors due to the large number of (essentially attacks on babelfish) small transactions. Since we are considering balancing curves. So we will build, in fact, a range of volumes that the protocol is interested in and it will be dynamic, which will give a positive user experience.
The only question is, what audience, then, are we targeting?
What if the babelfish audience can only afford small transactions?
And with small transactions, as I described above, any hacker, or just a whale, can spread a large volume over multiple transactions and disrupt the adequate distribution of balancing curves.

17

You’re touching on two distinct aspects here.

Firstly, the “Factor” is just one part of the equation that the Bitocracy will determine. The value of 2,000,000 isn’t related to deposit or withdrawal limits. It simply helps adjust the curve’s steepness.

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

Where C fine-tunes how steep or gentle the curve is. This function helps calculate the change in balance before and after a transaction, involving variables V_n and V_{n+1}. The difference between V before and after the transaction is noted as R = V_n - V_{n+1}. We’ve found that setting this to 2,000,000 works well after thorough testing. It makes the Balancing Curve moderate.

Secondly, there’s the matter of slippage for rewards and penalties. Consider multiple users interacting with the aggregator at once. If someone deposits or withdraws stablecoins before your transaction finalizes, it affects aggregator balance and pool weights and, in turn, the math outcome of the Balancing Curves. This means displayed rewards or penalties might not exactly match the UI. By setting a slippage value, transactions can proceed even if rewards or penalties deviate within the set margin. If there would be no slippage set, or it would be set to 0 - this transaction would fail and users would just waste gas.

I hope this clarifies things for you.

1 Like