**VERDICT CONFIRMED — prysm-4/5, with scope and impact qualifications.** At Prysm `eb681c1d13b57c2d0c5da27a63bb41ac9d071e1a`, both proposed omissions survive static review: REST/gRPC submission can record a current-slot committee member's vote against an older block, and the unknown-block queue can record a message in the following slot. The first path checks current slot, membership and signature, but not the referenced block's slot; the second checks the block's slot on replay, but not current slot. The shared receiver and `SetPTCVote` supply neither missing guard. Queue pruning exists but deliberately retains the preceding slot. These are divergences in recorded fork-choice votes; a head change depends on the surrounding votes and payload state. This review does not establish a persistent consensus split. [Spec][spec], [REST][rest], [gRPC][grpc], [receiver][receive], [queue][pending], [vote setter][fc].

**Scope, pins and live-code check.** Reviewed on 2026-10-27; public source/API reads only, with no client execution, node requests, signed-message submission or devnet experiment. This is the assigned single-candidate review, not a new inventory of all Glamsterdam EIPs or clients. The applicable proposal is **EIP-7732**, listed as scheduled by meta EIP-7773 at EIPs `d4c57552` (line 26); EIP-7732 is Last Call at that pin. The normative comparison here is the explicitly supplied consensus-specs `8a80ffa8`, `specs/gloas/fork-choice.md`. EIP-7732's embedded consensus links point to a different revision, `d9663f85...`; they were not substituted for the requested pin. The supplied execution-specs `7f2f4c9b` pin does not determine these CL message-admission rules. [Meta EIP][meta], [EIP-7732, lines 1–12 and 45–54][eip].

This is Gloas-specific behavior, not a finding in an activated mainnet PTC path: the pinned mainnet configuration sets `mainnetGloasForkEpoch = math.MaxUint64` at line 36, and committee access rejects pre-Gloas states. Ethereum's public roadmap also describes Glamsterdam as upcoming, with its mainnet date unconfirmed. Consequently the task's mainnet-details-withheld rule does not apply to this record. [Mainnet config][mainnet], [committee accessor, lines 740–749][committee], [roadmap][roadmap].

**Strongest refutation attempt: state lookup could implicitly bind the message to its block slot.** It does not. Choose consecutive slots `t` and `t+1` within one Gloas epoch, away from fork activation, with a known head block `R` at `t` and no newer head yet at `t+1`. Submit a correctly signed message with `data.slot = t+1`, `beacon_block_root = R`, and a validator in the `t+1` PTC. `PtcLookupState` computes `blockEpoch` from the caller-supplied message slot (line 53), not the block node. After resolving the dependent root, same epoch plus `blockRoot == headRoot` returns the head state immediately (lines 64–66). `DependentRootForEpoch` accepts the known same-epoch root; its underlying lookup uses epochs/ancestry, not exact slot equality. `PayloadCommitteeReadOnly(t+1)` accepts another slot within that state's epoch, and `PayloadCommitteeIndices` only requires membership in that selected committee. Thus current-slot membership does not imply that `R` was produced in the current slot. Signature verification proves who signed the supplied data, not that the root and slot agree. [Receiver, lines 52–88][receive], [chain wrapper, lines 574–587][chain], [dependent-root implementation, lines 834–909][deps], [accessor, lines 740–785][committee], [membership, lines 190–211][indices], [signature, lines 151–189][signature].

**Other refutation routes and their outcomes.**

