← All articles

Relay Inclusion Lists: Censorship Resistance Without a Hard Fork

@0x3hu79
@0x3hu79
April 2, 2026 · Censorship Resistance
#FOCIL#relays#censorship-resistance#PBS#block-building#inclusion-lists

FOCIL (Fork-Choice Enforced Inclusion Lists) is coming to Ethereum - a protocol-level mechanism where randomly selected committees force transactions into blocks, making censorship physically impossible. But FOCIL requires a hard fork, and hard forks take time.

In April 2025, Michael and Kubi from Gattaca/Titan published a proposal for relay inclusion lists (rILs) - a way to get FOCIL-style censorship resistance today, at the relay level, without any protocol changes, new trust assumptions, or significant technical complexity. The mechanism is designed as a default-on feature for non-censoring relays, with an opt-out for validators who prefer otherwise.

This is a pragmatic, deployable approach to a problem that has plagued Ethereum since the Merge, when up to 78% of blocks were OFAC-compliant censored for a period. Here’s how it works.

The Core Idea

Today, relays run the auction between builders and proposers but have no opinion on what transactions appear in blocks. The winning builder decides, and if that builder wants to exclude certain transactions, the relay has no mechanism to prevent it.

Relay inclusion lists change this. The relay independently generates a list of transactions from the mempool that should be included in the next block - and then enforces that builders include them. A block that omits a valid IL transaction gets rejected.

The critical design principle: this adds censorship resistance without changing the validator’s risk/reward profile. Validators remain blind to the IL’s contents, just as they’re blind to block contents today. The relay handles everything.

How the Scoring Rule Works

The relay needs a deterministic, fair way to decide which mempool transactions belong on the inclusion list. The proposed rule balances two intuitions: transactions that have been waiting a long time deserve inclusion, and transactions paying high fees signal genuine demand.

Step 1: Score each transaction

For each transaction in the mempool, compute two normalized scores:

The total score is the sum of both.

Step 2: Adjust for size

The total score is divided by the transaction’s byte size, producing a “density score” - value per byte. Transactions are ranked by descending density.

Why this design is clever

Normalizing by the median makes the formula self-adjusting. During fee spikes, the fee component dominates - high payers get included first. During congestion with stale transactions, the waiting time component dominates - long-waiters get priority. The median is also resistant to manipulation: an attacker spamming low-fee transactions just pushes the median down, making every other transaction score higher.

Density scoring (per byte) maximizes the number of distinct originators on the inclusion list. The list has a hard 8 kB cap (matching FOCIL’s spec). Favoring smaller transactions means more unique users get censorship protection from each list. Large transactions can still qualify by paying proportionally higher fees.

The relay fills the inclusion list up to 8 kB with the highest-density transactions, computes it before each slot, and exposes it via an HTTP API that builders fetch from.

Enforcement: How Blocks Get Validated

When a builder submits a block, the relay performs two checks:

1. Inclusion check. Every transaction on the IL must be either present in the block, or provably invalid.

2. Post-state simulation. For any IL transaction missing from the block, the relay simulates it against the block’s resulting state. If the transaction would still pass validity checks (correct signature, correct nonce, sufficient balance, enough gas), the block is rejected. The builder had no legitimate reason to exclude it.

If the simulation shows the transaction is genuinely invalid post-block (e.g., a different transaction from the same sender consumed the nonce, or the sender’s balance was spent), the block is accepted - the exclusion was unavoidable.

This is elegant because the relay doesn’t need to know the builder’s intent. It just checks: could this transaction have been included? If yes and it wasn’t, the block fails. Non-compliant builders may also face collateral penalties and temporary demotion.

The Rollout Model

Default on, opt-out available. Relays adopting rILs will enforce them for all blocks by default. Validators can opt out through the relay registration API if they prefer relays without this feature.

No additional burden on validators. The validator never sees the inclusion list. They sign the block header as usual. The relay does all the work.

Minimal economic impact. IL transactions pay priority fees - they’re real transactions with real value. Including them weakly increases block value. The only cost is slightly larger blocks (more data to propagate), which introduces a marginal latency trade-off. If all relays adopt, the bid curve adjusts naturally. If some don’t, validators still get the highest-paying block through the standard auction from non-IL relays.

