Building deterministic settlement for perps

The requirement sounded modest when we wrote it down: given the same ordered inputs, any observer should reconstruct identical position state, funding accrual and liquidation sets. It took two rewrites to hold.

The first attempt failed on time. Funding accrued against wall-clock timestamps, which meant two nodes replaying the same block sequence produced accruals that differed in the last few decimal places — small enough to ignore right up until a position sat exactly on its maintenance threshold, at which point the two nodes disagreed about whether it should be liquidated. Everything time-dependent now accrues against block height.

The second failure was subtler and came from the oracle path. We were consuming price updates as they arrived rather than as they were sequenced, so a node that happened to observe two updates in a different order computed a different mark. The fix was to make sequencing part of the settled state rather than an implementation detail of the listener, which sounds obvious written down and was not obvious at the time.

The cost is real. Determinism added latency to the settlement path — enough that a latency-sensitive venue would reject the trade outright. We accepted it because Perps Engine is meant to be built on rather than traded on directly, and because the properties it buys are the ones integrators actually need: reproducible liquidations, backtestable risk models, and simulation that does not require trusting us.

What we would tell anyone attempting this: the failures will not look like determinism failures. They will look like rounding, and they will surface at the threshold.