LibDecimalFloatDeployProdTest has five red tests on main and every open
branch, and no amount of in-repo work can fix them:
[FAIL: arbitrum: DecimalFloat not deployed] testProdDeploymentArbitrum()
[FAIL: base: DecimalFloat not deployed] testProdDeploymentBase()
[FAIL: base_sepolia: DecimalFloat not deployed] testProdDeploymentBaseSepolia()
[FAIL: flare: DecimalFloat not deployed] testProdDeploymentFlare()
[FAIL: polygon: DecimalFloat not deployed] testProdDeploymentPolygon()
The pinned address has no code at it
eth_getCode on the current pin 0x799632d282178e770C7465cad54aDA1021A913D6
returns 0x on arbitrum, base and flare.
eth_getCode on the previous 0.1.1 pin
0xBee0eEcB2f2b3aE6E5Aa9E2C8C0EE9b5eDe9C926 returns 39261 hex chars of code
on all three. That one is real; the current one was never deployed.
The constants are not wrong — the deployment is missing
This is the important part, because it rules out the tempting fix.
- A local build of
main reproduces keccak256(deployedBytecode) for
DecimalFloat as 0xdc468883…f55e, which is exactly
DECIMAL_FLOAT_CONTRACT_HASH. The pins match the source they were derived
from.
git diff sol-v0.1.7 origin/main -- src/ is empty, so 0.1.7's codehash is
that same value.
So the source, the codehash and the derived address all agree with each other.
What is missing is a broadcast.
How it got here
Commit 4d98fce (2026-06-17, "after formatter fix") moved the constants to a
newly derived address, as it should have. The Manual sol artifacts dispatch
on 2026-06-29 then tried to deploy it and reverted at gas estimation
(execution reverted, data: 0x), so the address the repo now points at has
never had code at it.
What must NOT be done
- Reverting the pins to
0xBee0eE…C926 would turn CI green while silently
repointing every downstream consumer at a different mainnet contract with
different bytecode. That is a production change disguised as a CI fix.
- Weakening or deleting
LibDecimalFloatDeployProdTest is the same act in
a different place. The test is correct: it is reporting a true fact.
What is needed
A deployment of DecimalFloat across arbitrum, base, base_sepolia, flare and
polygon, at the current bytecode, via the usual dispatch:
gh workflow run manual-sol-artifacts.yaml --ref main -f suite=decimal-float
The 2026-06-29 gas-estimation revert should be expected to recur and needs
diagnosing as part of this — deploying is not simply a matter of re-running
the dispatch.
Until then rainix-sol / test stays red on these five regardless of every
other fix, so main cannot go fully green without a human deploying.
Filed while working through the other causes of red CI (#265, #266, #267,
#268), none of which can touch this one.
LibDecimalFloatDeployProdTesthas five red tests onmainand every openbranch, and no amount of in-repo work can fix them:
The pinned address has no code at it
eth_getCodeon the current pin0x799632d282178e770C7465cad54aDA1021A913D6returns
0xon arbitrum, base and flare.eth_getCodeon the previous0.1.1pin0xBee0eEcB2f2b3aE6E5Aa9E2C8C0EE9b5eDe9C926returns 39261 hex chars of codeon all three. That one is real; the current one was never deployed.
The constants are not wrong — the deployment is missing
This is the important part, because it rules out the tempting fix.
mainreproduceskeccak256(deployedBytecode)forDecimalFloatas0xdc468883…f55e, which is exactlyDECIMAL_FLOAT_CONTRACT_HASH. The pins match the source they were derivedfrom.
git diff sol-v0.1.7 origin/main -- src/is empty, so 0.1.7's codehash isthat same value.
So the source, the codehash and the derived address all agree with each other.
What is missing is a broadcast.
How it got here
Commit
4d98fce(2026-06-17, "after formatter fix") moved the constants to anewly derived address, as it should have. The
Manual sol artifactsdispatchon 2026-06-29 then tried to deploy it and reverted at gas estimation
(
execution reverted, data: 0x), so the address the repo now points at hasnever had code at it.
What must NOT be done
0xBee0eE…C926would turn CI green while silentlyrepointing every downstream consumer at a different mainnet contract with
different bytecode. That is a production change disguised as a CI fix.
LibDecimalFloatDeployProdTestis the same act ina different place. The test is correct: it is reporting a true fact.
What is needed
A deployment of
DecimalFloatacross arbitrum, base, base_sepolia, flare andpolygon, at the current bytecode, via the usual dispatch:
The 2026-06-29 gas-estimation revert should be expected to recur and needs
diagnosing as part of this — deploying is not simply a matter of re-running
the dispatch.
Until then
rainix-sol / teststays red on these five regardless of everyother fix, so
maincannot go fully green without a human deploying.Filed while working through the other causes of red CI (#265, #266, #267,
#268), none of which can touch this one.