diff --git a/EIPS/eip-7877.md b/EIPS/eip-7877.md
index 7666674087d182..66d17bc7ea4ea1 100644
--- a/EIPS/eip-7877.md
+++ b/EIPS/eip-7877.md
@@ -40,13 +40,9 @@ RETURN -> MRETURN (0xf3)
 
 The `MRETURN` opcode is a rename of `RETURN`, whereby sequential bytes in memory are returned. It will operate exactly as it currenty does as of the Cancun hard-fork, and its gas cost will remain the same.
 
-`RRETURN` operates similar to `MRETURN`. It pops two items off the stack, an offset to begin reading bytes from in the
-existing `RETURNDATA` buffer, and a number of bytes to return. Those bytes are used to overwrite the existing `RETURNDATA` buffer and then a return to the previous function is performed.
+`RRETURN` operates similar to `MRETURN`. It pops two items off the stack: `offset` (starting byte index into the current call’s `RETURNDATA` buffer) and `length` (number of bytes to return). It returns the slice `RETURNDATA[offset : offset + length)`. Bounds and error semantics are identical to `RETURNDATACOPY` per [EIP-211](./eip-211.md): if `offset + length > RETURNDATASIZE`, execution fails; zero-length reads at bounds are allowed.
 
-`SRETURN` and `TRETURN` operate similarly, except on storage and transient respectively. It pops two items off the stack,
-a slot number to begin reading from, and a number of sequential slots to return from. Ex: `SRETURN(0x0, 0x40)` returns the 64 bytes of data in slots [0, 1], and `TRETURN(0x0, 0x40)` returns the data in transient storage slots [0, 1]. Since the
-existing `S/TLOAD` opcodes already return 32-bytes, having the opcode return data in chunks of 32-bytes should make implementation by assembly/compiler much simpler.
-If the length parameter is a zero, then only the initial slot value should be returned, so `SRETURN(0x00, 0x00)` returns the value at storage slot 0.
+`SRETURN` and `TRETURN` operate similarly, except on storage and transient storage respectively. Each pops two items off the stack: `slot` (starting storage slot index) and `length` (byte length to return). Bytes are produced by serializing consecutive slots starting at `slot` in ascending order (`slot`, `slot + 1`, …). Each slot is serialized as its 32 raw bytes exactly as if the 256-bit word were written to memory via `MSTORE` (i.e., big-endian 32-byte representation). The returned byte stream is the first `length` bytes of this concatenation. If `length` is not a multiple of 32, the final slot contributes only the first `length % 32` bytes of its 32-byte image. If `length == 0`, zero bytes are returned. Reads of uninitialized storage/transient slots yield 32 zero bytes each.
 
 The cost for these opcodes should be similar to the cost of accessing data now.