> they could bucket orders by e.g. second resolution and then execute the orders in a bucket in random ordering. This will give predictable ordering at second r

> they could bucket orders by e.g. second resolution and then execute the orders in a bucket in random ordering. This will give predictable ordering at second resolution but would make front-running or racing impossible as the sub-second ordering would be unpredictable. In that case I as a broker who knows that one of my clients has just channeled a big, market-moving buy order of some stock through me to the exchange would simply inject a few hundred of smaller orders that buy the same stock, but with a low limit price that's slightly above the current price, but likely below the price the stock will be traded at after the big buy order has been executed. Statistically I will then get half of my orders executed before the big one hits, the other half of them will be ignored because the limit has been exceeded, which results in a nice, nearly risk-free profit for me. I could even try to put some sell orders in there with a sell limit slightly above the estimated price after execution of the big order in an attempt to sell the same stock that I just bought in the same batch that I got them. Similar stuff can also be done without direct knowledge about some big order coming through, but just on the assumption of such orders being placed into the market by various participants due to external events. The game just moves from being one in which everyone tries to beat the clock into one in which everyone tries to predict the orders in the next "execution batch" and how to best generate your own orders to profit from that. Since that's still a race against time (there's a limited window of time in which you need to get your orders in) the entire aspect of getting your orders to the exchange quickly is still relevant, hence there will still be massive investments into that. It's just that in such a case, you add another aspect into which people can invest massively: compute power to perform as many statistical simulations of the next execution batches' contents as possible in as little time as possible. I guess such statistical prediction stuff is already being done by HFTs today, but due to there being no clearly delimited time window granted to the HFTs that would be large enough to do very complex simulations, I guess this complex statistical modeling is done on larger timescales, like to devise trading strategies over weeks, months or years, and the modeling that produces the orders that quickly react to sudden market events is probably pretty simple because it must be absurdly fast, producing results in microseconds. So what you would get is something very much like the Bitcoin blockchain hash race, just not for something as trivial as hashes, but for the best possible advance simulation of the next "order block". Doesn't matter in the end, though, because both are embarrassingly parallel problems and thus can and will easily be blown up to consume as much energy and hardware as you can provide. The one thing that prevents this from happening in our current trading system is the continuity of the timescale - which is exactly what you'd like to eliminate!