diff --git a/EIPS/eip-4844.md b/EIPS/eip-4844.md
index 47f3ec1477..f33008e104 100644
--- a/EIPS/eip-4844.md
+++ b/EIPS/eip-4844.md
@@ -273,7 +273,7 @@ def point_evaluation_precompile(input: Bytes) -> Bytes:
     # Quotient kzg: next 48 bytes
     quotient_kzg = input[144:192]
     assert verify_kzg_proof(data_kzg, x, y, quotient_kzg)
-    return Bytes([])
+    return Bytes(U256(FIELD_ELEMENTS_PER_BLOB).to_bytes32() + U256(BLS_MODULUS).to_bytes32())
 ```
 
 ### Gas price of blobs (Simplified version)
@@ -426,14 +426,18 @@ the kzg in the blob and some commitment using whatever proof system the ZK rollu
 They would use a commitment proof of equivalence protocol, using the point evaluation precompile,
 to prove that the kzg (which the protocol ensures points to available data) and the ZK rollup's own commitment refer to the same data.
 
-### Versioned hashes
+### Versioned hashes & precompile return data
 
 We use versioned hashes (rather than kzgs) as references to blobs in the execution layer to ensure forward compatibility with future changes.
 For example, if we need to switch to Merkle trees + STARKs for quantum-safety reasons, then we would add a new version,
-allowing the point verification precompile to work with the new format.
+allowing the point evaluation precompile to work with the new format.
 Rollups would not have to make any EVM-level changes to how they work;
 sequencers would simply have to switch over to using a new transaction type at the appropriate time.
 
+However, the point evaluation happens inside a finite field, and it is only well defined if the field modulus is known. Smart contracts could contain a table mapping the commitment version to a modulus, but this would not allow smart contract to take into account future upgrades to a modulus that is not known yet. By allowing access to the modulus inside the EVM, the smart contract can be built so that it can use future commitments and proofs, without ever needing an upgrade.
+
+In the interest of not adding another precompile, we return the modulus and the polynomial degree directly from the point evaluation precompile. It can then be used by the caller. It is also "free" in that the caller can just ignore this part of the return value without incurring an extra cost -- systems that remain upgradable for the foreseeable future will likely use this route for now.
+
 ### Data gasprice update rule
 
 The data gasprice update rule is intended to approximate the formula `data_gasprice = MIN_DATA_GASPRICE * e**(excess_data_gas / DATA_GASPRICE_UPDATE_FRACTION)`,