Found Monday 2026-04-27 morning while attempting to verify #61 fix on live Anvil stack. **Hard blocker for #61, #65, #66, #67, #71 verification AND mainnet deploy.** ## Repro ``` cd /srv/qa/repos/yieldomega SKIP_ANVIL_RICH_STATE=1 bash scripts/start-local-anvil-stack.sh ``` Stack reaches `=== Deploy (DeployDev) ===` then exits 1. Per `/tmp/yieldomega_deploy_dev.log`: ``` Error: `TimeCurve` is above the contract size limit (28454 > 24576). ``` ## Direct measurement ``` forge build --optimizer-runs 1 jq '.deployedBytecode.object | length / 2 - 1' out/TimeCurve.sol/TimeCurve.json # 28454 forge build --optimizer-runs 200 jq '.deployedBytecode.object | length / 2 - 1' out/TimeCurve.sol/TimeCurve.json # 28783 ``` Cap is 24,576. Overage is **~3,878 to 4,207 bytes** depending on optimizer setting. `--optimizer-runs 1` (used by `scripts/start-local-anvil-stack.sh` to fit local) doesn't help. Higher runs makes it slightly larger here. ## Likely cause `contracts/src/TimeCurve.sol` git history: ``` 6d52ce6 fix(timecurve): opt-in WarBow flag plant on buy (GitLab #63) d36cccb feat(contracts): TimeCurveBuyRouter + buyFor for single-tx Kumbaya buys cf6fe19 feat(contracts): gate WarBow CL8Y burns on sale interactions (issue #55) f2500ec feat(contracts): final signoff gates for DOUB claims and TimeCurve value (issue #55) 0048249 feat(contracts): UUPS + ERC1967Proxy for core routing (GitLab #54) ``` Most likely culprit is `d36cccb` adding `buyFor` (which TimeCurveBuyRouter calls) plus the surrounding storage / gate logic, with `6d52ce6` and `cf6fe19` adding more on top. Sunday baseline (`9a183b9` end of day) was probably already over but I didn't run a full stack on Sunday — only verified at source level for #55/#56. Forge tests pass (191/191) because they don't enforce EIP-170 (Anvil's `--code-size-limit` defaults disable it for tests). ## Impact - **#61 verification BLOCKED.** `482a25a` fix can't be tested because the deploy itself fails before the proxy address resolution code path even runs. - **#65, #66, #67, #71 verification BLOCKED.** Whole single-tx Kumbaya buy stack depends on a deployable TimeCurve. - **#38, #39 still blocked** (transitive). - **MegaETH TGE April 30 = 3 days from now.** Mainnet deploy fails the same way; EIP-170 is mainnet-enforced, not just an Anvil flag. ## Mitigations the team may want to consider - Move TimeCurve sub-functions into libraries (external, delegatecall) — biggest typical EIP-170 fix - Use `--code-size-limit` Anvil flag for local testing as a stop-gap so QA can keep moving on #61, BUT this **does not fix mainnet** - Audit recent additions (`buyFor`, WarBow CL8Y gates, signoff flags) for inlining opportunities or shared internal helpers - Consider splitting `TimeCurveBuyRouter` integration so the router does more of the work and TimeCurve stays minimal I'll wait for direction before re-running the stack — running with `--code-size-limit` Anvil flag would let me move on #61 verification, but I want to make sure that's the right call given mainnet timing. cc @PlasticDigits