BLOOM V2.4 — MAINNET CONTRACTS, JOB 1/3

Implemented the contracts, tests, ABIs, scripts, hashes, and deployment handoff.

• forge build, forge test (62 passed), formatting, and artifact checks pass.
• No mainnet transactions sent. Farms await the real Job 2 BLOOM token.
• Immediate sIMD exits work; IMD redemption is disabled because of the official one-block hold.
• Historical RPC replay required archive access; current-block verification succeeded.

Created launch.json for BloomTreasury, then BloomFactory, with $owner and matching constructor arguments. Notes document deferred farms and Job 2 dependencies.

Checks passed: manifest structure, compiled ABI matching, forge build, and all 62 tests using the required fuzz seed.

Only launch.json changed. No transactions broadcast.

I found two permission defects in the farm code and none that let anyone take user funds. Both findings and a coverage row for every listed entry point (91 rows) are in .imd-findings.json. No repository files were changed; the scratch test directory has been removed.

Findings

1. Medium: a farm that can never activate blocks its asset forever (src/BloomFactory.sol:83).

   • Cause: _register checks fewer things than activate(): it skips the chain id, decimals() == assetDecimals and the asset code-hash checks. A farm that fails those still gets registered.
   • No way back: the factory has no way to unregister or replace a farm, and bindRegistry on the Treasury is one-time. The only fix is redeploying both Factory and Treasury, and fees already received stay in the old Treasury.
   • Reproduction: call deployFarm with StakedBLOOM initcode using decimals 6 when BLOOM has 18. Registration succeeds, activate() always reverts InvalidDependency, and deploying the correct farm reverts DuplicateFarm.
   • Proof: the attached Foundry test fails on the current code with DuplicateFarm() and passes once _register rejects such a farm.
   • Also: the existing test testWrongChainAndDecimalsCannotActivate registers exactly such a farm.

2. Low: renouncing the pause power doesn't stop deposits from being paused (src/core/Farm.sol:106).

   • Cause: deposits also check the factory whitelist. After the owner calls renouncePowers(PAUSE) on a farm, whitelistAsset(asset, false) on the factory still halts new deposits. It also blocks startEpoch and restartEpoch.
   • Asymmetry: continueEpoch skips that check, so a running epoch can still be changed while deposits are closed.
   • Unaffected: withdrawals and claims keep working. I confirmed this one in a local scratch test.

Checked and holding

• Owner-only actions: every one is gated by owner plus an irreversible renounced-power bitmask. Ownership transfer takes two steps, and the one-time bindings can't be front-run.
• Admin recovery: recoverExcess, recoverUnallocatedRewards and spendFees are each capped so they can't touch user principal or reward obligations. The Treasury can't spend donations.
• User paths: neither withdraw nor claim depends on the pause, the whitelist or the activation flag.
• ETH payouts: a payout capped at 50,000 gas runs under the reentrancy lock and falls back to WETH.

Static-analysis leads: the arbitrary-send-eth, reentrancy-balance, weak-prng and strict-equality leads were traced. In each case the recipient is the caller's own chosen address or the call sits behind the owner check or the reentrancy lock, so none became a finding.

Not covered in depth: detailed share and reward rounding math, which other reviewers own. User-input mistakes, such as naming the WETH or Treasury address as the payout address, are left out as user error.

Both snippets match the tree, all 89 entry points have coverage rows, and the proof test fails on the current code for the stated reason.

Outcome: two findings recorded in .imd-findings.json, with a coverage row for every listed entry point.

Finding 1, medium, share-rate inflation through the retained fee. For the three launch farms the inflation guard is one virtual share and one virtual asset unit. A holder deposits D, withdraws all but one share, and the 14% retained fee leaves 0.14·D backing that single share. New deposits are then priced at roughly 0.07·D per share, so anything below 0.07·D reverts and anything up to 0.14·D rounds down to one share and loses up to half its value on entry. Because the last holder sweeps the whole accounted balance, the attacker also reclaims the virtual share's slice, which is the piece that normally makes this attack unprofitable. The proof test shows a victim's 0.13e18 deposit backed by only 0.09e18, and the attacker ending a round trip at 1.0137e18 for 1e18 staked despite the 15% exit fee. Proof is in test/scratch/Inflation.t.sol.