| Attempt | Result and evidence |
| --- | --- |
| Another guard on the API path | REST `handlers_pool.go#L993-L1046` and gRPC `payload_attestation.go#L64-L84,#L105-L119` check the current slot, look up the committee and verify the signature, then broadcast and call the receiver. Neither reads the block's actual slot. The receiver `#L27-L50` resolves committee positions and calls `SetPTCVote`; the setter `gloas.go#L537-L549` selects the node by root and writes the bits. [REST][rest], [gRPC][grpc], [receiver][receive], [setter][fc]. |
| Broadcast invokes gossip validation and rejects the API message | The generic broadcaster serializes/publishes (`broadcaster.go#L41-L66,#L664-L690`). The payload gossip validator accepts self-originated messages immediately (`validate_payload_attestation.go#L23-L26`). Its remote-message block-slot check (`#L85-L92`) therefore does not protect the explicit local receiver call. Both API counterexamples require broadcast to succeed. [Broadcaster][broadcast], [gossip][gossip]. |
| Queue pruning removes stale messages at each slot boundary | Pruning is called by pending-block processing, scheduled three times per slot (`pending_blocks_queue.go#L32-L65`). But `pending_payload_attestation.go#L110-L122` deletes an entry only when `att.slot + 1 < currentSlot` (or malformed/empty). At `currentSlot = t+1`, a slot-`t` entry survives even if pruning has just run. Replay does not call `VerifyCurrentSlot`. [Pending-block processing][pendingblocks], [queue][pending]. |
| Downstream cache or pool rejects an old replay | `PayloadAttestationCache.Seen` is a slot/index deduplicator; `Add` replaces its tracked slot even when the supplied slot is older. The pool prunes relative to the incoming message's slot, not wall-clock slot. With an unseen validator/message and valid signature encoding, these do not reject the replay before the receiver. [Cache, lines 18–44][cache], [pool, lines 88–145][pool], [subscriber, lines 25–53][subscriber]. |
| A valid-chain invariant prevents the conditions | The API example needs an ordinary known head at `t` during slot `t+1`, plus a current PTC member willing to sign mismatched data; it does not need an invalid beacon block. For replay, a valid block may arrive one slot late: Gloas `on_block` permits `current_slot >= block.slot` (`#L1063-L1069`). Neither exact current-slot arrival nor a new head every slot is a chain-validity invariant. Choose all slots in the same epoch and a recent nonfinalized block, avoiding state-window/fork-boundary objections. [Spec][spec], [lookup][receive], [committee accessor][committee]. |
| The spec uses the processed lookup state's slot, or queued messages become block-carried | The spec obtains the referenced block's stored state before the equality check, not a head state selected to resolve PTC duties. The current-slot exception is specifically `is_from_block`; arrival of the referenced block does not put the independently queued message inside that block. The replay call passes the original message to the ordinary subscriber/receiver. [Spec, lines 1139–1187][spec], [queue, lines 68–107][pending], [subscriber][subscriber]. |
| A merged fix already addresses these paths | PR #17555 fixes the separate in-block handler. PR #16878 fixes remote gossip block-slot validation; #17363 adds API signature verification; neither installs the missing receiver checks. The public `develop` commit resolved to the supplied pin during this review; the inspected path histories show no later fix on that branch. Details below. [#17555 files][pr17555files], [#16878 files][pr16878files], [#17363 files][pr17363files], [develop][develop]. |

**Corrected surviving record.** Client: **Prysm**. EIP: **7732 / Gloas**. Pin: **`eb681c1d13b57c2d0c5da27a63bb41ac9d071e1a`**. Severity category: **fork-choice divergence**. Confidence: **high for the missing admission checks and resulting vote-vector divergence, moderate for a consequential head change without execution**.

The exact governing spec fragments at consensus-specs `8a80ffa8` are:

```python
# L1150
state = store.block_states[data.beacon_block_root]
# L1153-L1154
if data.slot != state.slot:
    return
# L1167-L1169 (comment omitted)
if not is_from_block:
    assert data.slot == get_current_slot(store)
```

These guards precede the vote assignments at lines 1182–1187. Unknown-block processing is deferred at lines 1148–1149; the subsequent current-slot check has no queue exemption. [Pinned fork-choice specification][spec].

**A. API block-slot mismatch (prysm-4).** Exact path: `beacon-chain/rpc/eth/beacon/handlers_pool.go#L993-L1046` or `beacon-chain/rpc/prysm/v1alpha1/validator/payload_attestation.go#L64-L119` → `beacon-chain/blockchain/receive_payload_attestation_message.go#L27-L50` (lookup `#L52-L88`) → `beacon-chain/forkchoice/doubly-linked-tree/gloas.go#L537-L549`. Use the same-epoch, previous-slot head example above, an available Gloas state/committee, a valid current-PTC signature, a nonsyncing API service and successful broadcast. The node records the current committee positions on `R`, although the spec returns before recording anything because `R`'s stored block state is at `t`, not `t+1`. This requires access to the submission API and an eligible signer's message; it is not an unsigned arbitrary-peer injection. Remote gossip of that same mismatched message is checked and ignored. [REST][rest], [gRPC][grpc], [receiver][receive], [setter][fc], [signature][signature], [gossip][gossip].

