address gk's review

specs/protocol/derivation.md

@@ -1293,16 +1293,15 @@ As described in [L1 Retrieval][#l1-retrieval], batcher transactions' types are r
 However, we want to allow deposit transactions and `SystemConfig` update events to get derived even from receipts of
 future transaction types, as long as the receipts can be decoded following a best-effort process:
 
-As long as a future transaction type follows the [EIP-2718][https://eips.ethereum.org/EIPS/eip-2718] specification,
-the type can be decoded as the first byte of an encoded transaction or receipt (excluding legacy transactions, which are
-not _future_ transactions). We can then proceed as follows to get the logs of such a future transaction, or discard the
-transaction's receipt as invalid.
+As long as a future transaction type follows the [EIP-2718][https://eips.ethereum.org/EIPS/eip-2718] specification, the
+type can be decoded from the first byte of the transaction's (or its receipt's) binary encoding. We can then proceed as
+follows to get the logs of such a future transaction, or discard the transaction's receipt as invalid.
 
 - If it's a known transaction type, that is, legacy (first byte of the encoding is in the range `[0xc0, 0xfe]`) or its
 first byte is in the range `[0, 4]` or `0x7e` (_deposited_), then it's not a _future transaction_ and we know how to
 decode the receipt and this process is irrelevant.
-- If a transaction's first byte is in the range `[5, 0x7d]`, it is expected to be a _future_ EIP-2718 transaction, so we
-can proceed to the receipt. Note that we excluded `0x7e` because that's the deposit transaction type, which is known.
+- If a transaction's first byte is in the range `[0x05, 0x7d]`, it is expected to be a _future_ EIP-2718 transaction, so
+we can proceed to the receipt. Note that we excluded `0x7e` because that's the deposit transaction type, which is known.
 - The _future_ receipt encoding's first byte must be the same byte as the transaction encoding's first byte, or it is
 discarded as invalid, because we require it to be an EIP-2718-encoded receipt to continue.
 - The receipt payload is decoded as if it is encoded as `rlp([status, cumulative_transaction_gas_used, logs_bloom,