A transaction can be included in a block and still be useless to your bot. A competing liquidation can execute first. A swap can move the pool price before your arbitrage runs. Your own transaction can appear in the block with a failed receipt and a gas bill.
That distinction matters when reading about FOCIL, short for fork-choice enforced inclusion lists. EIP-7805 proposes a way for validators to constrain which transactions builders may omit. It does not give a searcher a reservation at the top of a block, and it does not make an included transaction succeed.
Status checked September 16, 2026: FOCIL is a draft EIP and the consensus-layer headliner identified for Hegotá, the fork after Glamsterdam. The EF Protocol Cluster’s September 7 assessment ranks it S-tier. That is not mainnet activation, and there is no confirmed Hegotá mainnet date. The mechanics below describe the published proposal, not a service your bot can use on mainnet today.
The problem is omission, not slow RPC
A builder chooses the transactions and their order in an execution payload. Without an inclusion mechanism, a valid transaction can be left out because the builder does not want to include it. Paying a competitive fee does not itself create a protocol obligation to carry that specific transaction.
ePBS addresses a different problem. It moves the builder’s payload commitment and payment relationship with the proposer into the protocol. It does not, on its own, tell the builder which user transactions to include.
FOCIL adds that constraint through validators. A rotating committee constructs inclusion lists from its members’ local views of pending transactions. Builders receive those lists while preparing the next payload. Attesters use their stored lists when deciding whether to vote for it.
A better RPC connection can reduce the delay between your process and its node. It cannot substitute for this protocol rule, and it cannot force a committee member to select your transaction.
How an inclusion list reaches a block
The draft specifies a committee of 16 validators and a maximum of 8 KiB of encoded transaction data per list. Those are proposal parameters, not final Hegotá operating limits. Committee members can use different selection policies, such as transaction age or fee, and the EIP does not introduce an explicit reward for list construction.
The important steps are:
- Committee members publish signed lists. Each member builds from the transactions it knows about. No single member has a complete global mempool.
- Validators store lists before a view deadline. The deadline bounds which lists an attester uses for its decision. Equivocation evidence is tracked so that conflicting lists from one member can be excluded.
- Builders collect the constraints. This applies to an external builder or a proposer building locally. The builder can arrange its payload as it chooses, provided the result satisfies the inclusion-list rules.
- Attesters ask whether the resulting payload satisfies their lists. An omitted transaction is not automatically a failure. The execution-layer check considers the state after the payload and its remaining gas.
The published EIP includes an illustrative slot timeline. Do not copy its second marks into a production deadline scheduler. Hegotá must integrate FOCIL with the ePBS payload flow and its transaction-eligibility changes. The EF’s priorities post explicitly identifies the interaction between inclusion and Frame Transactions as an engineering requirement.
The actual obligation is conditional
The execution-layer algorithm in EIP-7805 is more precise than “include everything on the list.” For each listed transaction:
| Check | Result |
|---|---|
| Transaction is already in the payload | This transaction’s inclusion condition is satisfied |
| Its gas limit exceeds the gas remaining in the payload | It may be omitted |
| Its sender nonce or balance makes it invalid against the payload’s post-state | It may be omitted |
| It is absent, fits the remaining gas and passes the validity checks | Return INCLUSION_LIST_UNSATISFIED |
Notice the state reference. The check is against the state after executing the payload, not the state the committee member saw when building the list.
Suppose a listed transaction spends nonce 42. The builder includes another valid transaction from the same sender with nonce 42. The listed transaction can no longer be appended because that nonce has been consumed. Its absence is not the same case as omitting a still-valid, affordable transaction that fits.
Likewise, an otherwise valid transaction may be omitted when its gas limit exceeds the remaining block gas. The draft compares the transaction’s gas limit, not a guess at how much gas a successful execution might actually use.
The enforcement is in fork choice. The execution payload can be valid under ordinary execution rules while failing the additional inclusion-list condition. Honest attesters with the relevant stored lists then withhold their votes. Calling every omission an invalid EVM block loses that distinction.
Inclusion does not determine ordering
FOCIL does not require list transactions to execute first, last, together, or in the list’s own order. Builders retain ordering freedom subject to execution validity and the inclusion constraints.
Consider a liquidation transaction that is valid at the current head. Another liquidation runs earlier in the block and closes the position. Your transaction may still be valid at the transaction-envelope level: the signature, nonce and available balance permit execution. But the contract call can revert because the position is no longer liquidatable.
FOCIL does not protect that opportunity. Nor does it guarantee that an arbitrage executes before the swap that removes the spread. It addresses deliberate omission of eligible transactions, not a searcher’s preferred execution position.
A private bundle can express ordering and atomicity requirements to a builder under that builder’s API. Whether the builder accepts and includes it remains a separate matter. A successful simulation or a returned bundle hash is not a promise of inclusion. The Flashbots troubleshooting guide covers that part of the pipeline.
Inclusion does not guarantee execution success
An execution revert does not necessarily make a transaction invalid for block inclusion. It can consume gas and increment the sender’s nonce while reverting its EVM state changes. That is why a failed swap can have a canonical receipt.
The proposed inclusion-list check does not prove that a swap meets its slippage bound or that a liquidation remains profitable. Those are application conditions. Keep them in the signed transaction and enforce them in the executor contract.
For a bot, this leaves three different questions to answer:
- Can this signed transaction be included? Check chain, nonce, balance, fees and transaction validity.
- Will this call succeed in the simulated state and position? Run the actual executor path with its sender, calldata, value and dependencies.
- Will success still meet the strategy’s profit requirement? Include swap costs, gas and any builder payment in the calculation.
FOCIL does not collapse those checks into one. Raising a fee or securing a place on a list is not a replacement for simulation.
Public visibility and private transactions are different issues
The draft list-building flow starts with the committee members’ subjective mempool views. A transaction sent only to a private builder need not reach any committee member. A transaction broadcast publicly need not be selected either: lists are bounded and selection is discretionary.
There is a second meaning of “private transaction” in the Hegotá work. Privacy-preserving applications can publish a transaction whose validity can be checked without exposing all the application’s underlying private data. The EF discusses Recent Roots for Frame Transactions (EIP-8272) and VOPS Profiles for FOCIL Eligibility (EIP-8369) as supporting that path.
That is not the same as keeping an ordinary signed swap hidden in a builder’s inbox. Recent Roots does not make a builder-private transaction automatically visible to validators, and it is not a general encrypted-mempool upgrade. The transaction still needs to reach the inclusion mechanism in an eligible form.
Do not market a node’s mempool feed as a way to see private builder flow. Our mempool troubleshooting article separates propagation problems from transactions a public feed could never have observed.
There is no standardized FOCIL bundle endpoint
An inclusion list contains transactions, but it is not a searcher bundle with all-or-nothing execution semantics. Listing two transactions does not require that they both appear if one becomes invalid, and it does not require that they remain adjacent.
A scheme that routes transactions directly to committee members would have to handle a rotating committee, list-size limits, member selection policy and propagation deadlines. EIP-7805 does not define a public sendFocilBundle API or a receipt promising a particular position.
For ordering-dependent work, keep using the submission channels your builders actually support. If a provider introduces an inclusion-list product, inspect its guarantees separately from the protocol proposal. In particular, ask what happens when only part of a submitted sequence remains eligible.
What builders and searchers should prepare
Builders need to receive inclusion lists reliably, track equivocation and re-evaluate obligations as their candidate payload changes. Appending one transaction can change a listed sender’s nonce or balance, which changes which other transactions can still be appended. The EIP discusses this dependency explicitly; a single check against the parent state is insufficient.
Searchers should prepare observability rather than invent new submission code before an API exists. Keep the exact signed bytes, simulation state, target block, submission acknowledgement and canonical execution result. Distinguish a missing transaction from an included transaction that reverted. Distinguish both from a successful transaction whose opportunity was consumed earlier in the block.
When compatible testnets and client releases are available, exercise those cases against the actual combined fork implementation. Until then, use the proposal to identify assumptions, not to promise customers a maximum inclusion time.
BLAZED.sh runs scripts and containers beside an Ethereum mainnet node. That keeps the application-to-node path local, but it provides neither a FOCIL submission service nor an ordering guarantee. The relevant operational work is still accurate state reads, simulation and explicit handling of unsuccessful submissions.
The distinction to keep
FOCIL makes omission of certain listed transactions a fork-choice issue. Its obligation is conditional on the transaction still being appendable and fitting the remaining gas. It does not choose your execution position, preserve a trading opportunity or waive the cost of a revert.
For the surrounding upgrade, see the Hegotá EIP assessment. For the builder/proposer change arriving first, see ePBS and EIP-7732. Keep those protocol changes separate from the guarantees offered by whichever submission API your bot uses.