Rena V2 Weekly Dev Report #2

The past week has been full throttle towards V2 upgrades. This week’s task summary focused on setting the primary objectives of our codes for the Rena V2 upgrade. Let’s take a breather and check out what we achieved from the summary so far👇

Weekly Task Summary:

• rStakingV2 draft
• RenaV2Pair draft
• RenaV2Wrapper draft
• RenaVFactory draft
• Migration stakingV1 => stakingV2 draft
• rDistributor draft

What Was Achieved?

rStakingV2

The first draft for rStaking V2 is complete. The contract is using a “shares-based” staking mechanism to compute user rewards.

Here’s how it works out:

At the time of initialization, we set a base price for the shares, when a user enters the pool, shares are purchased with the staking token based on their current price, and the purchase price is recorded for the user.

Share price changes when rewards are distributed. The computation looks like this:

When a user unstakes from the pool, their rewards are computed like this:

Next up,

To implement the boosting mechanism based on locking duration, every stake has a unique ID which must be referred to upon unstaking. The amount of shares purchased is multiplied by a ratio computed out of a linear function based on the locking duration selected by the user. Based on how rewards are computed, the user who holds more shares will have higher rewards.

The maximum locking period is set to 1 year by default and can be adjusted via the contract admin.

rStaking V2 contract implements the standard IERC900 staking interface. Why the IERC900 standard? Because such an interface allows for every function the usage of additional bytes as arguments for custom operations. Locking duration from within has been encoded with ABI (Application Binary Interface).

RenaV2Pair

The first draft for RenaV2Pair is complete. It reuses the code from RenaV1Pair. However, instead of using the custom Rena version of UniswapV2 with the upgraded solidity version, we decided to use the original UniswapV2 code.

RenaV2Wrapper

We have completed the first draft for RenaV2Wrapper as well. Similar to the RenaV2Pair, It reuses the code from the original RenaV1 wrapper. The Ownable mechanism implemented in the original version is replaced with AccessControl from OpenZeppelin. This allows us to implement multiple admin roles within the same contract. A token burning system is also implemented to allow balancers to burn rTokens out of pairs during balancing.

RenaV2Factory

RenaV2Factory is also ready for the next phase as the first draft is ready. The RenaV2Factory also reuses the code from the original RenaV1Factory.

Migration

This contract handles the migration of lpStaking (staking v1) tokens into rStakingV2 (staking v2) contract that RenaV2 will be using. lpStaking allows users to stake UniswapV2 RENA/ETH LP tokens.

Here’s how the migration system works:

• The migration system withdraws the user stake while leaving the rewards (RENA) in place.
• Then, the user liquidity is removed from the UniswapV2 RENA/ETH pair, and ETH is swapped for RENA from the pair.
• The resulting RENA amount is then staked for the user on rStakingV2.

The migration function allows for implementing a locking period.

Slippage and deadline parameters are also implemented within the migration call to prevent attacks during the migration operation. These arguments shall be computed by the frontend the same as on Uniswap dApp.

We have also added a simple test to ensure that the migration works optimally. The test runs on a fork of the mainnet to be as close as possible to the real conditions.

rDistributor

rDistrbutor draft is also complete. This version only works for the RENA/ETH and RENA/rETH pairs.

When called by the Balancer, the contract checks whether the RENA token price is higher on the RenaV2 pair compared to the UniswapV2 pair. In case the price is indeed higher then, rETH is burned from the RenaV2 pair to balance the prices between RenaV2 and UniswapV2.

A second operation uses RENA tokens stored within the rDistributor to add to the liquidity to harvest the targeted discount.

The contract has an admin-managed variable that allows it to change the target reward. We have also added a few tests to ensure optimal performance of the contract’s basic functionality.

Further testing and observation are required to ensure that the math used for computations is safe for all types of tokens with different amounts of digits.

Organization and planning

All working branches have been merged within the same one as interoperation between the modules are required during testing.

A dev call was organized on July, Friday 15th to discuss design choices and documentation.

The development trajectory has been validated.

Next week’s target

Here’s what we’ll discuss in Rena Dev Report #3:

• Make rDistributor more generic for RenaV2 and UniswapV2 pairs
• Make sure rDistributor math is safe
• Implement Balancer code
• Add rDistributor tests
• Implement rBond mechanism
• Update requirements to match technical choices

V2 has been a project long in the making for us, and we are so excited to be finally able to showcase our brainchild to the world. Thanks for all your invaluable support, and as usual, stay tuned for more v2 updates!