When is a Solana slot complete from shreds?

2 conditions close local slot data

Local slot data is complete when the receiver knows the terminal data index and has every data shred from index zero through that index. The terminal index comes from a valid LAST_IN_SLOT flag on a data shred.

Neither condition is sufficient alone. Every observed index through 140 does not prove that 140 was terminal. A terminal packet at 140 does not fill a gap at 17. Receivers need the marker and a gap-free range.

This definition concerns bytes proposed by the leader. It does not mean the block executed successfully, won fork choice, received votes, reached a commitment level, or became rooted. Completion should be named slot_data_complete to preserve that boundary.

LAST_IN_SLOT is a data flag

The data-shred flags byte contains LAST_IN_SLOT in its high bits. Current flag semantics make the terminal marker imply DATA_COMPLETE as well.

The implication is logical. The final data shred ends both the current serialized entry batch and the slot's data stream. A parser should reject a flag pattern that claims terminal status without the required completion semantics rather than invent a new interpretation.

Coding shreds do not carry the data flags field. A coding index or final coding position cannot close a slot. Parity can help recover the terminal data shred, but completion state comes from the validated reconstructed data header.

DATA_COMPLETE closes a smaller unit

DATA_COMPLETE marks the final shred in one serialized vector of entries. A slot can contain several such completed ranges before its terminal shred.

This smaller boundary allows incremental decoding. If data indexes 0 through 23 are consecutive and index 23 carries DATA_COMPLETE, the receiver can deserialize that batch even though the leader later emits indexes 24 through 170.

Calling every data-complete marker slot complete discards this distinction and causes premature closure. Calling only the terminal range decodable wastes latency. Track entry_batch_complete and slot_data_complete separately.

Terminal arrival can be early

UDP reordering allows the last-in-slot shred to arrive before earlier data. When index 206 arrives with the terminal flag, the receiver learns the expected source range immediately.

It records terminal_index = 206 and computes the missing set across zero through 206. Existing FEC groups can repair some gaps. Others may still be in flight. The slot remains incomplete until the presence structure has no gap in that range.

The early terminal marker is useful. It turns an open-ended stream into a bounded assembly problem. It does not authorize filling absent positions with zeros or skipping undecodable entry batches.

A terminal claim can conflict

One authenticated packet can mark index 190 as terminal while another authenticated packet claims data index 191 for the same slot view. Different authenticated Merkle roots can also produce different terminal positions.

The receiver must not extend the first slot silently. It has conflicting leader-authenticated evidence. Partition set or block views, retain bounded evidence, and avoid concatenating bytes across the conflict.

Arrival time cannot choose the canonical proposal. Consensus and duplicate handling provide the wider decision. Low-latency consumers can record which view they acted on, then reconcile when executed block data becomes available.

FEC completeness is not slot completeness

One FEC set covers a bounded data-index range. A slot normally contains several sets. Completing the set anchored at 128 says nothing about a missing data index 9 in the first set.

Conversely, slot data can become complete even if some coding shreds never arrive. Parity is a recovery aid. When every source data shred is present directly, coding-set completeness is unnecessary for ledger assembly.

Maintain per-set source completeness and per-slot consecutive completeness independently. Release coding payloads after their source set is complete, while retaining data until its entry batch is consumed.

Presence from zero matters

The slot stream begins at data index zero. A receiver that subscribes halfway through a slot can observe a terminal marker and possess every index from 90 through 150, yet it does not have complete slot data.

For trading, the late receiver may still decode a completed batch if its serialization starts within the captured range and all required bytes are present. It must not label the whole slot complete without the prefix.

For archival completeness, repair or another block source is required. State should distinguish joined_late, missing_prefix, internal_gap, and missing_terminal. These cases call for different remediation.

Parent relation is part of slot validity

Data headers carry a parent offset. Members of one coherent slot proposal should agree on the parent relationship. A complete byte range with inconsistent parent claims is not one valid assembled block.

The parent slot can be less than current slot minus one because slots may be skipped. Completion does not require every numeric slot between parent and child to contain a block.

After local data completion, replay still needs the parent ledger state before executing the child. A child can be byte-complete while its parent data or bank state remains unavailable. Local storage and replay readiness are separate milestones.

Entry batches can be released incrementally

The receiver maintains a current batch start and scans consecutive data indexes. At each DATA_COMPLETE marker, it concatenates meaningful data ranges, deserializes the vector of entries, validates framing, and advances the batch start.

The terminal marker closes the final batch. If every earlier batch was already consumed, slot completion requires little additional work beyond decoding that final range. This is why direct shred parsing can expose transactions throughout production rather than at the end.

