I’m submitting this technical proposal for the changes in the proposal to launch an enhanced version of the RIF on Chain Protocol, which aims to integrate into the protocol a range of innovative features designed to enhance security measures and pave the way for reaching new milestones.
Implementation
To implement this enhancement, we crafted new smart contracts to seamlessly integrate many features from the existing protocol but also introduce innovative functionalities and bolstered security measures.
some technical/coding knowledge is necessary to fully understand this document.
The upgrade will introduce:
- Lower fees
- Joint issuance and redemption of USDRIF and RIFPRO
- Swap operations of USDRIFs for RIFPROs, and RIFPROs for USDRIFs
- The Queue
- The removal of the RIFX token
- Simplified settlement functions
- Vendor integration made easier
If this proposal is approved and applied, it will no longer be possible to operate on the actual version of the protocol. The current state of the protocol will transition to this upgraded version seamlessly, ensuring full transparency for the community to enjoy the benefits
The IPFS web dApp will be updated with the new RIF On Chain Protocol version. We took the opportunity not only to incorporate the new features but also to enhance the user experience.
Lower fees
Overcoming the 24 KB size limit restriction posed a challenge, yet the reduction in gas fees is attributed to the consolidation of logic into a handful of smart contracts, as opposed to a multitude of them in V1. Please check, the comparative graph in the community proposal
Joint issuance and redemption of USDRIF and RIFPRO
This new feature allows for the simultaneous issuance and redemption of USDRIF and RIFPRO tokens. It ensures smooth transactions while maintaining the global coverage of the RIF on Chain protocol. To mint USDRIF or redeem RIFPRO, the system’s coverage must exceed the target of 5.5. If coverage dips close to or below 5.5, users can still mint USDRIF or redeem RIFPRO using the joint issuance and redemption feature. The main advantage with these new operations is that mints and redeems are done in equivalent proportions so that its price and global coverage are not modified.
Depending on which operation the user is executing, if the amount is not enough, the transaction is reverted.
To see full detailed code, check it here.
To see full detailed code, check it here.
For more details, please refer to RIF On Chain Technical White Paper v2.1 section Joint issuance and redemption of TPs and TCs
Swap operations of USDRIFs for RIFPROs, and RIFPROs for USDRIFs
The feature will enhance the RIF on Chain usability by combining 2 transactions into one and therefore allowing the user to save gas and protocol fees. For instance, the swap operation of exchanging RIFPRO for USDRIF is equivalent to redeeming an amount of RIFPRO and subsequently utilising that RIF to mint USDRIF. In the previous version of the protocol (V1), users were required to execute two separate transactions and incur gas and protocol fees for each. With this enhancement, users only need to pay for a single transaction.
Here is the Swap operation of USDRIFs for RIFPROs:
To see full detailed code, check it here.
Here is the Swap operation for RIFPROs for USDRIFs:
To see full detailed code, check it here.
For more details, please refer to RIF On Chain Technical White Paper v2.1 section Swaps
The Queue
The transaction Queue is a mechanism that lifts the price Oracle demands to a high-frequency price to ensure enhanced protection of the protocol. In its essence, the transaction Queue is a smart contract that allows the collateral bag to queue orders for their execution after a certain period of time. When the user enters a transaction, it is sent to the queue. The user will be required to pay gas fee for the new queued transaction. Once the transaction enters the queue, cancellation is not permitted, and the funds become locked. The queued transaction could be executed by any address ensuring decentralization. Once the execution starts, the queue sends blocks of queued transactions to the collateral bag for execution. The collateral bag will report 1 by 1 if it was successful or failed, and if it fails, the locked funds will be returned to the owner.
With the inclusion of the Queue, there is no longer a need to adhere to the suggestions outlined in the forum proposal Enhancing Transaction Cost Management for Users with Ethereum-based Gas Price Settings
For more details, please refer to RIF On Chain Technical White Paper v2.1 section Queue
Here is the Queue logic:
To see full detailed code, check it here.
Here are a few examples of how transactions are queued:
To see full detailed code, check it here.
The removal of the RIFX token
RIFX are 2X+ leveraged positions, which were disabled following a decision of the RIF on Chain and Money on Chain community last year. However, part of the code remained in the protocol. In this proposed version, the RIFX feature will be removed from the code entirely to improve the purity of the model. In the future, such financial features should be built into a layer outside and above the protocol.
Simplified settlement functions
To see full detailed code, check it here
As you can see in the image, the settlement function is just a few lines of code now, and it only invokes the _distributeSuccessFee(). If you check the next image, you will appreciate that this feature is disabled for RIF On Chain protocol.
To see full detailed code, check it here.
Vendor integration made easier
To check more details on this subject please refer to RoC V2 migration plan - Integrators technical documentation
Commission Splitter enhancement:
In Rif On Chain V1, we operated with two distinct Commission Splitters:
- CommissionSplitterV2
- Its primary function is to gather operation fees, accumulating them until triggered by the “split” function, where it then distributes the entire accumulated balance of MOC and RIF to two specified addresses and the Rif On Chain V1 contract.
- CommissionSplitterV3
- Its primary function is to gather weekly interest from RIFPRO holders in RIF, accumulating them until triggered by the “split” function, where it then distributes the entire accumulated balance of RIF to two specified addresses
Recognizing the redundancy and potential for inefficiency in maintaining separate codes, we made a significant enhancement by consolidating them into a unified CommissionSplitter. This consolidation offers multiple benefits. Firstly, it enables the new CommissionSplitter to seamlessly process MOC transactions, a functionality previously exclusive to CommissionSplitterV3, thereby preventing the need for additional pull requests and voting procedures in case of errors.
Moreover, we introduced a fee retainer mechanism, optimizing RIF token handling by retaining the RIF tokens in real-time during each operation, eliminating the need to wait for split moments.
Fee retainer is set to 25% for Rif on Chain protocol:
To see full detailed code, check it here.
Allow Different Recipient parameter
All nine operation types now offer the option to either send tokens to the same account that executed the operation or to a different account.
A new parameter (allowDifferentRecipient) has been introduced to control this functionality. When set to true it enables the ability to send tokens to a different account. However, for security reasons, in the case of RIF on Chain Protocol, this parameter will remain permanently deactivated, ensuring that operations can only be performed within the user’s own account.
To see full detailed code, check it here
If you check the next image, you will appreciate that this feature is disabled for RIF On Chain protocol.
To see full detailed code, check it here.
This is the new release to add these changes to the stable-protocol-core-v2 repository.
This is the new release to add these changes to the stable-protocol-roc-v2 repository.
This is the pull request to add these changes to the rdoc-contract repository.
The new proxy contract for the MoCCore.sol already deployed in mainnet will be this 0xA27024Ed70035E46dba712609fc2Afa1c97aA36A
The new expansion contract MoCCoreExpansion.sol already deployed in mainnet will be this 0x86C6CEde6A2355BDcCF410905E486b33D82a84ce
The new contract for the MoCQueue.sol already deployed in mainnet will be this 0x9181E99dceace7dFd5f2E7d5126275D54067A9E3
The new contract for the MoCVendors.sol already deployed in mainnet will be this 0x5F69df7e853686a794c13be029FF228642C07012
Migration Process
To enable the migration, some upgrades were indeed performed on RIF On Chain V1 protocol, ultimately resulting in all functional contracts being “disabled” to avoid confusion.
The migration essentially happens in two major steps:
- RoC v2 initialization
- Changer execution
To get full details on these steps, please refer to RoC V1 to V2 migration overview section Technical Migration Procedure
Here is the changer migration logic:
Here are the steps before and after the migration logic is executed:
Here are the details on the MOC_Migrator:
And the MoCExchange_Migrator logic:
And here is the Deprecated logic:
The change contract to make the implementation change already deployed in mainnet would be this 0x12f1bf1aa1e3673d9fc073c8bd09817c9f2b717a
The RIF on Chain protocol has undergone a thorough independent evaluation of the protocol’s codebase and security measures by an independent Auditor, Kudelski Security. The primary goal was to identify any vulnerabilities and potential exploits. The Auditor evaluation has found only “low risk” and “no significant risk” issues. The full audit reports can be accessed here and here.
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 RootstockLabs & mimLABS teams)
Call to MOC holders: