diff --git a/EIPS/eip-7620.md b/EIPS/eip-7620.md
index 410f4620d86c8..dc378097b3cf1 100644
--- a/EIPS/eip-7620.md
+++ b/EIPS/eip-7620.md
@@ -53,7 +53,7 @@ We introduce two new instructions on the same block number [EIP-3540](./eip-3540
 
 In EOF EVM, new bytecode is delivered by means of creation transactions (with an empty `to`) in the form of an EOF container (`initcontainer`). Such a container may contain arbitrarily deeply nesting subcontainers. The `initcontainer` and its subcontainers are recursively validated according to all the validation rules applicable for the EOF version in question. Next, the 0th code section of the `initcontainer` is executed and may eventually call a `RETURNCONTRACT` instruction, which will refer to a subcontainer to be finally deployed to an address.
 
-EOF creation transactions (ones with an empty `to` and with `data` starting with `EF00` magic) are defined in detail in a separate EIP.
+EOF creation transactions (ones with an empty `to` and with `data` starting with `EF00` magic) are defined in detail in [EIP-7698](./eip-7698.md).
 
 `EOFCREATE` instruction is in turn a replacement of the `CREATE` and `CREATE2` legacy instructions allowing factory contracts to create other contracts. The main difference to the creation transaction is that the `initcontainer` is selected to be one of the subcontainers of the EOF container calling `EOFCREATE`. It is worth noting that no validation is performed at this point, as it has already been done when the factory contract containing `EOFCREATE` was deployed.
 
@@ -70,11 +70,11 @@ Details on each instruction follow in the next sections.
 - deduct `GAS_KECCAK256_WORD * ((initcontainer_size + 31) // 32)` gas (hashing charge)
 - check that current call depth is below `STACK_DEPTH_LIMIT` and that caller balance is enough to transfer `value`
   - in case of failure return 0 on the stack, caller's nonce is not updated and gas for initcode execution is not consumed.
-- caller's memory slice [`input_offset`:`input_size`] is used as calldata
+- caller's memory slice `[input_offset:input_size]` is used as calldata
 - execute the container and deduct gas for execution. The 63/64th rule from [EIP-150](./eip-150.md) applies.
 - increment `sender` account's nonce
 - calculate `new_address` as `keccak256(0xff || sender || salt || keccak256(initcontainer))[12:]`
-- behavior on `accessed_addresses` and address colission is same as `CREATE2` (rules for `CREATE2` from [EIP-684](./eip-684.md) and [EIP-2929](./eip-2929.md) apply to `EOFCREATE`)
+- behavior on `accessed_addresses` and address collision is same as `CREATE2` (rules for `CREATE2` from [EIP-684](./eip-684.md) and [EIP-2929](./eip-2929.md) apply to `EOFCREATE`)
 - an unsuccessful execution of initcode results in pushing `0` onto the stack
     - can populate returndata if execution `REVERT`ed
 - a successful execution ends with initcode executing `RETURNCONTRACT{deploy_container_index}(aux_data_offset, aux_data_size)` instruction (see below). After that:
@@ -175,7 +175,7 @@ Creation transaction, `CREATE` and `CREATE2` cannot have its *code* starting wit
 
 ## Security Considerations
 
-It is the EOF creation transaction (specified in a separate EIP) which needs a detailed review and discussion as that is where external unverified code enters the state. Among others:
+It is the EOF creation transaction (specified in [EIP-7698](./eip-7698.md)) which needs a detailed review and discussion as that is where external unverified code enters the state. Among others:
 
 1. Is its complexity under control, ruling out any DoS attempts
 2. Is it correctly priced and always charged for