Friday afternoon, Revest Finance disbursed the first in a series of 24 payments as part of our Open Beta staking program. The operation was a smooth one, and we were happy to see that single-asset stakers had successfully received payouts. It quickly became apparent that there was a bug with the splitting of staking rewards between single-asset stakers and LP stakers. As outlined in our post on the topic, Revest’s staking system is supposed to split staking rewards 50:50 between single-asset and LP stakers; however, in this instance, 99% of the rewards had been mistakenly distributed to single-asset stakers. We discovered both the cause of the bug. In both writing and testing our code, we had made the implicit assumption that RVST tokens and LP tokens existed at a 1:1 ratio; the testing had also been built under this assumption, resulting in improper weighting of LP’s relative to RVST, and the incorrect distribution of rewards. The code was secure, however it was clear to us that redeployment would be necessary to patch the bug.
To rectify this, we set about re-deploying both the staking contract itself and the rewards handler, copying all data from the original contracts to the new ones. To this end, we constructed a system capable of downloading the data from the blockchain, storing it into a JSON file, and then reading from that file and writing back to the chain on the new contracts. In our system, the staking contract acts as both an address lock and an output receiver; as the already-minted staking FNFTs had their outputs directed to the original staking contract, this field would also need to be updated to allow for proper unstaking operations. To accomplish this, we utilized the novel form of upgradeability that the Revest Protocol has chosen to emulate from AAVE; rather than utilizing upgradeable contracts, a router contract is instead utilized to store the addresses of what is and is not permissioned to interact with components of the Revest Protocol. The entry point to Revest, Revest.sol, has been left deliberately stateless to allow for future expansion; we utilized this upgradeability to deploy a version of Revest.sol that allowed us to remap the effected FNFTs from the original staking contract to the new staking contract. Following the completion of this operation, the original Revest.sol was moved back into place, and operation resumed as normal. An additional disbursal has since taken place and both LP and single-asset stakers are now receiving their fair payouts.
The remaining 88,000 RVST still in the original rewards handler contract will be recovered and recycled into the staking rewards and marketing budgets, gas permitting the reasonable success of such an operation.
To ensure the security of the Revest Protocol during this upgrade process, all operations were carried out by either the Gnosis Multisig or via a single use software wallet created explicitly for the purpose of this task.
For the Revest team, transparency and security are just as important as innovation. We will continue to share any and all information on the goings on of the platform as the Revest ecosystem grows to accommodate an incredible growing roster of partnerships and use-cases.