Smart contract maxis, Your Solidity compiler may have quietly deleted a store you needed, and you'd never see it in your source. Solidity 0.8.38 came out last Thursday. It fixes a bug in the Yul optimiser that sat in every release from 0.8.19 to 0.8.37. The optimizer keeps notes on what's in memory and storage. It uses those notes to replace a load with a value it already knows, and to skip a store that writes what's already there. To decide whether two addresses can overlap, it describes each one as a base variable plus an offset. Same base, different offset, so they must be different slots. Those descriptions were cached. Then someone reassigns the base variable. The optimiser doesn't always notice. Now it compares an address built from the old value with one built from the new value as if they shared a base. It decides they're different, but at runtime they point to the same place. The result is a stale note. A later load can return an old value. A store you needed can get removed. A keccak256 over that location can hash outdated data. Only code compiled with the optimizer on is exposed. With via-IR, any code can hit it, even without inline assembly. With the default legacy pipeline, only some inline assembly and compiler-generated helpers. Unoptimized builds are safe. The team rates it low severity, and they did something I wish every compiler team did. They recompiled every verified contract in the Sourcify database with and without the fix, and the bytecode was identical for all of them. So it's rare. Rare isn't the same as never, especially if your code is fresh and not deployed yet. The bug came in through the Ethereum Foundation bug bounty, and a second report showed plain Solidity without assembly can trigger it.