diff --git a/EIPS/eip-2718.md b/EIPS/eip-2718.md
index 29c287d1..bd86e2ae 100644
--- a/EIPS/eip-2718.md
+++ b/EIPS/eip-2718.md
@@ -14,7 +14,7 @@ requires: 155
 Defines a new transaction type that is an envelope for future transaction types.
 
 ## Abstract
-As of `FORK_BLOCK_NUMBER`, `rlp([TransactionType, Payload])` will be a valid transaction where `TransactionType` is a number identifying the format of the transaction and `payload` is the transaction, whose definition is defined in future EIPs.  The first new transaction type will be a wrapped legacy transaction with the format `rlp([0, rlp([nonce, gasPrice, gasLimit, to, value, data, v, r, s])])`.
+`rlp([TransactionType, Payload])` will become a valid transaction and `rlp([TransactionType, Payload])` will become a valid transaction receipt where `TransactionType` is a number identifying the format of the transaction and `payload` is the transaction/receipt contents, whose definition is defined in future EIPs.  The first new transaction type will be a wrapped legacy transaction with the format `rlp([0, rlp([nonce, gasPrice, gasLimit, to, value, data, v, r, s])])` and a wrapped legacy receipt with the format `rlp([0, rlp([status, cumulativeGasUsed, logsBloom, logs])])`.
 
 ## Motivation
 In the past, when we have wanted to add new transaction types we have had to ensure they were backward compatible with all other transactions, meaning that you could differentiate them based only on the encoded payload, and it was not possible to have a transaction that matched both types.  This was seen in [EIP-155](./eip-155.md) where the new value was bit-packed into one of the encoded fields.  There are multiple proposals in discussion that define new transaction types such as one that allows EOA accounts to execute code directly within their context, one that enables someone besides `msg.sender` to pay for gas, and proposals related to layer 0 multi-sig transactions.  These all need to be defined in a way that is mutually compatible, which quickly becomes burdensome to EIP authors and to clients who now have to follow complex rules for differentiating transaction type.