Incentive compatible. Builders who comply get their blocks accepted. Builders who don’t get rejected and potentially penalized. The IL targets transactions that are non-contentious and long-waiting - they shouldn’t conflict with the builder’s MEV strategies.

What rILs Don’t Solve

It’s important to be clear about the limitations:

Single-party trust. The relay generates the IL from its own mempool view. If the relay itself is dishonest - excluding specific transactions from the IL - there’s no protocol-level recourse. This is the fundamental difference from FOCIL, which distributes IL generation across multiple randomly-selected committee members. The authors acknowledge this and position rILs as a stepping stone, not a replacement.

Private transactions. rILs only cover public mempool transactions. If a transaction was sent privately to a specific builder, the relay never sees it and can’t include it on the IL. The censorship resistance gap for private flow (identified in the blockspace market paper) remains.

Per-relay fragmentation. Each relay maintains its own IL. Until relays converge on shared ILs, builders may need to construct slightly different blocks for each relay - adding construction overhead.

Future Directions

The paper outlines three evolution paths:

Blob inclusion lists. Extending rILs to cover blob-type transactions (EIP-4844 data blobs). This would improve censorship resistance for L2 data availability - particularly relevant as rollups become major blockspace consumers.

Larger inclusion lists. The current 8 kB cap mirrors FOCIL’s spec, but relay ILs aren’t constrained by validator bandwidth (they don’t propagate through the p2p network). Once the concept is proven, the size can expand.

Multi-relay inclusion lists. The most interesting direction. If multiple relays each publish their own IL, they could share them and take the intersection - producing a single deterministic list. This would:

This last point earned explicit endorsement from mikeneuder (Ethereum Foundation), who noted it “helps pave the way for in-protocol FOCIL.”

The Normalization Debate

The ethresear.ch discussion thread included a substantive technical review from aelowsson, who proposed several alternative scoring formulas and raised questions worth understanding.

Is normalization necessary? A simpler multiplicative formula like S(t) = (waiting_time + a) * priority_fee would be harder for the relay to manipulate, since it doesn’t depend on the median (which the relay controls by choosing its mempool view). The authors agreed that with a threshold filter (only scoring transactions where max_fee_per_gas > base_fee_per_gas), normalization becomes less critical.

Per-byte vs. per-gas density. Blockspace is measured in gas, not bytes. Using byte-size density favors small transactions, but the 8 kB cap is a byte-level networking constraint, not a gas-level blockspace constraint. The choice depends on what you’re optimizing for: maximizing originators (per-byte) or maximizing blockspace efficiency (per-gas). Both are defensible.

Full block handling. If a block is already at the gas limit, should the IL still be enforced? The authors say yes - builders should account for IL transactions when packing the block, potentially with a gas threshold. This follows the stronger FOCILR (FOCIL with ranked transactions) approach rather than the basic FOCIL design.

These are active design questions. The initial implementation will likely be conservative, with room to iterate based on production data.

What This Means for Block Builders

rILs are headed to production relays. The authors indicated readiness to proceed with implementation. When a relay starts enforcing rILs, builders must include IL transactions or face block rejection.

The adaptation is straightforward. Fetch the IL via HTTP API at slot start. Include those transactions in the block. No ordering constraints - place them wherever is most efficient. The main change is reserving gas capacity for IL transactions during block construction.

This is practice for FOCIL. Builders who adapt to rILs now will have zero adjustment when in-protocol FOCIL arrives. Builders who ignore rILs will scramble later. The operational patterns are deliberately aligned with EIP-7805.

Censorship resistance becomes a relay differentiator. Relays that adopt rILs offer validators a concrete, verifiable property: censorship resistance. This matters to validators who care about Ethereum’s neutrality - and there’s reason to believe that’s a growing constituency. Builders should anticipate that the relays they work with will increasingly enforce inclusion lists, and build accordingly.

Sources

Original proposal:

Referenced specifications and related work: