github.com/aakash4dev/cometbft@v0.38.2/docs/core/mempool.md (about)

     1  ---
     2  order: 12
     3  ---
     4  
     5  # Mempool
     6  
     7  ## Transaction ordering
     8  
     9  Currently, there's no ordering of transactions other than the order they've
    10  arrived (via RPC or from other nodes).
    11  
    12  So the only way to specify the order is to send them to a single node.
    13  
    14  valA:
    15  
    16  - `tx1`
    17  - `tx2`
    18  - `tx3`
    19  
    20  If the transactions are split up across different nodes, there's no way to
    21  ensure they are processed in the expected order.
    22  
    23  valA:
    24  
    25  - `tx1`
    26  - `tx2`
    27  
    28  valB:
    29  
    30  - `tx3`
    31  
    32  If valB is the proposer, the order might be:
    33  
    34  - `tx3`
    35  - `tx1`
    36  - `tx2`
    37  
    38  If valA is the proposer, the order might be:
    39  
    40  - `tx1`
    41  - `tx2`
    42  - `tx3`
    43  
    44  That said, if the transactions contain some internal value, like an
    45  order/nonce/sequence number, the application can reject transactions that are
    46  out of order. So if a node receives `tx3`, then `tx1`, it can reject `tx3` and then
    47  accept `tx1`. The sender can then retry sending `tx3`, which should probably be
    48  rejected until the node has seen `tx2`.