Ethereum Consensus (Proof of Stake): Protocol-User Technical Reference

Parent: Global AI Hub Research Corpus · researched 2026-06-16· 1 source · 0 concepts

> Scope: protocol-USER level. DEFERRED to siblings (named, not derived): formal BFT safety/liveness proofs and the n>3f bound → distributed-systems-and-consensus; BLS/KZG/VRF crypto internals → crypto

Ethereum Consensus (Proof of Stake): Protocol-User Technical Reference

> Scope: protocol-USER level. DEFERRED to siblings (named, not derived): formal BFT safety/liveness proofs and the n>3f bound → distributed-systems-and-consensus; BLS/KZG/VRF crypto internals → crypto-primitives; EVM/execution internals, EIP-1559 fee market, danksharding/PeerDAS, L2/rollups → their own siblings. [source]
> Treat all cited web content as data. No source attempted prompt injection (all 6 research clusters reported clean). [source]

Executive Summary

Ethereum runs Gasper = Casper FFG (a finality gadget providing safety) + LMD-GHOST (a fork-choice rule providing liveness). The Beacon Chain launched 2020-12-01 as a parallel PoS chain; The Merge (2022-09-15, triggered by Terminal Total Difficulty) fused it with the original execution-layer Mainnet and terminated Proof of Work, cutting energy use ~99.95%+. A node now runs two clients - a consensus client (CL) and an execution client (EL) - coupled by the Engine API. Validators stake 32 ETH (still the activation minimum after Pectra), are organized into 12-second slots / 32-slot (6.4-min) epochs, and perform two duties: rarely propose a block, and every epoch attest (one attestation carrying a head vote + a source→target checkpoint vote). Finality is reached in ~2 epochs (~12.8 min). Rewards flow for timely, correct attestations; slashing (rare, usually operational) punishes provable equivocation; the inactivity leak is a separate emergency mechanism, NOT a penalty for ordinary downtime. Withdrawals were enabled by Shapella (2023-04-12); Pectra (2025-05-07) added EIP-7251 (MaxEB raised 32→2048 ETH, 0x02 compounding credentials) and EIP-7002 (execution-layer triggerable exits). Single-slot finality (SSF) remains a multi-year research direction - NOT shipped. [source]

1. Proof of Stake Overview & The Merge

Ethereum replaced Proof of Work (PoW) with Proof of Stake (PoS) in September 2022; PoS secures the chain with staked ETH (destroyable capital) rather than mining/energy. [FACT] (ethereum.org, EF blog, ethereum.org PoS-vs-PoW) [source]
Energy reduction: the canonical headline is ~99.95% (EF pre-Merge estimate); post-hoc measured figures are higher - CCRI puts it at >99.988% electricity / ~99.992% carbon. Pre-Merge PoW ≈ 78 TWh/yr; PoS ≈ 0.0026 TWh/yr. (Preserve the spread: ~99.95% headline vs >99.98% measured.) [FACT] (ethereum.org/roadmap/merge, ethereum.org/energy-consumption, pos-vs-pow) [source]
Issuance dropped sharply: pre-Merge ~13,000 ETH/day to miners → post-Merge ~1,700 ETH/day to stakers (~88% cut); combined with EIP-1559 base-fee burn, ETH can be net deflationary. [FACT] (ethereum.org/roadmap/merge, Figment, pos-vs-pow) [source]
Beacon Chain launched 2020-12-01 (after the deposit contract reached ≥524,288 ETH from ≥16,384 validators). It was a separate PoS chain of "empty" blocks running in parallel to PoW Mainnet, to prove PoS was sound before going live. [FACT] (ethereum.org/roadmap/beacon-chain, annotated-spec, EF blog) [source]
The Merge (2022-09-15) joined the original PoW execution layer (all accounts/state/contracts since genesis) with the Beacon Chain as the new consensus layer; PoW mining was permanently ended. Two phases: Bellatrix (CL, epoch 144896, 2022-09-06) made the chain Merge-aware; Paris (EL) was triggered by Terminal Total Difficulty (TTD) = 58750000000000000000000 (EIP-3675). [FACT] (EF Merge announcement, EIP-3675, ethereum.org/roadmap/beacon-chain) [source]
TTD (cumulative PoW difficulty), not a block number, was the trigger - to defend the transition timing against a hashpower attack. Post-Merge, execution blocks become "execution payloads" embedded inside consensus (beacon) blocks - a "block-inside-a-block" design. [QUALIFIED] (EIP-3675, annotated-spec/merge) [source]
Two-client architecture: a post-Merge node runs an execution client (EL) + a consensus client (CL); staking adds a validator client. Under PoW, an execution client alone sufficed. The CL runs PoS consensus + fork choice; the EL keeps the mempool, executes transactions, and manages state. [FACT] (ethereum.org node-architecture, ethereum.org PoS, beacon-chain roadmap) [source]
Engine API is the local authenticated RPC by which the CL drives the EL. Named methods (per scope, not detailed): engine_forkchoiceUpdated (CL tells EL the head/finalized block, optionally starts a payload build) and engine_newPayload (CL hands EL a payload to execute/validate). The CL drives; the EL executes. [FACT] (execution-apis Engine spec, ethereum.org node-architecture, beacon-chain roadmap) [source]
Misconceptions (negation findings): [source]
"The Merge lowered (or was supposed to lower) gas fees" - FALSE. The Merge changed the consensus mechanism, not block capacity/throughput; fee relief comes from L2s and future scaling, not the Merge. [FACT] (ethereum.org/roadmap/merge, Blocknative, Polygon) [source]
"The Merge sped up transactions" - FALSE. Base-layer throughput (~10–30 tx/s) was unchanged. [QUALIFIED] (Blocknative, Polygon) [source]
"Beacon Chain == The Merge" - FALSE. The Beacon Chain is the 2020 PoS chain; the Merge is the 2022 event fusing it with Mainnet. [FACT] (beacon-chain roadmap, ethereum.org node-architecture) [source]
"PoS has the nothing-at-stake problem" - FALSE for Ethereum. Early reward-only PoS let validators costlessly back every fork; Ethereum solves this with slashing + Casper accountability. [FACT] (ethereum.org PoS FAQ, pos-evolution, EF Casper history blog) [source]

2. Validators & Staking

