Rena V2 weekly Dev Report #3

This week was intense, mostly dominated with test running, revamping drafts, fixing bugs, and more. Let’s dive in!

Weekly Task Summary

• Validate rDistributor math for safety
• Make rDistributor more non-specific for RenaV2 and UniswapV2 pairs
• Implement Balancer code
• Add rDistributor tests
• Implement rBond mechanism
• Documentation

What Was Achieved?

rDistributor

Extensive automated testing throughout the week revealed balancing issues on different token pairs. We re-wrote ~80% of the original draft with the new code that fixed the issues identified during the test runs. The second draft for rDistributor is complete.

After the Rena dev call on Tuesday 19th of July, it was decided that rDistributor will be implemented in different versions to support more DEXs. The development of a UniswapV3 version was also planned to be developed in the near future.

rBalancer

We paused the work on rBalancer due to concerns over sandwich attacks on the rebalancing function. In its initial implementation, the contract will need to interact with UniswapV2 pairs during the balancing operation (calling rDistributor balancing functionality for each Rena pair).

In this case, the UniswapV2 price could be manipulated before the balancing operations to obtain a higher discount than the Rena pair standard discount over Uni pairs.

The solution is to be discussed during the next Rena dev call.

RenaV2Router

This task has been added during the development process because rBalancer requires advanced trading capabilities on RenaV2 to operate, and the RenaV2Router provides such functionality.

This is more or less the same version as the RenaV1Router. However, implementation was changed to fit more closely to the original UniswapV2Router02 contract code.

Rena pairs are order sensitive as opposed to Uniswap, where a pair Token1/Token2 and a pair Token2/Token1 map to the same pair. In the case of a Rena pair, the second token of the pair is the one turned into rToken using the Wrapper contract. Since most of the code used is inherited from Uniswap, a function “getPair” needs to be overridden to map Token1/Token2 and Token2/Token1 couplings to different pairs addresses.

In our implementation, we forked UniswapV2 to change this specific function of the Uniswap library. This allowed for much less custom code in RenaV2Router. The first draft for the router is complete; until further tests are written, it appears functional.

Documentation

More in-depth analysis of specific parts of the documentation leads to a more detailed listing of contract requirements and test use cases. Some parts of the documentation had to be slightly modified to match implementation choices, such as having the rBalancer also implement the preBalancer functionality.

Carryover

Due to extensive reworking of rDistributor required, rBonds had to be pushed to next week’s tasks.

Next week’s target

• Complete rBalancer contract code
• Write tests for rBalancer
• Implement rBonds mechanism
• Write rDistributor UniV3 version
• rRewarder requirements
• rRewarder contract code

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