Rena V2 Weekly Dev Report #8

4 min readSep 14, 2022

It’s been an intense week of code rework and bug fixes for the Rena dev team. With the merge creating new excitement among builders and users alike, we are working on the same tandem and goal to ship the Rena v2 functionalities!

Without further ado, let’s dive in!

Weekly Task Summary:

rBalancer testing
rRewarder testing
RenaV2Pair testing
RenaV2Factory testing
RenaV2Router testing

What was Achieved?

rBalancer

As mentioned in the previous dev report (#7), due to heavy contract code rework on the rBalancer, including the functionality split into: rBalancer, and rRewarder — new requirements (Figure) were identified for testing. This week we focused on testing the 14 requirements (Figure2).

rRewarder

Similar to the rBalancer, requirements were identified for the rRewarder as well. During one of the tests, an issue was observed while using the rRewarder with a RENA/ETH pair.

To understand the issue, let’s first recap the function/role of the rRewarder:

rRewarder is a generic implementation of the LP purchasing and rewards capability of the previous version or rBalancer. The contract allows using any accumulating token instead of ETH, meaning it can be leveraged for non-ETH pairs. Both tokens for the rBond can be customized to target any Uniswap v2 pair. So the rRewarder is a contract used to purchase UniswapV2 pair liquidity periodically and distribute the LP tokens between stakers and the said project’s treasury.

For the rRewarder to function, a token (in our tests wETH) is sent to the contract by the RenaV2 system to accumulate. Once the reward distribution is done, the contract purchases a second token of the pair using 50% of the accumulated token balance (in our case, we purchased Rena for 5 ETH), then we use the remainder of the accumulating token and the whole amount of the purchased token to buy liquidity.

This is where the bug comes up:

When purchasing liquidity, we realized during testing that some RENA token dust remained in the contract, which will result in dust collecting in the contract.

Bug Fix:

To address this issue, the liquidity purchase logic had to be rewritten to ensure that only the accumulating token could remain as the dust.

Later on, a second issue was observed:

The liquidity purchasing logic wasn’t working if the purchased token had fees upon transfer, which was needed while performing the tests with RENA token.

Bug Fix:

We rewrote the liquidity purchase to remove usage of UniswapV2Router since it always adjusted the liquidity by using the second token (in our case wETH) and had no guarantee of consuming the whole amount without leaving dust.

One of the arguments of addLiquidity allowed to set a fixed amount of RENA to be consumed. However, sending RENA through the router collected fees, which meant there was no easy answer to predicting how much RENA would reach the pair in the end (unless it went through fee computations specific to fee-based tokens). Hence, we decided to use the liquidity token minting function in the pair contract itself.

What’s interesting about the solution above?

It’s the fact that first, we send the purchased token to the pairs, then we inspect how much of it is actually reaching the pair, and only then do we proceed with computing how much of the second (accumulating) token should be sent to the pair for accurate minting. When adding liquidity, it is crucial to add a precisely equal amount of matching token weights in both the reserve in the said pair.