Audit reference
Protofire, March 2026, finding H01 — Mismatched Log-Table Addresses Leads to Silent Numeric Corruption. Severity: High. Status at audit (19a65ffa): New.
What
LibDecimalFloat.LOG_TABLES_ADDRESS is hardcoded to 0x6421E8a23cdEe2E6E579b2cDebc8C2A514843593 (src/lib/LibDecimalFloat.sol:50). The deployment script targets a different address: ZOLTU_DEPLOYED_LOG_TABLES_ADDRESS = 0xc51a14251b0dcF0ae24A96b7153991378938f5F5 (src/lib/deploy/LibDecimalFloatDeploy.sol:18).
pow10, log10, pow, sqrt all extcodecopy from the hardcoded 0x6421... address. That address has no deployed code on any of the supported networks (Arbitrum, Base, Base Sepolia, Flare, Polygon). EVM extcodecopy on an address with no code copies zeros into memory and does NOT revert.
Impact
Every transcendental call against the production DecimalFloat contract returns garbage: log/exp lookups operate on a zeroed table. Silent — no revert, no event, just wrong numbers.
Recommendation
Remove the hardcoded 0x6421... constant in LibDecimalFloat.sol. Either:
- Re-export the deployed address from
LibDecimalFloatDeploy and use that single source of truth, or
- Refactor the concrete contract to take the table address as a constructor argument.
After fixing, redeploy and update LibDecimalFloatDeploy constants per the existing release process.
Verification
Add a fork test that calls log10/pow10/sqrt/pow against the deployed DecimalFloat on a real chain and asserts the result matches the off-chain LibDecimalFloatSlow reference. The test must fail before the fix and pass after.
Audit reference
Protofire, March 2026, finding H01 — Mismatched Log-Table Addresses Leads to Silent Numeric Corruption. Severity: High. Status at audit (
19a65ffa): New.What
LibDecimalFloat.LOG_TABLES_ADDRESSis hardcoded to0x6421E8a23cdEe2E6E579b2cDebc8C2A514843593(src/lib/LibDecimalFloat.sol:50). The deployment script targets a different address:ZOLTU_DEPLOYED_LOG_TABLES_ADDRESS = 0xc51a14251b0dcF0ae24A96b7153991378938f5F5(src/lib/deploy/LibDecimalFloatDeploy.sol:18).pow10,log10,pow,sqrtallextcodecopyfrom the hardcoded0x6421...address. That address has no deployed code on any of the supported networks (Arbitrum, Base, Base Sepolia, Flare, Polygon). EVMextcodecopyon an address with no code copies zeros into memory and does NOT revert.Impact
Every transcendental call against the production
DecimalFloatcontract returns garbage: log/exp lookups operate on a zeroed table. Silent — no revert, no event, just wrong numbers.Recommendation
Remove the hardcoded
0x6421...constant inLibDecimalFloat.sol. Either:LibDecimalFloatDeployand use that single source of truth, orAfter fixing, redeploy and update
LibDecimalFloatDeployconstants per the existing release process.Verification
Add a fork test that calls
log10/pow10/sqrt/powagainst the deployedDecimalFloaton a real chain and asserts the result matches the off-chainLibDecimalFloatSlowreference. The test must fail before the fix and pass after.