Rena V2 Weekly Dev Report #12

The past week has been a lot of problems solving and brainstorming to optimize Rena V2 contracts after another major contract refactoring. Developing a complex system such as RenaV2 often entails potential misalignments as new gears and utilities are added to the system.

For instance, permissionless rBond creation is a significant step towards decentralizing the system and enhancing the overall robustness of the protocol. However, it asks for new changes and adjustments to be made to achieve synergy with other components of the system.

Weekly Task Summary:

• Administration Access Refactoring
• New unit tests

What was Achieved?

Administration Access Refactoring

We have added the latest version of the contract to Rena Draftv2.

With the rBonds, only the rBond owners have the right to add liquidity to a pair. This new rBonds system caused an issue with the RenaV2PoolManager, which was consequently unable to liquidity to the token pairs.

To address this misalignment, we modified the access check to allow the transaction origin as an identity for admin checking. This was the most speedy route to solve the problem. However, the tradeoff to this route is that it exposes the rBond admin to phishing attacks, where a malicious contract executed by the admin could add liquidity to the rBond.

Finding a more efficient and secure solution to this issue is a priority for us, and we’re already looking for a solution. One such approach involves removing the RenaV2PoolManager and adding the liquidity operating tooling into the RenaV2Pair code itself. However, we are about to reach the block limit, and this approach could also make the system undeployable.

Another approach would be to allow the RenaV2PoolManager contract to add liquidity to any RenaV2Pair, and check admin access in the pool manager itself. Unfortunately, it’s not practical to pass the address of the RenaV2PoolManager to the pair to grant access automatically because of the order of deployment of these contracts.

As a result of the refactoring, rBond creators are the owners of both RenaV2Pair and rDistributor and can call admin functions. They can choose to balance their rBond themselves or set up an allowance for Rena to call the balancing function on their behalf without relinquishing their other admin rights.

Rewarders calls are still the same as in Draftsv1 and need to be called with the correct slippage arguments, and we’re looking into ways to streamline the process, as the next task is the Rewarder contract.

New unit tests

A total of 12 unit tests were written to cover the new administration system, and 37 existing tests were removed. All tests are passing successfully.

Next week’s tasks

• Allow the rewarder to use custom staking contracts.
• Check the possibility of using UniswapV3 LP Rewards.

Thank you for reading our Rena V2 report! We’ll be back next week for another update for week #13.🙌