Rena V2 Weekly Dev Report #11

In the previous report, we shared with you the new Rena V2 development cycle. We started executing the plan starting with two highly complex and extensive tasks. Due to the enormity of these two tasks, our usual weekly sprint was extended into a two-week sprint. Hence the report shares updates from 26 September to 7th October.

Weekly Task Summary:

• Permissionless rBond creation
• Refactor administration access

What was Achieved?

Permissionless rBond creation

Permissionless rBond creation enables anyone to create their own rBond. To achieve permissionless rBonds our tasks consisted of deploying.

• RenaV2Pair, and;
• rDistributor contracts with proper admin access for the rBond creator

This was achieved during the major refactoring of RenaV2 drafts V1 contracts. Key changes include rBond, which is no longer a singleton contract operating with all RenaV2Pairs but has been simplified and is now deployed and owned by the RenaV2Pair contract itself.

What benefits does this mechanism bring to users?

It ensures that the locking mechanism of rBond tokens is controlled by the RenaV2Pair, and thus can be configured by the rBond owner only. It also decreases the complexity of setting up proper admin access and mitigates potential attacks on the rBond contract. Additionally, rBond creators can now control token locking duration, rebalance frequency, wrapped tokens destination, and the targeted discount.

Another major change is that the rBond creator can now switch between targeting the Uniswap V2 or Uniswap v3 pair using a single function call. The function has the ability to find Uniswap pairs automatically, thus resulting in a more secure approach than allowing the user to directly provide the address of a Uniswap pair, which can potentially bind the rBond with a malicious contract or an invalid pair.

Several existing unit tests were required to be rewritten due to the new nature of the rBond contract.

rDistributor contract is now automatically deployed for every RenaV2Pair and is also configured with proper admin access rights.

Refactor administration access (80% complete)

As was previously seen with the rBalancer refactoring round from Dev Report #7, the Rena V1 administration system was extremely complex and was not sufficiently configurable for a permissionless protocol. As a result, extensive refactoring had to be done to handle administration over liquidity providing into a rBond.

A major change was the removal of RenaV2Wrapper, which subsequently led to the removal of the main attack point identified during the development of the v1 draft.

The functionality of wrapping the second token of the rBond is now embedded within the RenaV2Pair contract code. To achieve this, UniswapV2 inheritance was severed, and the contract was upgraded to the latest solidity version. This thus unlocked the ability to remove potentially threatening “wrapping” admin access rights on RenaV2Wrapper, which were set for every rBond, thus ensuring that a rBond can’t be exploited to attack other rBonds. Creating both the wrapper and locking a part of the RenaV2Pair functionality opened up a much easier permissionless setup while also severing any admin links between rBonds, thus isolating risks.

Another major change is the removal of RenaV2Router, which is now split between 2 contracts:

• RenaV2PoolManager
• RenaV2SwapHelper

RenaV2Pool manager facilitates the addition and removal of liquidity for the rBond owner, while RenaV2SwapHelper is the main interaction contract for users to purchase tokens from rBonds.

A large number of tests had to be rewritten to match the important changes. Additionally, RenaV2Wrapper unit tests have been removed.

Next week’s target

• Complete refactoring administration access
• Write new unit tests

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