Suppose I have 2 transactions calling the same contract with a very high gas price, let's say 1000 gwei for tx a and 1001 gewi for tx b. If tx a is sent first before tx b, will tx b be faster to execute the contract since it has higher fee?

In my testing on the testnet however, tx a is faster to reach the contract when they are included in the same block. So my assumption is if 2 tx are included in the same block, then instead of picking up the the one with higher fee it will be "first come, first served". Is my assumption correct?

  • Hi there. Are you sending the two transactions from the same node/account, or different nodes/accounts? Commented Feb 14, 2018 at 17:03
  • I sent them from the same node with different accounts Commented Feb 14, 2018 at 17:10
  • Did you send them at exactly the same time or there was some delay like a few seconds? Commented Feb 14, 2018 at 17:41
  • there was a 1-2 seconds delay Commented Feb 14, 2018 at 17:41
  • 1
    @user3082537 sorry I meant whatever testnet you used, not necessarily rinkeby. Commented Feb 14, 2018 at 18:19

1 Answer 1


Put your "miner theory" hat on.

In theory, a miner could select one tx over another even if the one skipped was willing to pay more. Not only does gas price come into play, but so does gas units. The miner typically wants to squeeze the block full with the highest paying gas prices. But if the lower cost had lower total gas units, then the miner could select that tx to fill the current block if that block was near it's limit.

For more info here's a good article. Feel free to skip down to:

  1. Transaction is broadcast to the network

and pickup from there.

If you notice the picture above, the miners store all the transactions in the pool sorted by gas price. The higher the gas price, the more likely the transaction is included in the next block. This is the common configuration for a miner node (to optimize for higher pay). However, a miner can configure her node to sort the transactions however they like (say they want to help the network by mining only low gas transactions).


Had a good talk with Sebastian about this one.

So let's define somethings that are currently unclear.

If both transactions are from the same address, the protocol enforces the nonce. So even if the first tx has a lower gas price, it will be and HAS to be included before the later nonce. QnA


  1. Transaction Execution Yellow Paper

If both tx are from different addresses then it is up to the miner in which order they are included in the same block. QnA

Thanks, again, Sebastian for discussing this topic further with me so I can provide a better response :)

  • 1
    Agreed on the game theory aspect, but that wouldn't explain why both transactions were included in the same block, but effectively in reverse expected order :-\ Commented Feb 14, 2018 at 18:53
  • 1
    I thought there would be no guarantee of any order unless there is an order inherent in the transactions, i.e. if an account receives some ether in tx a, which it spends in tx b, then putting tx b first will not pass validation. So tx a would have to be processed first. Otherwise, if there is no such dependency, I do not see anything that would impose an order. Commented Feb 14, 2018 at 19:25
  • Hmm... More research on this, I shall do. Commented Feb 14, 2018 at 19:44
  • @AjoyBhatia how about a nonce? Every transaction must include a nonce so it makes sense that the miner will sort transactions by nonce. Commented Feb 14, 2018 at 21:07
  • 1
    @AjoyBhatia - If A and B are from the same account, the order will be enforced by the transaction nonces. If A and B are from different accounts, B will only be allowed (i.e. put into a block by a miner) if it makes a valid state change (which as you say, may require the state imposed by A to be valid as a prerequisite). Commented Feb 14, 2018 at 21:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.