diff --git a/EIPS/eip-7685.md b/EIPS/eip-7685.md
index 82c2e323f4f6c8..b998ab46b9a896 100644
--- a/EIPS/eip-7685.md
+++ b/EIPS/eip-7685.md
@@ -13,9 +13,9 @@ created: 2024-04-14
 ## Abstract
 
 This proposal defines a general purpose framework for storing contract-triggered
-requests. It extends the execution header and body with a single field each to
-store the request information. This inherently exposes the requests to the
-consensus layer, which can then process each one.
+requests. It extends the execution header with a single field to store the
+request information. Requests are later on exposed to the consensus layer, which
+then processes each one.
 
 ## Motivation
 
@@ -23,60 +23,52 @@ The proliferation of smart contract controlled validators has caused there to be
 a demand for additional EL triggered behaviors. By allowing these systems to
 delegate administrative operations to their governing smart contracts, they can
 avoid intermediaries needing to step in and ensure certain operations occur.
-This creates a safer system for end users.
+This creates a safer system for end users. By abstracting each individual request
+details from the EL, adding new request types is simpler and does not require an
+update on the execution block structure.
 
 ## Specification
 
 ### Execution Layer
 
-#### Request
+#### Requests
 
-A `request` consists of a `request_type` prepended to an opaque byte array
-`request_data`:
+A `requests` object consists of a `request_type` prepended to an opaque byte
+array `request_data`.
 
 ```
-request = request_type ++ request_data
+requests = request_type ++ request_data
 ```
 
-Let `requests` be the list of all `request` objects in the block in ascending
-order by type. For example:
+Each request type will defines its own `requests` object using with its own
+`request_data` format.
 
-```
-[0x00_request_0, 0x01_request_0, 0x01_request_1, 0x02_request_0, ...]
-```
-
-The ordering of requests within a type is to be defined by each request type.
+#### Block Header
 
-#### Block structure
+Extend the header with a new 32 byte value `requests_hash`.
 
-The block body is appended with a list of requests. RLP encoding of the extended
-block body structure is computed as follows:
+The construction looks like:
 
-```python
-block_body_rlp = rlp([
-    field_0,
-    ...,
-    # Latest block body field before `requests`
-    field_n,
-    [request_0, ..., request_k],
-])
+```
+sha256(sha256(requests_0) ++ sha256(requests_1) ++ ...)`
 ```
 
-#### Block Header
-
-Extend the header with a new 32 byte value `requests_hash`:
+Or in pseudocode:
 
 ```python
-def compute_requests_hash(list):
-    return keccak256(rlp.encode([rlp.encode(req) for req in list]))
+def compute_requests_hash(requests):
+    m = sha256()
+    for r in requests:
+        m.update(sha256(r))
+    return m.digest()
 
-block.header.requests_root = compute_requests_hash(block.body.requests)
+block.header.requests_hash = compute_requests_hash(requests)
 ```
 
 ### Consensus Layer
 
-Each proposal may choose how to extend the beacon chain types to include the new
-EL request.
+Each proposal may choose how to extend the beacon chain types to include new EL
+request types.
 
 ## Rationale
 
@@ -110,8 +102,7 @@ The authors' recommendations on source and validity of requests are:
 ### Ordering
 
 The ordering across types is ascending by type. This is to simplify the process
-of verifying that all requests which were committed to in `requests_root` were
-found in the block.
+of verifying that all requests which were committed to in `requests_hash` match.
 
 An alternative could be to order by when the request was generated within the
 block. Since it's expected that many requests will be accumulated at the end of