When to (un)wrap (un)signed integers

[pimhakkert]

Hi,

A few versions ago I would declare using PRBMathUD60x18 for uint256; so all my uint256 variables would be safe to work with.

Now we are required to wrap a normal uint256 into a UD60x18. My question is, when do I wrap and unwrap the integers? Say a user inputs a uint256 and I need to make calculations based on that, is the following function fine? Should I always return a UD60x18, and if so, will that break anything expecting a uint256?

function calculateTax(uint256 _usdcAmount) public returns(uint256)
{
    UD60x18 _amount = ud(_usdcAmount);

    //7.5%
    UD60x18 _percentage = ud(0.075e18);
    UD60x18 _result =  _amount.mul(_percentage);

    return unwrap(_result);
}

It has become a little more difficult to use this implementation, and I want to make sure I ask this before I break something. Thank you in advance.

[PaulRBerg]

Hi @pimhakkert, thank you for your question.

so all my uint256 variables would be safe to work with

Actually, they weren't safe.

The goal with a fixed-point math library is to emulate decimals with simple integers - this means that non-emulated numbers should NOT be used together with emulated numbers, e.g. you should not take the logarithm of a non-emulated (non-fixed-point) uint256. Though there are exceptions, this is an important rule of thumb that can prevent nasty bugs that are otherwise hard to detect.

My question is, when do I wrap and unwrap the integers?

This is a very broad question that I cannot answer succinctly, I'm afraid. What I can do is recommend you to Solidity's blog post on user defined value types.

Say a user inputs a uint256

User defined value types like UD60x18 are zero cost abstractions over uint256, so you can define the function argument that your user interacts with as UD60x18 (unless the argument is a token amount that has a different number of decimals).

is the following function fine?

I cannot answer this because it depends on what you want to do with the _result. What I can say is that you should be mindful of the number of decimals that USDC has (6 decimals) in case you want to further compose it with other PRBMath functions. If you do want to do that, you should multiply the USDC amount by 10^12. This is what I refer to as the "precision scalar technique", and I have explained it in more detail in this tweet.

It has become a little more difficult to use this implementation

I view this as a feature, not a bug. The purpose is to force you, the user, to implement type safety and draw a line in the sand between your fixed-point and non-fixed-point types. It's a really good thing from a security point of view to be aware that some integers are actually fixed-point types, and have 18 decimals, while others are not (e.g. unix timestamps).

[pimhakkert]

Actually, they weren't safe.

The goal with a fixed-point math library is to emulate decimals with simple integers - this means that non-emulated numbers should NOT be used together with emulated numbers, e.g. you should not take the logarithm of a non-emulated (non-fixed-point) uint256. Though there are exceptions, this is an important rule of thumb that can prevent nasty bugs that are otherwise hard to detect.

That does make sense, yes.

This is a very broad question that I cannot answer succinctly, I'm afraid. What I can do is recommend you to Solidity's blog post on user defined value types.

This helped. I now understand the change in V3.

I cannot answer this because it depends on what you want to do with the _result. What I can say is that you should be mindful of the number of decimals that USDC has (6 decimals) in case you want to further compose it with other PRBMath functions. If you do want to do that, you should multiply the USDC amount by 10^12. This is what I refer to as the "precision scalar technique", and I have explained it in more detail in this tweet.

USDC was perhaps a bad example on my side, but thank you. Nice tweet, by the way.

I view this as a feature, not a bug. The purpose is to force you, the user, to implement type safety and draw a line in the sand between your fixed-point and non-fixed-point types. It's a really good thing from a security point of view to be aware that some integers are actually fixed-point types, and have 18 decimals, while others are not (e.g. unix timestamps).

After reading your answer and the included material I have to say I agree with you.

[PaulRBerg]

Glad to hear that we've cleared up the issue. In hindsight, it seems like my answer was a bit harsh and heavy-handed - I'm sorry for that.

Speaking of tweets, I also recommend skimming through the announcement thread in which I explained the rationale behind V3. This tweet is particularly relevant for our discussion herein.

[pimhakkert]

No worries. I like the move to Foundry, seems logical.