diff --git a/EIPS/eip-7892.md b/EIPS/eip-7892.md
index 06aab266733032..4b3b7417bc8e0a 100644
--- a/EIPS/eip-7892.md
+++ b/EIPS/eip-7892.md
@@ -8,7 +8,7 @@ status: Last Call
 last-call-deadline: 2025-10-28
 type: Informational
 created: 2025-02-28
-requires: 7840
+requires: 4844, 7840
 ---
 
 ## Abstract
@@ -44,7 +44,11 @@ The key motivations for BPO forks are as follows:
 
 ### Definition
 
-BPO hardforks are defined as protocol upgrades that modify only blob-related parameters through configuration, without requiring any client-side code changes. The new parameters take effect immediately at the specified activation time.
+Once clients implement the enabling changes defined in this EIP, BPO hardforks are protocol upgrades that modify only blob-related parameters through configuration, without requiring additional client-side code changes. The new parameters take effect immediately at the specified activation time.
+
+### Enabling change
+
+This EIP introduces a one-time enabling change across both the execution and consensus layers so that blob-related parameters are sourced from per-fork schedules defined in client configuration. Specifically, execution clients MUST read `target`, `max`, and `baseFeeUpdateFraction` from the active `blobSchedule` entry (as introduced in [EIP-7840](./eip-7840.md)), and consensus clients MUST carry a corresponding `BLOB_SCHEDULE`. After these enabling changes are implemented in clients, subsequent BPO forks become configuration-only and require no additional client-side code changes.
 
 ### Blob schedule configuration
 
@@ -58,7 +62,7 @@ To ensure consistency, when a regular hardfork changes any of these parameters,
 
 ### Execution layer configuration
 
-To facilitate these changes on the execution layer, each fork in the `blobSchedule` object defined in [EIP-7840](./eip-7840.md) is linked to an activation timestamp via a top-level `<fork_name>Time` field, which holds the Unix timestamp of the activation slot as a JSON number. BPO forks SHOULD be named using the convention `bpo<index>`, where `<index>` starts at `1`. Left padding is unnecessary since these labels are not subject to lexicographic sorting. Activation timestamps are required only for forks that occur **after** Prague.
+To facilitate these changes on the execution layer, each fork in the `blobSchedule` object defined in [EIP-7840](./eip-7840.md) is linked to an activation time via a top-level `<fork_name>Time` field, which holds the Unix timestamp of the fork activation as a JSON number. BPO forks SHOULD be named using the convention `bpo<index>`, where `<index>` starts at `1`. Left padding is unnecessary since these labels are not subject to lexicographic sorting. Activation timestamps are required only for forks that occur **after** Prague.
 
 ```json
 {
@@ -105,6 +109,8 @@ We modify the functions `get_base_fee_per_blob_gas` and `calc_excess_blob_gas` d
 In line with how updating `BLOB_BASE_FEE_UPDATE_FRACTION` was handled in [EIP-7691](./eip-7691.md), the functions use the *current* block's blob schedule.
 Moreover, `TARGET_BLOB_GAS_PER_BLOCK` is removed and replaced with `GAS_PER_BLOB * blob_schedule.target`, as it is now redundant. 
 
+This constitutes the enabling change on the execution layer: clients MUST parameterize blob fee computation on the active `BlobSchedule` so that future BPO forks can be performed via configuration only, without further client code changes.
+
 ```python
 class BlobSchedule:
    target: U64
@@ -143,7 +149,7 @@ The parameters and schedules above are purely illustrative. Actual values and sc
 **Requirements:**
 
 - Execution and consensus clients **MUST** share consistent BPO fork schedules.
-- The slot number in the EL's `blobSchedule` **MUST** align with the start of the epoch specified in the consensus layer configuration.
+- The activation timestamp fields in the execution layer configuration **MUST** align with the start time of the epoch specified in the consensus layer configuration.
 - The `max` field in the EL's `blobSchedule` **MUST** equal the `MAX_BLOBS_PER_BLOCK` value in the consensus layer configuration.
 
 ### Modified `compute_fork_digest`