diff --git a/EIPS/eip-3540.md b/EIPS/eip-3540.md
index 2e0fd04ef49e44..5fd10b756f6d58 100644
--- a/EIPS/eip-3540.md
+++ b/EIPS/eip-3540.md
@@ -136,8 +136,10 @@ For clarity, the *container* refers to the complete account code, while *code* r
 
 For clarity, the *EOF prefix* together with a version number *n* is denoted as the *EOFn prefix*, e.g. *EOF1 prefix*.
 
-1. If *initcode's container* has EOF1 prefix it must be valid EOF1 code.
-2. If *code's container* has EOF1 prefix it must be valid EOF1 code.
+1. If *initcode's container* has EOF1 prefix it MUST be valid EOF1 code.
+2. If *code's container* has EOF1 prefix it MUST be valid EOF1 code.
+3. If *initcode's container* is valid EOF1 code the resulting *code's container* MUST be valid EOF1 code (i.e. it MUST NOT be empty and MUST NOT produce legacy code).
+4. If `CREATE` or `CREATE2` instruction is executed in an EOF1 code the instruction's *initcode* MUST be valid EOF1 code (i.e. EOF1 contracts MUST NOT produce legacy code).
 
 ## Rationale
 
@@ -167,18 +169,11 @@ minimal set of restrictions related to the contract creation: if *initcode* or *
 container prefix it must be validated. This adds two validation steps in the contract creation,
 any of it failing will result in contract creation failure.
 
-Since *initcode* and *code* are evaluated for EOF1 independently, number of interesting combinations are allowed:
+Moreover, it is not allowed to create legacy contracts from EOF1 ones. And the EOF version of *initcode* must match the EOF version of the produced *code*.
+The rule can be generalized in the future: EOFn contract must only create EOFm contracts, where m ≥ n.
 
-- Create transaction with EOF1 *initcode* can deploy legacy contract,
-- EOF1 contract can execute `CREATE` instruction with legacy *initcode* to create new legacy contract,
-- Legacy contract can execute `CREATE` instruction with EOF1 *initcode* to create new EOF1 contract,
-- Legacy contract can execute `CREATE` instruction with EOF1 *initcode* to create new legacy contract,
-- etc.
-
-To limit the number of exotic bytecode version combinations, additional restrictions are considered, but currently are not part of the specification:
-
-1. The EOF version of *initcode* must much the version of *code*.
-2. An EOF1 contract must not create legacy contracts.
+This guarantees that a cluster of EOF contracts will never spawn new legacy contracts.
+Furthermore, some exotic contract creation combinations are eliminated (e.g. EOF1 contract creating new EOF1 contract with legacy *initcode*).
 
 Finally, create transaction must be allowed to contain legacy *initcode* and deploy legacy *code* because otherwise there is no transition period allowing upgrading transaction signing tools. Deprecating such transactions may be considered in the future.