**B. Delayed unknown-block replay (prysm-5).** Exact path: `beacon-chain/sync/validate_payload_attestation.go#L49-L66` → `pending_payload_attestation.go#L16-L65` → `#L68-L107` → `subscriber_payload_attestation.go#L25-L53` → receiver/setter above. A valid slot-`t` PTC message arrives during `t` before its valid block `R`. Membership/signature checks against a compatible head succeed, the root queue has capacity, and no duplicate has been processed. The block is imported in `t+1`, in the same epoch, after the fork-choice clock has advanced; committee lookup remains available. Replay checks `R.slot == message.slot`, but not `message.slot == currentSlot`. Pruning retains it throughout `t+1`; pool/cache processing succeeds and the receiver records its votes. The spec refuses that non-block-carried message at this processing time. Arrival hooks exist both in `subscriber_beacon_blocks.go#L86-L93` and `pending_blocks_queue.go#L162-L166`. No malicious signature or invalid chain is needed for this ordering. Re-broadcast occurs after local processing, so a failed or deduplicated re-broadcast does not undo the local write. [Gossip][gossip], [queue][pending], [subscriber][subscriber], [block subscriber][blocksubscriber], [pending-block processing][pendingblocks], [receiver][receive], [spec][spec].

The two omissions can set previously absent bits or overwrite existing payload/data-availability bits; this is not necessarily a monotonically increasing vote count. Those fields feed `ptcVotedEarlyAndAvailable`/`ptcVotedLate` and the payload-extension decision (`gloas.go#L260-L316`). Sufficient changed votes can alter a previous-slot payload decision in a suitable surrounding fork-choice state. A single eligible message proves a record mismatch, not by itself a changed canonical head. No invalid-block-acceptance, valid-block-rejection, gas/fee, or persistent-split claim is made. [Vote setter and consumers][fc].

**Other-client cross-check.** Lighthouse `a376defa`, `consensus/fork_choice/src/fork_choice.rs#L1400-L1441`, updates its time from the caller's system slot, resolves the referenced block, returns when `block.slot != payload_attestation.data.slot` (`#L1426-L1428`), and errors on a non-block-carried message whose slot differs from the store's current slot (`#L1430-L1441`). That is direct evidence of both guards at the fork-choice boundary in another implementation; it is not a claim that every Lighthouse caller has been audited. [Pinned Lighthouse source][lh].

**Known-check and later-fix review.** Status values below are public GitHub API observations on 2026-10-27, not a guarantee that no differently worded or unpublished report exists.

