Lines of code
<https://github.com/code-423n4/2023-09-venus/blob/b11d9ef9db8237678567e66759003138f2368d23/contracts/Tokens/Prime/libs/Scores.sol#L22&gt;

Vulnerability details

Impact

In the prime.sol contract, the function _CalculateScore is used to calculate and scale the capital using 1e18 as the SCALE_FACTOR. The capital is then used to call _CalculateScore() in Score.sol to calculate the score. The problem here is that using 1e18 as the scaling factor will give accurate value when using vtokems with 1e18 decimal, but will return different value for other tokens with decimals other than 1e18.
This leads to the Capital being in decimals other than 1e18 which is which may be below or above 1e18. This error can supposedly be averted if the capital is equal to the xvs token.

function _calculateScore(address market, address user) internal returns (uint256) {
        uint256 xvsBalanceForScore = _xvsBalanceForScore(_xvsBalanceOfUser(user));

        IVToken vToken = IVToken(market);
        uint256 borrow = vToken.borrowBalanceStored(user);
        uint256 exchangeRate = vToken.exchangeRateStored();
        uint256 balanceOfAccount = vToken.balanceOf(user);
        uint256 supply = (exchangeRate * balanceOfAccount) / EXP_SCALE;

        address xvsToken = IXVSVault(xvsVault).xvsAddress();
        oracle.updateAssetPrice(xvsToken);
        oracle.updatePrice(market);

        (uint256 capital, , ) = _capitalForScore(xvsBalanceForScore, borrow, supply, market);
        capital = capital * (10 ** (18 - vToken.decimals()));

        return Scores.calculateScore(xvsBalanceForScore, capital, alphaNumerator, alphaDenominator);
    }

When this function, calls the function _CalculateScore in Score.sol there is no check that ensures that the capital is scaled back to 1e18 decimal before using it to calculate the score of users. This leads users recieving more or less scores than they should.

Proof of Concept

Let’s look at this scenario,
Given:
capital = 0.123752854531397362 (18 decimal places). We’ll use the following formula to scale capital to match the vToken’s decimal places:

capital = capital * (10 ** (18 - vToken.decimals()))
~
Assuming that vToken.decimals() also returns 18, the scaling factor would be 
solidity
(10 ** (18 - 18)), 

which simplifies to (10 ** 0), or simply 1. Therefore, you don’t need to change the value of capital since both capital and vToken use the same number of decimal places (18).So, the scaled capital remains the same:
capital = 0.123752854531397362 (18 decimal places). In this case, the capital is correctly scaled and will not result in incorrect calculations.
Consider another senario,
If the vToken has 8 decimal places, and you want to calculate the score based on a capital value that has 18 decimal places. The scaling factor is calculated as:

   scaling factor = 10^(18 - vToken.decimals())
   //In this case, the scaling factor would be:
   scaling factor = 10^(18 - 8) = 10^10

Now, you can use this scaling factor to adjust the capital value:
Given:

    //capital = 0.123752854531397362 (18 decimal places)
     scaling factor = 10^10
    //You can calculate the scaled capital as follows:
     scaled capital = capital * scaling factor
     scaled capital = 0.123752854531397362 * 10^10
     //Now, perform the calculation:
    scaled capital = 1,237,528.54531397362So, 

The scaled capital value, when vToken has 8 decimal places, would be 1,237,528.54531397362. This value is not scaled to the 1e18 and can lead to wrong calculations of the user scores of used in this form.

Tools Used

Manual review

Recommended Mitigation Steps

Ensure that capital is correctly scaled back to 1e18 before using it’s value for calculating the scores. And add a check that ensures that the capital is scaled correctly.

Assessed type

Math

---

The text was updated successfully, but these errors were encountered:

All reactions