Forte: Float128 Solidity Library
Findings & Analysis Report

2025-04-29

Overview
- About C4
Summary
Scope
Severity Criteria
High Risk Findings (5)
Medium Risk Findings (1)
- [M-01] Inconsistent mantissa size auto-scaling between packedFloat encoding and calculations will lead to unacceptable rounding errors
Low Risk and Non-Critical Issues
Disclosures

Overview

About C4

Code4rena (C4) is a competitive audit platform where security researchers, referred to as Wardens, review, audit, and analyze codebases for security vulnerabilities in exchange for bounties provided by sponsoring projects.

A C4 audit is an event in which community participants, referred to as Wardens, review, audit, or analyze smart contract logic in exchange for a bounty provided by sponsoring projects.

During the audit outlined in this document, C4 conducted an analysis of the Forte: Float128 Solidity Library smart contract system. The audit took place from April 01 to April 11, 2025.

Final report assembled by Code4rena.

Summary

The C4 analysis yielded an aggregated total of 6 unique vulnerabilities. Of these vulnerabilities, 5 received a risk rating in the category of HIGH severity and 1 received a risk rating in the category of MEDIUM severity.

Additionally, C4 analysis included 7 reports detailing issues with a risk rating of LOW severity or non-critical.

All of the issues presented here are linked back to their original finding, which may include relevant context from the judge and Forte team.

Scope

The code under review can be found within the C4 Forte: Float128 Solidity Library repository, and is composed of 3 smart contracts written in the Solidity programming language and includes 1530 lines of Solidity code.

Severity Criteria

C4 assesses the severity of disclosed vulnerabilities based on three primary risk categories: high, medium, and low/non-critical.

High-level considerations for vulnerabilities span the following key areas when conducting assessments:

Malicious Input Handling
Escalation of privileges
Arithmetic
Gas use

For more information regarding the severity criteria referenced throughout the submission review process, please refer to the documentation provided on the C4 website, specifically our section on Severity Categorization.

High Risk Findings (5)

[H-01] Early 72-digit adjustment in sqrt will lead to incorrect result exponent calculation

Submitted by montecristo, also found by 0xcrazyboy999, boredpukar, CoheeYang, Franfran, HappyTop0603, MysteryAuditor, PabloPerez, v2110, and zzebra83

The vulnerability resides in sqrt function. For sufficiently large numbers, sqrt function utilizes Uint512 library to calculate mantissa part (rMan) of sqrt of a given number.

File: 2025-04-forte/src/Float128.sol:

