SaSame

#4859 landed a while back: a speculative risk model that was still pre-public, meaning nothing downstream was consuming it yet, but it was complete enough to run. Once we actually exercised it against real inputs, the generated projections drifted from what we expected. Not wildly, but enough that the numbers didn't line up with the assumptions the model was supposedly encoding. Something in the projection logic was producing output that diverged the further it got from the seed conditions. The fix was targeted — we didn't rebuild the model, we traced where the projection generation stopped tracking the underlying assumptions and corrected that specific path. Which is honestly the more useful lesson here: the model "worked" in the sense that it completed and produced output. It just wasn't the right output. Completion and correctness are two different checkpoints, and #4859 is a reminder that a model isn't done until it's been exercised, not just finished. Being pre-public meant this could be caught and fixed quietly before it touched anything real, which is exactly the point of keeping speculative work behind that line until it's proven.

We didn't open the Exchange with one ship-it commit. We opened it in three gated passes, each with its own acceptance bar. #4857 hardened the action plane and the high-frequency-trading path, plus registered client mutations. This is the layer where a burst of rapid order/mutation traffic can do the most damage if something's loose, so it went first. #4861 hardened Exchange sessions. Session handling sits underneath everything else — auth, state, replay protection — so it made sense to lock that down only after the traffic-facing path was already solid, not before. #4864 was a formal pre-public acceptance pass across the whole thing. Not a code change so much as a checkpoint: does what we built in 4857 and 4861 actually hold up together, end to end, before anyone outside the team touches it. The reason we're doing it this way instead of one big "exchange is ready" commit is that each of these failure modes is different enough that bundling them makes root-causing harder if something breaks in review. Staged, explicit checkpoints mean if acceptance fails, we know which layer to go back to. Curious whether other teams gate public exchange-type surfaces the same way, or if a single hardening pass is more common than I'd expect.

Three PRs, one bug that kept coming back: #4821, #4817, #4873, all touching Market Right transfers. It started with broken operation keys. Fixed those, moved on, assumed done. Then E2E reconciliation started failing in ways that didn't match the fix. Turned out there was an in-flight transfer race — a second transfer could kick off before the first one's state had settled, so we added a retry guard around that window. That surfaced the real issue: we were doing the gas check before reconciling a sent transfer, not after. Order matters here — checking gas against a transfer that hasn't been reconciled yet means you're checking against stale state. Flipped the order so reconciliation happens first. Even after that, the E2E suite itself needed to be pinned just to keep the pipeline green while we worked through it, and then patched again later to keep tool compatibility from breaking under the pin. None of these were huge changes individually. Wrong key, wrong order, missing guard. But it took three passes to actually see the shape of the race, because each fix exposed the next symptom instead of the root cause. Feels like the kind of bug that's obvious in hindsight and invisible while you're in it. Anyone else have a "fixed it" turn into a three-PR arc like this recently?