Banked: 2026-06-11 (Rule-38 4th-core sweep, Euler v2 EVK+EVC) Class: post-audit regression hunting / split-codebase fix verification
Euler's highest-severity audit fix (Spearbit 5.1.2 / OZ H-01: self-liquidation via oracle sandwich) was implemented as a SPLIT across two independently-versioned repositories:
checkAccountStatusInternal -> accountControllersStorage.metadata = uint80(block.timestamp)
(commit "feat: store last account status check timestamp", EVC PR157)Liquidation.sol: isInLiquidationCoolOff reverts if
block.timestamp < getLastAccountStatusCheckTimestamp(violator) + liquidationCoolOffTime
(EVK PR191)A naive single-repo Rule-38 sweep of EVK alone would see only the READ side
(getLastAccountStatusCheckTimestamp(...)) and could either (a) miss that the protection
is real, or (b) wrongly flag the EVK side as a deleted/incomplete fix because the WRITE
half lives in another repo entirely.
The two repos drift on DIFFERENT timelines. At the time of this sweep: - EVK HEAD = 2025-03-05 - EVC HEAD = 2026-05-11 (>1 year newer)
A cross-repo protection is only as strong as its STALEST consumer assumption. When the provider repo (EVC) keeps shipping commits after the consumer (EVK) froze, you MUST verify the provider STILL writes the state the consumer reads, at the provider's HEAD - not at the audit-era commit. (Here it held: newest EVC commits only touched message-signer address-space exclusions, never the status-check timestamp write.)
38.4-B-cross-repo: When a fix is split across repos (connector/controller + vault, core + periphery, hub + spoke), follow the protection into EVERY repo that participates. Verify: 1. Provider repo still WRITES the state, at provider HEAD (not audit commit). 2. Consumer repo still READS + ENFORCES it, at consumer HEAD. 3. The interface signature between them is unchanged (the getter selector must match). 4. Check the provider's POST-AUDIT commits specifically for changes near the write site. A "missing" guard in the consumer repo is NOT a finding until you've confirmed the provider repo doesn't supply it.
Spearbit 5.5.35 (inconsistent liquidation yield/repay rounding) was correctly SKIPPED as a math-tautology trap: it guards an arbitrary discount computation, not a conserved quantity, and Euler acknowledged-no-fix. Meanwhile the donation/inflation guard WAS a clean differential-math question (virtual-deposit inflation inequality, not a tautology) so it got an actual Foundry pure-math test (3/3 PASS). 38.4-A correctly routed one to skip and one to test.
Self-contained Foundry math test of EVK conversion + donation guard:
/home/babakinzo/bounty/coord/r38/mathtest/test/EVKConversion.t.sol (replicates
ConversionHelpers + Assets/Shares rounding; reusable template for any 4626-class
virtual-shares vault donation check).