Rena V2 Weekly Dev Report #4

With first drafts with most of the V2 upgrades complete, we are focusing on testing and implementation. Let’s recap another significant week of progress on Rena Finance V2!

Weekly Task Summary

• rBalancer contract code
• Tests for rBalancer
• rBonds mechanism
• rDistributor UniV3 version
• rRewarder requirements
• rRewarder contract code

What Was Achieved?

rBalancer

Last week, work on rBalancer was paused due to the balancing issues on different token pairs. After the weekly Dev call, we reached a solution.

Solution:

For the present version, we had to change the requirements per the documentation to make the rebalancing only callable by an admin.

Motivation:

This was done to prevent sandwich attacks during the computation of discounts on the pairs. Such an attack would move the price of a token on uniswap, then trigger the rebalance, which would set the price of this token on the Rena pair to the discounted price, then set the price on uniswap to its previous value.

While being a relatively economical operation for the attacker, it could produce a much higher discount on the Rena pair than the one expected. This attack vector is discarded by making Rena the solely allowed caller of the rebalance function.

Mechanism:

The contract can call an atomic rebalance on pairs officially supported by Rena.

rBalancer purchases liquidity out of the RENA/ETH uniswap pair and distributes it to stakers and treasury. An admin can modify the treasury share.

A cool-down period is required before consecutive calls of the rebalancing function. The cooldown is automatically set to 12 hours but can be modified by an admin.

On August 8th, an additional mechanism is implemented to delay the ETH used to purchase the liquidity by one rebalance call to prevent front-running attacks and other exploits. This mechanism guarantees that only the ETH present in the contract at the last call of the rebalancer will be used to purchase liquidity. This feature is still debatable and could be removed in the future.

Minimal tests have been written to ensure that the rBalancer operates as expected. More testing is being written to ensure resilience to the known liquidity, loans, and arbitrage attacks.

rBond

The first draft is for rBond operational.

It consists of two major modules:

• The first module is the rBond contract. This contract allows to delay the distribution of a token by a set time. Each token can have a different distribution delay fixed by an admin. Any authorized contract can lock any tokens in a Bond assigned to a specific owner. Only the owner of the bond is able to claim the tokens once the Bond expires.
• The second module is a modification of the RenaV2Pair contract. This contract allows the creation of a custom swap function using almost the same code as UniswapV2Pair. In this custom function, the tokens are sent into the rBond contract upon swaps for delayed collection by the user.

With these modifications, any purchase from a RenaV2 pair will mint a Bond for every trade for the buyer, who will be able to claim them after the Bond has expired.

rRewarder

After evaluating the requirements, it appears that this could potentially be forked the rBalancer with very few modifications, if any. The discussion on forking the rRewarded in question is scheduled for the weekly Rena meeting. We will share the details on the call with the next Weekly report (#5).

All the requirements except for rRewarder are complete. These requirements serve as guidelines in writing tests and ensure that all the features required by the contracts are thoroughly tested.

Carryover

Work on the rDistributor moved due to substantial reworking in upcoming weeks. Further work on rRewarded also has been scheduled for upcoming weeks as discussion on the fork continues.

Next week’s target

• Write rDistributor UniV3 version
• rRewarder requirements
• rRewarder contract code
• Write more tests

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