How can I debug exluded transactions?

The Flashbots Ship
1

Hi! I have a question about how transaction inclusion works in Flashbots Protect.

I sent a private transaction with a positive priority fee. It was targeted for three specific blocks. Later, I simulated the transaction at the end of each of those blocks, and it successfully executes in all of them. All three blocks had plenty of unused gas, so block fullness wasn’t a constraint.

However, the transaction was still not included, and the Flashbots API returned status: FAILED, isRevert: false, seenInMempool: false.

My question is:

Under what conditions would a private Flashbots Protect transaction be skipped even if it:

does not revert when appended to the actual block,

fits comfortably within the gas limit,

has a positive priority fee (so it gives the builder some revenue),

and I had the relevant builders selected in Protect?

Why builders may ignore low-value private transactions even when blocks have room?

Here’s an example in case it helps:

https://protect.flashbots.net/tx/0xff0d4cce391d5e49af5eb1e518a5c63d658c43c55151536eaa95a43125313b6d

In case no one knows, a pointer to some place I could ask this would be already helpful.

Thanks!

2 Likes
2

Hey,

I ran a quantitative risk analysis on your transaction to understand why it didn’t get included, and the numbers tell the story clearly. On the surface, everything looked fine: the transaction doesn’t revert, it fits within the gas limit, it has a positive priority fee, and the relevant builders were even selected.

But the probability math reveals why that wasn’t enough.

>
TransactionData :{"status":"FAILED","hash":"0xff0d4cce391d5e49af5eb1e518a5c63d658c43c55151536eaa95a43125313b6d","maxBlockNumber":23925248,"transaction":{"from":"0x943810707e090f1bdc486c4c990d43da3b162e52","to":"0xa9d635ef85bc37eb9ff9d6165481ea230ed32392","gasLimit":"3265288","maxFeePerGas":"237695242","maxPriorityFeePerGas":"103252809","nonce":"20007","value":"0"},"fastMode":false,"seenInMempool":false,"isRevert":false}

Here’s the simple breakdown I found:

Your 0.103 Gwei priority fee sits in the bottom percentile. Most builders enforce minimums around approximately 1–5 Gwei, so almost nine out of ten times, your transaction is rejected before block construction even begins.

On top of that, with fastMode disabled, only one builder received your transaction. That builder wins roughly 35% of blocks based on market share, which means that even if the transaction is accepted, there’s still a 65% chance it won’t be included in the next block.

Putting these factors together makes it really clear why the transaction struggled; low fee plus limited builder visibility leads to very slim inclusion odds.

I plotted a graph to show that the top two reasons: Priority Fee Too Low (Figure 1) and Builder Selection Mismatch (Figure 2). The chart clearly illustrates that even with a positive fee, a fee that’s too low, combined with limited builder selection, makes inclusion very unlikely.

Figure 1
Figure 11684×876 94.9 KB

Figure 2
Figure 21878×990 160 KB

Well, the Bottom line:

Even though the transaction was technically valid, it failed because the fee was too low and only one builder received it. Taken together, this gave it a very slim chance of being included within the target number of blocks. To be precise, about an 11.9% chance of inclusion over three blocks.

Thank You.