Rena V2 Weekly Dev Report #6

For this week’s sprint, the theme was testing and more testing. Besides the backend, the week was spent preparing for the frontend test environment and targetted decisions regarding V2 upgrades. Let’s dive in.

Weekly Task Summary

• rBonds testing
• rStakingV2 testing
• rBalancer testing
• New test added to the rDistributor
• Frontend integration testing environment

What was Achieved?

rBonds

For the rbond we identified 12 requirements (Figure 1), out of which all 12 were covered for testing(Figure 2).

Figure 1

Figure 2

rStakingV2

Test rStakingV2 (50%)

For rStaking V2, we gathered 23 requirements (Figure3), out of which we have covered more than half for testing.

Figure 3

rDistributor

Recapping the previous Rena Dev report #5 — we gathered 15 requirements for the rDritibutor. Following that, two new requirements and corresponding tests were added to it (Figure4).

Figure 4

Here are some more details about the newly added requirements:

• R16: covers univ3 compatibility check. At the time we chose to use usdc/eth uniswap v3 pair in our unit test. USDC has only 6 digits, which revealed a flaw in the way we computed rDistributor balancing values. More specifically a precision issue due to the reserve of USDC being much lower than the reserve of ETH in the pair.

A fix to the contract was applied:

By changing the operations order, we were able to remove the need for a precision factor, and Uint256 max value is less restrictive in our situation compared to a precision factor. This means multiplying token reserves in the pair won’t create an overflow unless the reserves are significant, which is highly unlikely, even in the worst-case scenario for even 18-digit tokens.

Let’s say, for example, that the pair stores the total supply of 2 18-digit tokens with a max supply of 1B each. This means multiplying those values leads to 10⁹ * 10⁹ *10¹⁸ * 10¹⁸ = 10⁵⁴.

The maximum value stored in a uint256 is (2²⁵⁶-1), which leads to a value greater than 10⁷⁷ (1.1579209e+77). This leaves us with a very comfortable margin, which means that the new algorithm can handle a higher amount of digits per token or higher total supply and should cover 100% of the use cases for RenaV2.

• R17: tests that the contract is feeless for the RENA token, which is an important part of the deployment process.

Frontend integration Testing environment

Based on the pace of technical development, we can begin front-end interaction in a few weeks.

Carry over

Due to modifications required by the rDistributor contract, its testing was pushed back to next week.

Next week’s target

• Test rBalancer
• Test RenaV2Pair

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