Keep enough byte ownership to handle a late conflict. A strategy path can release payloads after decoding, but a diagnostic path may retain hashes or a short raw window. Memory policy and evidence policy need not be identical.

Skipped slots have no terminal shred

A skipped slot is a leader opportunity that produced no accepted block data. A raw receiver may observe no valid shreds for it. Absence of a LAST_IN_SLOT packet cannot distinguish a skipped slot from local packet loss in real time.

Later cluster state, replay, RPC, or repair context resolves the status. A timeout can close local working state as expired, but it should not assert skipped solely from silence.

This is an important negative-information limit. UDP tells the receiver what arrived. It does not deliver a reliable notification that no valid packet existed.

Local timeouts are policy, not protocol

A trading system may evict incomplete slot state tens or hundreds of milliseconds after its opportunity expires. An archival system may retain the same slot for repair over a much longer horizon.

Neither timeout changes the protocol definition of completion. expired_incomplete means the local policy stopped waiting. It is not a slot-complete or slot-skipped signal.

Use monotonic clocks and active-slot context. Wall-clock adjustments should not reopen or instantly expire state. Bound future-slot packets so an attacker cannot create long-lived timers for arbitrary coordinates.

Completion metrics need multiple frontiers

Record highest_data_index, contiguous_data_frontier, latest_data_complete_index, terminal_index, missing_count_before_terminal, and recovered_count. These values explain why a slot remains open.

First_shred_to_terminal measures production and delivery span. Terminal_to_data_complete measures how long gaps delayed local closure. First_shred_to_first_batch captures useful early decoding. Local_complete_to_confirmed measures the later consensus gap.

One block_latency metric combines network arrival, loss, recovery, serialization, execution, and commitment. Splitting the clocks shows where an optimization can actually help.

Slot completion and execution

Complete ordered entry bytes are input to replay. Transactions execute against parent state. Some transactions fail and record errors while the block can still be valid. Replay checks Proof of History and other ledger rules.

A raw feed often exposes transaction messages before those outcomes exist locally. Strategy logic should treat them as proposed actions, not settled account changes.

After RPC or a local validator reports the executed block, reconcile signatures, statuses, balances, and fork identity. Early observation and later truth can share transaction signatures while carrying different confidence states.

Slot completion and commitment

Confirmed and finalized are consensus commitment concepts. They depend on votes, fork choice, and rooting, not packet presence.

A receiver can have every authenticated data shred for a slot that never confirms. It can also lack local raw packets for a slot that the rest of the cluster confirms. Local availability and network commitment answer different questions.

Data models should express both axes. availability might be none, partial, recoverable, or complete. commitment might be processed, confirmed, finalized, or unknown according to the chosen source. One boolean cannot represent the cross-product.

A safe completion state machine

OPEN accepts sane authenticated members. TERMINAL_KNOWN begins when a valid last-in-slot claim establishes an end index. DATA_COMPLETE begins when every source index through that end exists and all entry batches decode.

CONFLICTED isolates incompatible authenticated claims. EXPIRED_INCOMPLETE records policy eviction without sufficient data. RECONCILED links the proposal to later executed and commitment observations.

Transitions should be monotonic within one block view. A late identical duplicate does not reopen DATA_COMPLETE. A late authenticated conflict can add a parallel view and an alert, but it should not mutate already emitted bytes without an explicit correction event.

Missing terminal and missing middle differ

Two incomplete slots can have the same number of received packets and require different actions. A slot with indexes zero through 179 but no terminal marker has an unknown end. A slot with terminal index 180 and one missing middle index has a known, narrow recovery target.

For the missing middle, the receiver can identify the FEC set, count available rows, run recovery, or request that exact source. For the missing terminal, it cannot know whether production ended at 180, 240, or never produced a valid close. Repair can query peers, but a low-latency parser has no safe index to invent.

Metrics should separate terminal_unknown from gaps_before_terminal. Timeout policy can also differ. A trading path may stop waiting for new entry batches after the slot opportunity passes while retaining known-gap work briefly if parity is close to threshold.

Late terminal arrival can close a slot whose earlier data was already decoded. Record the terminal receive time even when no transaction emission depends on it. That time describes availability and path health, while first-batch time describes actionable latency.

If a terminal marker never arrives but later consensus exposes a canonical block, the raw path was incomplete. Reconciliation should record that delivery outcome rather than retroactively mark the raw assembly complete from RPC data.

Likewise, repair bytes obtained later can create eventual_local_complete without changing the original real-time result. Store first completion time and completion source. A system that repairs every slot minutes later can have perfect archival availability and poor trading-path availability at the same time.

Both measurements belong in operational reports.