Rena V2 weekly dev report #7

For this week, we’ve been working in full-throttle mode, and the sprint was saturated with heavy code rework, modifications, and testing. Let’s dive in.

Weekly Task Summary:

• rBalancer testing
• Rena v2Pair testing
• rStaking testing
• rBalancer code rework/new functionality

What was Achieved?

rStaking

In the previous Rena v2 dev report (#6) we mentioned that out of the 23 identified requirements (Figure 1), 50% were tested. This week we concluded the remaining tests(Figure 2).

Figure 1

Figure 2

rBalancer Contract Code

Heavy code rework on the rBalancer contracts:

A new system requirement on rBalancer triggered a heavy code rework on the contract.

The core idea is to provide the ability to distribute staking rewards in the form of UniswapV2 LPs not only to the Rena rBond but to any rBond. Projects leveraging rBonds will then have the ability to also get a Rewarder system for their stakers and will have to set up their own token accumulation system to allow their rewarder to purchase Uniswap LPs.

Both contracts had to be redefined, and new technical requirements were written to ensure proper implementation and testing.

The new code is ready:

For the updated mechanic, the whole functionality has been split into two contracts:

• rBalancer
• rRewarder

For the first sub-contract, i.e the rBalancer:

What modifications does the new code include?

a. rBalancer will no longer purchase LPs out of the UniswapV2 Rena/ETH pair and has for a single purpose, to call rRewarder and rDistributor lists of contracts within a cooldown period.

b. The other important modification is list handling. Previous rBalancer code used on-chain lists for rDistributors allowing to officially list rBonds created by other projects and trigger rebalancing of all official rBonds during the rebase call. An admin could add and disable distributors to rBalancer, as shown in Figure 3.

Figure 3

During the refactoring process, it was established the on-chain list will no longer be used. Instead, we would simply provide the distributors and rewarders to call as an argument, as shown in Figure 4.

Figure 4

This way the lists can be dynamically managed. The “minimalExpectedLiquidity” function provides slippage arguments to rewarders, thus preventing price manipulation attacks.

c. Last but not least, we also decided not to use the “delay of rebalance of rBonds” function. This step was key in cases where one rBonds rebalance is reverted. All calls have been modified to resist revert, as shown in Figure 5.

Figure 5

We also identified the requirements to test the new code (Figure 6). In total, 14 requirements were identified.

Figure 6

For the second sub-contract, i.e the rRewarder (Uniswap v2 version):

The contract code for rRewarder is ready. This contract 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.

Much like rBalancer, there is a possible cooldown period between reward calls. The call triggers the purchase of LPs from the Uniswap pair and the distribution of LP tokens to treasury and stakers in customizable shares.

More admin roles were created to allow RenaV2 more control over non-Rena-generated rBonds while still allowing projects to control some features of their reward system.

rBalancer instance is supposed to have the ability to override the reward call and trigger it even if the project controlling the rBond chose a different cooldown period. The project can still call the reward function within the bounds of this cooldown period.

The contract also has the ability to automatically wrap and send ETH into wETH, permitting easier usage for rBonds with ETH within the pair.

For the rRewarder, we have identified 30 requirements (Figure 7)

Figure 7

Carry over

rBalancer testing has been moved to next week as new requirements have been identified based on the changes in the contract code. Additionally, work on Renav2Pair has also been pushed to next week due to more work required on the rBalancer.

Next week’s target

• rBalancer testing
• rRewarder testing
• RenaV2Pair testing
• RenaV2Factory testing
• RenaV2Router testing

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