Search
Search for projects by name or address
Sequencing
Rotating block production across independent operators improves real-time censorship resistance, while deterministic host-chain inclusion provides eventual censorship resistance. No system shown here combines both guarantees today.
Decentralized Sequencing
Columns
Columns
# | name | Set
size | Block production
access | Min. stake /
entry rate | Block
time | Block
production | Proposer / committee
rotation | Deterministic
CR | Additional
CR | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
# | name | Set
size | Block production
access | Min. stake /
entry rate | Block
time | Block
production | Proposer / committee
rotation | Deterministic
CR | Additional
CR | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
# | name | Set
size | Block production
access | Min. stake /
entry rate | Block
time | Block
production | Proposer / committee
rotation | Deterministic
CR | Additional
CR | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 |  | This snapshot is generated from Dune validator-day summaries and curated staking attribution. Lido stake is split among its node operators. Validator indices are not independent operators, and compounding validators can have different effective balances. | Anyone can deposit the minimum stake and join the activation queue without governance approval. Activation remains subject to protocol churn limits. | Compounding validators can have an effective balance of up to 2,048 ETH. Proposal probability is weighted by effective balance. Validator activation is limited by an effective-balance churn cap. An epoch contains 32 slots and lasts 6m 24s. | 12 seconds | A single proposer is selected for each slot from the proof-of-stake validator set. The proposer controls the final payload choice and can order transactions locally or through a builder. | One validator index is selected for every slot with probability proportional to its effective balance. A missed proposal leaves the slot empty. | Ethereum mainnet does not currently enforce a forced-transaction queue or inclusion list. Inclusion-list proposals such as FOCIL are not live on mainnet. | A proposer can build locally to include public-mempool transactions instead of accepting an external builder bid. This bypasses censoring builders and relays, but users cannot compel the proposer to use the fallback. Combining a highly decentralized operator set with per-slot proposer rotation results in short inclusion delays under selective censorship. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
2 |  | 3129 sequencers 486.22 M AZTEC | Open | Can be changed by onchain Governance, but the contract requires nonzero minimum, divisor, and maximum queue-flush parameters. | Current expected interval between L2 block proposals. Multiple blocks can be produced by the same proposer within one slot, so this interval can differ from the proposer rotation interval. | A committee is randomly sampled from the sequencer set for an epoch. A block is accepted only if >2/3 of committee members attest to it. | A random committee is sampled from the sequencer set for each epoch, a random block producer is sampled from the committee for each slot in the epoch | No | Escape hatch: 332.00 M AZTEC bond to enter a set from which one proposer is periodically selected every 2d 23h to bypass the regular committee, include transactions, and prove the resulting checkpoints. 1.66 M AZTEC proposal tax. Private transactions: allow users to cheaply resist censorship based on transaction content while the chain is live. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
3 |  | The active-ongoing validator count and effective stake snapshot are generated from the corresponding Gnosis Analytics endpoints for the same date. Validator indices are not independent operators. | Open | stake-weighted block production rights, no maximum defined by the consensus clients | 5s | A single proposer is selected for each slot from the proof-of-stake validator set. The proposer controls the final payload choice and can order transactions locally or through a builder. | Block production is not committee-based, sequencers rotate every block (epochs do not affect sequencer rotation) | No | Shutter encrypted mempool beta | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
4 |  | 104 validators 3.61 B POL | The current validator cap is 105. Validator entry is permissioned (Polygon Multisig or an EOA). | stake-weighted block production rights, no maximum | 2s | Block production rights are delegated for multi-block spans, so selective censorship by a single entity lasts for a whole span. | Randomly sampled validators delegate block production for the duration of a span: 6400 blocks | No | No | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Inclusion delay by censorship fraction
T99 inclusion delay in a static sequencer set by censoring fraction of sequencer/validator stake
Points mark the largest attributed entities' cumulative stakes. A line stopping before the 50% limit indicates that any more censorship will prevent inclusion completely. This is usually due to the sequencer network's consensus mechanism stopping block production at that threshold.
Centralized sequencing
Inclusion columns show how a user bypasses censorship by the centralized operator while the chain is live. Exit covers the worst case where state proposers stop. Delays assume Ethereum includes the required L1 transactions.
Columns
Columns
# | name | Trusted
preconfirmation | Trusted
ordering | Sequencer | RT
CR | Forced
inclusion | Inclusion
delay | Inclusion
mechanics | Exit
delay | Exit
economics | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
# | name | Trusted
preconfirmation | Trusted
ordering | Sequencer | RT
CR | Forced
inclusion | Inclusion
delay | Inclusion
mechanics | Exit
delay | Exit
economics | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
# | name | Trusted
preconfirmation | Trusted
ordering | Sequencer | RT
CR | Forced
inclusion | Inclusion
delay | Inclusion
mechanics | Exit
delay | Exit
economics | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 |  | The public sequencer feed provides a trusted soft confirmation per block with no protocol enforcement or slashing. A block closes early when it fills, up to 8 blocks per second. A paid Fast Feed publishes each transaction as soon as it is ordered and executed within a 125 ms round, before its block closes. These messages are tentative and can be lost if the sequencer fails mid-block. | Transactions arriving during each 125 ms round (2 per 250 ms block) are included in descending priority fee order, with the sequencer's arrival time breaking ties. After each round, waiting transactions receive an anti-starvation boost to their queue position, not to the fee they pay. Priority fees are paid to the network fee account. This policy is operated by the centralized sequencer and is not enforced by the L1 contracts. | The Arbitrum operator controls the real-time sequencer feed. Their documented production HA architecture runs redundant sequencer replicas and selects one active instance through shared Redis state. This improves availability but is not BFT consensus and does not create independent operators or censorship resistance. | The centralized sequencer can censor transactions submitted through the normal L2 path. | The first Ethereum transaction enqueues the message in the delayed inbox. After the delay expires, anyone can submit a second transaction calling forceInclusion, which advances all delayed messages through the selected message. | The message-specific delay is the lower of delayBlocks and the delay buffer. The current buffer gives the maximum delay. The force call becomes valid in the following Ethereum block. | Forced inclusion creates an L1-originated L2 message rather than submitting the original signed L2 transaction. The full delayed-inbox message is capped at 117,964 bytes, so the available call data is slightly smaller. L1 contract callers use an aliased address on L2. The rollup owner can pause the Inbox or enable its allowlist, preventing new submissions. | After successful L2 inclusion (forced or sequencer), the user can propose the assertion needed to exit by posting the assertion bond. The assertion cadence can add up to 15 minutes. A maximally delayed BoLD challenge can take up to twice the 45,818-block edge challenge period, followed by a 14,400-block grace period. | Self-proposing the assertion needed for an exit requires a 3,600 WETH bond. If challenged, the user must defend it through BoLD and post additional refundable bonds of 555 WETH and 79 WETH to enter the lower challenge levels. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
2 |  | The centralized builder streams cumulative Flashblock preconfirmations about every 200 ms while sealing regular L2 blocks every 2 seconds. Flashblocks are out of protocol: the promise has no protocol enforcement or slashing, and a preconfirmation can be absent or reorged. | For each 200 ms build loop, the centralized builder selects available transactions by priority fee. Transactions committed to an earlier Flashblock are not reordered when a higher-fee transaction arrives later, so arrival time also affects ordering. This policy is not enforced by the derivation rules. | The Base operator controls real-time ordering. They document five sequencer instances coordinated by op-conductor using Raft leader election, with only the leader producing blocks. The replicas improve availability but do not create independent operators or censorship resistance. | The centralized sequencer can censor transactions submitted through the normal L2 path. | The user submits one Ethereum transaction to the OptimismPortal which is automatically derived by conforming nodes. | The static sequencing window is measured in Ethereum blocks. | Forced inclusion creates an L1-originated deposit transaction rather than submitting the original signed L2 transaction. Its calldata is capped at 120,000 bytes, its minimum L2 gas limit is 21,000 plus 40 gas per calldata byte, and deposits share a metered 20,000,000 gas resource limit per Ethereum block. L1 contract callers use an aliased address on L2. | After successful L2 inclusion (forced or sequencer), a permissionless ZK proof is needed to finalize the state and exit on L1. Without the centralized TEE proof, the game waits 5 days, followed by the currently 0 seconds finality air gap. The 1 day withdrawal-proof maturity period runs concurrently. | Self-proposing the state needed for an exit requires a valid ZK proof and a 0.05 ETH bond for one 600-block checkpoint. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
3 |  | The centralized sequencer streams cumulative Flashblock preconfirmations every 250 ms while sealing regular L2 blocks every 2 seconds. Flashblocks are out of protocol: the promise has no protocol enforcement or slashing, and 250 ms is a target that can vary with execution load. | For each 250 ms build loop, the centralized builder selects available transactions by priority fee. Transactions committed to an earlier Flashblock are not reordered when a higher-fee transaction arrives later, so arrival time also affects ordering. This policy is not enforced by the derivation rules. | The OP Mainnet operator controls real-time ordering. They run redundant sequencer instances coordinated by op-conductor using Raft leader election, with only the leader producing blocks. op-conductor explicitly assumes all nodes are honest and is not Byzantine fault tolerant, so the replicas do not create independent operators or censorship resistance. | The centralized sequencer can censor transactions submitted through the normal L2 path. | The user submits one Ethereum transaction to the OptimismPortal which is automatically derived by conforming nodes. | The static sequencing window is measured in Ethereum blocks. | Forced inclusion creates an L1-originated deposit transaction rather than submitting the original signed L2 transaction. Its calldata is capped at 120,000 bytes, its minimum L2 gas limit is 21,000 plus 40 gas per calldata byte, and deposits share a metered 20,000,000 gas resource limit per Ethereum block. L1 contract callers use an aliased address on L2. | After successful L2 inclusion (forced or sequencer), the user can propose the state needed to exit by creating a permissionless fault dispute game. A maximally delayed challenge path can take up to 17 days 3 hours: both teams' 3 days 12 hours chess clocks plus up to 10 days 3 hours of cumulative clock extensions. This is followed by the 3 days 12 hours finality air gap. Parallel branches increase the transactions and gas needed to defend and resolve the game. The 7 days withdrawal-proof maturity period runs concurrently. | Self-proposing the state needed for an exit starts with a 0.08 ETH bond. If challenged, the user must defend it with progressively larger bonds: each counterclaim costs 1.09 times the claim it counters, favoring the attacker in a capital-exhaustion attack. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
4 |  | The current proposer targets a PRE_CONFIRMED receipt in about 500 ms. It is a trusted promise before consensus decides the block, with no onchain enforcement or slashing, and can be reverted if the proposal does not become the consensus block. The 1.5-second L2 block time is a target: a block can close earlier when it reaches a resource limit or later while transactions are still executing or consensus takes longer. | The active proposer selects eligible transactions from its peer-to-peer synchronized mempool in descending tip order, with the transaction hash breaking equal-tip ties. Transactions whose gas-price bound is below the current threshold remain pending. This offchain policy is not enforced by Ethereum. | StarkWare controls 5 equal-weight, permissioned proposers selected in deterministic round-robin order. The deployment assumes no malicious validators and requires more than half of the voting weight (3/5). The replicas can tolerate process outages, but do not create independent operators or censorship resistance. | The permissioned sequencer committee is controlled by one operator, StarkWare, which can censor transactions submitted through the normal L2 path. | There is no user-callable forced-inclusion function. A user can log an L1-to-L2 message with one Ethereum transaction and contact the Security Council minority. The council can then bypass sequencer consensus by participating in a valid, proven state update, but whether and when it does so is discretionary. | The contracts impose no deadline for the Security Council minority to respond, for SHARP to prove the state transition, or for an Operator to post the state update. | Logging a message creates an L1-originated L1-handler transaction rather than submitting the original signed L2 transaction. It does not automatically enter the canonical L2 order and has no other effect than recording the intent. The Security Council path must produce Starknet OS execution, data availability and an accepted SHARP proof before posting the state update. An unconsumed message can be cancelled through a two-call L1 process after a 5 days 1 minute 40 seconds delay. | Under operator failure, a user cannot independently advance the state needed for an exit. There is no deadline for the Security Council minority to act or for SHARP to produce the required proof. Once an accepted fact and valid state update reach Ethereum, there is no additional state-finalization delay. | A user cannot self-propose state. Progress requires the recursive STARK proving pipeline and cooperation from a whitelisted Operator or the Security Council minority. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
A system combining decentralized sequencing for real-time censorship resistance with deterministic L1 inclusion for eventual censorship resistance would provide the strongest overall protection. No live system shown here offers that combination yet.