Skip to content
Financial Context Wiki

Censorship resistance

Censorship resistance is a network's ability to keep valid transactions reachable and eligible for inclusion despite filtering by particular intermediaries or block producers.

Updated

For educational purposes only; not investment advice. Investing may result in loss.

Direct answer

Censorship resistance is a network’s ability to keep a valid transaction reachable and eligible for eventual inclusion even when particular gateways, peers, builders or block producers refuse it. It is a degree of resilience, not a promise that every transaction enters the next block or that every access provider must serve every user.

The claim must name the layer, actor and time window. A base chain may resist sustained transaction censorship while a wallet, frontend, RPC endpoint, exchange or rollup sequencer blocks access immediately. A transaction can also be delayed for non-censorship reasons such as an invalid signature, wrong nonce, insufficient balance, a fee below local relay policy or competition for limited block space.

How it works

Follow one signed transaction through distinct stages:

  1. Creation and submission. The wallet constructs and signs a transaction, then sends it through an RPC provider, a private route or the peer-to-peer network. A gateway can refuse it without changing the base protocol.
  2. Admission and propagation. Nodes check consensus validity and their own mempool or relay policy. A transaction may be consensus-valid but not relayed by a particular node. Multiple independent peers and submission paths reduce reliance on one gatekeeper.
  3. Block construction and proposal. A miner, validator, sequencer or external builder chooses transactions and their order. Rotating producers make one actor’s refusal temporary only if a meaningful share of later producers can see and include the transaction.
  4. Validation and fork choice. Other nodes reject invalid blocks and decide which valid branch is canonical. Independent validation prevents a producer from making an invalid transaction valid, but it does not normally force that producer to include a particular valid transaction.
  5. Confirmation or finality. Inclusion is not the same as durable settlement. Reorganizations can remove a recent inclusion; the relevant confirmation or finality rule is chain-specific.

Measure outcomes instead of assigning a binary label. For a transaction first broadly available at t_seen and included at t_included:

inclusion delay = t_included - t_seen

Compare that delay with similarly priced, similarly complex transactions in the same congestion window. Another useful measure is:

eligible inclusion rate = included eligible transactions / observed eligible transactions

“Eligible” must state validity, nonce, balance, fee, gas or weight, timing and capacity rules. Otherwise ordinary fee selection or congestion can be mistaken for selective censorship.

Resistance depends on diversity across failure domains: peers, RPCs, autonomous operators, pools, clients, builders, relays, sequencers, hosting providers and jurisdictions. Raw node counts can mislead because many nodes or validator keys may share one controller. Forced-inclusion paths or inclusion lists can strengthen guarantees, but their deployment status and conditions matter. EIP-7805, for example, is a proposal and is not a currently deployed Ethereum guarantee.

Example

Suppose a valid transaction reaches the public network at block height 840,000. It offers a competitive fee, fits in each following block and remains valid. Three producers omit it; the fourth includes it at height 840,004.

  • The observed delay is 4 blocks from the stated starting point.
  • Three omissions do not alone prove coordination; ordering, propagation and producer policy require investigation.
  • Inclusion by an independent fourth producer shows that the first producers lacked a complete veto.
  • If producers controlling 90% of opportunities apply the same filter, a simplified independent-slot model gives per-slot inclusion probability 1 - 0.90 = 10% and expected wait 1 / 0.10 = 10 slots. Correlated control and real selection rules can invalidate this model.

To document suspected censorship, preserve the signed transaction or identifier, first-seen observations from independent nodes, fee and validity checks, mempool policies, block contents, producer attribution and comparable transactions. One RPC error or missing explorer entry is not enough.

Risks

  • False positives: invalidity, stale nonce, insufficient funds, fee policy, capacity or poor propagation can look like censorship.
  • Concentrated ordering: a dominant pool, builder, relay or sequencer can turn selective filtering into long delays.
  • Access-layer censorship: domains, app stores, frontends, wallets and RPC providers can block practical access while direct protocol access remains possible.
  • Correlated infrastructure: separate-looking endpoints may share an operator, cloud, client, relay or legal exposure.
  • Privacy leakage: rebroadcasting through many services may improve reach while exposing IP, timing and transaction linkage.
  • Weak escape paths: forced inclusion may carry fees, bonds, delays, windows, data requirements or privileged controls.
  • Reorganization and governance risk: inclusion may not be final, and upgrades or emergency powers can alter assumptions.

Use genuinely independent paths where practical. Never share seed phrases or private keys with an RPC, relay or “anti-censorship” service, and do not replace or rebroadcast a transaction without understanding nonce and fee rules.

Common misconceptions

  • “Valid means guaranteed inclusion.” Validity creates eligibility; producers still select transactions unless a stronger rule applies.
  • “Decentralized means uncensorable.” Concentration can remain in production, builders, relays, RPCs, frontends or governance.
  • “One blocked RPC proves chain censorship.” It proves one access path failed or refused the request, not a network-wide veto.
  • “A high fee defeats every filter.” A competitive fee addresses economic ordering, not an explicit filter.
  • “Eventual inclusion is enough.” Inclusion after an operational deadline may be useless; the time window belongs in the claim.

Sources

Navigation

Search the wiki...