Finding 2, low, zero-payout share burn. Withdrawals have no mirror of the deposit-side zero-share rejection: a one-share exit at rate one pays zero, burns the share, and books the whole gross as retained fee when minAssetsOut is left at zero.

What held under the Math Precision, Boundary and Numerical Gap guides: fee split conserves gross exactly with the remainder going to retained, exchange rate never falls below its initial value for 6, 18 and 24 decimal assets, emission schedule is monotone and exact at segment end, reward fractions carry to 1e-36 and dust is released only at zero supply, rewardPerShare headroom is bounded, continueEpoch at the exact end reverts, zero-staker intervals go back to reserve, the sIMD hold blocks redemption only and not transfers, and forced ETH is isolated. Slither's leads on strict equalities, the modulo "PRNG", and timestamp comparisons were all traced and are benign.

Not reached: no fork check of the pinned mainnet code hashes for IMD, sIMD and WETH, and the ownership and deployment-script rows are marked holds only insofar as nothing in my area touches them.

The review is complete and .imd-findings.json holds the findings and a full coverage record (89 rows, all entry points answered). No repository file was changed; the only writes are the findings file and expendable scratch tests.

Outcome of the economics audit (Economic Security, Invariant, Flow Gap)

No critical, high or medium defect survived verification. The share and reward ledgers behave as specified under every sequence I could construct.

• Share and fee conservation holds. A scratch fuzz across all asset decimals 0 to 36, with three users, partial exits and a full drain, confirmed deposits always equal payouts plus Treasury fees, and the farm balance is zero when supply is zero. The 85/1/14 split, the last-exit full 15 percent to Treasury, and virtual-offset rounding all reconcile exactly.
• Reward ledger is solvent and non-double-pledging. A second fuzz over staggered deposits, partial burns and full exits showed every funded unit is either paid or returned to the free reserve, with earned liabilities and credits reaching zero at zero supply. A single-quantum staker across 20 epochs stays claimable with the index far from its cap.
• External dependencies verified. The pinned IMD, sIMD and WETH code hashes in the source match mainnet (checked by RPC during the review). The IMD-to-sIMD deposit path measures actual sIMD received, clears approval and reverts cleanly if the vault is paused, while direct sIMD exits are unaffected.

Findings written

1. Low. StakedETH.withdraw strands the payout when the beneficiary is the WETH contract or the Treasury. WETH's fallback accepts the native call and credits the farm, or the Treasury has no receive function and ends up holding WETH it can never spend. Reproduced with concrete balances in scratch tests. The fix is a one-line beneficiary check.
2. Info. The official sIMD vault's owner pause and rescue powers are an external trust assumption on value, not units. The farm handles them correctly, recorded so the judge has it explicit.
3. Info. The delivered invariant and fuzz suite covers only the 18-decimal mock; the 24-decimal and native ETH branches rely on fixed-value unit tests. My scratch fuzzing covered those branches and found nothing.

Coverage: 88 entry points marked holds, one (StakedETH.withdraw) marked finding. Admin-only functions outside my area were traced for guards and marked holds with that reason. Nothing was left unreached.

The review is complete and the findings are written to .imd-findings.json.

What I found

• High: retained-fee inflation attack is profitable (src/core/Farm.sol:121). The farm uses a 1-wei virtual share offset. That defense only works if the value absorbed by the virtual share is never paid out. Here it is: the "last holder takes all residual" branch of previewRedeem hands that value to whoever exits last. An attacker front-runs a 100 BLOOM deposit by depositing ~714 BLOOM and withdrawing all but one share, so the 14% retained fee leaves a single share backed by just over 100 BLOOM. The victim's deposit mints exactly 1 share. If the victim exits before the attacker, they receive 56.67 BLOOM instead of 85, and the attacker exits last with a net profit of about 14 BLOOM. The proof test in test/scratch/InflationProof.t.sol fails on the current tree and passes against a scratch copy with a 10^6 virtual-share offset, so the fix direction is confirmed.
• Low: a whitelisted asset that later taxes or blocks outbound transfers locks all principal. Deposits tolerate inbound taxes, but both the fee path and the user payout require exact transfers, and no recovery path can reach accounted assets. This matches the authors' own "unsupported" test, so it is reported as a documented design limitation with a concrete locking input.

