diff --git a/specs/altair/p2p-interface.md b/specs/altair/p2p-interface.md
index 85e859191..02a159f7a 100644
--- a/specs/altair/p2p-interface.md
+++ b/specs/altair/p2p-interface.md
@@ -106,9 +106,18 @@ The following validations MUST pass before forwarding the `signed_contribution_a
 
 ```python
 def get_sync_subcommittee_pubkeys(state: BeaconState, subcommittee_index: uint64) -> Sequence[BLSPubkey]:
+    # Committees assigned to `slot` sign for `slot - 1`
+    # This creates the exceptional logic below when transitioning between sync comittee periods
+    next_slot_epoch = compute_epoch_at_slot(state.slot + 1)
+    if compute_sync_committee_period(get_current_epoch(state)) == compute_sync_committee_period(next_slot_epoch):
+        sync_committee = state.current_sync_committee
+    else:
+        sync_committee = state.next_sync_committee
+
+    # Return pubkeys for the subcommittee index
     sync_subcommittee_size = SYNC_COMMITTEE_SIZE // SYNC_COMMITTEE_SUBNET_COUNT
     i = subcommittee_index * sync_subcommittee_size
-    return state.current_sync_committee.pubkeys[i:i + sync_subcommittee_size]
+    return sync_committee.pubkeys[i:i + sync_subcommittee_size]
 ```
 
 - _[IGNORE]_ The contribution's slot is for the current slot, i.e. `contribution.slot == current_slot`.
diff --git a/specs/altair/validator.md b/specs/altair/validator.md
index dbcc73486..3a96adb46 100644
--- a/specs/altair/validator.md
+++ b/specs/altair/validator.md
@@ -143,6 +143,10 @@ A validator determines beacon committee assignments and beacon block proposal du
 To determine sync committee assignments, a validator can run the following function: `is_assigned_to_sync_committee(state, epoch, validator_index)` where `epoch` is an epoch number within the current or next sync committee period.
 This function is a predicate indicating the presence or absence of the validator in the corresponding sync committee for the queried sync committee period.
 
+*Note*: Being assigned to a sync committee for a given `slot` means that the validator produces and broadcasts signatures for `slot - 1` for inclusion in `slot`.
+This means that when assigned to an `epoch` sync committee signatures must be produced and broadcast for slots on range `[compute_start_slot_at_epoch(epoch) - 1, compute_start_slot_at_epoch(epoch) + SLOTS_PER_EPOCH - 1)`
+rather than for the range `[compute_start_slot_at_epoch(epoch), compute_start_slot_at_epoch(epoch) + SLOTS_PER_EPOCH)`.
+
 ```python
 def compute_sync_committee_period(epoch: Epoch) -> uint64:
     return epoch // EPOCHS_PER_SYNC_COMMITTEE_PERIOD
@@ -261,7 +265,7 @@ This process occurs each slot.
 
 ##### Prepare sync committee signature
 
-If a validator is in the current sync committee (i.e. `is_assigned_to_sync_committee()` above returns `True`), then for every slot in the current sync committee period, the validator should prepare a `SyncCommitteeSignature` according to the logic in `get_sync_committee_signature` as soon as they have determined the head block of the current slot.
+If a validator is in the current sync committee (i.e. `is_assigned_to_sync_committee()` above returns `True`), then for every `slot` in the current sync committee period, the validator should prepare a `SyncCommitteeSignature` for the previous slot (`slot - 1`) according to the logic in `get_sync_committee_signature` as soon as they have determined the head block of `slot - 1`.
 
 This logic is triggered upon the same conditions as when producing an attestation.
 Meaning, a sync committee member should produce and broadcast a `SyncCommitteeSignature` either when (a) the validator has received a valid block from the expected block proposer for the current `slot` or (b) one-third of the slot has transpired (`SECONDS_PER_SLOT / 3` seconds after the start of the slot) -- whichever comes first.