I've got a script running that sends a transactions to the chain every block. I've confirmed my network that tx are consistently being sent every 350ms and the RPC is receiving them with 10ms response time. It's running on an EC2 so I believe the network is not an issue.

When I'm reviewing the transactions on solscan, I'm noticing many gaps of 5-10 blocks where my transactions don't hit, and the occasional bunch up of three to five transactions in a single block.

Can someone help me understand the mechanics of how transactions are selected and included within blocks to explain why this might be happening, or if potentially there is another explanation? I'd like to see consistent block to block transactions if possible.

Or are there any better ways to troubleshoot & things I should be looking at?

1 Answer 1


currently with the low cost of failing a transaction (<1 cent) and due to the shitcoin sniping hype, people are constantly spamming RPC's with transaction with the hope than one of them will land early enough that they will make profits.

How does Solana contains the transactions? RPCs queues the incoming transactions, and they get sent in a FIFO manner Leaders (solana validator in charge of building current block) receives transactions from RPCs within their TPU (transaction processing unit) and process them in a FIFO manner as well(this is quite not true but lets consider it is)

So why do all your transactions lands at the same time When under high load, the RPC knows that the leader will receive too many transaction and wont process them all, so the RPC sends your transaction to the current leader but it sends it at the next leader, the next-next leader etc (the amount of forward depends on the RPC settings)

so lets say

1st transaction | ts = 0ms | sent to leader, leader+1, leader+2

2nd transaction | ts = 400ms | sent to leader(old leader+1), leader+1(old +2), leader+3

3rd transaction | ts = 800ms | sent to leader(old+2 of 1st txn), leader+1, etc

if your 1st doenst get included in block built by leader and leader+1 but get included in leader+2, where for whatever reason leader load got lower and that you kept sending txns the way decribed above, your 1st transaction and 2nd might land in their respective leader+2 and leader+1 which is the 3rd transaction current leader

  • Thank you, very very helpful. A couple followup questions if you don't mind: 1) It sounds like if I sent the same tx (with the same blockhash) multiple times within a second, it won't matter because the RPC is what is holding it back? 2) Would higher priority fee get me included in those blocks with many txs above those already there? Commented Apr 3 at 15:31
  • 1
    1/ yea if you dont use a dedicated rpc its most probable that the rpc is just queuing it and not sending instantly 2/no as of my knowledge priority fees are just used to get ur txn executed earlier when already included in a block but not to higher your chances of getting included (would have to double check this, im not sure its 100% true but i havent played with prio fees enough yet)
    – 4cAsrSgN9r
    Commented Apr 3 at 15:42

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.