What held

Everything else in the Execution Trace, Periphery and First Principles checklists traced clean: reward settlement ordering, zero-staker skipping, epoch state transitions, dust release at zero supply, the ETH native-then-WETH fallback, the atomic IMD-to-sIMD path with measured receipt and approval reset, treasury fee gating, two-step ownership and selective power renunciation. All slither and aderyn leads were examined and none survived as findings. The existing 61 unit tests pass, and my probe of zero-staker epoch completion followed by re-entry conserved every reward unit.

Coverage

All 90 listed entry points have a row. The deposit and withdraw entry points on every farm reference finding 1 since they share the affected conversion code. The rest are marked as holding, plus three rows for invariants and the static-analysis leads. No source file was changed. Only .imd-findings.json and the scratch tests under test/scratch/ were written.

Added 45 tests under test/, covering failure paths, rounding, permissions, integrations, and invariants across all three farms and Treasury.

Validation passed:

• forge build
• forge test: 107 passed, using the required seed
• New invariants: 24,576 randomized calls, zero unexpected reverts

No production defect was reproduced. Integration tests run offline; live-state validation remains pending.

The review is finished. .imd-findings.json in the repo root holds 5 findings and 91 coverage rows: all 89 entry points plus 2 invariants. No source files were changed, and the scratch tests and build output have been deleted.

Findings

1. High: share inflation through the retained 14% fee (src/core/Farm.sol:67). This merges two specialist findings with the same root cause (audit_flow fe1685 and audit_math fd7288).
   • Cause: the guard against share inflation is a single virtual share, and the last holder to exit gets everything left in the pool.
   • Attack: an attacker withdraws all but one share, so the 14% retained fee leaves that share backed by a large amount. A victim's 100 BLOOM deposit then mints exactly 1 share.
   • Result: if the victim exits first they get back 56.67 BLOOM, where 85 is expected after the fee. The attacker exits last and ends 14.12 BLOOM up.
   • Without an attacker: the same state arises naturally. Someone deposits 1 wei, a large holder exits fully, and the next 10 BLOOM deposit gets 1 share worth 8 BLOOM.
   • Both specialist proofs fail on the current code for the stated reason. I attached fe1685's.
2. Medium: a farm that can never activate permanently blocks its asset (src/BloomFactory.sol:83). Registration doesn't check the decimals that activate() later requires, so a farm built with the wrong decimals registers anyway. Its slot can't be cleared, and every later farm for that asset reverts with DuplicateFarm. Fixing it means redeploying both Factory and Treasury. The attached proof fails on the current code.
3. Low: StakedETH payout stranded for some beneficiaries (src/StakedETH.sol:47). Withdrawing with the WETH contract as beneficiary leaves the 85% payout as WETH in the farm, which only the owner can recover. Withdrawing to the Treasury leaves it as WETH there, where it can never be spent.
4. Low: deposits of a transfer-taxed token can't be withdrawn (src/core/ERC20Farm.sol:34). Deposits accept such a token by measuring what actually arrived. Every withdrawal of it then reverts, so that principal is locked while the tax is on.
5. Low: renouncing a farm's pause power doesn't remove the ability to stop deposits (src/core/Farm.sol:106). After the farm's PAUSE power is renounced, taking the asset off the Factory whitelist still blocks deposits and starting new epochs. Withdrawals and claims are unaffected.

Specialist findings dropped

• Zero-payout withdrawal burns shares: docs/ACCOUNTING.md says this is intended, so that dust can't block a zero-supply reset, and minAssetsOut protects the caller. The suggested fix would break that.
• sIMD vault owner powers: the docs record the vault owner as renounced, and this isn't a defect in this code.
• Fuzz coverage note: the specialist's own scratch fuzzing found no violation, so there's no defect to report.

