Implement higher precision type UD51x27

[Keinberger]

Hey everyone 👋

@PaulRBerg, I read through your previous post on increasing intermediary precision in log2 and exp2 to avoid the limitations of UD60x18 and SD59x18, and I completely agree with the need for better precision handling in these kinds of operations.

Your suggestion to improve intermediary precision makes a lot of sense, especially in the context of operations that involve inverses and other complex math where losing precision early can lead to significant inaccuracies.

However, I believe we should take it a step further and consider implementing a publicly usable higher-precision type, such as UD51x27. This would serve not only to improve intermediary computation precision within the library, but also allow external users to benefit from that same level of precision — particularly in two key scenarios:

1. Chained Mathematical Operations

1. Chained Mathematical Operations

In DeFi and other smart contract applications, it's common to perform multiple multiplications and divisions in a single formula or pipeline. When using fixed-point math like UD60x18, each mulDiv truncates precision to 18 decimals. As a result, the loss compounds and the end result can deviate from what it should be, especially when dealing with small values like percentages, interest rates or per-second / per-block values.

To better illustrate, here’s an example of a chained operation using PRBMath:

uint256 result = ud(x).mul(ud(y)).mul(ud(z)).div(ud(a)).intoUint256();

Note: After each function call, the result is scaled back to 18 decimals. In essence, there are no intermediary values that exceed that decimal format ⇒ PRBMath cannot preserve higher intermediary precision.

A higher-precision type like UD51x27 would allow for significantly reduced imprecision in these cases.

2. Storing High-Precision Values in Storage

2. Storing High-Precision Values in Storage

Chained operations may not always be done in a single memory computation. Especially in DeFi protocols, where devs often store intermediate values (like growth factors, interest rates, or debt indices) in contract storage to be used in later computations.

With the current UD60x18 format, precision can be lost during this storage round-trip, particularly for values that accumulate over time, such as per-second interest rates or yield multipliers.

Having a UD51x27 storage-compatible type would allow protocols to store and later retrieve precise values without degrading accuracy over time. This is critical in long-lived financial applications, where subtle inaccuracies can lead to measurable discrepancies over time.

👉 For the reasons outlined above, some major players in DeFi (Aave, MakerDAO, Uniswap, etc…) are using higher precision types. I personally think the addition of higher precision types to PRBMath would be incredibly useful. I’m bringing this up due to personal issues that I have experienced with being constrained to 18 decimal precision while using PRBMath.

Proposed Solution & Contribution Offer

Proposed Solution

• New folder named “ud51x27” inside of the “src” directory, with files mirroring UD60x18 structure
• New general src/UD51x27.sol file that imports from all the files from the folder
• Add new casting functions to existing types (for casting to UD60x27) and general casting utils (src/casting)
• Core piece inside of ud51x27/Math.sol file, where we have to redo most of the functions and ensure compatibility. Major changes are required at the mul/div functions, as well as the logarithmic and exponential functions.

Contribution Offer

I’d be happy to:

• Implement the above described logic
• Share a full proof of concept
• Coordinate with you @PaulRBerg and other contributors for review/feedback.

Open Questions

• Should we implement a signed variant right away (SD50x27)? Are there strong use cases requiring signed high-precision values?
• Do you, @PaulRBerg , have any preference in regards to file names / file structures?
• Should this feature, if approved, be integrated into PRBMath v5?