| Record | Observed state | Relevance |
| --- | --- | --- |
| [Prysm #17555][pr17555] | Closed, merged 2026-09-28; merge `413fcb51ee1f1b277eefe88ce0653b24aef2e115` | Known adjacent fix. Changed only `beacon-chain/blockchain/process_block.go`, its tests and a changelog. Adds actual block-slot equality and writes every seat belonging to each in-block voter. At the review pin the guard is present at `process_block.go#L640-L645`. It does not modify the standalone receiver, RPC handlers or pending queue. [Files][pr17555files], [pinned in-block code][blockpath]. |
| [Prysm #16878][pr16878] | Closed, merged 2026-06-02 | Known remote-gossip block-slot fix, implementing consensus-specs PR #5281 per its description. Its patch adds `VerifyBlockSlotMatches` to gossip verification, not RPC/receiver admission. [Files][pr16878files]. |
| [Prysm #17363][pr17363] | Closed, merged 2026-10-16 | Known API signature fix, already at the pin. Necessitates a valid eligible signature in the corrected condition, but does not bind the referenced root to the message slot. [Files][pr17363files]. |
| [Prysm #16909][pr16909] | Closed, merged 2026-07-01 | Introduces the bounded queue and replay hooks. Its description mentions stale pruning; the actual pinned strict `<` expression still permits next-slot replay. [Queue source][pending]. |
| [Prysm #17576][pr17576] | Closed, merged 2026-10-07 | Gossip clock-disparity allowance, not a current-slot recheck at queue replay or fork-choice insertion. The example waits until the next slot after clock advancement and does not depend on clock disparity. [Pinned verifier][signature], [queue][pending]. |
| [Prysm #17550][pr17550], [#17552][pr17552] | Open, unmerged | Validator-side PTC data retry/read behavior; neither is a merged beacon-node admission fix. |
| [Prysm #17785][pr17785] | Open, unmerged | PTC duty dependent-root handling at the Gloas fork epoch; the counterexamples use an ordinary same epoch after activation. |
| [Prysm issue #17233][issue17233] | Open | Ordinary pending-attestation re-gossip/seen-message behavior, not this payload-message current-slot admission check. In any case this candidate's local mutation precedes replay broadcast. |

The all-state issue/PR searches for `"payload attestation" "slot"`, `"PTC" "slot"` and `"pending payload"` returned 59, 67 and 33 records respectively. I found the related records above, but did not find an exact report/fix of the remaining API or replay admission omissions. Thus the surviving portions are **not established as already known**; #17555 must not be used to mark them fixed. [Search 1][search1], [search 2][search2], [search 3][search3].

The `commits/develop` API resolved to the review pin (`2026-10-27T15:19:43Z`). Path-history queries were made for the receiver, queue and both API files. Latest listed relevant changes were receiver #17424 (`d4d5b821...`), queue #17103 (`b894b041...`), REST #17711 (`5d2d58da...`, voluntary-exit event change) and gRPC #17363 (`948f8d20...`). No later commit on the observed `develop` head refutes the pinned finding; this is a statement about that observed branch, not every branch. [Head][develop], [receiver history][history1], [queue history][history2], [REST history][history3], [gRPC history][history4].

**Public result coverage and limitations.** Searches of the public Hive and execution-spec-tests issue indexes for Glamsterdam plus payload attestation each returned zero records. I did not obtain a public Hive/EEST run exercising these two CL admission paths. Direct HTTP reads of the Hive results and EEST documentation roots returned 403; the browser reader exposed only a Hive title with no result rows, and an EEST notice that tests/documentation have moved into execution-specs. These are coverage limitations, not evidence that tests passed or that this candidate is novel. No report from these sources was used to claim a reproduced split. [Hive query][hivesearch], [EEST query][eestsearch], [Hive results][hive], [EEST notice][eest].

**Validation performed.** Manually traced both complete source paths and the state, committee, signature, broadcast, cache, pool and pruning refutations; checked the pinned spec and Lighthouse guards; inspected PR #17555's file diff and the public branch/path histories. No behavioral tests were run, as this assignment is source review only. The output was checked locally for UTF-8 Markdown, the required verdict and the 24,000-byte limit. All source line references use one-based lines in the raw files, not browser-rendered line numbering.

**URLs read and cited.** Reference links below identify the evidence; source files are raw pinned files and issue/PR metadata is from the public API.

[spec]: https://raw.githubusercontent.com/ethereum/consensus-specs/8a80ffa8/specs/gloas/fork-choice.md
[meta]: https://raw.githubusercontent.com/ethereum/EIPs/d4c57552/EIPS/eip-7773.md
[eip]: https://raw.githubusercontent.com/ethereum/EIPs/d4c57552/EIPS/eip-7732.md
[roadmap]: https://ethereum.org/roadmap/glamsterdam/
[mainnet]: https://raw.githubusercontent.com/OffchainLabs/prysm/eb681c1d13b57c2d0c5da27a63bb41ac9d071e1a/config/params/mainnet_config.go
[receive]: https://raw.githubusercontent.com/OffchainLabs/prysm/eb681c1d13b57c2d0c5da27a63bb41ac9d071e1a/beacon-chain/blockchain/receive_payload_attestation_message.go
[rest]: https://raw.githubusercontent.com/OffchainLabs/prysm/eb681c1d13b57c2d0c5da27a63bb41ac9d071e1a/beacon-chain/rpc/eth/beacon/handlers_pool.go
[grpc]: https://raw.githubusercontent.com/OffchainLabs/prysm/eb681c1d13b57c2d0c5da27a63bb41ac9d071e1a/beacon-chain/rpc/prysm/v1alpha1/validator/payload_attestation.go
[fc]: https://raw.githubusercontent.com/OffchainLabs/prysm/eb681c1d13b57c2d0c5da27a63bb41ac9d071e1a/beacon-chain/forkchoice/doubly-linked-tree/gloas.go
[pending]: https://raw.githubusercontent.com/OffchainLabs/prysm/eb681c1d13b57c2d0c5da27a63bb41ac9d071e1a/beacon-chain/sync/pending_payload_attestation.go
[gossip]: https://raw.githubusercontent.com/OffchainLabs/prysm/eb681c1d13b57c2d0c5da27a63bb41ac9d071e1a/beacon-chain/sync/validate_payload_attestation.go
[chain]: https://raw.githubusercontent.com/OffchainLabs/prysm/eb681c1d13b57c2d0c5da27a63bb41ac9d071e1a/beacon-chain/blockchain/chain_info.go
[deps]: https://raw.githubusercontent.com/OffchainLabs/prysm/eb681c1d13b57c2d0c5da27a63bb41ac9d071e1a/beacon-chain/forkchoice/doubly-linked-tree/forkchoice.go
[committee]: https://raw.githubusercontent.com/OffchainLabs/prysm/eb681c1d13b57c2d0c5da27a63bb41ac9d071e1a/beacon-chain/state/state-native/getters_gloas.go
[indices]: https://raw.githubusercontent.com/OffchainLabs/prysm/eb681c1d13b57c2d0c5da27a63bb41ac9d071e1a/beacon-chain/core/gloas/payload_attestation.go
[signature]: https://raw.githubusercontent.com/OffchainLabs/prysm/eb681c1d13b57c2d0c5da27a63bb41ac9d071e1a/beacon-chain/verification/payload_attestation.go
[cache]: https://raw.githubusercontent.com/OffchainLabs/prysm/eb681c1d13b57c2d0c5da27a63bb41ac9d071e1a/beacon-chain/cache/payload_attestation.go
[pool]: https://raw.githubusercontent.com/OffchainLabs/prysm/eb681c1d13b57c2d0c5da27a63bb41ac9d071e1a/beacon-chain/operations/payloadattestation/pool.go
[subscriber]: https://raw.githubusercontent.com/OffchainLabs/prysm/eb681c1d13b57c2d0c5da27a63bb41ac9d071e1a/beacon-chain/sync/subscriber_payload_attestation.go
[pendingblocks]: https://raw.githubusercontent.com/OffchainLabs/prysm/eb681c1d13b57c2d0c5da27a63bb41ac9d071e1a/beacon-chain/sync/pending_blocks_queue.go
[blocksubscriber]: https://raw.githubusercontent.com/OffchainLabs/prysm/eb681c1d13b57c2d0c5da27a63bb41ac9d071e1a/beacon-chain/sync/subscriber_beacon_blocks.go
[blockpath]: https://raw.githubusercontent.com/OffchainLabs/prysm/eb681c1d13b57c2d0c5da27a63bb41ac9d071e1a/beacon-chain/blockchain/process_block.go
[broadcast]: https://raw.githubusercontent.com/OffchainLabs/prysm/eb681c1d13b57c2d0c5da27a63bb41ac9d071e1a/beacon-chain/p2p/broadcaster.go
[lh]: https://raw.githubusercontent.com/sigp/lighthouse/a376defa/consensus/fork_choice/src/fork_choice.rs
[pr17555]: https://api.github.com/repos/OffchainLabs/prysm/pulls/17555
[pr17555files]: https://api.github.com/repos/OffchainLabs/prysm/pulls/17555/files
[pr16878]: https://api.github.com/repos/OffchainLabs/prysm/pulls/16878
[pr16878files]: https://api.github.com/repos/OffchainLabs/prysm/pulls/16878/files
[pr17363]: https://api.github.com/repos/OffchainLabs/prysm/pulls/17363
[pr17363files]: https://api.github.com/repos/OffchainLabs/prysm/pulls/17363/files
[pr16909]: https://api.github.com/repos/OffchainLabs/prysm/pulls/16909
[pr17576]: https://api.github.com/repos/OffchainLabs/prysm/pulls/17576
[pr17550]: https://api.github.com/repos/OffchainLabs/prysm/pulls/17550
[pr17552]: https://api.github.com/repos/OffchainLabs/prysm/pulls/17552
[pr17785]: https://api.github.com/repos/OffchainLabs/prysm/pulls/17785
[issue17233]: https://api.github.com/repos/OffchainLabs/prysm/issues/17233
[develop]: https://api.github.com/repos/OffchainLabs/prysm/commits/develop
[history1]: https://api.github.com/repos/OffchainLabs/prysm/commits?sha=develop&per_page=100&path=beacon-chain/blockchain/receive_payload_attestation_message.go
[history2]: https://api.github.com/repos/OffchainLabs/prysm/commits?sha=develop&per_page=100&path=beacon-chain/sync/pending_payload_attestation.go
[history3]: https://api.github.com/repos/OffchainLabs/prysm/commits?sha=develop&per_page=100&path=beacon-chain/rpc/eth/beacon/handlers_pool.go
[history4]: https://api.github.com/repos/OffchainLabs/prysm/commits?sha=develop&per_page=100&path=beacon-chain/rpc/prysm/v1alpha1/validator/payload_attestation.go
[search1]: https://api.github.com/search/issues?q=repo%3AOffchainLabs/prysm%20%22payload%20attestation%22%20%22slot%22&per_page=100
[search2]: https://api.github.com/search/issues?q=repo%3AOffchainLabs/prysm%20%22PTC%22%20%22slot%22&per_page=100
[search3]: https://api.github.com/search/issues?q=repo%3AOffchainLabs/prysm%20%22pending%20payload%22&per_page=100
[hivesearch]: https://api.github.com/search/issues?q=repo%3Aethereum/hive%20%22Glamsterdam%22%20%22payload%20attestation%22&per_page=100
[eestsearch]: https://api.github.com/search/issues?q=repo%3Aethereum/execution-spec-tests%20%22Glamsterdam%22%20%22payload%20attestation%22&per_page=100
[hive]: https://hive.ethpandaops.io/
[eest]: https://eest.ethereum.org/