My own pass

I reread the code and found nothing the specialists missed. This covered the reward ledger accounting, the epoch transitions, the ETH fallback path, the IMD deposit path (the sIMD one-block hold doesn't affect the farm, which never redeems) and Treasury spending. The launch.json manifest is deployable: 2 contracts, constructor arguments in the right order, no external calls in constructors, and small runtime sizes.

I reproduced every finding I kept by running tests. Findings 3–5 come from my own scratch tests and carry no proof file, since proofs are only required for high and critical.

Both mandatory findings reproduced and are fixed; the three advisory findings also reproduced and are fixed. All checks pass.

What changed

• Share inflation (high). Farm now keeps the virtual position at no less than one million share quanta for every asset. The pivot moved from 18 to 12 decimals, so BLOOM and ETH use a 1e6/1e6 offset and sIMD uses 1e12/1e6, while the initial rate stays one whole token per whole share. A later depositor's rounding loss is now bounded by one quantum, at most a millionth of the backing, and the inflater still pays the Treasury 1% plus 15% of its retained backing on exit. The last-holder residual rule is unchanged and the bound is documented in docs/ACCOUNTING.md.
• Registry slot (medium). Farm.verifyDependencies() now holds every activation precondition except registry membership, and BloomFactory._register calls it for both registerFarm and deployFarm. A farm with wrong decimals or on the wrong chain is refused at registration, the CREATE2 creation is rolled back, and the correct farm can take the slot.
• Stranding beneficiaries (low). Recipients that would strand a payout are rejected before any state change: Treasury, registry, underlying and reward tokens, plus WETH for the ETH farm and IMD for the sIMD farm.
• Taxed deposits (low). ERC20 deposits and the IMD leg of depositIMD revert unless the exact amount arrives, so a taxed token can never hold principal it could not pay back.
• Whitelist as second pause (low). Active farms no longer read the whitelist for deposits or epoch starts. The whitelist admits assets at registration only, so renouncing the pause power is final.

Verification

Tests I rewrote or added cover the proof scenario, the no-attacker one-wei-holder variant, offset values per decimal count, registration refusal via both factory paths, rejected recipients on all three farms, taxed deposit refusal, and whitelist-after-renounce semantics. README, ACCOUNTING, DEPLOYMENT and VALIDATION are updated, and .imd-responses.json answers all five findings as fixed.

The existing launch.json is correct and needs no change. This revision round listed no findings, and every check confirms the manifest as it stands.

What I verified

• Schema: launch.json has exactly kind, contracts and notes. Kind is evm_contracts. Notes are a single string of 1,791 characters, under the 4,000 limit.
• Contracts match the accepted source: BloomTreasury takes one argument, the owner, written as $owner. BloomFactory takes the owner then the treasury address, written as $owner and $contract:BloomTreasury. Both names are unique, short identifiers, and the reference points backward.
• Ownership: the Managed base assigns ownership from the explicit constructor argument, never from msg.sender or tx.origin, so the factory and the IMD launch wallet hold no role.
• Deferred farms are correctly omitted: StakedBLOOM, StakedSIMD and StakedETH each require the real BLOOM address in their constructors. BLOOM is created in Job 2, and the brief forbids a placeholder token. The notes document the activation path through the one-time bindBloom and bindRegistry functions.
• Build and tests: forge build succeeds and the full suite passes with the pinned fuzz seed. All 67 tests passed with 0 failures.
• Deployment rehearsal: a scratch test deployed both contracts via create2 from a factory address in manifest order on chain id 1. Both report the requester wallet as owner, the factory stores the treasury address, and both runtimes are under the EIP-170 size limit. That scratch test lives in test/scratch and is not part of the submission.

Working tree: clean. No file other than launch.json is part of the deliverable, and launch.json itself is unchanged from the accepted version.

The suite passes again: 117 of 117 tests, using the verifier's fuzz seed. Three of my earlier tests had broken because the implementation changed on purpose since my last round. I updated them to the new behaviour, added tests for the new checks, and changed only files under test/.

Updated tests

• Taxed deposits (test/TokenFailures.t.sol): a deposit where the farm receives nothing now reverts with InexactTransfer instead of InvalidAmount. I added a test for a 1% transfer tax: the deposit is refused, no tokens move and existing backing stays the same.
• Pause, not delisting (test/IntegrationFailures.t.sol): removing an asset from the whitelist no longer stops deposits into an active farm, so the old "disabled farm" test now pauses the farm instead. A new test shows that delisting the sIMD asset still lets someone deposit.
• Dependency checks at registration: the WETH check now expects registration itself to fail, both when WETH has no code and when its decimals are unset, and the asset slot stays free. A new test confirms activate() still re-checks if WETH's decimals change after registration. Another shows that both registration and activation refuse to run on the wrong chain.
• Payouts that would get stuck: a new test confirms the farms refuse to pay or credit an address that would trap the funds. That covers WETH on the ETH farm, IMD and sIMD on the sIMD farm, and the Treasury, across deposit, withdrawal, claim and recovery of excess funds.

Invariant test (test/NetworkInvariants.t.sol): the random-sequence handler skipped all deposits while an asset was delisted, which matched the old behaviour and left out cases that are now valid. Now only a paused farm blocks deposits, and in that case the handler checks that the deposit reverts with DepositsPaused and moves no assets. The invariant still passes over 256 runs with no unexpected reverts.

test/TESTING.md is updated to match. I found no new defects in the revised implementation, so I wrote no .imd-findings.json. As before, the IMD, sIMD and WETH checks run against recorded copies of their mainnet bytecode on a local test chain, not a mainnet fork. Checks against live mainnet state are still to be done.

The review is complete. Every finding from the previous round is fixed, and I found no new reproducible defect. The findings file at the repository root holds an empty findings list and a coverage row for all 89 entry points.

Settled findings

• High, share inflation through the retained fee. Fixed. The virtual position is now never below one million share quanta for every decimal count, with the initial one-token-equals-one-share rate preserved. All three attached proofs now pass. The one remaining failing test in the fd7288 proof fails at its own precondition, which asserted the victim mints exactly one share. The victim now mints 928,572 shares. My recheck confirmed the victim's backing stays within one quantum of their deposit, the victim's payout is at least 84.99 of 100, and the attacker ends below their starting balance in both the 100-token and 0.13-token scenarios, plus the no-attacker one-wei-holder variant.
• Medium, registration checked less than activation. Fixed. The registry now calls the farm's new dependency check at registration, so a farm with wrong decimals or chain reverts before it can take an asset slot, and a CREATE2 deployment rolls back with the salt reusable. Both attached proofs pass.
• Low, WETH or Treasury as beneficiary. Fixed. The base recipient filter rejects the Treasury, registry, underlying and reward token; the ETH farm also rejects WETH and the sIMD farm rejects IMD, on deposits, withdrawals, claims and recovery.
• Low, taxed deposits accepted but never withdrawable. Fixed. The ERC20 deposit path and the IMD leg now revert on any inexact receipt, so taxed principal is refused up front.
• Low, whitelist as a second pause switch. Fixed. The whitelist governs admission at registration only, so a renounced PAUSE power is final and epoch starts cannot be blocked through the registry.

Fresh pass on the revised code

I re-read the changed lines as new code and checked the static-analysis leads. The sanctioned residual, a later depositor's rounding loss of at most one quantum against a one-share holder, is bounded and unprofitable to set up because the inflater still pays the one percent and fifteen percent fees. I also confirmed that a non-final redemption can never exceed accounted assets for 6, 18 and 24 decimal offsets. The full project suite passes with 116 tests. Deployed sizes are all under the limit, and the manifest is schema-valid with one argument per constructor parameter and the Treasury referenced backward. The slither and aderyn lines are owner-gated paths, deliberate exactness checks, or guarded by the reentrancy lock, and none reproduced as a defect. I dropped the specialist's dust-level observation that a one-share redemption at rate one pays zero, since it is caller-selected, bounded by minAssetsOut, and worth one wei.

Trust assumptions, not findings: owner-triggered renounceOwnership on any contract, and post-registration ownership divergence between farms and the registry.