719: if (
720:             (aL && aExp > int(ZERO_OFFSET) - int(DIGIT_DIFF_L_M - 1)) ||
721:             (!aL && aExp > int(ZERO_OFFSET) - int(MAX_DIGITS_M / 2 - 1))
722:         ) {
723:             if (!aL) {
724:                 aMan *= BASE_TO_THE_DIGIT_DIFF;
725:                 aExp -= int(DIGIT_DIFF_L_M);
726:             }
727: 
728:             aExp -= int(ZERO_OFFSET);
729:             if (aExp % 2 != 0) {
730:                 aMan *= BASE;
731:                 --aExp;
732:             }
733:@>           (uint a0, uint a1) = Uint512.mul256x256(aMan, BASE_TO_THE_MAX_DIGITS_L);
734:             uint rMan = Uint512.sqrt512(a0, a1);

Exponent part (rExp) is basically rExp = aExp / 2, except there are minor adjustment to set mantissa part to have exactly 38 or 72 digits:

File: 2025-04-forte/src/Float128.sol:

735: int rExp = aExp - int(MAX_DIGITS_L);
736:             bool Lresult = true;
737:             unchecked {
738:@>               if (rMan > MAX_L_DIGIT_NUMBER) {
739:@>                   rMan /= BASE;
740:@>                   ++rExp;
741:@>               }
742:@>               rExp = (rExp) / 2;
743:                 if (rExp <= MAXIMUM_EXPONENT - int(DIGIT_DIFF_L_M)) {
744:                     rMan /= BASE_TO_THE_DIGIT_DIFF;
745:                     rExp += int(DIGIT_DIFF_L_M);
746:                     Lresult = false;
747:                 }
748:                 rExp += int(ZERO_OFFSET);
749:             }

L738-L741 does the following thing:

If rMan has 73 digits (L738), adjust to it to have 72 digits and increment rExp by 1.

L742 does the following thing:

Divide rExp by 2 because exponent is halved by sqrt operation.

The problem is:

Halving (L742) should take place before the digit adjustment (L738-L741).

To help understanding, we’ll investigate in depth in POC section with a concrete example.

Notice that the second part of sqrt function, where sqrt is calculated without using Uint512 library, halving takes place before adjustment, so no such vulnerability is observed.

Impact

The result exponent will be wrong (off-by-one), which will lead to blatantly wrong calculation result.

Recommended mitigation steps

The following diff will fix the issue:

diff --git a/src/Float128.sol b/src/Float128.sol
index 7637d83..a8dbb2e 100644
--- a/src/Float128.sol
+++ b/src/Float128.sol
@@ -735,11 +735,11 @@ library Float128 {
             int rExp = aExp - int(MAX_DIGITS_L);
             bool Lresult = true;
             unchecked {
+                rExp = (rExp) / 2;
                 if (rMan > MAX_L_DIGIT_NUMBER) {
                     rMan /= BASE;
                     ++rExp;
                 }
-                rExp = (rExp) / 2;
                 if (rExp <= MAXIMUM_EXPONENT - int(DIGIT_DIFF_L_M)) {
                     rMan /= BASE_TO_THE_DIGIT_DIFF;
                     rExp += int(DIGIT_DIFF_L_M);

Proof of Concept

Scenario:

We consider a packedFloat float with 72-digits, which is equivalent to 3.82e2338 in real number
We will calculate sqrt(float) = result using Float128 library
Expected result is approx. 1.95e1169
However, actual result is approx. 1.95e1168 due to vulnerability
We verify actual result is wrong by calculating float / (result * result)
- If the result is correct, this should be around 1
- However, the verification returns a number > 99
- This means rExp is calculated incorrectly (off-by-one) due to reported vulnerability

Put the following content in test/poc.t.sol and run forge test --match-test testH01POC -vvv

pragma solidity ^0.8.24;

import "forge-std/Test.sol";
import "src/Float128.sol";
import {Ln} from "src/Ln.sol";
import {Math} from "src/Math.sol";
import {packedFloat} from "src/Types.sol";

contract ForteTest is Test {
    using Float128 for packedFloat;

    function testH01POC() external {
        int256 mantissa = 382000000000000000000000000000000000000000000000000000000000000000000000;
        int256 exponent = 2267;
        // float = 3.82e2338
        packedFloat float = Float128.toPackedFloat(mantissa, exponent);
        // expected result = 1.95e1169
        packedFloat result = float.sqrt();
        // actual result = 1.95e1168
        _debug("result", result);
        // float / (result * result) > 99
        assertTrue(float.div(result.mul(result)).gt(Float128.toPackedFloat(99, 0)));
    }

    function _debug(string memory message, packedFloat float) internal {
        console.log(message);
        _debug(float);
    }

    function _debug(packedFloat float) internal {
        (int256 mantissa, int256 exponent) = float.decode();
        emit log_named_uint("\tunwrapped", packedFloat.unwrap(float));
        emit log_named_int("\tmantissa", mantissa);
        emit log_named_uint(
            "\tmantissa digits", Float128.findNumberOfDigits(packedFloat.unwrap(float) & Float128.MANTISSA_MASK)
        );
        emit log_named_int("\texponent", exponent);
    }
}

Deep dive:

In L734, rMan is sqrt(3.82e72 * 1e71), and Uint512 library returns a number with 73 digits
In L735, rExp is aExp - 72 = 2266 - 72 = 2194
At this point, rMan and rExp / 2 are correct result of sqrt
- rExp / 2 = 2194 / 2 = 1097
- rMan is 73 digits number
- So result will be something like 1.95e1098
However, since rMan has 73 digits, library tries to trim it to 72 digits in L738~L741
- rMan /= 10
- rExp = (rExp + 1) = 2195
rExp is halved in L742 to get final exponent:
- rExp = 2195 / 2 = 1097

After trimming, rMan is divided by 10 but rExp remains 1097, the same number before trimming. The final exponent will be off by one.

oscarserna (Forte) confirmed

[H-02] Sqrt function silently reverts the entire control flow when a packed float of 0 value is passed

Submitted by YouCrossTheLineAlfie, also found by 0x23r0, 0xbrett8571, 0xpetern, Akxai, bareli, CodexBugmenot, Dest1ny_rs, djshan_eden, felconsec, Franfran, Illoy-Scizceneghposter, JuggerNaut63, maxzuvex, maze, micklondonjr, rmrf480, Tezei, TheCarrot, and who_rp

https://github.com/code-423n4/2025-04-forte/blob/4d6694f68e80543885da78666e38c0dc7052d992/src/Float128.sol#L712

Finding description

The Float128::sqrt function is used to find the square root of the given packed float.

Mathematically, intuitively and as per most other libraries in different programming languages, it is ideal to say that square root of 0 should return 0.

However, the implementation of sqrt function stops the executing when the give packed float is 0 via stop().

    function sqrt(packedFloat a) internal pure returns (packedFloat r) {
        uint s;
        int aExp;
        uint x;
        uint aMan;
        uint256 roundedDownResult;
        bool aL;
        assembly {
            if and(a, MANTISSA_SIGN_MASK) {
                let ptr := mload(0x40) // Get free memory pointer
                mstore(ptr, 0x08c379a000000000000000000000000000000000000000000000000000000000) // Selector for method Error(string)
                mstore(add(ptr, 0x04), 0x20) // String offset
                mstore(add(ptr, 0x24), 32) // Revert reason length
                mstore(add(ptr, 0x44), "float128: squareroot of negative")
                revert(ptr, 0x64) // Revert data length is 4 bytes for selector and 3 slots of 0x20 bytes
            }
            if iszero(a) {
                stop()          <<@ -- // Stops the execution flow entirely
            }

This can lead to serious issues where the code execution just stops mid-way silently reverting the control flow.

Impact

Serious financial consequences can happen in protocols using this library as the entire code execution reverts due to the stop().

Recommended mitigation steps

It is recommended to return 0 instead of using the stop():

    function sqrt(packedFloat a) internal pure returns (packedFloat r) {
        uint s;
        int aExp;
        uint x;
        uint aMan;
        uint256 roundedDownResult;
        bool aL;
        assembly {
            if and(a, MANTISSA_SIGN_MASK) {
                let ptr := mload(0x40) // Get free memory pointer
                mstore(ptr, 0x08c379a000000000000000000000000000000000000000000000000000000000) // Selector for method Error(string)
                mstore(add(ptr, 0x04), 0x20) // String offset
                mstore(add(ptr, 0x24), 32) // Revert reason length
                mstore(add(ptr, 0x44), "float128: squareroot of negative")
                revert(ptr, 0x64) // Revert data length is 4 bytes for selector and 3 slots of 0x20 bytes
            }
            if iszero(a) {
-                stop()
+                r := 0
+                leave
            }

Proof of Concept

Add a file named test.t.sol inside the /test folder:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

import "forge-std/Test.sol";
import "forge-std/console2.sol";
import "src/Float128.sol";

contract TestingContract is Test {
    using Float128 for packedFloat;
    using Float128 for int256;

function testSqrtSilentRevert() public {
        console2.log("Test started");
        
        // First test with a non-zero value to show normal behavior
        packedFloat nonZero = Float128.toPackedFloat(1, 0);
        packedFloat nonZeroResult = Float128.sqrt(nonZero);
        console2.log("Non-zero sqrt completed");
        
        packedFloat zero = Float128.toPackedFloat(0, 0);

        // Should silently revert as per the solidity's yul docs.
        packedFloat zeroResult = Float128.sqrt(zero);

        console.log("Zero sqrt completed" ); // Never printed
        assertEq(false, true, "This will never terminate as the control never reaches here due to silent termination"); // Test would pass successfully which it shouldn't have had.
    }

}

oscarserna (Forte) confirmed

[H-03] Natural logarithm function silently accepts invalid non-positive inputs

Submitted by ChainSentry, also found by 0x23r0, ahmetwkulekci, Albert, Bz, CodexBugmenot, CodexBugmenot, djshan_eden, dreamcoder, Egbe, FigarlandGarling, Franfran, gmh5225, gregom, hoossayn, jerry0422, JuggerNaut63, komronkh, MalfurionWhitehat, MartinGermanConsulate, MATIC68, maxzuvex, maze, micklondonjr, montecristo, Orhukl, osuolale, Shinobi, soloking, theboiledcorn, X-Tray03, ZOL, and zzebra83

https://github.com/code-423n4/2025-04-forte/blob/4d6694f68e80543885da78666e38c0dc7052d992/src/Ln.sol#L63-L77

Summary

The natural logarithm function (ln()) in the Ln.sol contract accepts negative numbers and zero as inputs without any validation, despite these inputs being mathematically invalid for logarithmic operations. In mathematics, the natural logarithm is strictly defined only for positive real numbers. When a negative number or zero is passed to the ln() function, it silently produces mathematically impossible results instead of reverting.

This vulnerability directly contradicts fundamental mathematical principles that the Float128 library should uphold. The Float128 library documentation emphasizes precision and mathematical accuracy, stating that “Natural Logarithm (ln)” is among its available operations. Yet the implementation fails to enforce the basic domain constraints of the logarithm function.

The lack of input validation means any system relying on this library for financial calculations, scientific modeling, or any mathematical operations involving logarithms will silently receive nonsensical results when given invalid inputs. This undermines the entire trustworthiness of the library’s mathematical foundations.

Vulnerability details

The ln() function in Ln.sol extracts the components of the input number (mantissa, exponent, and flags) but never checks if the input is positive before proceeding with calculations:

    function ln(packedFloat input) public pure returns (packedFloat result) {
        uint mantissa;
        int exponent;
        bool inputL;
        assembly {
            inputL := gt(and(input, MANTISSA_L_FLAG_MASK), 0)
            mantissa := and(input, MANTISSA_MASK)
            exponent := sub(shr(EXPONENT_BIT, and(input, EXPONENT_MASK)), ZERO_OFFSET)
        }
        if (
            exponent == 0 - int(inputL ? Float128.MAX_DIGITS_L_MINUS_1 : Float128.MAX_DIGITS_M_MINUS_1) &&
            mantissa == (inputL ? Float128.MIN_L_DIGIT_NUMBER : Float128.MIN_M_DIGIT_NUMBER)
        ) return packedFloat.wrap(0);
        result = ln_helper(mantissa, exponent, inputL);
    }

The function extracts the mantissa but ignores the MANTISSA_SIGN_MASK (bit 240), which indicates whether the number is negative. The subsequent calculations use this unsigned mantissa value, essentially computing ln(|input|) rather than ln(input). When the input is negative, this produces mathematically meaningless results.

To demonstrate this vulnerability, I created two test cases:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

import "forge-std/Test.sol";
import "forge-std/console2.sol";
import "src/Float128.sol";
import "src/Ln.sol";
import "src/Types.sol";

contract LnVulnerabilityTest is Test {
    using Float128 for int256;
    using Float128 for packedFloat;
    
    function testLnWithNegativeInput() public {
        // Create a negative number (e.g., -2.0)
        int mantissa = -2 * 10**37; // Scale to match normalization requirements
        int exponent = -37;  // Adjust for normalization
        
        // Convert to packedFloat
        packedFloat negativeInput = Float128.toPackedFloat(mantissa, exponent);
        
        // Verify it's negative
        (int extractedMantissa, int extractedExponent) = Float128.decode(negativeInput);
        console.log("Input mantissa:", extractedMantissa);
        console.log("Input exponent:", extractedExponent);
        console.log("Input is negative:", extractedMantissa < 0);
        
        // Call ln() with negative input - this should be mathematically invalid
        // but the function doesn't validate and will return a result
        packedFloat result = Ln.ln(negativeInput);
        
        // Output the result
        (int resultMantissa, int resultExponent) = Float128.decode(result);
        console.log("Result mantissa:", resultMantissa);
        console.log("Result exponent:", resultExponent);
        
        // The fact that we got here without reversion proves the vulnerability
        console.log("Vulnerability confirmed: ln() accepted negative input");
    }
    
    function testLnWithZeroInput() public {
        // Create a zero
        packedFloat zeroInput = Float128.toPackedFloat(0, 0);
        
        // Call ln() with zero input - this should be mathematically invalid
        // but the function doesn't validate and will return a result
        packedFloat result = Ln.ln(zeroInput);
        
        // Output the result
        (int resultMantissa, int resultExponent) = Float128.decode(result);
        console.log("Result mantissa:", resultMantissa);
        console.log("Result exponent:", resultExponent);
        
        // The fact that we got here without reversion proves the vulnerability
        console.log("Vulnerability confirmed: ln() accepted zero input");
    }
}

Running these tests with Foundry produced the following results:

[PASS] testLnWithNegativeInput() (gas: 37435)
Logs:
  Input mantissa: -20000000000000000000000000000000000000
  Input exponent: -37
  Input is negative: true
  Result mantissa: 69314718055994530941723212145817656807
  Result exponent: -38
  Vulnerability confirmed: ln() accepted negative input
[PASS] testLnWithZeroInput() (gas: 65407)
Logs:
  Result mantissa: -18781450104493291890957123580748043517
  Result exponent: -33
  Vulnerability confirmed: ln() accepted zero input
Suite result: ok. 2 passed; 0 failed; 0 skipped; finished in 12.55ms (9.01ms CPU time)
Ran 1 test suite in 84.39ms (12.55ms CPU time): 2 tests passed, 0 failed, 0 skipped (2 total tests)

These results clearly demonstrate that:

For a negative input of -2.0, the function returns a value approximately equal to ln(2) ≈ 0.693.
For an input of 0, the function returns a large negative finite number.

Both results are mathematically invalid. The natural logarithm of a negative number is a complex number with a real and imaginary part, not a real number. The natural logarithm of zero is negative infinity, not a finite value.

What’s particularly concerning is how the function appears to work by using the absolute value of the input for negative numbers. This gives no indication to callers that they’ve passed invalid input, making the error especially difficult to detect.

Impact

The silent acceptance of invalid inputs by the ln() function has far-reaching consequences:

Mathematical Integrity Violation: The fundamental integrity of mathematical operations is compromised. Users expect a mathematical library to either produce correct results or fail explicitly when given invalid inputs.
Silent Failure Mode: The function gives no indication that it received invalid input, making debugging nearly impossible. Users may be completely unaware that their calculations are based on mathematically impossible values.
Financial Calculation Risks: If this library is used in financial applications, incorrect logarithmic calculations could lead to severe financial miscalculations. For example, in compounding interest calculations, option pricing models, or risk assessments that rely on logarithmic functions.
Cascading Errors: The invalid results will propagate through any system using these calculations, potentially causing widespread computational integrity issues that become increasingly difficult to trace back to their source.

Tools Used

Foundry

Recommendation

To fix this vulnerability, proper input validation should be added to the ln() function:

function ln(packedFloat input) public pure returns (packedFloat result) {
    // Check if input is zero
    if (packedFloat.unwrap(input) == 0) {
        revert("ln: input must be positive, zero is invalid");
    }
    
    // Check if input is negative (MANTISSA_SIGN_MASK is bit 240)
    if (packedFloat.unwrap(input) & MANTISSA_SIGN_MASK > 0) {
        revert("ln: input must be positive, negative is invalid");
    }
    
    // Continue with existing code...
    uint mantissa;
    int exponent;
    bool inputL;
    assembly {
        inputL := gt(and(input, MANTISSA_L_FLAG_MASK), 0)
        mantissa := and(input, MANTISSA_MASK)
        exponent := sub(shr(EXPONENT_BIT, and(input, EXPONENT_MASK)), ZERO_OFFSET)
    }
    
    if (
        exponent == 0 - int(inputL ? Float128.MAX_DIGITS_L_MINUS_1 : Float128.MAX_DIGITS_M_MINUS_1) &&
        mantissa == (inputL ? Float128.MIN_L_DIGIT_NUMBER : Float128.MIN_M_DIGIT_NUMBER)
    ) return packedFloat.wrap(0);
    
    result = ln_helper(mantissa, exponent, inputL);
}

This ensures the function explicitly fails when given mathematically invalid inputs, maintaining the integrity of the mathematical operations and preventing silent failures that could lead to system-wide computational errors.

Gordon (Forte) confirmed

[H-04] Unwrapping while equating inside the `eq` function fails to account for the set `L_MATISSA_FLAG`

Submitted by YouCrossTheLineAlfie, also found by 0xbrett8571, agent3bood, ChainSentry, gmh5225, harsh123, maxzuvex, patitonar, Rorschach, Uddercover and X-Tray03.

The Float128::eq function is designed to return a boolean if the given two packed floats are equal. However, the issue lies with the way the function equates two packed floats via unwrapping:

    function eq(packedFloat a, packedFloat b) internal pure returns (bool retVal) {
        retVal = packedFloat.unwrap(a) == packedFloat.unwrap(b);
    }

As per the docs, it is clearly mentioned that Mantissa can be of two types M: 38 Digits and L: 72 digits.

/****************************************************************************************************************************
 * The mantissa can be in 2 sizes: M: 38 digits, or L: 72 digits                                                             *
 *      Packed Float Bitmap:                                                                                                 *
 *      255 ... EXPONENT ... 242, L_MATISSA_FLAG (241), MANTISSA_SIGN (240), 239 ... MANTISSA L..., 127 .. MANTISSA M ... 0  *
 *      The exponent is signed using the offset zero to 8191. max values: -8192 and +8191.                                   *
 ****************************************************************************************************************************/

So if there are two packed floats which are equal in nature upon deduction, but one of them has 38 digit mantissa and other has the 72 digit mantissa, the eq function would fail as unwrapping custom float type to underlying type (uint) means that the packed float with 72 digit mantissa will have the L_MANTISSA_FLAG set; which would introduce an incorrect unwrapped version than intended leading to false values.

Impact

The eq function is one of the crucial components of the library, this issue renders it useless for scenarios when one of the packed float has the L_MANTISSA_FLAG on.

Recommended mitigation steps

After running through a few different solutions, the recommendation would be to normalise values before equating, further optimizations are made to reduce gas costs:

    function eq(packedFloat a, packedFloat b) internal pure returns (bool retVal) {
        // If the bit patterns are equal, the values are equal
        if (packedFloat.unwrap(a) == packedFloat.unwrap(b)) {
            return true;
        }
        
        // If either is zero (no mantissa bits set), special handling
        bool aIsZero = (packedFloat.unwrap(a) & MANTISSA_MASK) == 0;
        bool bIsZero = (packedFloat.unwrap(b) & MANTISSA_MASK) == 0;
        
        if (aIsZero && bIsZero) return true;
        if (aIsZero || bIsZero) return false;
        
        // Getting the mantissa and exponent for each value
        (int mantissaA, int exponentA) = decode(a);
        (int mantissaB, int exponentB) = decode(b);
        
        // Checking if signs are different
        if ((mantissaA < 0) != (mantissaB < 0)) return false;
        
        // Getting absolute values
        int absA = mantissaA < 0 ? -mantissaA : mantissaA;
        int absB = mantissaB < 0 ? -mantissaB : mantissaB;
        
        // Applying exponents to normalize values
        // Convert both to a standard form with normalized exponents
        
        // Removing trailing zeros from mantissas (binary search kind of optimisation can be made, but later realised mantissas can be 10000000001 as well, sticking with this O(num_of_digits - 1) solution)
        while (absA > 0 && absA % 10 == 0) {
            absA /= 10;
            exponentA += 1;
        }
        
        while (absB > 0 && absB % 10 == 0) {
            absB /= 10;
            exponentB += 1;
        }
        
        // Checking if the normalized values are equal
        return (absA == absB && exponentA == exponentB);
    }

Below is the test that proves to the issue to be fixed when the mitigation above is replaced with the existing eq function:

    function testFixedEq() public {
        // Contains 72 digits (71 zeros) and -71 exponent (L Mantissa used here)
        packedFloat packed1 = Float128.toPackedFloat(100000000000000000000000000000000000000000000000000000000000000000000000, -71);

        // This is exactly the same value which would've resulted if packed1 was human readable (a * 10^b)
        packedFloat packed2 = Float128.toPackedFloat(1, 0);

        (int256 mantissa2, int256 exponent2) = packed2.decode();
        (int256 mantissa1, int256 exponent1) = packed1.decode();

        console2.log("Mantissa1: ", mantissa1); // Mantissa1:  100000000000000000000000000000000000000000000000000000000000000000000000
        console2.log("Exponent1: ", exponent1); // Exponent1:  -71
        console2.log("Mantissa2: ", mantissa2); // Mantissa2:  10000000000000000000000000000000000000
        console2.log("Exponent2: ", exponent2); // Exponent2:  -37

        // Eq Passes now
        bool isEqual = Float128.eq(packed1, packed2);
        assertEq(isEqual, true);
    }

Proof of Concept

The below test case can ran inside the /test folder by creating a file called test.t.sol:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

import "forge-std/Test.sol";
import "forge-std/console2.sol";
import "src/Float128.sol";

contract TestingContract is Test {
    using Float128 for packedFloat;
    using Float128 for int256;

function testBrokenEq() public {
        // Contains 72 digits (71 zeros) and -71 exponent (L Mantissa used here)
        packedFloat packed1 = Float128.toPackedFloat(100000000000000000000000000000000000000000000000000000000000000000000000, -71);

        // This is exactly the same value which would've resulted if packed1 was human readable (a * 10^b)
        packedFloat packed2 = Float128.toPackedFloat(1, 0);

        (int256 mantissa2, int256 exponent2) = packed2.decode();
        (int256 mantissa1, int256 exponent1) = packed1.decode();

        console2.log("Mantissa1: ", mantissa1); // Mantissa1:  100000000000000000000000000000000000000000000000000000000000000000000000
        console2.log("Exponent1: ", exponent1); // Exponent1:  -71
        console2.log("Mantissa2: ", mantissa2); // Mantissa2:  10000000000000000000000000000000000000
        console2.log("Exponent2: ", exponent2); // Exponent2:  -37

        // Eq fails
        bool isEqual = Float128.eq(packed1, packed2);
        assertEq(isEqual, false);
    }

}

oscarserna (Forte) confirmed

[H-05] Precision loss in `toPackedFloat` function when mantissa is in range (`MAX_M_DIGIT_NUMBER`, `MIN_L_DIGIT_NUMBER`)

Submitted by v2110, also found by agent3bood, HappyTop0603, hecker_trieu_tien, Riceee, and ZOL

https://github.com/code-423n4/2025-04-forte/blob/main/src/Float128.sol#L1102

Finding description and impact

The current implementation determines the result mantissa’s size (M or L) solely based on the exponent, without considering the actual number of digits in the provided mantissa (digitsMantissa).

In cases where the mantissa lies within the range (MAX_M_DIGIT_NUMBER, MIN_L_DIGIT_NUMBER) and the exponent satisfies the condition exponent <= 20 - digitsMantissa (as it doesn’t meet the condition exponent - MAX_DIGITS_M(38) + digitsMantissa > MAXIMUM_EXPONENT(-18)), the function downcasts the mantissa to a Medium-sized (M) format by dividing it with BASE^(digitsMantissa - MAX_DIGITS_M). This results in a loss of precision equivalent to digitsMantissa - MAX_DIGITS_M.

This precision loss becomes especially significant when the mantissa is near the lower boundary of MIN_L_DIGIT_NUMBER. For example, a mantissa of 2^235 can lead to a precision loss of up to 33 digits.

Moreover, the toPackedFloat function serves as a foundational component for this library, as all arithmetic operations depend on its output. Therefore, any loss in precision at this stage can propagate and severely affect subsequent calculations, such as multiplication.

This type of downcasts exists in mul and sqrt functions as well.

Recommended mitigation steps

To preserve precision, which this library explicitly prioritizes over gas efficiency, consider incorporating digitsMantissa into the logic that determines the result mantissa’s size. This ensures that the chosen format maintains maximum accuracy across all supported input ranges.

One potential mitigation could be:

isResultL := or(isResultL, gt(digitsMantissa, MAX_DIGITS_M))

Alternatively, explicitly check whether the mantissa falls within the range (MAX_M_DIGIT_NUMBER, MIN_L_DIGIT_NUMBER) and ensure the size is determined accordingly. Or, a more flexible way is to adopt a flag like div(divL) function.

Proof of Concept

Copy/paste the below code into Float128Fuzz.t.sol and run forge test --mt testToPackedFloatLossInRangeBetweenMaxMAndMinL --ffi -vvvv.

Second test will fail as expected and it will show the significant precision loss.

function testToPackedFloatLossInRangeBetweenMaxMAndMinL() public pure {
        int256 man;
        int256 expo;
        // Around Lower boundary of MIN_L_DIGIT_NUMBER
        assembly {
            man := shl(235, 1)
            expo := sub(0, 51)
        }

        packedFloat float = man.toPackedFloat(expo);
        (int manDecode, int expDecode) = Float128.decode(float);
        packedFloat comp = manDecode.toPackedFloat(expDecode - expo);
        console2.log('DecodedMan', manDecode);
        console2.log('DecodedExp', expDecode);

        int256 retVal = 0;
        if (man != 0) {
            retVal = _reverseNormalize(comp);
        }
        assertLt(retVal, man);

        // Around Upper boundary of MAX_M_DIGIT_NUMBER
        assembly {
            man := shl(127, 1)
            expo := sub(0, 19)
        }

        float = man.toPackedFloat(expo);
        (manDecode, expDecode) = Float128.decode(float);
        comp = manDecode.toPackedFloat(expDecode - expo);
        console2.log('DecodedMan', manDecode);
        console2.log('DecodedExp', expDecode);

        retVal = 0;
        if (man != 0) {
            retVal = _reverseNormalize(comp);
        }
        assertLt(retVal, man);
    }

    function testToPackedFloatLossInRangeBetweenMaxMAndMinLEffect() public {
        int256 man;
        int256 expo;
        assembly {
            man := shl(235, 1)
            expo := sub(0, 51)
        }

        packedFloat float = man.toPackedFloat(expo);

        // Check effect with multiplication
        string[] memory inputs = _buildFFIMul128(man, expo, man, expo, "mul", 0);
        bytes memory res = vm.ffi(inputs);
        (int pyMan, int pyExp) = abi.decode((res), (int256, int256));

        packedFloat result = Float128.mul(float, float);
        (int rMan, int rExp) = Float128.decode(result);

        checkResults(result, rMan, rExp, pyMan, pyExp, 0);
        // //////////////////////////////////////////////35digits difference from here
        //  "rMan", 304858256866796116345859104471988897039037891665498727750484539172886869
        // "pyMan", 304858256866796116345859104471988897045761537369626088951089546838415208
        // rExp = pyExp = -32
    }

oscarserna (Forte) acknowledged

Medium Risk Findings (1)

[M-01] Inconsistent mantissa size auto-scaling between `packedFloat` encoding and calculations will lead to unacceptable rounding errors

Submitted by montecristo

Library has “mantissa size auto-scaling” rule to achieve the following:

In other words, the library down scales the size of the mantissa to make sure it is as gas efficient as possible, but it up scales to make sure it keeps a minimum level of precision. The library prioritizes precision over gas efficiency.

However, there is a discrepancy between auto-scaling rule of encoding (i.e. toPackedFloat) and other calculations (add, sub, mul, div).

packedFloat encoding has the following rule:

If mantissa has 38 digits and exponent > -18, encoded packedFloat will be forced to be in L-mantissa
If mantissa has 72 digits, encoded packedFloat will use L-mantissa
Otherwise
1. If -18 < exp + digitsMantissa - 38, output will use L-mantissa
2. Otherwise, output will use M-mantissa

However, all arithmetic operations enforce the following auto-scaling rule:

For calculation result r, if -18 < exp + digitsMantissa - 38, output will use L-mantissa
Otherwise, output will use M-mantissa

For example, check how auto-scaling rule is implemented in mul function:

File: 2025-04-forte/src/Float128.sol

493: if (Loperation) {
494:             // MIN_L_DIGIT_NUMBER is equal to BASE ** (MAX_L_DIGITS - 1).
495:             // We avoid losing the lsd this way, but we could get 1 extra digit
496:             rMan = Uint512.div512x256(r0, r1, MIN_L_DIGIT_NUMBER);
497:             assembly {
498:                 rExp := add(rExp, MAX_DIGITS_L_MINUS_1)
499:                 let hasExtraDigit := gt(rMan, MAX_L_DIGIT_NUMBER)
500:@>               let maxExp := sub(sub(add(ZERO_OFFSET, MAXIMUM_EXPONENT), DIGIT_DIFF_L_M), hasExtraDigit)
501:@>               Loperation := gt(rExp, maxExp)
...
518: } else {
519:             assembly {
520:                 // multiplication between 2 numbers with k digits can result in a number between 2*k - 1 and 2*k digits
521:                 // we check first if rMan is a 2k-digit number
522:                 let is76digit := gt(rMan, MAX_75_DIGIT_NUMBER)
523:@>               let maxExp := add(
524:@>                   sub(sub(add(ZERO_OFFSET, MAXIMUM_EXPONENT), DIGIT_DIFF_L_M), DIGIT_DIFF_76_L),
525:@>                   iszero(is76digit)
526:@>               )
527:@>               Loperation := gt(rExp, maxExp)
...
553: if Loperation {
554:                 r := or(r, MANTISSA_L_FLAG_MASK)
555:             }

The implementation just checks rExp is greater than maxExp and decide mantissa L flag on rExp > maxExp condition. (This condition is equal to -18 < exp + digitsMantissa - 38 in rule #3).

So clearly, arithmetic operations use only #3 of auto-scaling rule for encoding, while encoding also has additional #1 and #2 rules.

This means the following:

Encoded packedFloats can contain more information (72-digit) even when their exponent is less than -52
This additional digits contributes to arithmetic operations
However, the operation discards the additional digits after calculation if the exponent is less than -52

This can lead to the following problems:

Unreliable behavior of the library (calculation will output 38 digits even though arguments are all L-mantissa, or vice versa)
Unacceptable rounding error as we will observe in POC section.

Recommended mitigation steps

Enforce the same auto-scaling rule between encoding and calculation operations. i.e.:

Drop rule #1 and #2 from auto-scaling rule of encoding
Or, add rule #1 and #2 to auto-scaling rule of calculations

NOTE: Basically rule #1 and rule #3.1 are equivalent. So the fix just needs to handle the case of rule #2.

Proof of Concept

Scenario:

We have two packedFloat a and b
Both of them have exp < -52 and have 72-digit mantissas
a and b will be L-mantissa due to encoding rule #2
However, both a + b and a - b will be in M-mantissa because exp < -52
We evaluate a + b - b and a - b + b and compare the results
They will differ by 9 ULPs
However, according to README, maximum acceptable ULP of add and sub are 1 resp. So expected result should not be off by more than 2 or 3 ULPs

Put the following content in test/poc.t.sol and run forge test --match-test testM03POC -vvv:

pragma solidity ^0.8.24;

import "forge-std/Test.sol";
import "src/Float128.sol";
import {Ln} from "src/Ln.sol";
import {Math} from "src/Math.sol";
import {packedFloat} from "src/Types.sol";

contract ForteTest is Test {
    using Float128 for packedFloat;

    function testM03POC() external {
        int256 aMan = 100000000000000000000000000000000000000000000000000000000000000000000000;
        int256 aExp = -53;

        int256 bMan = 999999999999999999999999999999999999999999999999999999999999999999999999;
        int256 bExp = -56;

        packedFloat a = Float128.toPackedFloat(aMan, aExp);
        packedFloat b = Float128.toPackedFloat(bMan, bExp);
        packedFloat left = a.add(b).sub(b);
        packedFloat right = a.sub(b).add(b);
        _debug("a", a);
        _debug("b", b);
        _debug("left", left);
        _debug("right", right);
        (int256 lMan, int256 lExp) = left.decode();
        (int256 rMan, int256 rExp) = right.decode();
        assertEq(lExp, rExp, "exp mismatch");
        assertEq(rMan - lMan, 9, "ULP != 9");
    }

    function _debug(string memory message, packedFloat float) internal {
        console.log(message);
        _debug(float);
    }

    function _debug(packedFloat float) internal {
        (int256 mantissa, int256 exponent) = float.decode();
        emit log_named_uint("\tunwrapped", packedFloat.unwrap(float));
        emit log_named_int("\tmantissa", mantissa);
        emit log_named_uint(
            "\tmantissa digits", Float128.findNumberOfDigits(packedFloat.unwrap(float) & Float128.MANTISSA_MASK)
        );
        emit log_named_int("\texponent", exponent);
    }
}

Console output:

Logs:
  a
        unwrapped: 57525106735054637002573000029187941038311220714476402038523254701685114667008
        mantissa: 100000000000000000000000000000000000000000000000000000000000000000000000
        mantissa digits: 72
        exponent: -53
  b
        unwrapped: 57504804570277296390618000459179026016121290907713894611025795427269603229695
        mantissa: 999999999999999999999999999999999999999999999999999999999999999999999999
        mantissa digits: 72
        exponent: -56
  left
        unwrapped: 57754696853475826965418828704284520445468793621070232503079063507853155237878
        mantissa: 99999999999999999999999999999999999990
        mantissa digits: 38
        exponent: -20
  right
        unwrapped: 57754696853475826965418828704284520445468793621070232503079063507853155237887
        mantissa: 99999999999999999999999999999999999999
        mantissa digits: 38
        exponent: -20

oscarserna (Forte) disputed

Low Risk and Non-Critical Issues

For this audit, 7 reports were submitted by wardens detailing low risk and non-critical issues. The report highlighted below by eternal1328 received the top score from the judge.

The following wardens also submitted reports: 0x23r0, CodexBugmenot, K42, montecristo, PabloPerez, and unique.

Float128.sol

[01] Potential for silent arithmetic overflow in exponent adjustment

Even if the sign detection bug were somehow “fixed,” the direct usage of exp(10, N) in EVM for \(N \approx 76\) is still borderline for 256‐bit arithmetic. In particular:

\(10^{76}\) is already \(\approx 2^{252.8}\).
\(10^{77}\) is \(\approx 1.267 \times 10^{77}\), which is \(\approx 1.27 \times 2^{256}\).

Thus, 10^77 in 256‐bit arithmetic would overflow to \(\mod 2^{256}\) and produce an incorrect result.

[02] Additional observations/smaller issues

sqrt Implementation
The library attempts a “bit‐based approximate” approach to compute the square root of large numbers. While this might work if the inputs are carefully scaled, it’s quite complex and could be off by 1 in boundary conditions. Thorough testing is recommended.

“Autoscaling” M ↔ L
The logic that automatically promotes or demotes between 38‐digit and 72‐digit mantissas is fairly intricate. Even if the exponent–mantissa logic were corrected, the transitions should be heavily fuzz‐tested to ensure no corner cases are missed (e.g., borderline exponents, borderline mantissas near \(10^{38}\) or \(10^{72}\)).

[03] Recommendations/how to fix

Implement “decimal exponent” logic manually: If you genuinely need to multiply or divide by \(10^{N}\) (for up to \(N=76\)), do so with a small custom loop or with a precomputed table of powers of 10 up to 76. Do not rely on the EVM’s exp opcode for decimal exponent.
Use a signed integer for exponent difference: You must do a proper (256‐bit) signed subtraction for exponent differences, e.g.:
```
int256 aExpSigned = int256(shr(EXPONENT_BIT, a) - ZERO_OFFSET);
int256 bExpSigned = int256(shr(EXPONENT_BIT, b) - ZERO_OFFSET);
int256 adj = aExpSigned - bExpSigned;
```
Then check if (adj < 0) { … } else { … }.

Right now, the code is mixing 14‐bit exponent with a top‐bit sign check that never triggers.
Check for exponent overflow
- If \(N > 77\) is ever needed, then you cannot do 10^N in a single 256‐bit integer.
- Decide how big an exponent difference you actually must support. Possibly your design forbids differences > 76 or 77. If so, enforce that with explicit require statements or logic.

Ln.sol

[01] No domain check for `\( x \le 0 \)`

Issue

The function ln() does not verify whether the input represents a non‐negative number. Mathematically, \(\ln(x)\) is undefined for \(x \le 0\).

Risk

A zero or negative packedFloat could lead to unpredictable or meaningless results (e.g. division by zero) rather than an expected revert.
Attackers (or buggy logic) might pass invalid inputs that cause the code to behave incorrectly.

Recommendation

At the outset of ln(), ensure x > 0. If Float128 offers a sign‐checking method, use it, e.g.:

if (isNegative(x) || isZero(x)) {
    revert("Ln: domain error, x <= 0");
}

In a production scenario, it’s generally correct to revert on \(\ln(0)\) or \(\ln(\text{negative})\).

[02] Potential for recursive calls/extreme inputs

ln_helper() may flip the exponent and compute \(\ln(1 / argument)\) for values below 1, re‐entering ln(...).

If there’s a scenario where the flipped exponent does not converge or leads back to a similar condition, infinite recursion (or very deep recursion) could occur.

Risk

On certain edge cases—extremely large or extremely small exponent—there might be repeated calls into ln(), eventually running out of gas or reverting.

Recommendation

Add safeguards (e.g., if exponent is beyond some threshold, revert or approximate the limit) and thoroughly test low‐magnitude inputs (like \(x \approx 1e-6000\)) to verify that recursion terminates.

[03] Handling of extreme large/small exponents

The code attempts various manipulations (e.g., BASE_TO_THE_MAX_DIGITS_M_X_2 / mantissa) in ln_helper(). If mantissa is extremely small or zero, you can end up dividing by zero. Conversely, if the exponent is huge, subsequent multiplications might overflow.

Recommendation

Check exponent ranges (e.g., ensure it does not exceed library limits).
Ensure you cannot do a division by zero.
Consider reverting when input is so large or so tiny that (\ln) is not representable under the chosen floating‐point constraints.

[04] Piecewise approximation thresholds may be error‐prone

The library uses big nested if statements with thresholds (like mantissa > (68300000 * 10**68)) to switch among different polynomial expansions or partial sums.

Risks

Any off‐by‐one or mis‐typed threshold can produce incorrect results.
The series expansions’ coefficients (e.g., the large inline assembly expansions) might have transcription errors.
No explicit test coverage is shown for each threshold boundary.

Recommendation

Heavily test each boundary to ensure correctness.
Provide mathematical justifications and expected approximation errors for every piecewise segment.
Consider using a more standard polynomial approximation or series approach that can be validated easily (e.g., a known range‐reduction and Taylor method).

[05] Potential overflow in expressions like `10**76 - int(mantissa)`

The code uses 10**76 directly (close to \(2^{256}\)) in lines like:

int z_int = 10**76 - int(mantissa);

Although 10**76 itself fits in 256 bits, it’s very near the upper limit. Any future attempt to use 10**77 would exceed 2^{256} and revert.

Recommendation

Add a safety check or ensure the code never tries powers beyond 10**76.
Confirm if z_int can become negative when mantissa is large, which might break subsequent logic if not handled explicitly.

[06] Recommendations/how to fix

Domain Checking: The library must revert for \(x \le 0\), as \(\ln(x)\) is not defined in that region.
Recursive Behavior: The internal call to ln(...) for reciprocals can lead to deep recursion unless the input range is carefully controlled.
Extreme Exponents: Large or tiny exponents/values might trigger division by zero or overflow.
Approximation Thresholds: Hardcoded step functions with large expansions are prone to boundary and transcription errors.
Large Constants: Powers like 10**76 are at the edge of feasible 256‐bit integers, risking overflow if extended.

All these issues should be addressed (or at least extensively tested) to ensure the library accurately computes natural logarithms across valid input ranges.

Disclosures

C4 is an open organization governed by participants in the community.

C4 audits incentivize the discovery of exploits, vulnerabilities, and bugs in smart contracts. Security researchers are rewarded at an increasing rate for finding higher-risk issues. Audit submissions are judged by a knowledgeable security researcher and disclosed to sponsoring developers. C4 does not conduct formal verification regarding the provided code but instead provides final verification.

C4 does not provide any guarantee or warranty regarding the security of this project. All smart contract software should be used at the sole risk and responsibility of users.

Forte: Float128 Solidity Library Findings & Analysis Report

2025-04-29

Table of contents

Overview

About C4

Summary

Scope

Severity Criteria

High Risk Findings (5)

[H-01] Early 72-digit adjustment in sqrt will lead to incorrect result exponent calculation

Impact

Recommended mitigation steps

Proof of Concept

[H-02] Sqrt function silently reverts the entire control flow when a packed float of 0 value is passed

Finding description

Impact

Recommended mitigation steps

Proof of Concept

[H-03] Natural logarithm function silently accepts invalid non-positive inputs

Summary

Vulnerability details

Impact

Tools Used

Recommendation

[H-04] Unwrapping while equating inside the eq function fails to account for the set L_MATISSA_FLAG

Impact

Recommended mitigation steps

Proof of Concept

[H-05] Precision loss in toPackedFloat function when mantissa is in range (MAX_M_DIGIT_NUMBER, MIN_L_DIGIT_NUMBER)

Finding description and impact

Recommended mitigation steps

Proof of Concept

Medium Risk Findings (1)

[M-01] Inconsistent mantissa size auto-scaling between packedFloat encoding and calculations will lead to unacceptable rounding errors

Recommended mitigation steps

Proof of Concept

Low Risk and Non-Critical Issues

Float128.sol

[01] Potential for silent arithmetic overflow in exponent adjustment

[02] Additional observations/smaller issues

[03] Recommendations/how to fix

Ln.sol

[01] No domain check for \( x \le 0 \)

Issue

Risk

Recommendation

[02] Potential for recursive calls/extreme inputs

Risk

Recommendation

[03] Handling of extreme large/small exponents

Recommendation

[04] Piecewise approximation thresholds may be error‐prone

Risks

Recommendation

[05] Potential overflow in expressions like 10**76 - int(mantissa)

Recommendation

[06] Recommendations/how to fix

Disclosures

Forte: Float128 Solidity Library
Findings & Analysis Report

[H-04] Unwrapping while equating inside the `eq` function fails to account for the set `L_MATISSA_FLAG`

[H-05] Precision loss in `toPackedFloat` function when mantissa is in range (`MAX_M_DIGIT_NUMBER`, `MIN_L_DIGIT_NUMBER`)

[M-01] Inconsistent mantissa size auto-scaling between `packedFloat` encoding and calculations will lead to unacceptable rounding errors

[01] No domain check for `\( x \le 0 \)`

[05] Potential overflow in expressions like `10**76 - int(mantissa)`