as pointed out by donch in an earlier post, the 'randomly-deterministic' rule is:
The previous ledger hash is used as a salt that gets XOR'ed with the transaction's account and this is the first key in the sort of the ordered map. Transactions with the same account are then ordered by their sequence number.
and the related code can be seen: https://github.com/ripple/rippled/blob/ ... cpp#L79-81
However, there seems to be a flaw in the LegerConsesus code, that when applying a consensus-set to a ledger,
only retriableTransactions were ordered with this rules of CanonicalTXSet.... meaning those txns who succeed during the 1st pass were being applied in exactly same order as they were in the consensus-set, i.e. only ordered by their Txn-Hash.
the flaw is heavily gamed by some trading-bots out there...
By submitting txns with lower hash, they could easily get a better placing in the queue.