diff --git a/EIPS/eip-4844.md b/EIPS/eip-4844.md
index f33aadd1017395..ff3348a4859fd8 100644
--- a/EIPS/eip-4844.md
+++ b/EIPS/eip-4844.md
@@ -31,7 +31,7 @@ However, data sharding will still take a considerable amount of time to finish i
 This EIP provides a stop-gap solution until that point by implementing the _transaction format_ that would be used in sharding,
 but not actually sharding those transactions. Instead, the data from this transaction format is simply part of the beacon chain and is fully downloaded
 by all consensus nodes (but can be deleted after only a relatively short delay).
-Compared to full data sharding, this EIP has a reduced cap on the number of these transactions that can be included, corresponding to a target of ~0.25 MB per block and a limit of ~0.5 MB.
+Compared to full data sharding, this EIP has a reduced cap on the number of these transactions that can be included, corresponding to a target of ~0.375 MB per block and a limit of ~0.75 MB.
 
 ## Specification
 
@@ -45,10 +45,10 @@ Compared to full data sharding, this EIP has a reduced cap on the number of thes
 | `BLOB_COMMITMENT_VERSION_KZG` | `Bytes1(0x01)` |
 | `POINT_EVALUATION_PRECOMPILE_ADDRESS` | `Bytes20(0x14)` |
 | `POINT_EVALUATION_PRECOMPILE_GAS` | `50000` |
-| `MAX_DATA_GAS_PER_BLOCK` | `2**19` |
-| `TARGET_DATA_GAS_PER_BLOCK` | `2**18` |
+| `MAX_DATA_GAS_PER_BLOCK` | `786432` |
+| `TARGET_DATA_GAS_PER_BLOCK` | `393216` |
 | `MIN_DATA_GASPRICE` | `1` |
-| `DATA_GASPRICE_UPDATE_FRACTION` | `2225652` |
+| `DATA_GASPRICE_UPDATE_FRACTION` | `3338477` |
 | `MAX_VERSIONED_HASHES_LIST_SIZE` | `2**24` |
 | `MAX_CALLDATA_SIZE` | `2**24` |
 | `MAX_ACCESS_LIST_SIZE` | `2**24` |
@@ -323,7 +323,7 @@ Instead, those transactions are only announced using `NewPooledTransactionHashes
 ### On the path to sharding
 
 This EIP introduces blob transactions in the same format in which they are expected to exist in the final sharding specification.
-This provides a temporary but significant scaling relief for rollups by allowing them to initially scale to 0.25 MB per slot,
+This provides a temporary but significant scaling relief for rollups by allowing them to initially scale to 0.375 MB per slot,
 with a separate fee market allowing fees to be very low while usage of this system is limited.
 
 The core goal of rollup scaling stopgaps is to provide temporary scaling relief,
@@ -427,9 +427,9 @@ TBD
 
 ## Security Considerations
 
-This EIP increases the storage requirements per Beacon block by a maximum of ~0.5 MB.
-This is 4x larger than the theoretical maximum size of a block today (30M gas / 16 gas per calldata byte = 1.875M bytes), and so it will not greatly increase worst-case bandwidth.
-Post-merge, block times are expected to be static rather than an unpredictable Poisson distribution, giving a guaranteed period of time for large blocks to propagate.
+This EIP increases the bandwidth requirements per beacon block by a maximum of ~0.75 MB.
+This is 40% larger than the theoretical maximum size of a block today (30M gas / 16 gas per calldata byte = 1.875M bytes), and so it will not greatly increase worst-case bandwidth.
+Post-merge, block times are static rather than an unpredictable Poisson distribution, giving a guaranteed period of time for large blocks to propagate.
 
 The _sustained_ load of this EIP is much lower than alternatives that reduce calldata costs, even if the calldata is limited,
 because there is no existing software that stores the blobs indefinitely and there is no expectation that they need to be stored for as long as an execution payload.