Loading...
LoadingLoading...
LoadingLoading audit report...
WalletGuard.ai, powered by Gestalt Labs
Findings selected for deep verification. Where possible we generated a Solidity proof-of-concept and executed it against a forked mainnet.
src/Ln.solFunction: calculateQ1Lines: 191-193The analyzed contract appears to be a pure mathematical library implementing floating-point arithmetic (Float128), 512-bit integer operations (Uint512), and natural logarithm computation (Ln) in Solidity. The analysis identified 0 critical, 0 high, 4 medium, 5 low, and 2 informational findings, with several additional findings dropped as non-exploits or code quality observations. The most dangerous pattern identified is silent arithmetic corruption: the ln() function accepts negative inputs without reverting, producing mathematically meaningless results that propagate silently through any consuming protocol. While no direct fund-theft vectors exist in this library-only contract, the precision and correctness defects pose meaningful risk to any financial protocol that depends on this library for accurate computation, and the overall security posture is conditionally acceptable only if consuming contracts implement their own input validation.
The natural logarithm function (ln) is mathematically undefined for zero and negative numbers. Instead of rejecting these invalid inputs with an error, this contract silently computes a wrong answer and returns it. Any financial protocol using this library to compute logarithms of prices or quantities could silently receive incorrect results without any warning, potentially leading to miscalculated interest rates, prices, or other critical values.
When subtracting a negative number from zero (0 minus a negative value), the result should be positive. Instead, a bug in how the sign bit is toggled causes the function to return a negative result. For example, 0 - (-5) would incorrectly return -5 instead of +5. Any calculation chain involving subtraction from zero with a negative operand will silently produce the wrong sign, corrupting downstream financial math.
If a zero-mantissa floating-point value is passed to the logarithm function, the contract will crash with an uninformative panic error rather than a clear message explaining the problem. While this does not cause silent data corruption (the transaction reverts), it can break integrating contracts that do not expect this type of failure, and makes debugging significantly harder.
A caller supplies a negative packedFloat to ln() (Finding 5). Because ln() performs no sign check, it silently computes and returns a nonsensical positive result. That result is then compared using ge() or le() (Finding 6/10), which may itself produce incorrect ordering due to mixed-sign zero edge cases or differing canonical representations. The combined effect is that a consuming protocol receives a wrong logarithm value AND may branch incorrectly on the comparison of that value, compounding the arithmetic error into a logic path error without any revert or event indicating a problem.
The sub() function incorrectly returns a negative result when subtracting a negative number from zero (Finding 11). If that corrupted negative result is then passed to ge() or le() (Finding 10), the comparison may further misfire because the sign bit is unexpected relative to the mantissa encoding. The result is a doubly-incorrect value flowing into a doubly-incorrect comparison, with no error signal at either step.
| Agent | Status | Findings | Severity | Confidence | Duration | Coverage |
|---|---|---|---|---|---|---|
| reentrancy | success | 3 | 1L | 65% | 35.6s | Cross-function reentrancy patterns across all files, External call ordering and CEI pattern compliance, ERC-777/ERC-1155 callback hooks, Flash loan callback patterns, Read-only reentrancy in view/pure functions, Overflow/underflow in unchecked blocks (Uint512.sol arithmetic), Assembly block correctness in Float128.sol and Uint512.sol, Division by zero handling in Float128.div, Recursive function depth in Ln.ln/ln_helper, Integer precision and rounding in fixed-point arithmetic, Access control and state mutability, Taylor series convergence properties |
| access control | success | 2 | 73% | 28.8s | Access control and visibility modifiers on all public/external functions, Signature verification patterns (none present), Initializer and proxy patterns (none present - pure library code), Selfdestruct and delegatecall usage (none present), Integer overflow/underflow in assembly blocks, Recursion depth in ln() and ln_helper(), Division by zero protections in Float128.div and Uint512.div512x256, ecrecover usage (none present), tx.origin usage (none present), Ownership patterns (none present - library only), Assembly-level arithmetic correctness in Uint512 and Float128, Type safety of packedFloat custom type, Reentrancy (not applicable - pure computation libraries) | |
| economic | success | 4 | 1M1L | 74% | 56.7s | Flash loan attack surface - no token balances, pure math library, Oracle manipulation - no price feeds used, Governance attacks - no governance mechanisms, MEV exposure - no swaps or liquidations, Integer overflow/underflow in assembly blocks (Uint512, Float128), Division before multiplication precision loss in Ln.sol calculateQ1/Q2/Q3, Input validation in ln(), sqrt(), div() functions, Taylor series convergence accuracy in intermediateTermAddition, Comparison function correctness (lt, le, gt, ge, eq) for edge cases, packedFloat encoding/decoding correctness in toPackedFloat and decode, Sign handling in two's complement arithmetic within assembly blocks, Recursive ln() call via ln_helper for potential infinite recursion, Constants correctness (ln10, ln2, ln1dot1 encoded values), Negative zero handling across comparison functions |
| logic validation | success | 5 | 1M2L | 61% | 1.2m | Input validation on ln(), div(), sqrt() functions, Integer overflow/underflow in unchecked blocks in Uint512.sol sqrt256() and sqrt512(), Division before multiplication patterns in ln_helper() and div512x256(), Recursion depth and termination in ln() and ln_helper(), Comparison function correctness (lt, le, gt, ge, eq) for edge cases, Assembly block correctness in add(), sub(), mul(), div() of Float128, Taylor series convergence in intermediateTermAddition(), Sign handling in sub() and ln(), Packed float encoding/decoding correctness in toPackedFloat() and decode(), Uint512 mul256x256, div512x256, sqrt256, sqrt512 assembly correctness, calculateQ1, calculateQ2, calculateQ3 helper precision, Type safety and downcast risks in the packedFloat type system |
| code quality | success | 7 | 71% | 1.1m | Arithmetic correctness in Float128 add/sub/mul/div operations, Sign handling in two's complement mantissa arithmetic, Recursive ln computation and termination conditions, Taylor series convergence and truncation error, Comparison function correctness (lt, le, gt, ge, eq), Assembly block correctness in all library functions, Integer overflow/underflow in unchecked blocks, Division by zero protection in div() and div512x256(), Uint512 arithmetic correctness, Function visibility and gas optimization, EVM assembly opcode usage (mulmod, addmod, sar, shl, shr), Packed float encoding/decoding correctness | |
| compiler bugs | success | 2 | 1M | 73% | 32.1s | Arithmetic correctness in Float128 add/sub/mul/div operations, Sign-handling logic in sub() when operands are zero or negative, Recursion depth and termination in Ln.ln() / ln_helper(), Division-by-zero guards in Float128.div(), Square-root-of-negative guard in Float128.sqrt(), Bit-packing and masking correctness in packedFloat encoding/decoding, Comparison functions (lt, le, gt, ge, eq) for edge cases with zero and negative values, Uint512 assembly arithmetic for overflow/underflow, Compiler bug patterns: pragma ^0.8.24 is outside all affected ranges |
| assembly safety | success | 5 | 1M1L | 70% | 1.0m | Complete codepoint scan for non-ASCII characters, RTLO (U+202E), zero-width characters (U+200B, U+200C, U+200D), and Cyrillic homoglyphs in all identifiers, function names, and string literals across all files, All assembly{} blocks in Uint512.sol, Float128.sol, and Ln.sol for sload/sstore, hardcoded slot numbers, free memory pointer corruption, return vs leave, selfdestruct, delegatecall, extcodesize patterns, Shift instruction argument ordering (shl/shr/sar) in all assembly blocks, View/pure function purity violations in assembly, Checked all assembly delegatecall and external call patterns (none found), Logic correctness of add/sub/mul/div/sqrt operations for edge cases (zero, negative, boundary values), Sign handling in sub() for zero operands, ln() negative input guard absence, Taylor series precision adequacy in intermediateTermAddition, stop() usage in sqrt() for zero input case, Memory safety of inline error-encoding assembly in div() and sqrt(), Integer overflow/underflow risks in unchecked blocks, Recursive call pattern in ln() calling ln() via ln_helper |
| l2 specific | success | 6 | 1M2L | 75% | 1.1m | Float128 arithmetic operations (add, sub, mul, div, sqrt) for overflow and precision issues, Ln.sol natural logarithm implementation including recursion paths, Input validation in all public/external entry points, Assembly blocks for correctness of bit manipulation and mask usage, Integer overflow/underflow in unchecked blocks, Division by zero conditions throughout all functions, Comparison functions (lt, le, gt, ge, eq) for correctness, Taylor series convergence and precision in intermediateTermAddition, calculateQ1/Q2/Q3 helper functions for correctness and visibility, packedFloat encoding/decoding (toPackedFloat, decode) for correctness, Uint512 library mathematical correctness, L2-specific patterns (no L2 imports, predeploys, or cross-domain calls detected - chain-agnostic library) |
This automated audit has inherent limitations. The following areas are not covered.
This report is an automated point-in-time assessment and does not guarantee protection against all possible attacks. It does not cover off-chain components, economic modeling, or business logic correctness unless explicitly noted. Changes to the contract after the audit commit are not reviewed. This is not financial or legal advice. WalletGuard, powered by Gestalt Labs, provides this analysis as-is with no warranty of completeness.
[](https://walletguard.ai/audit/96273f55-7967-4e17-a973-49e69e386c7a)
<a href="https://walletguard.ai/audit/96273f55-7967-4e17-a973-49e69e386c7a"> <img src="https://walletguard.ai/api/badge/96273f55-7967-4e17-a973-49e69e386c7a" alt="WalletGuard Audit Badge" /> </a>
Secured by WalletGuard