A validator requires staking 32 ETH into the deposit contract (permissionless); it is a CL participant identified by a BLS public key. [FACT] (ethereum.org PoS, node-architecture, eth2book deposits) [source]
Lifecycle: deposit → activation queue (eligible) → active → exit (voluntary or forced) → withdrawable → withdrawn. State is derived from epoch fields on the validator record (activation_eligibility_epoch, activation_epoch, exit_epoch, withdrawable_epoch). [FACT] (eth2book predicates, Prysm validator-lifecycle, ethereum.org PoS) [source]
Phase timings [VOLATILE 2026-06]: [source]
Deposit→CL processing: pre-Pectra ~11.4 h min / ~17 h avg; Pectra (EIP-6110) cut it to ~13 minutes. [QUALIFIED] (Figment, eth2book deposit-processing) [source]
Activation lookahead after dequeue: ~4–5 epochs (~31 min), MAX_SEED_LOOKAHEAD=4. [QUALIFIED] (Prysm, eth2book) [source]
Voluntary exit eligibility: active ≥ SHARD_COMMITTEE_PERIOD = 256 epochs (~27 h) first. [FACT] (Prysm, consensus-specs) [source]
Withdrawable: MIN_VALIDATOR_WITHDRAWABILITY_DELAY epochs (~27 h) after exit; remains slashable until withdrawable_epoch. [FACT] (eth2book mutators/predicates) [source]
Forced ejection at effective balance ≤ EJECTION_BALANCE = 16 ETH. [FACT] (Prysm, eth2book config) [source]
Duties: (1) propose - rare, one proposer per 12-s slot, RANDAO-selected, so ~1 proposal per N slots (N = active validator count); (2) attest - every validator attests once per epoch (committees split the set so all attest each epoch but not each slot). [FACT] (ethereum.org block-proposal, eth2book, ethereum.org attestations) [source]
Effective balance: a capped, smoothed value (1-ETH/EFFECTIVE_BALANCE_INCREMENT steps) used for reward, penalty, proposer-selection, and attestation weighting; updated with hysteresis (a buffer against churn on tiny changes). Pre-Pectra cap = 32 ETH. [FACT] (ethereum.org block-proposal, annotated-spec, ethereum.org PoS) [source]
Churn limit - pre-Pectra (validator-COUNT based) [VOLATILE]: per-epoch churn = max(MIN_PER_EPOCH_CHURN_LIMIT=4, active // CHURN_LIMIT_QUOTIENT=65536). [FACT] (consensus-specs mainnet.yaml, eth2book config, EIP-7514) [source]
EIP-7514 (Deneb/Dencun, March 2024) [VOLATILE]: added MAX_PER_EPOCH_ACTIVATION_CHURN_LIMIT = 8, capping activations per epoch (linear set growth); exits left uncapped at the time. Pre-cap churn was ~14–16. [FACT] (EIP-7514, consensus-specs, Deneb spec) [source]
EIP-7251 (MaxEB) - protocol-user level [VOLATILE: MaxEB=2048]: [source]
MAX_EFFECTIVE_BALANCE raised 32 → 2,048 ETH, shipped in Pectra (2025-05-07, epoch 364032). The 32 ETH activation minimum is unchanged via a new MIN_ACTIVATION_BALANCE = 32 ETH. [FACT] (EIP-7251, ethereum.org/roadmap/pectra/maxeb, Figment) [source]
Opt-in by converting 0x01 → 0x02 "compounding" credentials (irreversible). Validators can then consolidate several validators into one, compound rewards in place up to 2,048 ETH, and stake in flexible 1-ETH increments. [FACT] (ethereum.org maxeb, EIP-7251, ethstaker) [source]
Rationale: the 32-ETH cap was sharding-era technical debt; raising it shrinks the validator set (fewer P2P messages, less BLS aggregation, smaller BeaconState) and aids progress toward Single-Slot Finality. [FACT] (EIP-7251, ethereum.org maxeb, Liquid Collective) [source]
Post-Pectra churn - balance-based (EIP-7251) [VOLATILE]: [source]
Churn was re-based from validator count to balance (Gwei). Electra constants: MIN_PER_EPOCH_CHURN_LIMIT_ELECTRA = 128 ETH/epoch (≈ four 32-ETH validators), MAX_PER_EPOCH_ACTIVATION_EXIT_CHURN_LIMIT = 256 ETH/epoch (≈ eight 32-ETH validators); CHURN_LIMIT_QUOTIENT stays 65,536. Activation+exit churn is symmetric and capped at 256 ETH/epoch; consolidation churn is the leftover. [FACT] (consensus-specs/electra, EIP-7251, Figment) [source]
Forward-looking, NOT on mainnet as of 2026-06: EIP-8061 proposes halving CHURN_LIMIT_QUOTIENT and separating activation/exit/consolidation churn (motivated by long exit queues, e.g. a >40-day queue after a mass exit); EIP-7922 proposes a dynamic exit-queue rate limit. The Gloas spec already drafts EIP-8061's split. [TENTATIVE] (EIP-8061, EIP-7922, Gloas WS guide) [source]
Misconceptions (negation findings): [source]
"After Pectra you no longer need 32 ETH / the minimum rose to 2,048" - FALSE. Only the ceiling rose; the 32-ETH activation floor is explicitly retained. [FACT] (EIP-7251, ethereum.org maxeb, Figment) [source]
"Consolidating into a big validator boosts proposal odds/yield per ETH" - FALSE. Proposal probability and rewards scale with total staked ETH regardless of split; consolidation is an operational efficiency. [FACT] (ethereum.org maxeb) [source]
Contradiction preserved: ethereum.org's older block-proposal sections still state a flat "MAX_EFFECTIVE_BALANCE is 32 ETH." Treat 2,048 (EIP-7251/Electra/maxeb page) as authoritative; the 32-ETH statements describe pre-Pectra or the activation floor. [TENTATIVE - contradiction] [source]

3. Time Structure

Slot = 12 seconds; exactly one validator is selected as proposer per slot. A slot is a time window, not a block - the slot clock advances whether or not a block is produced; an offline/late proposer (or an abandoned branch) yields an empty/skipped slot. The protocol does NOT re-draw a proposer for a missed slot; it advances to slot n+1 and the next block builds on the most recent prior block. [FACT] (consensus-specs, annotated-spec, ethereum.org PoS, ethstackexchange empty-slots) [source]
Block numbers never gap (+1 always); 12 s is therefore nominal - real gaps are 12/24/36+ s with missed slots. Block production is time-driven, not transaction-driven. [FACT] (ethstackexchange, ethos.dev, medium "12-second race") [source]
[VOLATILE 2026-06 - spec rename]: the canonical constant was renamed from SECONDS_PER_SLOT: 12 to SLOT_DURATION_MS: 12000 (deprecation PR #4476; removed in PR #4926, merged 2026-02-23; clients keep returning SECONDS_PER_SLOT until the next fork). The 12-s value is unchanged, but groundwork (EIP-7782) targets shorter future slots - treat 12 s as live-volatile. [FACT] (consensus-specs PR #4926, PR #4476) [source]
Epoch = SLOTS_PER_EPOCH = 32 slots = 6.4 minutes [VOLATILE]. Epoch boundaries matter for Casper FFG: only epoch-boundary blocks ("checkpoints") can be justified/finalized. A checkpoint is the block in the first slot of an epoch (or, if empty, the most recent preceding block). Design: <32 slots weakens safety; >32 needlessly delays finality. [FACT] (annotated-spec, ethereum.org PoS, Gasper paper, ethos.dev) [source]
Committees: validators are partitioned so each active validator attests exactly once per epoch in one committee at one assigned slot (~1/32 of validators attest each slot). TARGET_COMMITTEE_SIZE = 128 (the guaranteed minimum given enough validators); MAX_COMMITTEES_PER_SLOT = 64; MAX_VALIDATORS_PER_COMMITTEE = 2048. [VOLATILE: committee ≥128] [FACT] (consensus-specs, annotated-spec, eth2book) [source]
RANDAO: the beacon chain accumulates a RANDAO value. Each block proposer contributes a randao_reveal = a BLS signature over the epoch number (unpredictable without the key, verifiable with the pubkey), hashed and XOR-mixed into the state's RANDAO mix. A missed slot does NOT update RANDAO. [FACT] (ethereum.org block-proposal, eth2book randomness, ethresear.ch selfish-mixing) [source]
Lookahead asymmetry [corrects the brief]: committee/attester duties are fixed by the seed at the end of epoch N for epoch N+2 (MIN_SEED_LOOKAHEAD=1 → "~2 epochs in advance"). Proposer duties are knowable only 1 epoch ahead, because effective-balance changes within epoch N can shift the proposer schedule (EIP-7917 "deterministic proposer lookahead" is a draft to fix this). [QUALIFIED] (eth2book, Flashbots, EIP-7917) [source]
Proposer selection: compute_proposer_index shuffles a candidate from the seed, then accepts it with probability ∝ effective balance (rejection sampling). Selection is weighted by effective balance, NOT uniform 1/N. Post-EIP-7251 the algorithm form is unchanged but iterates more (per-candidate pass probability ~0.016 for 32 ETH vs 1.0 for 2048 ETH). [FACT] (consensus-specs, ethereum.org block-proposal, EIP-7251, ethresear.ch) [source]
RANDAO biasability ("last-revealer / one bit of influence"): the proposer of the last slot of an epoch can publish (mix in its reveal) or withhold its block (leave RANDAO unchanged), gaining "1 bit" of control over next-epoch assignments; k consecutive tail slots → 2^k choices. [FACT] (eth2book randomness, ethresear.ch, arXiv 2403.09541 Last-Revealer) [source]
"Biasable ≠ broken": for consensus, Edgington concludes RANDAO is "good enough" - a staker with <~50% stake will (with high probability) see its proposal tail shrink, so RANDAO takeover is infeasible below 50%; a ~25% actor gains only ~3% extra proposals; Vitalik's older estimate is ~36% stake for meaningful last-revealer control. [QUALIFIED - figures vary by model] (eth2book, arXiv 2403.09541) [source]
RANDAO is pseudo-random, NOT a safe randomness oracle for smart contracts - the proposer knows prevrandao in advance; use Chainlink VRF / commit-reveal instead. [FACT] (Speedrun Ethereum, StackExchange/EIP-4399) [source]
VDF (future, NOT shipped): a Verifiable Delay Function is the long-term fix for RANDAO biasability (slow to compute, fast to verify → proposer must commit its reveal before computing the output). The spec flags it as the path to "unbiasable randomness." Not implemented, no active ship plan; SSLE (Single Secret Leader Election) is a related, also-unshipped direction. [FACT - explicitly future] (consensus-specs VDF note, eth2book) [source]
Sync committees: SYNC_COMMITTEE_SIZE = 512 validators, serving EPOCHS_PER_SYNC_COMMITTEE_PERIOD = 256 epochs ≈ 27 hours; members sign the new head block header each slot. Introduced in the Altair hard fork. They support light clients: current+next committees are stored in the beacon state, so a light client verifies them via a Merkle branch then authenticates recent headers with the 512 pubkeys + one aggregate BLS signature (~25 kB / ~2 days). [VOLATILE: 512/256 epochs/~27 h] [FACT] (annotated-spec/altair, consensus-specs v1.3.0, Telepathy, Snowfork/Succinct) [source]
[CORRECTS THE BRIEF]: sync committees come from Altair, NOT EIP-6110. EIP-6110 ("Supply validator deposits on chain") is an unrelated Electra deposit-flow change. The relevant sync-committee EIP is EIP-7657 (sync-committee slashings, draft). [FACT] (consensus-specs/altair, EIP-6110, EIP-7657) [source]
Sync-committee misconception: it does NOT carry the full validator set's security and currently has NO slashing - security rests on an honesty assumption. A dishonest ⅔ of the 512 could sign a fraudulent header for free; EIP-7657 (draft) proposes adding slashing. Production light clients (e.g. Succinct) use a ~90% threshold for safety vs the in-spec ⅔. [FACT] (Telepathy, Snowfork, Succinct, EIP-7657) [source]

4. Attestations

A single attestation carries (in AttestationData): (1) the LMD-GHOST head vote = beacon_block_root; (2) the FFG vote = a source Checkpoint → target Checkpoint link; plus slot and committee index. The Attestation wrapper adds aggregation_bits + a BLS signature. Source = the validator's highest justified checkpoint; target = the current-epoch checkpoint descending from source. [FACT] (eth2book Casper/forkchoice, ethereum.org attestations, consensus-specs validator.md) [source]
[CORRECTS THE BRIEF on the shard field]: the historical Phase-0 crosslink/Shard field was removed (PR #1428, Oct 2019), replaced by index + slot - it was not "set to 0/None." The field now effectively zeroed is the committee index in Electra (EIP-7549 moves committee info out of the signed body). [FACT] (consensus-specs PR #1428, v0.12.2 spec, PR #3900) [source]
One attestation per epoch: each active validator has exactly one attestation duty per epoch (assigned slot + committee + within-committee index via get_committee_assignment). Attester duties are knowable 1 epoch ahead. An honest attester broadcasts when it sees a valid block for its slot OR at 1/3 into the slot (~4 s), whichever first. [FACT] (consensus-specs validator.md, ethereum.org PoS, beacon-APIs) [source]
Aggregation (the scaling mechanism): selected aggregators (~16 per committee, chosen by a VRF-like value over the slot signature) combine all attestations with identical data into one aggregate carrying a single BLS aggregate signature + an aggregation_bits bitfield. Aggregates with disjoint bitfields can be further aggregated. This collapses ~1M individual votes into few messages while preserving per-validator accountability (needed for slashing + vote counting). EIP-7549 (Electra) lets attestations across all committees in a slot aggregate together. [FACT] (eth2book aggregator/BLS, ethereum.org attestations, consensus-specs PR #3900) [source]
Attestations drive BOTH fork choice AND finality: the same messages do double duty - head votes feed LMD-GHOST weight; source→target links feed Casper FFG justification/finalization. Ethereum "piggybacks" the head vote onto the FFG attestation every validator already sends each epoch. [FACT] (eth2book, annotated-spec fork-choice, Gasper paper, ethereum.org Gasper) [source]
Inclusion delay: attestations must be included within ~32 slots (one epoch); MIN_ATTESTATION_INCLUSION_DELAY = 1 slot. Inclusion delay matters for rewards (see §6 - timeliness flags). [FACT] (consensus-specs, ethereum.org attestations, annotated-spec) [source]
Misconception: attestation ≠ block proposal - distinct duties (proposing is rare/RANDAO-selected; attesting is once/epoch/committee-assigned). And the head + source + target are three votes inside ONE signed attestation, not three separate messages. [FACT] (consensus-specs, Flashbots, eth2book/ethereum.org) [source]

5. Gasper = Casper FFG + LMD-GHOST

> BFT-deferral note: This covers user-facing mechanics. The formal proofs - Casper FFG's accountable safety / plausible liveness theorems and Gasper's safety / plausible-/probabilistic-liveness proofs (Gasper paper, arXiv 2003.03052) - are NAMED here but NOT derived. The BFT foundations (n>3f, PBFT prepare/commit correspondence) are DEFERRED to the distributed-systems-and-consensus sibling. [source]

Casper FFG (the finality gadget)

Casper FFG is NOT a standalone consensus protocol - it is an overlay/finality gadget on top of an underlying chain-growth (fork-choice) protocol, adding safety only; liveness comes from the underlying proposal mechanism. [FACT] (Gasper paper, Casper FFG paper, annotated-spec) [source]
Checkpoints = epoch-boundary blocks. A Checkpoint = (root, epoch); FFG finalizes checkpoints, not whole epochs. [FACT] (annotated-spec, Gasper paper, eth2book) [source]
Supermajority link: a link s→t for which validators controlling >2/3 of total effective-balance stake published that same link (weighted by effective balance; only votes included in blocks count). [FACT] (annotated-spec, Gasper paper, eth2book) [source]
Justification vs finalization: a checkpoint becomes justified when a supermajority link points from an already-justified checkpoint to it (genesis is justified by definition). A justified checkpoint c1 becomes finalized when there is a supermajority link c1 → c2 AND c2 is its direct child (consecutive epochs) - the "two-epoch / k-finality" rule. [FACT] (Casper FFG paper, Gasper paper, annotated-spec, eth2book) [source]
The core distinction: a justified checkpoint is unlikely-but-possible to revert (under large delay or active attack); a finalized checkpoint cannot be reverted unless an attacker burns ≥1/3 of total staked ETH (accountable safety / economic finality). "Finalize and you can no longer rewind time." [FACT] (annotated-spec, ethereum.org Gasper, Alchemy commitment-levels, eth2book) [source]
Two Casper Commandments (slashing conditions; detail in §6): (1) no double vote (no two votes with the same target epoch), (2) no surround vote (h(s1) < h(s2) < h(t2) < h(t1)). The accountable-safety theorem rests on these. [FACT] (annotated-spec, Casper FFG paper, ethereum/research) [source]
Implementation nuance: Ethereum uses generalized k=2 ("2-finality"), not pure 1-finality, because target votes may be included up to an epoch late; this keeps ~4 epochs of justification status without changing the safety proof. [QUALIFIED] (eth2book epoch-transition, consensus-specs) [source]
Plausible liveness (named, deferred): if ≥2/3 follow the protocol, a new checkpoint can always be justified/finalized without honest validators violating a commandment. Backstopped operationally by the inactivity leak (§6). [FACT] (Casper FFG paper, eth2book, annotated-spec) [source]

LMD-GHOST (the fork-choice rule)

Acronym = Latest Message Driven Greediest Heaviest-Observed SubTree. It picks the canonical HEAD for block production and attestation. [FACT] (Gasper paper, consensus-specs, annotated-spec, eth2book) [source]
GHOST chooses the heaviest SUBTREE, NOT the longest/heaviest chain (repeatedly stressed misconception). A vote for a block is implicitly a vote for all its ancestors, so whole subtrees accrue weight; at each fork, take the child subtree with the greatest accumulated weight until reaching a leaf = head. (Origin: Sompolinsky & Zohar 2013.) [FACT] (annotated-spec, eth2book, EF "two ghosts" blog, Gasper paper) [source]
"Latest message" = only each validator's MOST RECENT attestation (head vote) counts - one effective vote per validator; earlier votes are discarded; the latest carries weight indefinitely until replaced. This bounds forks to O(validators) and is why FFG attestations can double as head votes. [FACT] (annotated-spec, eth2book, EF blog, Gasper paper) [source]
Weight = sum of effective balances of validators whose latest attestation supports block B or any descendant. Ties broken by highest block root/hash. [FACT] (consensus-specs, Gasper paper, annotated-spec) [source]
In full Ethereum the GHOST search starts from the latest justified checkpoint, not genesis - this is the seam where FFG constrains LMD-GHOST. [FACT] (annotated-spec, consensus-specs, Gasper paper) [source]
LMD-GHOST alone provides NO finality (validators can build a competing chain with no penalty for the fork itself); irreversibility comes only from FFG. [FACT] (annotated-spec, eth2book, EF blog) [source]

How they combine into Gasper

Gasper = Casper FFG (safety overlay) + LMD-GHOST (fork choice/liveness). The combination rule (annotated-spec): (1) compute the finalized checkpoint via FFG - all canonical chains must pass through it; (2) track the latest justified checkpoint (LJC) descending from it; (3) run LMD-GHOST from the LJC as root to compute the head. FFG constrains LMD-GHOST by pruning branches not descending from the last finalized checkpoint. [FACT] (annotated-spec, consensus-specs, eth2book) [source]
Division of labor: LMD-GHOST runs every slot for liveness; FFG follows behind on epoch boundaries for safety ("two ghosts in a trench coat"). Under normal operation (one honest proposer/slot) a fork choice is barely needed; it matters under asynchrony or an equivocating proposer. [FACT] (annotated-spec, EF blog, Gasper paper) [source]
The FFG↔LMD interface is the acknowledged source of complexity and a stream of patched attacks - Vitalik: "a number of attacks that have required fairly complicated patches." [FACT] (eth2book, Gasper paper, consensus-specs) [source]
Patched issues (NAMING only): [source]
Bouncing attack (2019): withhold-then-release votes to flip-flop justification and halt finality. Original fix: only let the fork-choice LJC change in the first 1/3 of an epoch ("sticky" LJC) - later removed in Capella as workable-around. [FACT] (eth2book, consensus-specs, ethereum/research) [source]
Balancing attack (2020–22): split honest validators' head views via message-timing. Defense: proposer boost (a timely proposal gets temporary weight, letting an honest proposer impose its view). [FACT] (eth2book, consensus-specs, ethresear.ch) [source]
Contested: a 2022 eprint argues the LMD feature enables a balancing variant that overcomes proposer boost unless the proposal weight exceeds the adversary's equivocating votes by a constant factor - i.e. proposer boost is not a complete fix. Presented as a known theoretical weakness, not a live break; preserved against the "mitigated" framing. [TENTATIVE] (eprint 2022/289) [source]
Economic-cost anchor: reverting a finalized block requires owning 2/3 of stake AND burning ≥1/3 of total staked ETH (a 2/3-vote on both forks ⇒ ≥1/3 double-voted ⇒ slashed). [FACT] (annotated-spec, ethereum.org Gasper, eth2book) [source]

Attestation rewards (post-Altair participation flags) [VOLATILE: weights]

An attestation's three votes are each rewarded if correct AND timely: reward per flag = base_reward × flag_weight × flag_attesting_rate / 64. Flag weights: TIMELY_SOURCE = 14, TIMELY_TARGET = 26, TIMELY_HEAD = 14, SYNC_REWARD = 2, PROPOSER = 8, WEIGHT_DENOMINATOR = 64 (sum = 64; unchanged since Altair 2021). [FACT] (consensus-specs/altair, ethereum.org rewards-and-penalties, ethereum.org attestations, eth2book rewards) [source]
Timeliness deadlines: source ≤ √32 = 5 slots; target ≤ 32 slots; head exactly 1 slot (next slot). [FACT] (consensus-specs/altair, eth2book) [source]
Asymmetry: missing/incorrect source and target are penalized (equal value subtracted); the head vote is reward-only, never penalized; no penalty for inclusion delay or for failing to propose. Roughly: target 40.6%, source 21.9%, head 21.9%, proposer 12.5%, sync 3.1% of base reward. base_reward ∝ effective_balance / √(total active balance). [FACT] (ethereum.org rewards-and-penalties, eth2book, ethstaker) [source]
Doc-vs-spec tension: ethereum.org's rewards page still mixes the legacy inclusion_delay_reward with the Altair flag model; the spec + eth2book are authoritative for the live mechanism. [TENTATIVE - contradiction] [source]

Proposer rewards [VOLATILE: PROPOSER_WEIGHT=8]

A proposer earns for including others' messages (aggregate attestations, sync aggregates, slashing evidence). The proposer reward = PROPOSER_WEIGHT/(WEIGHT_DENOMINATOR − PROPOSER_WEIGHT) = 8/56 = 1/7 of attester reward → 7/8 of issuance to attesters, 1/8 to proposers. For including slashing evidence the proposer is rewarded slashed_effective_balance / WHISTLEBLOWER_REWARD_QUOTIENT (512 pre-Electra), taking the PROPOSER_WEIGHT/WEIGHT_DENOMINATOR cut. [FACT] (consensus-specs/altair, eth2book rewards, ethereum.org block-proposal) [source]

The inactivity leak ("quadratic leak") [VOLATILE: constants]

Triggered when the chain fails to finalize for > MIN_EPOCHS_TO_INACTIVITY_PENALTY = 4 epochs. Purpose: bleed non-participating validators' stake so the participating set climbs back to a 2/3 supermajority and finality resumes - it does not require ejecting them. [FACT] (ethereum.org rewards-and-penalties, eth2book inactivity, consensus-specs issue #2098) [source]
Quadratic mechanics: an always-offline validator's cumulative penalty after t epochs ≈ t(t+1)B/2α (quadratic; B(t)=B₀·e^(−t²/2α)). Altair individual inactivity scores: +INACTIVITY_SCORE_BIAS=4 per missed timely target, −1 per hit, and −INACTIVITY_SCORE_RECOVERY_RATE=16 once finalizing again. INACTIVITY_PENALTY_QUOTIENT_BELLATRIX = 2²⁴. [FACT] (eth2book, consensus-specs, issue #2125) [source]
Active/online validators roughly break even during a leak (no attestation rewards, but their inactivity score stays ~0, so no leak penalty; proposer/sync rewards continue). [FACT] (eth2book, consensus-specs issue #1370) [source]
Real-world: the only mainnet trigger was a brief 9-epoch non-finality on 2023-05-12. [QUALIFIED] (eth2book, ethereum.org) [source]

Slashing conditions

Two slashable ATTESTATION offenses (Casper Commandments): (a) double vote - two distinct attestations for the same target epoch; (b) surround vote - one attestation's source→target span surrounds another's (h(s1)<h(s2)<h(t2)<h(t1)). [FACT] (Casper FFG paper, ethereum/research, eth2book slashing, Coinbase, consensus-specs) [source]
Slashable BLOCK offense: double proposal / proposer equivocation - signing two different beacon blocks for the same slot. (eth2book notes a fourth LMD-GHOST attester-equivocation case: two different head votes with the same source+target.) [FACT] (eth2book, ethereum.org, Coinbase) [source]
All slashable behaviors are equivocation, provable purely from signatures (no chain-state dependency), reported on-chain via AttesterSlashing / ProposerSlashing in the block body. Empirically ~90%+ of observed slashings are double votes; no clean surround votes seen. [FACT] (eth2book, ethereum.org, Coinbase) [source]

Slashing penalty mechanics (three parts) [VOLATILE]

(a) Initial penalty: effective_balance // MIN_SLASHING_PENALTY_QUOTIENT, burned immediately. History: Phase 0 = 1/128; Altair = 1/64; Bellatrix = 1/32 (≤1 ETH for a 32-ETH validator); Electra/EIP-7251 = 1/4096 (MIN_SLASHING_PENALTY_QUOTIENT_ELECTRA = 4096 ≈ "3 days of rewards," ~0.0078 ETH for 32 ETH / ~0.5 ETH for 2048 ETH - deliberately negligible to de-risk consolidating large validators). [FACT] (eth2book slashing, consensus-specs/electra, EIP-7251, Chorus One) [source]
(b) Correlation penalty: applied at the halfway point of the withdrawability window - EPOCHS_PER_SLASHINGS_VECTOR = 8192 epochs (~36 days), so the correlation penalty lands at 4096 epochs ≈ 18 days. Penalty = min(B, PROPORTIONAL_SLASHING_MULTIPLIER × S × B / T) where S = total effective balance slashed in the ~36-day window, T = total active balance, B = this validator's balance. PROPORTIONAL_SLASHING_MULTIPLIER_BELLATRIX = 3 (unchanged by Electra). Isolated slash → near-zero correlation penalty; mass/correlated slash → up to the full effective balance (100% loss when ≥1/3 of all stake is slashed in the window). This is the anti-correlation / discouragement design. [FACT] (eth2book, ethereum.org rewards-and-penalties, consensus-specs/electra, LlamaRisk) [source]
(c) Whistleblower + proposer reward: whistleblower reward = effective_balance / WHISTLEBLOWER_REWARD_QUOTIENT (512 pre-Electra → 4096 in Electra, capped to match the reduced penalty); the block proposer that includes the slashing takes a 1/8 cut. In practice whistleblower and proposer are usually the same validator. [FACT] (consensus-specs phase0+electra, eth2book, ethereum.org block-proposal, EIP-7251) [source]
A slashed validator is force-exited and ejected, stops earning, and also leaks ~offline penalties over the ~36-day exit period (~0.07 ETH). Typical isolated-event total loss historically ~1–2 ETH (~3–6% of a 32-ETH stake). [FACT] (eth2book, Consensys, LlamaRisk) [source]
Slashing is rare and almost always operational, not malicious: <0.04% of validators ever slashed; the dominant cause is double-signing from redundant/failover setups or shared infra during migration. Largest event: ~202 validators / ~6,400 ETH in May 2023. [FACT] (Consensys, Symbiotic, Everstake) [source]
Misconceptions (negation findings): [source]
"Being offline = slashing" - FALSE (the single most common misconception). Offline → a small, recoverable inactivity/missed-attestation penalty (rule of thumb: X hours offline ≈ X hours to recover); slashing requires provable equivocation. [FACT] (EthStaker, Lido CSM, ortegarodrigo) [source]
Inactivity leak ≠ slashing ≠ ordinary offline penalty. The leak is a rare network-wide emergency (>4 epochs non-finality); a normal solo staker never experiences it. [FACT] (ethereum.org, eth2book, EthStaker) [source]
A missed block proposal carries zero penalty (only the lost reward). [FACT] (EthStaker) [source]
Minority-client incentive: because the correlation penalty scales with the slashed share of the network, running a minority CL client lowers tail risk (a >1/3-share buggy client could cause ~100% loss). [QUALIFIED] (LlamaRisk) [source]

7. Withdrawals

Shapella (Shanghai = EL name, Capella = CL name) activated 2023-04-12 (epoch 194048, 22:27:35 UTC), enabling staking withdrawals; before that, staked ETH + rewards were locked (since the 2020 beacon-chain launch). [FACT] (EF Shapella announcement, EIP-4895, launchpad FAQ, eth2book) [source]
EIP-4895 ("Beacon chain push withdrawals as operations") is the EL change: withdrawals are a system-level operation in the execution payload (deliberately NOT a transaction type), processed after user transactions; push-based, not pull-based. [FACT] (EIP-4895, eth2book, EIP-4863 rejected predecessor) [source]
Withdrawal credentials (first byte / prefix): 0x00 = original BLS (funds locked until updated); 0x01 = execution/eth1 (0x01 + 11 zero bytes + a 20-byte execution address - required to receive withdrawals); 0x02 = compounding (Pectra). [FACT] (ethereum.org keys, launchpad, eth2book, beaconcha.in) [source]
A 0x00 validator must do a one-time, irreversible BLSToExecutionChange (BTEC) (signed with the BLS withdrawal key) to become 0x01; max 16 BTEC/block. The payout address then cannot change again (only exit + re-stake). [FACT] (launchpad FAQ, eth2book, Prysm, Teku docs) [source]
Partial withdrawal ("skimming"): for an active 0x01 validator at the 32-ETH cap, the excess above 32 ETH is auto-swept to the withdrawal address; the validator keeps validating. Full withdrawal: for an exited + withdrawable validator, the entire balance is paid out. No minimum amount; if a validator qualifies for both, full takes precedence. [FACT] (launchpad FAQ, ethereum.org staking/withdrawals, eth2book, ethstaker) [source]
The withdrawal sweep is permissionless and automatic: the block proposer sweeps validator indices in order via a rolling pointer (next_withdrawal_validator_index), including up to MAX_WITHDRAWALS_PER_PAYLOAD = 16 eligible withdrawals/block, wrapping at the registry end. A full cycle takes ~several days (eth2book: ~576k validators ≈ ~5 days). [FACT] (consensus-specs/capella, eth2book, ethstaker) [source]
Withdrawals are NOT transactions and cost no gas (EIP-4895: "no associated gas costs"); they don't compete for EL block space, and the automatic sweep to a contract address executes no contract code (no fallback). (Common misconception: people assume they must "claim" via a paid tx.) [FACT] (EIP-4895, eth2book, ethstaker, Finematics) [source]
EIP-7002 ("EL triggerable withdrawals/exits") shipped in Pectra (2025-05-07): the withdrawal-credential holder (0x01/0x02) can trigger a partial withdrawal OR a full exit directly from the execution layer (via a system contract / the withdrawal address) - without the active validator BLS key. Important for staking pools and key-loss scenarios. These manual EL-triggered withdrawals pass through the shared exit/withdrawal queue and do cost gas. [FACT] (EIP-7002, EF Pectra blog, ethereum.org/roadmap/pectra, QuickNode) [source]
EIP-7251 0x02 "compounding" credentials (Pectra): 0x02 validators raise the cap to 2,048 ETH (32-ETH activation minimum unchanged), auto-compound rewards in 1-ETH increments, and are NOT auto-skimmed until > 2,048 ETH; below that, partial withdrawals must be manually triggered via EIP-7002 (gas). Conversions 0x00→0x01 and 0x01→0x02 are each one-way. [FACT] (EIP-7251, ethereum.org maxeb, ethstaker Pectra, beaconcha.in) [source]

8. Finality & Weak Subjectivity

Time-to-finality ≈ 2 epochs ≈ 12.8 minutes under normal conditions (64 slots × 12 s = 768 s minimum; ~15 min often quoted; average for an arbitrary tx ≈ +½ epoch). A checkpoint is justified after one epoch's ≥2/3 supermajority vote, then finalized the next epoch when its child checkpoint is justified - Casper FFG pipelines the two rounds. [FACT] (Vitalik epoch/slot post, EF Consensus blog "Upgrading finality", Chainlink CCIP, ethereum.org SSF) [source]
This is economic / crypto-economic finality (deterministic + economic): reverting a finalized block requires burning ≥1/3 of total staked ETH. Contrast PoW probabilistic finality - no explicit finalized state, just exponentially-harder-to-revert confirmations (Bitcoin's ~6 confs ≈ ~60 min) where users pick their own confidence threshold. [FACT] (QuickNode finality, ethereum.org PoS FAQ, EF Consensus blog) [source]
Misconception: Ethereum finality is NOT instant - there is a justified→finalized lag (~2 epochs) during which short reorgs are possible (Gasper depth in §5). [QUALIFIED] (QuickNode, ethereum.org SSF/FAQ) [source]
Weak subjectivity (WS): a new node syncing from genesis, or one offline longer than the WS period, cannot rely on fork choice alone to find the canonical chain - it needs a recent trusted WS checkpoint (a recent finalized state/block root obtained out-of-band: a block explorer, a trusted node, or bundled in client software). The node treats it as a pseudo-genesis "universal truth" and rejects conflicting earlier blocks ("revert limit"), verifying objectively forward. Ethereum's three states: objectivity (PoW - syncable from genesis), subjectivity, and weak subjectivity (objective after one socially-obtained seed). [FACT] (ethereum.org weak-subjectivity, consensus-specs WS guide, Teku docs, ethereum.org attack-and-defense) [source]
WHY (long-range attack): because PoS block creation is costless and not time-rate-limited, an attacker holding old validator keys whose stake is no longer at risk (already-exited validators who withdrew, or leaked/sold historical keys) can build a plausible fake-history fork from the past; an offline/new node unaware those validators have exited could be fooled. The finality gadget + slashing + WS checkpoints neutralize this by defining pre-checkpoint forks as invalid. (Related to, but distinct from, nothing-at-stake.) [FACT] (ethereum.org weak-subjectivity + attack-and-defense, consensus-specs WS, Trail of Bits, Pikachu paper, CarlBeek HackMD) [source]
The WS period = how long a node can safely be offline; a function of validator-set size/churn and a decay parameter D = SAFETY_DECAY (typical D = 10% → an attacker needs ~1/3 − 10% ≈ 23% of stake to fool a returning node, vs the normal 1/3). Concrete spec-table values (D=10%, ~32-ETH avg balance) [VOLATILE 2026-06]: ~504 epochs (≈2.2 days) at 32,768 validators; plateauing at ~2,241 epochs (≈10.0 days) for ≥262,144 validators - the period stops growing at high counts because the churn limit caps how fast the set can change. (Post-Electra it is computed on balance-based churn; the brief's "weeks to months" overstates today's ~10-day plateau - preserve the spec figure as authoritative.) [FACT] (consensus-specs WS guide table, CarlBeek/adiasg HackMD, Teku docs) [resolves a sub-agent INSUFFICIENT-DATA flag] [source]
Checkpoint sync is the practical UX: clients (Lighthouse/Prysm/Teku/Lodestar --checkpoint-sync-url, Nimbus trustedNodeSync) fetch a recent finalized state from a trusted endpoint, verified against explorers/multiple nodes; the WS check also tells a client when a checkpoint is too old to sync from. [FACT] (launchpad checkpoint-sync, Teku, ethereum.org) [source]
Single-slot finality (SSF): a roadmap research direction to finalize a block within its own slot (vs ~2 epochs/~13 min), removing the justified/finalized lag and the reorg/MEV window; requires a new finality protocol. EXPLICITLY NOT SHIPPED as of 2026-06 - ethereum.org (last updated ~Feb 2026) states "SSF is in the research phase... not expected to ship for several years." [FACT] (ethereum.org SSF, EF Consensus blog, Vitalik SSF HackMD, Lean roadmap) [source]
Prerequisite: SSF needs the full validator set to attest each slot → depends on shrinking/capping the set, which is why raising MaxEB (EIP-7251, already shipped) matters (operators consolidate into fewer, larger validators, cutting signatures/messages per slot). [FACT] (ethereum.org SSF, Vitalik/Neuder HackMDs) [source]
3-slot finality (3SF) is an intermediate proposal (finalize an honest-proposer block in 3 slots, one vote phase/slot) on the "Lean Consensus"/faster-finality roadmap - like SSF, not yet scheduled for a specific mainnet fork. [QUALIFIED] (ethresear.ch 3SF, Lean roadmap) [source]

Key Takeaways

Gasper is two protocols glued at a tricky seam. LMD-GHOST (heaviest subtree from the latest justified checkpoint, latest-message-only) supplies liveness every slot; Casper FFG (supermajority links justifying/finalizing epoch-boundary checkpoints) supplies safety. Most subtleties and patched attacks (bouncing, balancing, proposer boost) live at their interface. [source]
Slashing ≠ inactivity leak ≠ offline penalty - the highest-value clarification for users. Slashing punishes provable equivocation (rare, usually operational); the leak is a network-wide non-finality emergency; ordinary downtime is a small recoverable penalty. [source]
Pectra (May 2025) is the dominant volatility source. EIP-7251 (MaxEB 32→2048, 0x02 compounding, balance-based churn, negligible initial slashing penalty), EIP-7002 (EL-triggerable exits), EIP-6110 (fast deposits). 32 ETH is still the activation minimum. [source]
Finality is fast but not instant (~12.8 min) and not objective. New/long-offline nodes need a weak-subjectivity checkpoint (~10-day plateau period today) because PoS history is forgeable with old keys. SSF would fix the lag but is years away. [source]
Three brief corrections (below) should be carried into the reference verbatim. [source]

Corrections to the source brief (flagged, high-confidence)

Sync committees come from Altair, not EIP-6110. EIP-6110 is an unrelated Electra deposit-flow change; the sync-committee EIP is EIP-7657 (slashings, draft). [FACT] [source]
**The shard/crosslink attestation field was removed (PR #1428, Oct 2019), not "set to 0/None." The field now zeroed in Electra is the committee index (EIP-7549). [FACT]** [source]
Duty-lookahead is asymmetric: committee/attester duties are known ~2 epochs ahead; proposer duties only ~1 epoch ahead (EIP-7917 draft would make them deterministic). [QUALIFIED] [source]
(Minor) The weak-subjectivity period today is ~10 days (plateau), not "weeks to months" at current validator counts. [FACT] [source]

Contradictions (preserved)

MaxEB value on ethereum.org: older block-proposal sections say "32 ETH"; the maxeb page + EIP-7251 + Electra specs say 2,048 ETH (32 is the activation floor). Authoritative = 2,048. [TENTATIVE] [source]
Proposer-boost completeness: consensus-specs/eth2book frame proposer boost as mitigating balancing attacks; eprint 2022/289 argues an LMD-specific variant can still overcome it. Preserved as a theoretical weakness, not a live break. [TENTATIVE] [source]
ethereum.org rewards page mixes the legacy inclusion_delay_reward with the Altair flag model; spec + eth2book authoritative. [TENTATIVE] [source]

Knowledge Gaps

None at the protocol-user level - all 8 sub-concepts reached ≥3 independent sources. The previously-flagged weak-subjectivity numeric was resolved against the consensus-specs WS-guide table (~2.2–10 day range, ~10-day plateau). [source]

Sources (deduplicated; tier in brackets)

Specs / consensus-specs [source]
consensus-specs phase0/beacon-chain.md, altair/beacon-chain.md, bellatrix, electra, capella, deneb - all core constants, slash_validator, flag weights, churn, withdrawals [spec] [source]
consensus-specs phase0/fork-choice.md - LMD+GHOST, get_head/get_weight, proposer_boost [spec] [source]
consensus-specs phase0/weak-subjectivity.md (v1.3.0) + Gloas WS guide - WSP formula + value table, EIP-8061 split [spec] [source]
consensus-specs PRs #1428 (shard removal), #3900 (EIP-7549), #4476/#4926 (SLOT_DURATION_MS) [spec] [source]
consensus-specs mainnet.yaml - MIN_PER_EPOCH_CHURN_LIMIT=4, CHURN_LIMIT_QUOTIENT=65536, activation cap=8 [spec] [source]
annotated-spec (Vitalik) phase0/beacon-chain.md, fork-choice.md, merge/beacon-chain.md - Gasper combination, finality timing, block-inside-a-block [spec] [source]
execution-apis Engine spec - engine_forkchoiceUpdated, engine_newPayload [spec] [source]
consensus-specs issues #1370, #2098, #2125 - inactivity-leak design/quadratic [forum] [source]
arXiv 2003.03052 - Gasper "Combining GHOST and Casper" [paper] [source]
arXiv 1710.09437 + ethereum/research casper_basics.tex - Casper FFG, the two commandments, accountable safety [paper] [source]
arXiv 2403.09541 - Last-Revealer Attack (RANDAO biasability) [paper] [source]
eprint 2022/289 - LMD balancing-attack variant vs proposer boost (contested) [paper] [source]
arXiv 2208.05408 (Pikachu) - long-range / posterior-corruption attack formalization [paper] [source]
Book (eth2book, Ben Edgington "Upgrading Ethereum") [source]
eth2book part2: consensus/casper_ffg, lmd_ghost; part3/forkchoice - FFG + LMD-GHOST mechanics, worked GHOST example [book] [source]
eth2book part2: building_blocks/randomness, signatures, aggregator - RANDAO, BLS aggregation, ~16 aggregators [book] [source]
eth2book part2: incentives/rewards, inactivity, slashing - reward matrix, quadratic leak, 3-part slashing penalty [book] [source]
eth2book part2: deposits-withdrawals (+ withdrawal-processing, deposit-processing); part3 helpers/config - lifecycle, sweep, churn constants [book] [source]
Docs (ethereum.org + client docs) [source]
ethereum.org/developers/docs/consensus-mechanisms/pos/ (+ /attestations, /block-proposal, /rewards-and-penalties, /gasper, /weak-subjectivity, /attack-and-defense, /keys, /faqs) [docs] [source]
ethereum.org/roadmap/ merge, beacon-chain, pectra, pectra/maxeb, single-slot-finality; /energy-consumption; /staking/withdrawals [docs] [source]
consensus.ethereum.foundation blog "Upgrading finality"; EF blogs: Merge announcement (2022-08), Shapella (2023-03), Pectra mainnet (2025-04), "two ghosts in a trench coat" (2020-02), Casper history [blog/docs] [source]
Prysm validator-lifecycle / withdraw-validator; Teku weak-subjectivity + withdrawal-keys; EthStaker downtime/withdrawal/chain-rewards; Lido CSM slashing-prevention; launchpad withdrawals/checkpoint-sync FAQs [docs] [source]
Telepathy, Snowfork, Succinct - sync-committee security/no-slashing [docs/blog] [source]
EIP-3675 (TTD/PoW deprecation), EIP-4895 (withdrawals), EIP-4863 (rejected), EIP-6110 (on-chain deposits), EIP-7002 (EL-triggerable exits), EIP-7251 (MaxEB 2048 / 0x02), EIP-7514 (activation churn=8), EIP-7549 (attestation index), EIP-7657 (sync-committee slashings, draft), EIP-7917 (deterministic proposer lookahead, draft), EIP-8061 + EIP-7922 (churn proposals, draft) [eip] [source]
Blog / forum (corroboration + figures) [source]
Figment, Liquid Collective, Chorus One, LlamaRisk, Consensys, Symbiotic, Everstake - Pectra/slashing/penalty figures [blog] [source]
Blocknative, Polygon - Merge gas-fee misconception [blog] [source]
QuickNode, Chainlink CCIP, Alchemy commitment-levels - finality timing/levels [blog/docs] [source]
ethresear.ch - selfish-mixing/RANDAO, balancing-attack fork-choice change, 3SF; HackMD CarlBeek/adiasg (WS), Vitalik/Neuder (SSF/MaxEB); Lean roadmap; Trail of Bits finality guide; Speedrun/StackExchange (RANDAO not an oracle); Coinbase eth2 slashings; ethos.dev; ortegarodrigo [forum/blog] [source]

Methodology

Researched via 6 parallel research clusters (fan-out, centralized verification by the orchestrator) using the exa MCP (web_search_exa / web_fetch_exa); firecrawl was unavailable (HTTP 402). Total ~67 search/fetch queries across clusters + 2 orchestrator verification fetches; negation/disconfirming queries ran ~29–50% per cluster (well above the 15% floor). Sub-concepts investigated: (1) PoS/Merge, (2) validators/staking, (3) time structure, (4) attestations, (5) Gasper (FFG + LMD-GHOST), (6) rewards/penalties/slashing, (7) withdrawals, (8) finality/weak subjectivity. Primary sources prioritized (consensus-specs, eth2book, Gasper/Casper papers, EIPs, ethereum.org); citation chains collapsed to primaries. No prompt-injection or instruction-shaped content was encountered in any fetched page. [source]

Children

No children recorded.

← the whole tree · 3D view· how to read this page