diff --git a/specs/altair/beacon-chain.md b/specs/altair/beacon-chain.md
index a2138103d..438c892c6 100644
--- a/specs/altair/beacon-chain.md
+++ b/specs/altair/beacon-chain.md
@@ -667,7 +667,7 @@ def process_sync_committee_updates(state: BeaconState) -> None:
 
 This helper function is only for initializing the state for pure Altair testnets and tests.
 
-*Note*: The function `initialize_beacon_state_from_eth1` is modified with `ALTAIR_FORK_VERSION` fork version and initial sync committees.
+*Note*: The function `initialize_beacon_state_from_eth1` is modified: (1) using `ALTAIR_FORK_VERSION` as the current fork version, (2) utilizing the Altair `BeaconBlockBody` when constructing the initial `latest_block_header`, and (3) adding initial sync committees.
 
 ```python
 def initialize_beacon_state_from_eth1(eth1_block_hash: Bytes32,
diff --git a/specs/altair/fork.md b/specs/altair/fork.md
index b5dac5b22..be06e183e 100644
--- a/specs/altair/fork.md
+++ b/specs/altair/fork.md
@@ -34,7 +34,7 @@ Warning: this configuration is not definitive.
 
 TBD. Social consensus, along with state conditions such as epoch boundary, finality, deposits, active validator count, etc. may be part of the decision process to trigger the fork. For now we assume the condition will be triggered at epoch `ALTAIR_FORK_EPOCH`.
 
-Note that for the pure Altair testnets, we don't apply `upgrade_to_altair` since it starts with Altair version logic.
+Note that for the pure Altair networks, we don't apply `upgrade_to_altair` since it starts with Altair version logic.
 
 ### Upgrading the state