Updated BIP-0008: Balancing Curves Update & Parameters Setup

After a successful vote on Balancing Curves, we were preparing for a vote on Balancing Curves parameters. However, as informed earlier, before proceeding with the vote, we encountered unexpected challenges that required additional tests and fine-tuning before proceeding with the vote on parameters.

We were actively working to resolve these technical issues as quickly as possible, with the security of the protocol and platform in the first place. We have multiple examples in the crypto space, where even well established projects — like Curve — encountered serious problems. That is why we believe that being too careful is not a mistake.

We have conducted multiple additional tests and identified areas that require improvement to ensure the desired functionality of the Balancing Curves. These tests revealed concerns that needed to be addressed before proceeding with the vote on the parameters. While we have also identified further improvements that could be implemented in future versions, including the UI, these changes would necessitate more time.

As someone once said, ‘If we want something perfect, we must accept imperfection on our way there.’ Therefore, we have decided to move forward with the Balancing Curves in their current state, incorporating small changes, tweaks, and necessary improvements, with aim for further updates in the future.

In the previous version of the Balancing Curves Parameters proposal, we have noted that one crucial parameter was missing. 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), making it crucial to decide on this factor for the curves to function effectively. After conducting extensive simulations and engaging in discussions, we propose an initial setup of C with a value of 2,000,000, which would make the Balancing Curve moderate. We intend to observe the aggregator and reevaluate it as we go, and change it if there will be need for it.

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.

Other changes covered easier management of the Reward Manager by the BabelFish Multisig signers — in the future if BabelFish Bitocracy decides so, this will enable using a portion of the funds from the Reward Manager for other purposes. Another change was improvement of the consistency of small and large incentives. Next one is related to gas optimization — to prevent sending 0 value rewards. There are also two new events added to the code — onGlobalMaxPenltyChanged and onGlobalMaxRewardChanged — to reflect changes of the Max Penalty and Max Reward parameters.

We strongly believe that this is the right time to take this next step — move forward and find out where it will take us. Just keep in mind that with Balancing Curves we are building something unique in the crypto space, entering uncharted territory, we are exploring new and different approaches to stablecoin swaps. We want to ensure the efficiency and effectiveness of the Balancing Curves and the BabelFish Aggregator, that is why we are exploring other potentially beneficial improvements. One of the potential upgrades that could be voted on soon is altering the Balancing Curves formula, by changing factor C from fixed number to dynamic factor formula, which aims to adjust itself based on the aggregator’s state, leading to more flexible and adaptive incentives. While this change holds potential benefits, its implementation requires more time and careful testing. Initial tests are very promising, and once ready, we will open it up for discussion.

We want to remind you that your feedback and ideas are highly valuable and important for us. If you have any questions, suggestions, or feedback, please do not hesitate to share them with us. Your involvement in shaping the project’s future is highly appreciated.

The revised version of the draft BIP-0008 has been released on our forum (here). We appreciate your valuable feedback, which you can submit until August 8th (Tuesday). On that day, we will make the necessary adjustments and publish the final version on our Github repository. The voting process will begin 24 hours later, starting on August 9th (Wednesday) at 2 PM UTC. We greatly appreciate your active participation in giving feedback and voting. We eagerly look forward to it.

Summary of proposed parameters and updates:

Target weights:
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%

Incentives and Imbalance fees:
- Max Reward: 2.5%
- Max Penalty: 10%
- Reward and Penalty slippage: 2.5%
- Factor C = 2000000

Code changes:

• 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.