transaction-ordering dependence

Transaction-ordering dependence is the underlying property that makes a contract's outcome depend on the order in which transactions are mined, an order that no user controls. Two transactions that are individually valid can produce very different results depending on which lands first, and on most chains the entity that chooses the order, the proposer or block builder, can pick whichever ordering is most profitable. Whenever correctness or fairness rests on an ordering the user cannot pin down, the contract has a latent race condition.

Front-running and sandwich attacks are exploits; transaction-ordering dependence is the deeper condition they exploit. Classic examples include a reward that goes to whoever calls claim first; a swap whose execution price depends on whether an attacker's trade precedes it; and the ERC-20 approve race, where changing an allowance from one non-zero value to another can be exploited if the spender front-runs the change to spend at both the old and new limits. The common thread is that the same set of transactions yields different states under different orderings.

Mitigations attack the dependence rather than any single attacker. Commit-reveal removes the information an ordering attacker needs. Designing operations to be order-insensitive, for instance setting an allowance to zero before setting a new value, or pricing trades against a TWAP rather than the instantaneous pool, removes the profit from reordering. Batch auctions and fair-ordering protocols attempt to neutralize proposer discretion. The mindset is to assume an adversary controls the order and ask whether your invariants still hold.