Technical Proposal to introduce the Flux Capacitor and enable RDOC Minting

Dear RIF on Chain community members,

I am submitting this technical proposal for the changes in the proposal to introduce the Flux Capacitor and enable RDOC Minting, which aims to enhance the Rif on Chain protocol’s stability while also reinstating the minting operations for the RDOC stablecoin.

Implementation

The general idea to easily understand the proposal is that the Flux Capacitor is related to an electric capacitor that over time saves and releases energy to the system. Similarly, the Flux Capacitor is going to save and release the allowed amount of RIF tokens the user can operate.

In the Forum proposal, we define the implementation components, the new parameters and the Pseudo-Lineal Decay Factor. Please refer to those definitions in order to better understand the technical implementation described here.

The Flux Capacitor works with a Pseudo-Lineal Decay Factor. This means that as the blocks pass, the amount that can be operated increases in such a way that after the BS number of blocks, the maximum allowed is reached again. Which means that we would have to wait the same amount of blocks without any consumption in order for the Flux capacitor to return to full capacity.

If the users now operate over the protocol, they will affect the new 2 variables: AA and DA as described below:

  • For minting operations, the amount will be added to AA.
  • For redeeming operations, the amount will be subtracted from the AA limit.
  • In either case, the module of the amount will be added to the DA.
  • Whenever, one of those limits are reached, the transaction will be reverted.

Right now, we are working on improve the dApp with this changes:

  • Show actual limits of the Flux Capacitor on the Metrics Tab.
  • Show suggested maximum limits related to actual limits of the Flux Capacitor when doing minting and redeeming.
  • Show a descriptive message when the transaction failed because it exceeded the Flux Capacitor limits.

:warning: Warning: some technical/coding knowledge is necessary to fully understand this document.

The Flux Capacitor limits that we think will enhance the level of autonomy and security in Rif on Chain are:

These limits were calculated based on last year transactions over the protocol.

Here is the heart of the Flux Capacitor: the implementation for the Pseudo Linear Decay Factor:

Here we can see how the limits on the Flux Capacitor are updated on each mint/redeem operation:

We also need to calculate the new maximum for minting, so here it is:

Also we add 2 new functions for the dApp to query the maximum to mint/redeem, in order to inform the user before doing an operation:

When we finished adding the Flux Capacitor, we had a setback on the MocExchange.sol: we hit the 24.576 kb smart contract size limit.

So, after the changes done by the proposal, we decided that it was time to properly remove the code for the leveraged positions in Rif on Chain. The benefit of doing this is that we get enough space in the smart contract to fully include the Flux Capacitor feature.

To maintain the integrity and usability of the protocol, it is crucial to allow modification of the Flux Capacitor thresholds. However, this modification should only be able to be made by the address with the authority to pause the protocol, This restriction will ensure that any changes made to the threshold are carried out through authorization via multisig.

:information_source: Modifications to contract Stopper.sol will also be necessary

Adding the Flux capacitor, gives us the confidence to reinstate the minting operations for the RDOC stablecoin.

To achieve this, the change is simple and only affects the Moc.sol contract in Rif on Chain implementation. This is the same implementation that was before plus the Flux Capacitor logic it was overridden in this proposal.

:heavy_check_mark: Here is the pull request with full detail on the changes to be added to the repository.

:heavy_check_mark: The new implementation of the Moc.sol contract that is already deployed in mainnet would be this 0x345Fb1cCf607696Ca2dECA2CcFc1355434F71099

:heavy_check_mark: The new implementation of the MocExchange.sol contract that is already deployed in mainnet would be this 0x0f6f2778CD15D187C1147308695B1D62fb19b6BD

:heavy_check_mark: The new implementation of the StopperV2.sol contract that is already deployed in mainnet would be this 0x51072aC8Fe05Fcfdc14e02Bb3a0C7499Ad9eF140

:heavy_check_mark: The change contract deployed in mainnet is 0x37314a6c651e5bebbfc17f81a76cfc7666bf1bd0

:heavy_check_mark: The current implementation of the Moc.sol contract in mainnet is 0x62F9Bd2F7094Dd923e268ec7a9b6297D0Cc1f92E

:heavy_check_mark: The current implementation of the MocExchange.sol contract in mainnet is 0x7adCeff90eB56bA4A92c5e85C0374F63709a5f37

:heavy_check_mark: The current implementation of the StopperV2.sol contract in mainnet is 0x10D337Eb8E72fe0674C80634BFFDCCaFC3264c29

:heavy_check_mark: The Moc.sol proxy contract in mainnet is 0xCfF3fcaeC2352C672C38d77cb1a064B7D50ce7e1

We invite all community members to participate in the vote on this proposal for the Rif on Chain protocol.

Henrik Jondell
(With support from the IOV Labs team)

4 Likes

Audit report by the IOV Labs team is shared below.

1 Like

:mega: Call to MOC holders: This proposal is being voted on. How to vote Tutorial.

:mega: Llamado a los MOC holders: Esta propuesta se está votando. Tutorial de cómo votar.

:mega: The voting process is over:

  • 23.69 of the MOC tokens total supply participated in the vote.
  • 100% of the participants voted in favor.
  • No one voted against the proposal.
  • The change was successfully implemented.